Risk Assessment for Critical Infrastructures

The problem

In the past I did several risk assessments for different type of companies, including some that could be considered as critical infrastructures. For this reason I’ve spent some time reviewing different approaches to perform risk assessments in this kind of infrastructures and I found most of them maintain the classical approach of identify threat and vulnerabilities to estimate the likelihood, using the product of likelihood and impact to get the risk.

I think it’s the right approach for the Known risks, I mean the risks that we can easily think about. However, these approaches have a big weakness since if you can’t imagine a possible treat source or you don’t consider a given vulnerability you won’t take into consideration some important risks.

The cause

And this is because when we analyze the risks of Critical infrastructures, and it could happen in other organizations as well, we should consider some risks that may have an enormous impact but it’s really difficult to think about it since it haven’t happened never before.

Yes, we are talking about the risks defined by the Black Swan Theory, so these risks that are so hard to predict because they are beyond the realm of normal expectations.

Some well-known real examples could be the terrorist attacks of 11/09 in NY or the 11/03 in Madrid, but we can find also some nice technologic examples such the ‘Equation Group’. Who could imagine such kind of advanced malware in our hard disks firmware? I never consider this kind of risks when I did risk assessments because I couldn’t anticipate it, but it’s something that was happening during years!

So it’s clear that if you want to have a heuristic approach to risk assessment, and I really think we must have this kind of approach if we talk of critical infrastructures, we can’t use only the classic risk assessment methodologies because it’s impossible to consider all the possible threats or all the possible risk scenarios. Doesn’t matter how experts we are. Even if you could use all the experts in the world and you get all the time and budget to do your risk assessment you will ever forget some risks because the possible risks are nearly infinite.

The solution (or at least my proposal)

My proposal to solve this problem is to complement any of the classical methodologies (the one that you prefer) with a holistic approach. As we said, the problem is that we can’t imagine all the threats and we can’t define their likelihood so let’s stop to loss time trying to get it. I propose to forget these vectors and perform our risk assessments only based in the impact. Let’s forget about threats and vulnerabilities since we can’t identify all of it and we can’t quantify their probability.

Examples and conclusion

Let’s illustrate the idea with some examples.

Example 1: In a classical risk assessment you will think about how your competitors could try to enter in your network to get your strategic and confidential information. This exercise of ‘think as your enemies’ could be really useful to detect the ‘known risks’ and prepare controls and countermeasures and prioritize their implementation according to the cost-benefit analysis.

But you can go beyond this and on top of this classic approach assume that your network has been already powned and your confidential information has been stolen by your competitors. Don’t waste time thinking how, you already did it in your classical approach. Doesn’t matter how, the fact is that it already happen. So the risk is that your confidential information is in your competitor’s hands and then my proposal is to focus in countermeasures and controls to mitigate the impact. In this example, some controls could be strong encryption, honey-documentation (fake documentation to introduce noise..), etc..

Example 2: Other example can be a nuclear plant. They can use the traditional risk assessment approach to prevent and mitigate the known risks, but for sure, they must establish controls to prevent their industrial system being exploited by a threat that wasn’t taken into consideration in their risk assessment. They need to establish controls to prevent security incidents if their controls to segment their IT network and their industrial network are compromised.

They must consider any unexpected unknown risks and the only way that I can see to do that is to be totally focus in the possible impacts avoiding considering the classic threat-vulnerability approach for that unknown risks.

For sure you will find a lot of additional examples where this ‘impact only’ approach could be useful to complement the traditional risk assessment and try to manage these black-swans in your organization.

I really hope you enjoy this post and I’ll be interested in heard your feedback and thoughts about it.

Plan de Respuesta ante Incidentes de Seguridad & PCI DSS

No hay organización que esté a salvo de sufrir un incidente de seguridad.  Se puede tardar más o menos en padecerlo y en resolverlo, ser más o menos grave, o incluso puedes no enterarte de que estás teniendo un incidente de seguridad (no, tranquilos, no voy a hablar de APTs), pero en algún momento tu organización necesitará reaccionar ante un incidente.

Por ello, toda organización debería contar con un plan de respuesta ante incidentes de seguridad coherente con el impacto potencial que un incidente de seguridad pueda llegar a suponer para su negocio. La ausencia de un plan de respuesta ante incidentes de seguridad puede incrementar considerablemente el tiempo de reacción ante un incidente e incluso puede provocar que la respuesta no sea la adecuada y acabar agravando el impacto del mismo.

