La Voz de la Industria The Voice of the Industry

Por primera vez, este año nos hemos reunido para discutir uno de los temas más candentes en la actualidad, la revelación de vulnerabilidades en los sistemas de automatización industrial. Cada vez se suman más sectores (Distribución, Transporte, Aguas, entre otros) a la Voz de la Industria.

ENCUESTA:

Se presentaron las principales conclusiones del S4, SCADA Security Symposium que se celebró en Miami del 14 a 17 de Enero, 2014. Fue especialmente interesante la intervención del investigador y descubridor de Stuxnet,  así como la variedad de participaciones, desde el usuario final (caso de una empresa minera), la experiencia de una empresa más pequeña en la utilización de soluciones de código abierto, así como la importancia  de proteger el desarrollo de aplicaciones industriales mediante un código seguro, que contemple incluso las desarrolladas con código abierto.

Otros hechos significativos fueron los nuevos requisitos del Gobierno de Estados Unidos para máquinas Proxy, así como la presentación del proyecto Robus, según el cual se analizaron las vulnerabilidades de la implementación del protocolo industrial DNP3, y solo dos implementaciones resultaron no vulnerables.

Las conclusiones por tanto del evento S4 fueron:

1. Aproximaciones de TI a los entornos industriales, con especial atención a las tareas de virtualización y monitorización.
2. Adaptación y desarrollos específicos.
3. Solventar los puntos más críticos y establecer prioridades.
4. Implementación de protocolos industriales.
5. Discusión sobre la conveniencia o no de publicación de vulnerabilidades.

Pedro Pablo Pérez, hizo una interesante presentación de los servicios de Vigilancia Digital 24×7 de Telefónica y la situación actual de los Centros de Datos. A los asistentes les hizo ser conscientes de que los «Happy Days» en términos de seguridad terminaron cuando estos se abrieron a otro, llegando al concepto de «Endless Data Centers», es decir, centros de datos sin fronteras determinadas y que dan cobertura a sus empleados, clientes y muchas veces proveedores.

Uno de los aspectos más inquietantes a tener en cuenta es el de los «Insiders», es decir, personas internas en la organización que por una y otra razón deciden atacarla, bien causando situaciones de pérdida de nivel de servicio, bien provocando fugas de información corporativa.

Con este panorama, Telefónica refuerza su estrategia de seguridad comprando tanto empresas especializadas como contratando expertos en este tema para estar preparados para lo que parece la «tormenta perfecta» respecto a Ciber Seguridad:

·      Hacer lo mismo con menos recursos.

·      Cumplir con los aspectos obligatorios y legislativos.

Telefónica ha establecido una serie de laboratorios en los que poder realizar tareas de prevención, detección y respuesta.

Elyoenai Egozcue y Daniel Herreras presentaron la aproximación de S21Sec en la identificación de vulnerabilidades sin perder de vista el contexto en el que este actúa. Por lo tanto, consideran fundamental tener en cuenta las vulnerabilidades de diseño, desarrollo y configuración.

En los tipos de vulnerabilidades que S21 Sec analiza habitualmente se tiene en cuenta las vulnerabilidades de red, de plataforma y de procedimiento, elemento que no se debe descuidar.

Explicaron que las vulnerabilidades de red más habituales localizadas son: falta de control sobre el flujo de información, configuración defectuosa de la red, mala definición de su perímetro así como uso de protocolos inseguros.

Marc Sarrias de Palo Alto Networks presentó los retos que se deben superar en una gestión de seguridad de red en entornos industriales y como la tecnología de Palo Alto Networks puede ayudar  a lograr este fin.

Los retos más comunes, explicaba Marc Sarrias, han sido: La convergencia de los sistemas IT/OT,  la necesidad de segmentación de la red y la problemática de generación de información. También identificaba que en estos entornos hay igualmente varios problemas relacionados con la identificación del usuario, tales como: la utilización de usuarios genéricos, la integración de los sistemas en diversos repositorios, la falta de información sobre usos y privilegios, así como falta de trazabilidad.

Jorge Hormigos de Trend Micro comenzó su presentación describiendo algunos de los ataques más recientes,como por ejemplo un ataque a una petroquímica en 2013 que la dejó ocho horas sin servicio. Además según los datos de los CERT’s/ICS de Estados Unidos, los incidentes se han disparado desde 2010 (41 incidente reportado) a 214 en 2013.

Para proteger adecuadamente  los entornos industriales hay que tener en cuenta sus características, tales como la diversidad de tecnologías a las que hacer frente y el retardo en publicación de vulnerabilidades.

Trend Micro aporta una serie de soluciones para protección de entornos industriales tales como: Deep Security, Safe Lock, Portable Security, Deep Discovery y USB Security

La jornada concluyo con la Mesa Debate que tradicionalmente cierra los eventos de «La Voz de la Industria», en esta ocasión para debatir sobre la publicación de las vulnerabilidades de los sistemas industriales, y donde se contó con la apreciación de los fabricantes de soluciones, como Siemens,  representada por Juan Carlos Pozas y Logitek, representada por Fernando Sevillano , asi como del investigador de Ciberseguridad, Rubén Santamarta de IOActive  y la aportación de Samuel Linares, Director Centro.

