Vulnerabilidad de los Sistemas de Control

ISA Sección Española
Vulnerabilidad de sistemas de control
Estándares
Certificaciones
Formación
Publicaciones
Conferencias
Madrid y Cartagena
Reunión Técnica
“Vulnerabilidad de los Sistemas de Control
a ataques informáticos”
6
Participantes
Ponente:
•
Dr. Ingº Héctor D. Puyosa Piña
Director de Seguridad, Higiene y Medio Ambiente
SABIC Innovative Plastics - España
Mesa / Coloquio:
- Ponentes
7
Agenda
Parte I
-Vulnerabilidad de los sistemas de control a ataques informáticos
- Buenas prácticas de seguridad informática y su uso en sistemas de control
- Ejemplos de incidentes de seguridad
- Implantación de mejoras en la seguridad de los sistemas de control
Parte II
- Mesa redonda
8
Referencias
Esta presentación está basada en extractos y lecturas de los siguientes documentos:
•Borradores del Grupo de Trabajo ISA SP99 “Manufacturing and Control Systems Security”
• DRAFT dISA-99.00.01, Part 1: Concepts, Models and Terminology, Oct 2005
• DRAFT dISA-99.00.01, Part 2: Establishing a Manufacturing and ControlSystem Security Program, Sep 2005
•Reportes Técnicos de SA SP99 Standard Development Committee “Security Technologies for Manufacturing and Control Systems”
• ISA-TR99.00.01-2004 Reporte técnico aprobado 11-marzo-2004
• ISA-TR99.00.01-2007 Reporte técnico aprobado 29-octubre-2007
•“Get safe: Prepare for security intrusion”. D. Harrold, Control Engineering Magazine, March 2003.
•“U.S. Chemical Sector cyber-security strategy”, The Chemical Sector Cyber-Security Information sharing Forum, June 2002.
•“21 steps to improve cyber security of SCADA networks”, U.S.A. Department of Energy.
•“Site Security Guideline for the U.S. Chemical Industry”, The American Chemistry Council, the Synthetic Organic Chemical Manufacturers
Association, and The Chlorine Institute, Inc, October 2001.
•ISA Security Session October 2002 (documento públicos de referencia del comité SP-99):
• “Why IT Security doesn’t work on the plant floor”, E. Byres, British Columbia Institute of Technology, October 2002.
• “Electronic Intrusion on your control system”, B. Webb (Power Engineers) and J. Weiss (Kema Consulting), October 2002.
• “Process Control Network Security”, T. Good, DuPont, October 2002.
• “Control System Cyber-Security Technical Status and Overview”, J. Weiss, Kema Consulting, October 2002.
• “ISA SP-99 Introduction: Manufacturing and System Security Standard”, B. Singers, ISA Standards, October 2002.
•Oman, P., E.O. Schweitzer, and D. Frinke. 2006 . Concerns About Intrusions into Remotely Accessible Substation Controllers and SCADA
Systems, 2000.
9
Introducción
•
•
•
La seguridad de la información y del control de los procesos de
producción es una parte integral de la seguridad de la empresas
En la medida en que los procesos están más automatizados y
existe una mayor integración de los sistemas de información de las
plantas y las redes corporativas, la seguridad de la información es
aún más importante.
La tendencia es incrementar integración y conectividad de los
sistemas, utilizar sistemas operativos y arquitecturas abiertas,
protocolos de comunicación estandarizados y soluciones
computacionales modulares.
El
El riesgo
riesgo es
es
¡¡real!!
¡¡real!!
La vulnerabilidad de los sistemas es un riesgo real
10
Objetivos
•
Comunicar la vulnerabilidad de los sistemas de control a ataques
informáticos.
•
Crear la necesidad de que se trabaje para atajar esos riesgos.
•
Informar de medidas que se pueden implantar para disminuir la
probabilidad de sufrir un ataque informático.
•
Compartir buenas prácticas identificadas por ISA SP99 y otros en
este tema
11
Escenario actual de los Sistemas de Control
Pasado
Actual/Tendencias
Sistema Operativo:
Propietarios
Abiertos
Comunicación de datos
Propietarios
Protocolos estándar
Flujo de Información:
Segmentados
Integrados
Soluciones HW/SW :
Monolíticos
Modulares
Arquitecturas:
Cerrados
Abiertos
Más Abiertos = ¡¡Más exposición a riesgos !!
Es necesaria una estrategia para mitigar los riesgos
12
Vulnerabilidad de los Sistemas de Control
• Requieren una velocidad o frecuencia de respuesta que descarta el uso
de técnicas tradicionales en informática, como encriptado de bloques.
• No fueron diseñados pensando en la seguridad informática
• El requisito de fácil de usar para los operadores impide el uso de
passwords más seguros.
• La necesidad de verificaciones rigurosas de todos los cambios dificulta
la actualización periódica de parches de seguridad en los sistemas
operativos.
• Una vez que se rompe la protección de sus cortafuegos la seguridad es
sencillo comprometer su correcta operación en sistemas abiertos.
Las técnicas de seguridad informática no son siempre apropiadas
13
Vulnerabilidad de los Sistemas de Control
•
•
•
•
•
•
•
•
Los sistemas se diseñaron asumiendo que todos los usuarios son de
de
confianza
Los procesadores de control fueron diseñados para maximizar su
rendimiento y no su seguridad.
Los datos son casi siempre texto sin codificar
Protocolos son abiertos con mínima seguridad
Hay analizadores de protocolos disponibles en Internet
Los parches de seguridad no se instalan inmediatamente
Redes inalámbricas pueden ser un problema
No hay dudas de que un sistema de control puede ser pirateado sino de
cuando ocurrirá ese acceso no deseado.
Existe la tecnología para reducir la vulnerabilidad
14
Buenas Prácticas de Seguridad
• Hay una mezcla de dos culturas diferentes:
• Tecnología de la Información (TI)
• Control Industrial
• Existen al menos cinco razones por las que no se recomienda aplicar sin
una revisión previa las buenas prácticas de seguridad de la información en
TI:
• Requerimientos diferentes del rendimiento
• Requerimientos diferente de la fiabilidad
• Sistemas operativos y aplicaciones “inusuales”
• Diferencias en los objetivos de gestión del riesgo (entrega vs. seguridad)
• Las arquitecturas de seguridad son diferentes
Necesario el trabajo colaborativo de esas dos culturas
15
Diferencias Tecnologías de la Información – Control Industrial
•Requerimientos diferentes del rendimiento
Es necesario entender el impacto en rendimiento antes de aplica la
tecnología de seguridad informática.
Ejemplo: Un fabricante de Sistemas de Control demostró que el uso
de un bloque de encriptación tiene un impacto serio en el
rendimiento de polling de los SCADA.
•
Tecnología de la Información
Control Industrial
No es tiempo real
Tiempo real
Respuesta debe ser fiable
Tiempo de respuesta es crítico
Demanda una tasa alta de datos
Tasa modesta de datos es aceptable
Grandes retrasos se aceptan
Grandes retrasos son un problema
Extracto de
“Why IT Security doesn’t work on the plant floor”,
E. Byres, British Columbia Institute of Technology, October 2002.
16
Diferencias Tecnologías de la Información – Control Industrial
• Requerimientos diferentes de fiabilidad
Es necesario entender el impacto en fiabilidad antes aplicar la
tecnología de seguridad informática.
Ejemplo: Algunos sistemas de seguridad requieren intervención
humana antes de restablecer la reconexión después de un fallo
•
Tecnología de la Información
Control Industrial
Operación programada
Operación continua 24x7x365
Fallos ocasionales tolerados
Apagones son intolerables
Beta test en campo son aceptables
Pruebas Minuciosa son requeridas
Extracto de
“Why IT Security doesn’t work on the plant floor”,
E. Byres, British Columbia Institute of Technology, October 2002.
17
Diferencias Tecnologías de la Información – Control Industrial
• Sistemas operativos y aplicaciones “inusuales”
Los sistemas de control industrial pueden tener sistemas operativos
y aplicaciones inusuales desde el punto de vista de TI.
• Muchas de las soluciones de seguridad existentes para ofimática:
a) No se pueden ejecutar,
b) Interfieren con el sistema de control de procesos.
Ejemplo: Sistema de paro de emergencia de una caldera falló en
funcionar correctamente:
Se había instalado un antivirus en el ordenador usado para
programar el sistema de seguridad. El antivirus bloqueó la correcta
operación del sistema de seguridad.
Extracto de
“Why IT Security doesn’t work on the plant floor”,
E. Byres, British Columbia Institute of Technology, October 2002.
18
Diferencias Tecnologías de la Información – Control Industrial
• Objetivos diferentes de gestión del riesgo
• Ejemplo: Procedimiento de bloqueo del password
• TI: Bloqueo de TODOS los accesos por 10 minutos después de 3 intentos de
autentificación fallidos.
• Control Industrial: Hacer el acceso del operador a prueba de tontos.
9 Durante una fuga de cloro un operador entró en pánico y se equivocó tres veces
introduciendo el password.
9 La consola de operación bloqueó todos los accesos durante 10 minutos…
Tecnología de la Información
Control Industrial
Lo importante: integridad de datos
Lo importante: seguridad de las
personas
Riesgos: perdida de datos o de las
operaciones del negocio
Riesgos: perdida de la vida,
equipos o productos
Recuperación por rearranque del
sistema
Esencial la tolerancia a fallos
Extracto de
“Why IT Security doesn’t work on the plant floor”,
E. Byres, British Columbia Institute of Technology, October 2002.
19
Diferencias Tecnologías de la Información – Control Industrial
• Arquitecturas de seguridad diferentes
• Mundo TI: Los servidores son los dispositivos críticos para la protección.
• Mundo Industrial: Los dispositivos terminales, tales como PLC o control de
compresor son mucho más importantes que un dispositivo central como
puede ser el servidor de datos históricos.
Es necesaria la protección en todos los segmentos de la arquitectura
Ejemplo: IEEE 802.11 (Wireless Ethernet)
• Procedimiento de autentificación solo valida que la estación de
trabajo que firma en punto de acceso central es un dispositivo
autorizado.
• El punto de acceso nunca tiene que probar que es válido y autorizado al
dispositivo terminal.
Extracto de
“Why IT Security doesn’t work on the plant floor”,
E. Byres, British Columbia Institute of Technology, October 2002.
20
Diferencias Tecnologías de la Información – Control Industrial
OTROS POTENCIALES PROBLEMAS A CONSIDERAR
•
ActiveX
Acceso Remoto
•
– PCAnywhere,
PCAnywhere, Xwindows,
Xwindows, VNC
– Modems
•
SSL (Secure
(Secure Socket Layer)
Layer)
•
Telecomunicaciones u otros medios de comunicación
•
Redes de instrumentos y equipos de campo
21
Ejemplos de Incidentes de seguridad
•
•
•
•
•
•
Ruido o paquetes malos
Duplicación de direcciones IP
Tormentas Broadcast
Intrusión Interna
Intrusión Externa
Procedimientos/Arquitecturas
Extracto de
“Electronic Intrusion on your control system”,
B. Webb (Power Engineers) and J. Weiss (Kema Consulting), October 2002.
Variedad de causas: Auditoria, Accidental e Intrusión
22
Ejemplo: Ruido o paquetes malos
•
•
Propagación de ruido o malos paquetes por una red completa es un riesgo
serio.
Caso de Estudio en Industria papelera–
–
Daños en un cable en un área crearon paquetes de datos malos por reflexión.
Equipos de red “tontos” propagaron el problema a otras áreas.
Ejemplo: Dirección IP duplicada
•
•
Protocolo TCP/IP requiere que cada dispositivo tenga una IP única
Caso de Estudio: Controlador Línea de envasado:
–
–
–
Controlador & Escáner usan TCP/IP para comunicarse.
Impresora en Administración obtiene la misma dirección IP que el controlador.
Escáner intenta comunicarse con la impresora en vez del controlador.
23
Ejemplo: Tormenta Broadcast
•
•
•
Broadcasts son mensajes enviados a todos los nodes en la red.
Pocos mensajes broadcast son aceptables. Muchos pueden crera uan
tormenta que puede colapsar los recursos de las CPU de los dipositivos.
Caso de Estudio- DCS en planta de generación de vapor:
–
–
DCS usa Ethernet para comunicarse entre los terminales de operación y el
servidor de terminales de operación..
Los mensajes broadcast de un ordenador con MS Windows mal configurado
sobrecarga el servidor de terminales. Bloqueo de todos los terminales de
operación
Ejemplo: Intrusión Interna
•
•
Trabajador disgustado ataca un PLC en otra área de la planta sobre una red
de PLC.
Cambia password por una obscenidad, los accesos quedan bloqueados lo que
fuerza a una parada para restaurar el funcionamiento..
24
Ejemplo: Intrusión Interna 2
•
•
En una planta se realiza un upgrade mayor de un DCS.
Meses después, el ingeniero jefe de proyecto se conecta al DCS desde la
oficina de proyectos, usando la red corporativa de la empresa.
•
Ingeniero carga un programa en la estación del operador para que que le reenvié datos para alimentar un sistema experto en desarrollo.
Esta nueva tarea sobrecargó el gateway entre DCS/PLC.
Operadores pierden control sobre los dispositivos conectados al PCL.
•
•
Ejemplo: Intrusión Externa
•
•
Un hacker ataca el sistema de control de una planta de aguas residuales
usando un radio enlace.
El incidente causa que millones de litros de agua residuales sin tratar se
derramen contaminando el suelo de parques y jardines y las aguas de los rios
a los que este sistema vierte.
25
Ejemplo: Denegación de Servico (DOS)
•
Procedimientos de los sistemas de control no están preparados para
situaciones que puedan llevar a una DOS
–
–
•
Solicitar datos excesivos resulta en la perdida del servidor de base de datos
Solicitar datos excesivos resulta en perdida de la función de control
Arquitectura del sistema de control no está diseñada para nuevos
requerimientos orientados a la información
–
–
–
Perdida de acceso del operador de DCS
Perdida de acceso del operador de SCADA
Perdida de control del DCS
26
Comentarios/Observaciones
•
•
•
•
•
•
Sistemas de control han sido impactados por intrusiones informáticas
En la mayoría de los eventos identificados los problemas vienen del interior del
firewall corporativo.
Hay una interdependencia clara entre los sistemas de control y las políticas y
prácticas del departamento de Tecnología de la Información.
– Procedimientos de TI son buenos pero no siempre aplicables a sistemas
de control.
Imprescindible la colaboración del personal experto en control y en
tecnologías de la información para establecer e implantar políticas de
seguridad efectivas y prácticas.
La mayoría de los sistemas de control tiene un diseño pobre en seguridad y
protecciones débiles
Muchos de los incidentes de seguridad que han ocurrido podían haber sido
evitados por la aplicación de prácticas de seguridad del mundo de las TI.
27
Implantación de mejoras en la seguridad
Desarrollar un sistema de gestión de la
seguridad informática para los sistemas de
control incluye:
• Formación al personal de operaciones y de
control de procesos para que entiendan la
tecnología y los problemas asociados a la
seguridad informática
• Formación al personal de TI para que entienda
los procesos de fabricación y tecnología
asociada, además de métodos y procesos
relacionados con la gestión de seguridad de los
procesos (PSM)
• Desarrollar procedimientos que reúnan las
habilidades y conocimientos del control y la
informática
¡¡No hay un libro de recetas!!
dISA-99.00.02 detalla 19 actividades para desarrollar un sistema de gestión
28
Guía para la Implantación
Estableciendo un Programa de Seguridad en los Sistemas de Control y Fabricación (SC&F)
Basado en dISA-99.00.02 (Draft 1, Edit 5)
Actividades
Actividad 1 – Business Case
Actividad 2 – Obtener compromiso, soporte y financiación de la Dirección
Actividad 3 – Definir Objetivos y Alcance de la seguridad en SC&F de la empresa
Actividad 4 – Constituir un equipo de interesados (seguimiento y aprobación)
Actividad 5 – Aumentar la habilidades en seguridad a través de formación a los empleados
Actividad 6 – Caracterizar los riesgos claves de los sistemas de control y fabricación
Actividad 7 – Priorizar y calibrar los riesgos
Actividad 8 – Establecer políticas de seguridad a alto nivel que admite el nivel la tolerancia al riesgo
Actividad 9 – Establecer la estructura organizacional responsable de la seguridad
Actividad 10 – Inventariar las redes y dispositivos de SC&F
Actividad 11 – Exploración y Prioritización de los sistemas de control y fabricación
Actividad 12 – Realizar una evaluación detallada de la seguridad
Actividad 13 – Desarrollar políticas y procedimientos detallados de seguridad informática en SC&F
Actividad 14 – Definir el conjunto de estándares del control de mitigación de riesgos de seguridad en SF&C
Actividad 15 – Desarrollar elementos adicionales al plan de gestión de la seguridad informática
Actividad 16 – Implantar las soluciones rápidas
Actividad 17 – Diseñar y ejecutar proyectos de mitigación de los riesgos de seguridad informática
- Definir objetivos y alcance
- Diseñar el proyecto
- Ejecutar el proyecto
- Decidir la planificación de cuando hacer validaciones del programa
- Validación
Actividad 18 – Refinar e implantar el sistema de gestión de la seguridad informática de la empresa/unidad de negocio
Actividad 19 – Adoptar medidas operacionales para la mejora continua
29
Medidas de mitigación de riesgos
Tecnologías de autentificación y autorización
Herramientas de gestion: auditoria, medición, monitorización y detección
• Autentificación de password
• Autentificación por Desafío (Reto/Respuesta)
• Autentificación física/token
• Autentificación tarjeta smart
• Autentificación biométrica
• Autentificación basada en la localización
• Utilidades para auditar registro de acciones
• Sistemas de detección de virus y código malicioso
• Sistema de detección de intrusión
• Escáner de vulnerabilidad
• Utilidades de análisis forense
• Herramientas de configuración del host (Workstation/Controladores)
• Herramientas para la automatización de la gestión del software
Tecnologías de filtrado/bloqueo y contro de acceso
Control físico de la seguridad
• Herramientas de autorización basada en roles
• Cortafuegos (firewalls) de red
• Protección física
• Cortafuegos (firewalls) basados en host (Workstation/Controladores) • Seguridad personal
• Redes de área local virtuales (VLAN)
Tecnologías de encriptación y validación de datos
• Encriptado de clave simétrica (secreta)
• Encriptado de clave pública y distribución de claves
• Redes privadas virtuales (VPN)
Básico para mitigar ataques:
•Prevenir firewalls, routers, anti-virus
•Detectar detección de intrusión, logs de eventos
•Mitigar work-arounds, patches
•Recuperar respaldo de los sistemas, actualizaciones del sw
Referencia ISA-TR 99.00.01 2007
30
Ejemplo de DuPont
Seguridad basada en definición de perímetro
Fortaleza
Perímetro entre la red de control
de procesos y la Intranet
• Autentificación segura
• Autorización de destino
Debilidad
• Falta un mecanismos de
autentificación y autorización
que sea practicable en las
consolas de operación en sala
de control
• Autorización de aplicaciones
Windows
Extracto de
“Process Control Network Security”,
T. Good, DuPont, October 2002
E-Pass = Two Factor
Authentication (RSA)
31
Recomendaciones finales
• Formación sobre los riesgos. Llamar la atención y estar alertas.
• Entender las políticas y técnicas de seguridad usadas ampliamente en
el mundo de las tecnologías de la información y aplicarlas con criterio.
• Mantener una seguridad física y de las personas adecuada
• Definir situación actual
- Evaluación de vulnerabilidad
• Realizar evaluaciones de riesgos
- ¿Que necesita atención?
• Desarrollar una política de seguridad específica para los sistemas de
control
-Definir objetivos y alcance - Asegurar la participación multifuncional
• Tener un plan de respuesta a incidencias y de contingencia
32
GRACIAS POR SU COLABORACIÓN
CON ISA ESPAÑA
33