El pasado mes de mayo, el US Department of Homenland Security (DHS) publicó el informe «Common Cybersecurity Vulnerabilities in Industrial Control Systems» (pdf) que para todos aquellos que estéis interesados en los sistemas de control industriales (SCI) es un documento imprescindible (también si estáis empezando porque incluye explicaciones detalladas y muy claras sobre cada una de esas vulnerabilidades: en qué consisten, qué riesgos suponen, cómo afectan a este tipo de sistemas, etc.).
Este documento actualiza otro similar que fue publicado en 2009 y en este caso, recoge las conclusiones de los análisis de este tipo de sistemas realizadas durante 2009 y 2010. Las conclusiones se han extraído de tres fuentes: las evaluaciones de sistemas de este tipo, las intervenciones para responder a incidencias y las vulnerabilidades publicadas por el ICS-CERT y las auto-evaluaciones realizadas por los propios propietarios de estos sistemas utilizando la herramienta CSET – Cyber Security Evaluation Tool.
Para no aburrir mucho y no repetirnos respecto del propio informe, nos gustaría simplemente destacar las conclusiones más relevantes.
1. Incidencias y vulnerabilidades por tipo de componente del sistema
En el gráfico siguiente se refleja la distribución porcentual, pero destacaríamos que el 50% se detectan entre el host del sistema (24%), el servicio de supervisión (16%) y la red (10%).
2. Incidencias y vulnerabilidades por niveles
Tomando como referencia el modelo definido por la International Standards Association (ISA) para los niveles de red de los Sistemas de Control y Automatización Industrial (ISA99) el documento define los siguiente niveles:
- Nivel 4 – Sistemas de Ingeniería
- Nivel 3 – Control de Supervisión de Gestión del Sistema
- Nivel 2 – Monitorización y ‘Local Display’
- Nivel 1 – Control de protección local
- Nivel 0 – Equipos en el sistema
Y si analizamos las incidencias y vulnerabilidades, no hay ninguna al nivel de los equipos (¿?) y un ¡53%! son a nivel de los controles de supervisión.
3. Debilidades más habituales
Las debilidades más habituales son las incluidas en la tabla siguiente y catalogadas según si corresponden a la seguridad del producto/software, a su configuración o a la red en la que se implementan.
Una de las aportaciones que nos parece más interesantes es el desarrollo de recomendaciones específicas para los fabricantes, por un lado, y para los operadores, por otro. De esta forma, las recomendaciones para los fabricantes serían:
- Crear una cultura de seguridad
- Mejora de las capacidades de prueba de los SCI
- Creación y prueba de parches
- Rediseño seguro de los protocoles de red
- Incremento de la robustez del código de los analizadores de la red (para los protocolos de red que utilicen)
- Creación de analizadores (parsers) de los protocolos habituales para los IDSs comunes
- Documentar los servicios y canales de comunicación necesarios
- Rediseño de los SCI para la utilización del menor número de canales de comunicación posibles
- Implementar y probar mecanismos de cifrado y de autenticación robusta
- Mejorar la seguridad mediante las evaluaciones de seguridad de software independientes
En relación a los operadores y a los propietarios, las recomendaciones serían las siguientes:
- Restringir los privilegios de usuarios a aquellos que realmente los necesiten
- Cambiar todas las contraseñas por defecto y requerir contraseñas robustas
- Probar y aplicar parches
- Proteger las funciones críticas con capas y zonas de red seguras
- Personalizar las reglas de los IDSs y monitorizar los registros (logs)
- Forzar la seguridad mediante las evaluaciones de seguridad de software independientes
Como habréis podido comprobar, esto no es más que un resumen muy somero; os recomendamos una lectura detallada del documento. No os arrepentiréis.
Puedes segurinos en twitter.com/enplusone