El apartado 12.10 de PCI DSS v3 requiere a las organizaciones afectadas por el estándar que implementen un plan de respuesta de este tipo y que estén preparadas para responder de inmediato ante cualquier compromiso en sus sistemas. En este sentido, lo que exije el estándar es que el plan de respuesta incluya en su alcance todos los elementos claves que son necesarios para que la organización responda de manera efectiva en caso de que el compromiso pueda afectar a los datos de titulares de tarjeta. Sin embargo, puestos a desarrollar un plan de respuesta, pienso que es ridículo ceñirse únicamente al ámbito de PCI DSS, ya que con poco más esfuerzo podemos contar con un Plan de Respuesta que alcance a toda la organización y que nos permitirá responder de una manera eficaz y eficiente en caso de que se produzca un incidente.

Veamos pues las pautas a seguir para desarrollar un Plan que nos permita cumplir con el requisito 12.10 de PCI DSS pero que a su vez nos prepare para actuar ante incidentes que afecten a otros ámbitos de nuestra organización.

Preparación

En la fase de preparación deberemos llevar a cabo las siguientes actividades principales:

1- Tener claro el alcance de nuestro Plan. No es lo mismo preparar un Plan ante Incidentes de Seguridad que acotar el alcance únicamente a incidentes de Seguridad de la Información, de seguridad laboral, de seguridad patrimonial, etc... Para cumplir con PCI DSS, el alcance del Plan debe incluir como mínimo, todos los sistemas críticos dentro del ámbito de procesado, almacenaje y transferencia de datos de titulares de tarjeta.

2- Se deben definir y documentar los roles y las responsabilidades de todos los participantes en el Plan de Respuesta ante Incidentes.

3- Aunque numerosas metodologías de gestión de incidentes de seguridad proponen la realización de un análisis de riesgos, incluido el recien publicado marco de ciberseguridad del NIST, yo soy partidario de realizar únicamente un BIA (Business Impact Analisys) que nos permita tener claro qué impacto puede tener un inciente en diferentes ámbitos (legal, financerio, operativo, daños humanos, reputación). Hay diferentes metodologías o aproximaciones para realizar un BIA pero mi recomendación, sobretodo en una primera implantación del Plan, es optar por una que sea suficientemente simple como para tener un BIA realista en poco espacio de tiempo. Es importante señalar que este BIA no debe limitarse a analizar incidentes que dañen la disponibilidad de la información, puesto que no se trata de preparar el Plan de Continuidad de Negocio, si no que se tiene que tener en cuenta también los impactos en cuanto a pérdida de confidencialidad e integridad de la información, así como otros tipos de incidentes no relacionados con la seguridad de la información en caso de que el alcance del Plan sea tal.

4- Definir que escenarios de incidentes se pueden producir partiendo del análisis realizado en el BIA. Es decir, documentar todos aquellos sucesos que puedan causar los principales impactos identificados en el punto anterior. Es recomendable en una primera redacción del Plan no ser excesivamente ambicioso y agrupar e unificar la respuesta ante incidentes de manera que el volumen de escenarios sea manejable. No nos servirá de nada documentar 500 posibles casuísticas si luego vamos a tardar 5 años en redactar los procedimientos de respuesta para cada una de ellas.

5- Documentar los mecanismos establecidos para poder detectar la materialización de los escenarios definidos en la fase anterior. En esta fase es muy probable que se identifiquen deficiencias o imposibilidades en la detección de algunos de los escenarios. En aquellos casos en los que sea viable, se debe preparar un plan de mejora destinado a implantar controles o mejoras que permitan la detección en un tiempo tolerable de dichos escenarios. Al considerar los elementos que pueden disparar el procedimiento de gestión de incidentes, PCI DSS obliga a que como mínimo se consideren los sistemas de monitorización de la organización, como son los IDS/IPS, los firewalls o los sistemas de monitorización de la integridad de los ficheros (FIM).

6- Documentar los criterios de clasificación de los incidentes. Se debe definir una taxonomía y los criterios para clasificar un potencial incidente en su correspondiente categoría. Nuevamente, mi recomendación es que prime la simplicidad no definiendo más de 10 categorías diferentes de incidentes para facilitar su clasificación.