El debate se abrió con el resultado a la pregunta que se planteaba en el proceso de registro:

¿Qué piensa de la publicación de vulnerabilidades?

Los asistentes respondieron con las siguientes proporciones:

·       52% consideraron conveniente una revelación parcial

·       45% consideraron conveniente una revelación completa

·       3% consideran que no se deben publicar en absoluto

A partir de estos datos se plantearon las siguientes preguntas:

¿Como deben publicarse las vulnerabilidades?

Juan Carlos Pozas (Siemenes): De acuerdo con que se publiquen de manera controlada via newsletters o alerts ya que los clientes buscan una relación frente a un evento determinado.

Fernando Sevillano (Logitek): Es partidario de «revelar con equilibrio». En entornos TI es muy habitual publicar las vulnerabilidades  y estas afectan habitualmente tanto al fabricante como al usuario. Además, publicar y estudiar como se han resuelto sirve para crear metodología.

Rubén Santamarta (IOACTIVE): Considera que hay una diferencia entre la «publicación ética» y la «publicación real».  El proceso reglamentario es contactar con el fabricante vía CERT, aunque no siempre es así porque el fabricante no responde. Por otro lado, los investigadores necesitan publicar su trabajo para seguir siendo valorados como tales.

Samuel Linares (CCI):  Si está de acuerdo en la obligatoriedad de publicación de incidentes, contando con el CERT como mediador, y con especial énfasis en las instalaciones críticas. Samuel además propone hacer pública la vulnerabilidad pasado un plazo prudencial en el que el fabricante haya podido reaccionar. Es muy importante el diseño de un proceso claro de publicación.

¿Debe haber responsabilidad legal una vez que se hayan publicado las vulnerabilidades?

Juan Carlos Pozas (Siemens): Hay una responsabilidad sobre la vida útil de los equipos que hay que salvaguardar. Además, las vulnerabilidades tienen mucho impacto en la reputación del fabricante por lo que el mercado se autoregula. Además, si hay una responsabilidad ligada a las funcionalidades del dispositivo, ¿no se consideraría fraude no publicarlas?

Fernando Sevillano (Logitek): Depende de la naturaleza del incidente y del equipo.  Si se ha descubierto la vulnerabilidad de un fabricante y no realiza ninguna acción para remediarlo, esto afecta negativamente a su negocio.

Rubén Santamarta (IOACTIVE):  Ya existe la manera de establlecer esta responsabilidad. Esta depende de la criticidad de los mismos.

Samuel Linares (CCI):  Hay que diferenciar entre el proceso sancionador y la responsabilidad implícita.  Al igual que otros productos en el mercado, como por ejemplo las piezas de un coche, este debe cubrir una serie de especificaciones asi como el proceso necesario para su sustitución.

¿Cómo Deben Publicarse la Vulnerabilidades?

Juan Carlos Pozas (Siemens):  El sistema afectado es comprometido y se trata de analizar y saber sus efectos, teniendo que identificar los puntos más críticos. Hay una falta de madurez en el proceso actual de publicación. Hay que llegar a un nivel mínimo de compromiso entre la vulnerabilidad y su solución.

Fernando Sevillano (Logitek):  Hay que priorizar realizando un análisis cuantitativo del riesgo, asi como una concienciación contínua que es la que puede ayudar a crear una cultura de protección. Es importante asi mismo priorizar respecto tanto a los efectos como a las acciones.

Samuel Linares (CCI):  Deben publicarse teniendo en cuenta las organizaciones industriales, los estados y los fabricantes. Se deben financiar mediante las tres partes y concienciar a la ciudadanía.

Rubén Santamarta (IOACTIVE):    Se debe publicar a los afectados teniendo en cuenta los distintos entornos. Además, al ser de interés público la protección de infraestructuras críticas, los propios Estados deben contribuir a su publicación. La ciberseguridad requiere mucho más esfuerzo.

Juan Carlos Pozas (Siemens): Los fabricantes somos los primeros interesados en someter el producto a todos los criterios y evaluaciones

Participación del Público: ¿Cuál es el papel del usuario frente a la obligatoriedad de una auditoria externa?

Fernando Sevillano (Logitek): Se están haciendo algunas cosas para que de la misma manera que hay unas ciertas exigencias para el usuario las haya igualmente para el fabricante. En las fábricas de software  se están utilizando metodologías seguras de desarrollo, incorporando técnicas que reduzcan las vulnerabilidades.  Sin embargo, todavía no existe (y es necesaria) una necesidad de certificación.

Rubén Santamarta:  Hay ya experiencias reales pero es necesario mejorar los protocolos industriales y mantener al atacante alejado de la red de control. Una vez que el atacante llega a esta red de control lo único que se puede hacer es protegerse.

Samuel Linares (CCI):  Ante la evidencia de los ataques que se están realizando no parecen servir de mucho los análisis de riesgos. El verdadero problema está en las «capas 8 y 9» del modelo, es decir en la de los administradores y la lta dirección.  El problema real son las personas y el uso que hacen de los sistemas. La solución pasa por el conocimiento, formación y procedimiento.