7- Documentar los procedimientos de actuación en caso de materialización de cada tipo de incidente. Los procedimientos deben incluir el detalle de acciones a realizar para:
* Contener el incidente.
* Solventar el incidente.
* Recuperar la operativa normal.
Entre estos procedimientos, se deberán incluir o referenciar los procedimientos del Plan de Continuidad de Negocio que deban ser seguidos en caso de que el incidente afecte a la continuidad del mismo.
Adicionalmente, para cumplir con PCI DSS, se deberán incluir o referenciar los procedimientos de copias de respaldo de los datos y cualquier aspecto o requisito legal a considerar en caso de incidente.

8- Documentar las estrategias y procedimientos de comunicación ante un incidente de seguridad. Es decir, qué se debe decir, a quién se debe decir y cómo se debe decir en cada caso, o en todo caso, definir claramente quien es el responsable de tomar estas decisiones en caso de incidente. El daño a la imagen o la reputación de la compañía puede variar enormemente en función de qué se comunique y cómo se comunique a raíz de un incidente de Seguridad. Para cumplir con PCI DSS estas estrategias deberán incluir, como mínimo, el procedimiento a seguir para comunicar cualquier compromiso de datos de tarjeta a las marcas de tarjeta de pago.

9- El Plan debe ser comunicado y distribuido entre todos los afectados y se debe garantizar su disponibilidad durante un potencial incidente. Es decir, si uno de nuestros escenarios posibles es que por motivo de un DoS se nos caigan nuestros sistemas corporativos, no guardemos únicamente en ellos nuestro Plan de Respuesta ante Incidentes, puesto que no podremos recuperarlo cuando lo necesitemos. Así mismo, si uno de los escenarios contemplados es el no poder acceder a la oficina, tampoco nos serviría de nada tenerlo impreso en nuestro escritorio.

10- Se deben definir y establecer las vías necesarias para que cualquiera pueda notificar a los responsables la ocurrencia de un posible incidente. Estas vías deben ser sencillas, rápidas y contar con diversas alternativas por si una de ellas fallara.

11- El equipo de respuesta ante incidentes debe estar convenientemente entrenado y con una disponibilidad de 24x7 para actuar en caso de que se materialice un incidente para evitar que el retraso en su resolución pueda agravar su impacto y consecuencias. Por otro lado, la correcta procedimentación de la actuación y formación del equipo son vitales para impedir que las actividades realizadas para solventar el incidente puedan degradar o corromper las evidencias necesarias para la adecuada investigación forense del incidente.

12- Se debe planificar un plan de pruebas que permita tener un alto grado de seguridad de que el Plan propuesto funciona correctamente en caso de incidente. Las pruebas, que deberán realizarse como mínimo anualmente, son críticas para garantizar que los procedimientos definidos son realmente eficaces y que todo el personal afectado tiene conocimiento necesario de los mismos. En este sentido, será necesario probar únicamente aquellas tipologías de incidentes que no se hayan dado realmente durante el año, no siendo necesario probar los procedimientos que se hayan usado realmente durante el año, al no ser que se hayan sido mejorados o modificados.

Durante el incidente.

Durante el incidente se deben tener en cuenta los siguientes aspectos:

1- Se deben seguir los procedimientos definidos en el Plan en cada caso.
2- Se debe mantener una bitácora detallada con todos los sucesos y actuaciones llevados a cabo durante el incidente.
3- Se debe priorizar la contención del incidente.
4- Una vez contenido, se debe proceder a su resolución.
5- Finalmente, una vez resuelto, se debe proceder a la recuperación de los sistemas afectados.

Mejora continua:

PCI DSS, y cualquier metodología de gestión de incidentes de seguridad que se precie, exige que se incluya un apartado específico de mejora continua en el plan de respuesta ante incidentes de manera que se analice la actuación y resolución ante cada incidente de seguridad para detectar áreas de mejora en los procesos de detección o respuesta ante los incidentes.

Para ello, se deben analizar los outputs, entendiendo qué ha pasado y por qué ha pasado, para cada uno de los incidentes sufridos así como de las pruebas realizadas y analizar qué mejoras se pueden implementar en el Plan en diversos ámbitos:

* Mejoras en la prevención de los incidentes.
* Mejoras en la detección de los incidentes.
* Mejoras en la contención y resolución de los incidentes.
* Mejoras en la recuperación de los equipos o del negocio.
* Mejoras en el plan de pruebas.
* Mejoras en los escenarios de incidentes definidos.
* Mejoras en la formación del personal.

Por último, también es importante tener en cuenta el plan dentro de la gestión del cambio de la organización, de manera que se actualice el Plan de Respuesta ante Incidentes siempre que algún cambio en los sistemas o la organización deje obsoleto algunos de los procedimientos definidos.



En definitiva, se trata de contar con un Plan documentado, distribuido, probado y conocido que permita actuar de la mejor manera y en el menor tiempo posible ante un incidente de seguridad con el objetivo de minimizar el impacto en diversos ámbitos que dichos incidentes pueden suponer para nuestras organizaciones.

Consejos para un Análisis de Riesgos Útil y Sencillo

Después de analizar, probar y sufrir numerosas metodologías de análisis de riesgos he llegado a una conclusión definitiva; cuanto más sencilla sea la metodología a emplear tanto más útil será el análisis de riesgos, ya que con poco esfuerzo podremos obtener una información interesante y útil para la gestión de la seguridad de nuestra organización.

Para ello, mi propuesta de decálogo es la siguiente:

1. Utiliza siempre un modelo cualitativo y con pocas dimensiones a valorar.
2. Explica bien a los directivos de tu organización qué es el nivel de riesgo residual, es decir, el nivel de riesgo aceptable por la organización y que sean ellos los que lo definan de una manera consciente.
3. Dedica esfuerzos a tener bien definido el mapa de activos de tu organización:

• Define una primera capa con los procesos de negocio y los procesos de soporte.
• Por debajo de estos, define la capa de aplicaciones.
• Por debajo de la capa de aplicaciones, los sistemas y bases de datos.
• Y finalmente, de una manera lo más agregada posible, los dispositivos de comunicaciones.
1. Prepara bien los criterios para valorar los impactos y realiza un BIA valorando por separado los impactos en cuanto a disponibilidad, integridad y confidencialidad. 
2. Entre los criterios para la valoración de impactos, ten en cuenta como mínimo, los impactos legales, financieros y de imagen.
3. Siempre que ea posible, agrupa los activos tecnológicos cuando estos estén en una misma ubicación de red y sean administrados de una manera homogénea. Esto simplificará en gran medida tu análisis de riesgos.
4. Selecciona un catálogo de amenazas lo más sencillo posible. Básate en Magerit o en cualquiera de otro catálogo existente y simplifícalo para adaptarlo a la realidad de tu organización.
5. No te compliques en la definición de controles y contramedidas. Básate en algún estándar como la ISO27002 o la NIST.
6. Prepara un plan de tratamiento de riesgos coherente teniendo en cuenta una estimación de esfuerzos lo más realista posible.
7. Cuando presentes los resultados del análisis de riesgos a la Dirección, traduce los resultados para que sean lo más inteligibles posible.

Finalmente, saca provecho a tu análisis de riesgos. No lo hagas simplemente para cumplir con el trámite exigido por el ENS, la ISO27001 o PCI DSS.

Un análisis de riesgos bien hecho no tiene porqué ser complejo ni necesita dedicar meses para su ejecución. Sin embargo, se le puede sacar mucho partido ya que permite:

• Identificar qué activos son los que están más expuestos.
• Cuales son las amenazas más relevantes para tu organización.
• Qué proyectos o medias de seguridad se deben priorizar.
• Qué proyectos o medias de seguridad no son necesarias y por lo tanto nos podemos ahorrar sus costes y esfuerzos.
• Es una excelente herramienta para justificar la necesidad de presupuesto, especialmente si el riesgo residual ha sido definido por la Dirección.

Evolución de las amenazas en las Infraestructuras Críticas

Hasta no hace tantos años, los sistemas que controlaban las infraestructuras críticas eran sistemas de control aislados o, en todo caso estaban conectados a redes de sistemas de control que permanecían aisladas. Por este motivo, la seguridad lógica nunca ha sido un pilar básico en el diseño del software que incorporan estos sistemas. De hecho, muchos de ellos carecen de cualquier tipo de medida de seguridad lógica, no contando ni siquiera con métodos básicos de control de acceso. También es práctica común el uso de protocolos inseguros como telnet o FTP, la total ausencia de trazas o logs, y el uso de sistemas operativos sin parchear u obsoletos como Windows NT, Windows 98 o en algunos casos especialmente preocupantes, incluso Windows 95…

Sin embargo, estas redes que antes estaban totalmente aisladas, se han ido conectando progresivamente a redes de administración y redes de usuario, tanto para alimentar con datos adquiridos sistemas ubicados en estas nuevas redes, como para facilitar la monitorización y administración remota de los sistemas de control. Y obviamente, estas nuevas redes están conectadas con Internet. Esta interconexión de redes provoca que los sistemas industriales que controlan algunas infraestructuras críticas sean mucho más vulnerables ya que potencialmente pasan a ser accesibles desde cualquier PC del mundo que cuente con conexión a internet.

Por otro lado, el escenario mundial en el que nos encontramos actualmente también ha sufrido una gran evolución desde el final del siglo XX. Los ataques deliberados desde internet ya no proceden de tecnólogos adolescentes con ganas de demostrar su habilidad. Actualmente, los atacantes pueden ser tan variados como naciones rivales, mafias o grupos terroristas. Y es que a pesar de que la motivación para perpetrar un “ciberataque” suele ser económica, también nos podemos encontrar con móviles políticos o sociales, por lo que la amenaza terrorista ha de ser tenida especialmente en cuenta en la seguridad de las infraestructuras críticas. Las amenazas están creciendo exponencialmente en los últimos años.

Así mismo, a nadie se le escapa que vivimos en una sociedad cada día más dependiente de la tecnología, pues existen cada vez más servicios esenciales que presentan una fuerte dependencia de sistemas de control digitales para su correcto funcionamiento. Por ello, el impacto potencial que un incidente pueda tener en estos sistemas es cada vez mayor, y es totalmente previsible que esta tendencia se acentúe en los próximos años.

De hecho, existen numerosos ejemplos públicamente conocidos de incidentes de seguridad ocurridos en infraestructuras críticas. Por poner algunos ejemplos concretos:

• EEUU (Agosto de 2003): El gusano “Slammer” infecta una red informática de una central nuclear. Como consecuencia queda desactivado durante cinco horas un sistema encargado de monitorizar que la planta estaba operando bajo condiciones de seguridad.
• EEUU (Diciembre de 2005): La central hidroeléctrica de Taum Sauk sufrió un fallo durante el proceso rutinario nocturno de llenado del embalse. El proceso de llenado no paró cuando se había acumulado ya el agua suficiente, sobrepasándose incluso la capacidad máxima de la presa. El incidente se debió a incongruencias entre mediciones que se transmitían por medio de radio enlaces.
• Polonia (Enero de 2008): Un adolescente polaco de catorce años de edad consigue realizar a voluntad el cambio de agujas en el sistema de tranvía de la ciudad, con la elaboración de un simple mando a distancia casero. Como consecuencia cuatro tranvías descarrilaron y doce personas resultaron heridas.
• EEUU (Marzo de 2008): En una central nuclear, se produce una actualización de un servidor que era utilizado para la monitorización de datos químicos y de diagnóstico asociados con uno de los sistemas de control primarios de la planta. Tras la instalación de la actualización, el ordenador fue reiniciado, lo que derivó en falta de información de monitorización, que a su vez fue malinterpretada por los sistemas de seguridad de la planta, que dispararon un apagado de emergencia de la misma.
• Global (2010): Aparece Stuxnet, el primer malware diseñado específicamente para infectar sistemas industriales. Es un software diseñado para atacar un modelo concreto de Siemens que utiliza 4 vulnerabilidades de tipo “Zero day” inéditas hasta la fecha. Además, utiliza certificados digitales robados para legitimar su contenido malicioso. La complejidad de su diseño pone de manifiesto que se tuvieron que invertir vastos recursos en su desarrollo. Adicionalmente, se especula con que su objetivo pudiera ser el sabotaje del programa nuclear iraní.
• EEUU (Febrero 2011): McAfee detecta una serie de ataques con origen en China dirigidos a los sistemas de varias compañías energéticas de EEUU a los que bautiza como “night dragon”. Estos ataques se basan en técnicas, herramientas y vulnerabilidades conocidas con objeto de obtener información altamente sensible de las organizaciones atacadas, como documentos financieros, información sobre exploraciones de nuevos yacimientos y negociaciones confidenciales entre directivos.
• Global (Octubre 2011): Symantec detecta un nuevo software que está aprovechando vulnerabilidades “Zero day” de Windows con objeto de recopilar información de los sistemas infectados. El malware es bautizado como “duqu” y comparte partes de código con Stuxnet. Como Stuxnet, también utiliza certificados robados para legitimar su contenido y se auto-elimina en los sistemas 36 días después de la infección. Se especula que el objetivo de este nuevo malware es obtener información suficiente para perpetrar un nuevo ataque a infraestructuras críticas siguiendo el modelo de Stuxnet.

Así pues, podemos constatar que tanto las vulnerabilidades como las amenazas y el impacto aumentan, por lo que por definición, el riesgo lo hace también. Como respuesta a esta nueva realidad, el legislativo español ha aprobado el Real Decreto 704/2011, de 20 de mayo, por el que se aprueba el Reglamento de protección de las infraestructuras críticas. Este RD establece el Reglamento que desarrolla la Ley 8/2011, por la que se establecieron las medidas para la protección de infraestructuras críticas y que fue aprobada tan sólo un mes antes, en abril de 2011. El principal objetivo de esta nueva Ley es preparar a las Administraciones Públicas para prevenir y reaccionar de manera óptima ante la materialización de amenazas que puedan afectar a las infraestructuras críticas.

En esta misma Ley, se definen las Infraestructura Críticas como las instalaciones, redes, sistemas y equipos físicos o tecnologías de la información cuyo funcionamiento es indispensable y no permite soluciones alternativas, por lo que su perturbación o destrucción tendría un grave impacto sobre los servicios esenciales. A su vez, define como servicios esenciales aquellos necesarios para el mantenimiento de las funciones sociales básicas, la salud, la seguridad, el bienestar social y económico de los ciudadanos, o el eficaz funcionamiento de las Instituciones del Estado y las Administraciones Públicas.

Uno de los requerimientos que la legislación establece para los operadores de Infraestructuras Críticas, es la realización de un análisis de riesgos que garantice la continuidad de los servicios proporcionados por dicho operador y en la que se recojan los criterios de aplicación de las diferentes medidas de seguridad que se implanten para hacer frente a las amenazas tanto físicas como lógicas identificadas sobre cada una de las tipologías de sus activos. Por lo tanto, es necesario que la metodología de análisis de riesgos aborde de una manera unificada, coherente y global todas las amenazas a las que esté sujeta la infraestructura, con independencia de que su origen pueda ser físico o digital. Otro aspecto relevante a señalar, es la necesidad de que la metodología utilizada tenga una consideración especial para con los riesgos que afecten a la disponibilidad de los servicios, primando dicha disponibilidad sobre la confidencialidad y la integridad de la información.

Otro aspecto de vital importancia para mejorar la seguridad de nuestras Infraestructuras Críticas, pasa por establecer arquitecturas de red seguras, siguiendo el modelo que los americanos han llamado “defensa en profundidad” y que consiste en definir diferentes segmentos de red en los que se agrupan los activos digitales en función de su criticidad. De esta manera, se deben garantizar unos mínimos controles de seguridad a cumplir en cada uno de los niveles definidos de acorde a su criticidad, así como controlar adecuadamente los flujos y protocolos de información que se permiten entre los diversos niveles definidos. Por ejemplo, se deberían segmentar los sistemas de control de las redes de administración, estas a su vez de las redes de usuario, de las DMZ, y de las redes externas no confiables, ya sean de proveedores, socios o Internet. Esta adecuada segregación de redes nos permitirá establecer unos controles de seguridad mínimos con objeto de garantizar la seguridad de los sistemas críticos que soporten las infraestructuras críticas.

Adicionalmente, opino que la figura del auditor externo deberá tomar un papel de especial relevancia en las futuras estrategias de protección de las infraestructuras críticas, como garante de que los operadores están alcanzando y manteniendo un adecuado nivel de seguridad en sus infraestructuras.

Por lo tanto, ha llegado la hora de que los operadores de infraestructuras críticas prioricen la seguridad en sus hojas de ruta, ya que además del crecimiento del riesgo, ahora también se ven sometidos a nuevas presiones legislativas a las que deben dar respuesta de una manera eficiente y en las que será especialmente relevante la coordinación con las administraciones públicas y las Fuerzas y Cuerpos de Seguridad del Estado.

Ciber granitos de arena

Cuando oímos hablar de Ciberseguridad en infraestructuras o servicios críticos, es frecuente pensar que se trata de una materia muy compleja y totalmente ajena a nosotros. Sin embargo, esto no se totalmente cierto. Obviamente, se trata de una disciplina compleja debido al continuo avance de las tecnologías de la información, así como al efecto globalizador y “anonimizador” que supone Internet. Pero esto no quiere decir que nos sea ajena. Todo lo contrario, como veremos a continuación.

En la actualidad la gran mayoría de servicios que utilizamos día a día requieren directa o indirectamente de los sistemas de información. La emisora de radio que nos despierta por la mañana, la empresa distribuidora que lleva nuestra marca de café preferida al supermercado de nuestro barrio, la empresa municipal que gestiona los semáforos o el sistema de transporte público de nuestra ciudad, o las grandes generadoras y distribuidoras eléctricas que producen y transportan la energía que necesitamos en nuestra casa y en nuestra oficina. Hoy día no es posible funcionar sin hacer un uso intensivo de sistemas de información.

Por lo tanto, al tratarse de servicios que dependen de los sistemas de información para su correcto funcionamiento, son servicios que tienen un cierto nivel de riesgo de verse afectados por un ciberataque. Riesgo que en caso de materializarse puede afectar directamente a nuestro día a día al quedarnos sin radio, suministros alimentarios o energía, entre otros muchos servicios que pueden verse afectados por un ciberataque. 

 Así pues, como vemos, la Ciberseguridad no nos es tan ajena como podríamos pensar. Más aún, todos tenemos parte de responsabilidad en mantener y mejorar la Ciberseguridad de nuestro país. Y no me refiero tan sólo a exigir a las autoridades y organizaciones que inviertan los recursos suficientes para proteger los servicios que nos prestan, sino también a cuidar la seguridad de nuestros propios sistemas de información.

¿Y qué tendrán que ver nuestros ordenadores, tablets o Smartphones con la seguridad de las Infraestructuras y los servicios críticos? Pues más de lo que en un primer momento podríamos imaginar.

Una de las principales amenazas que afectan a los sistemas de información de las organizaciones, son los ataques distribuidos de Denegación de Servicio (DDoS en inglés). Este tipo de ataques consisten en inundar los equipos de la organización objetivo del ataque con tal cantidad de peticiones que no sean capaces de procesarlas y acaben bloqueándose. Por ejemplo, imaginemos la página web de un banco en la que se ofrecen servicios de banca on-line y que está preparada para dar servicio hasta a 100.000 usuarios concurrentes. Si un atacante consigue que se realicen peticiones por parte de, por ejemplo, 10 millones de usuarios a un mismo tiempo, sin duda la página web del banco no será capaz de procesar todas las peticiones y acabará bloqueándose.

Sin embargo, un atacante no se comprará 10 millones de ordenadores para perpetrar este tipo de ataque, si no que utilizará una botnet, o lo que es lo mismo, una red de ordenadores ‘zombies’. Este tipo de redes, se componen de ordenadores personales que han sido infectados por un programa malicioso y que pueden ser utilizados para, entre otras funciones, colaborar en este tipo de ataques sin que el propietario de la máquina sea consciente de ello.

Por tanto, cuando tenemos nuestro ordenador de casa infectado, podemos estar siendo cómplices involuntarios de ciberataques u otros tipos de delitos telemáticos.

Así pues, todos podemos colaborar en aumentar la seguridad de los servicios e infraestructuras críticas de una manera sencilla, tomando una serie de medidas de seguridad básicas en nuestros propios ordenadores para evitar que pasen a formar parte de una de estas redes zombis. A continuación, enumeraremos algunas de estas medidas sencillas que podemos adoptar para mejorar la seguridad de nuestros equipos:

1. Mantén siempre tu sistema operativo actualizado.
2. Mantén siempre tu navegador web actualizado.
3. Instala y mantén actualizado un programa antivirus en tu equipo.
4. Evita acceder a enlaces o páginas no confiables.
5. Nunca descargues ni ejecutes archivos desde páginas no confiables.
6. No descargues ni abras adjuntos sospechosos en correos electrónicos.
7. Evita conectar tus lápices USB en ordenadores no confiables.
8. Toma, al menos, las mismas precauciones en la red que tomarías en el mundo real.
9. Usa tu sentido común también en Internet.
10. No dejes de visitar blogs relacionados con la ciberseguridad :)