Sugerencias para mejorar la seguridad en SCADA

http://www.s21sec.com
10 de Enero 2007

Abstract
En el siguiente artı́culo se explica brevemente la evolución de los sis-
temas SCADA y se presentan una lista de las vulnerabilidades más co-
munes que existen hoy en dı́a. Luego se hacen varias recomendaciones
para corregirlas, agrupadas en tres categorı́as: redes, sistemas y proced-
imientos

1 Introducción
Los sistemas SCADA o sistemas de supervisión y control y adquisición de datos,
comprenden todas aquellas soluciones de aplicación que recoge medidas y data
operativa de equipos de control locales y remotos. La data se procesa para
determinar si los valores están dentro de los niveles de tolerancia y, de ser
necesario, tomar medidas correctivas para mantener la estabilidad y el control.
La arquitectura básica comprende un servidor, o granja de servidores, cen-
tralizado; los RTU o PLC que manejan los dispositivos; consolas desde donde los
operadores monitorizan y controlan los diferentes equipos y un servidor histórico
de bases de datos que almacena en disco toda la información que recibe y maneja
el servidor central.
Estas infraestructuras suelen estar localizadas en sistemas de transportes:
metro, trenes, puertos o aeropuertos, sistemas industriales: quı́micas, refinerı́as,
etc., distribución y control de electricidad, agua, gas y en centrales nucleares.

2 Evolución de SCADA
“Los sistemas de control de procesos fueron diseñados antes del surgimiento de
Internet. Fueron pensados para ser sistemas aislados y no conectados en red,
por lo que carecen de dispositivos de seguridad como cortafuegos, mecanismos
de cifrado o software antivirus[7]”. La capacidad de procesamiento de estos
sistemas era limitada y estaban diseñados para ejecutar sus tareas, sin capacidad
adicional para ejecutar otras tareas o programas.
Las empresas han incorporado plataformas de hardware y software estándares
junto con sus vulnerabilidades conocidas a las redes SCADA. Se han interconec-
tado en red hardware propietario antiguo con equipos Windows y Unix La se-
guridad que se ofrecı́a antaño por el aislamiento ya no está presente y un amplio
conjunto de nuevas vulnerabilidades amenazan los sistemas SCADA. Además
muchos fabricantes han ido migrando sus aplicaciones y protocolos para adap-
tarlos a las redes comerciales, usando TCP/IP en la mayorı́a de los casos.

1
3 Vulnerabilidades conocidas
Hoy en dı́a es bastante común que las redes SCADA estén mezcladas con las
redes de las empresas sin ningún tipo de separación o control de acceso. En
muchos casos, los ordenadores tienen doble tarjeta de red conectadas a la red
de la empresa por un lado y a la red SCADA.
Esto crea una puerta de enlace potencial entre ambas, ya que basta compro-
meter alguna máquina para poder acceder de una red a otra. Los atacantes no
necesitan ser expertos en redes de control de procesos. Basta con atacar una
máquina de la red local de la empresa que tenga acceso a la red SCADA para
poder causar daños.
Una carencia de estos sistemas es que no se han implementado medidas de
seguridad básicas, tales como cifrado, autenticación, redundancia e incluso hay
implementaciones cuya pila TCP/IP es defectuosa, lo que las hace vulnerable a
un sinfı́n de ataques plenamente conocidos.
Los sistemas SCADA son muy sensibles a escaneos de red y de vulnerabili-
dades, es bastante arriesgado ejecutarlos ya que los resultados son impredecibles
y van desde ralentización de la red hasta denegaciones de servicio.
Recientemente se ha incorporado también el uso de redes inalámbricas 802.11x,
para reducir la necesidad de cableado al incorporar nuevos dispositivos. El grave
problema es que no están debidamente aseguradas, carecen de autenticación o
de protección de los datos entre el cliente y los puntos de acceso.
En general no se contemplan polı́ticas de renovación de contraseñas ni de
longitud mı́nima. Las contraseñas suelen compartirse, incluso suele existir so-
lamente un usuario en los equipos de red que se comparte entre todos los op-
eradores, lo que suele limitar en gran medida la capacidad de auditorı́a. Los
ficheros de eventos no se recogen ni se analizan.
Otro problema usual es la falta de comunicación o fluidez entre departamen-
tos. Muchas veces suelen existir conflictos de intereses entre el departamento
de ingenierı́a y el de informática. Las medidas de seguridad suelen entorpecer
o complicar las rutinas diarias lo cual no siempre es visto con buenos ojos.

4 Sugerencias
4.1 Arquitectura de red
Las redes SCADA deben tener una exposición mı́nima al mundo exterior y no
deben estar conectadas directamente a Internet, ni a la red corporativa. Se debe
separar, de ser posible fı́sicamente, las redes de la empresa de las redes SCADA.
Se recomienda el uso de cortafuegos y detectores de intrusos.
Para mejorar la seguridad en el entorno de red de la plataforma SCADA
es necesario migrar hacia una arquitectura que contenga una marcada división
entre las redes y controles de acceso perimetral robustos. Con estas medidas
se busca minimizar la ventana de oportunidad, tanto para atacantes externos
como usuarios malintencionados.
Se debe permitir la mı́nima cantidad de conexiones desde servidores u or-
denadores externos hacia los dispositivos internos de la red SCADA, y todas
aquellas permitidas deben estar debidamente documentadas y justificadas. Las
conexiones más comunes se establecen desde los dispositivos de control que

2
manejan los operarios, el servidor de bases de datos que recopila la data y para
tareas de mantenimiento.
Sin embargo esto no es un método infalible. Es posible que algún código
malicioso u otro tipo de ataque atraviesen las distintas zonas de la red y penetrar
en la red de control de procesos. Además la mayorı́a de los cortafuegos e IDS
no están diseñados adecuadamente para manejar los protocolos SCADA.
Los servidores que almacenan la data, comúnmente llamados Historian, re-
copilan información de la red SCADA y la almacenan para que esté disponible
para consultas y reportes históricos. Es recomendable que estos servidores se
ubiquen en una zona desmilitarizada (DMZ) localizada entre la red corpora-
tiva y la red SCADA. También es recomendable que se utilicen dos protocolos
distintos para comunicarse con cada red.
Un ejemplo de esto serı́a que utilicen alguna base de datos relacional para
compartir la información en la red corporativo y un protocolo SCADA para
recoger información desde esa red. Ası́ se configuran reglas diferentes en el
firewall y se minimiza el riesgo de incidentes como los que ocurrieron con la
infección del gusano Slammer en la planta nuclear Davis-Besse en Ohio, Estados
Unidos [5].
Otro factor de riesgo son las redes inalámbricas. Se debe evitar realizar
tareas crı́ticas usando este medio de conexión en los sistemas de control de
procesos cuando sea posible. Es recomendable limitar el uso de estas redes para
capturar datos solamente. En todo caso, es muy importante evitar conexiones
no deseadas en la red inalámbrica usando todas las medidas disponibles.

4.2 Servidores y equipos

Es más complicado aplicar medidas de seguridad interna de la red SCADA. Esto
se debe en mayor parte a que se tienen equipos obsoletos, con poca capacidad
para incorporar módulos de seguridad, las actualizaciones no se realizan pun-
tualmente y los protocolos suelen no contemplar medidas de control de acceso
o inclusive presentan fallas de implementación.
Para la seguridad interna es muy importante apoyarse en todas las opciones
de seguridad que ofrecen los productos que ya están instalados. Por otra parte,
también es importante usar protocolos abiertos y probados para proveer seguri-
dad en vez de apoyarse en protocolos propietarios.
La administración de parches necesita integrarse con los procedimientos de
control de cambios y manejo de incidentes de forma tal que las alertas de vul-
nerabilidades puedan dispararse y se tomen acciones apropiadas a tiempo.
En la mayorı́a de los casos hay un retardo desde que aparece la alerta de la
vulnerabilidad y la aparición del parche correspondiente. En otros no es posible
aplicar el parche debido al riesgo que implica o por limitaciones técnicas. En esos
casos el programa de manejo de parches debe considerar alguna de las siguientes
técnicas electrónicas o fı́sicas para proteger los recursos afectados: endurecer los
controles de acceso o crear una brecha fı́sica, para aislar esos equipos.

4.3 Polı́ticas y procedimientos

Antes de abordar un plan de seguridad hay que tener en cuenta que a difer-
encia de los sistemas tradicionales, la prioridad en plataformas SCADA es la
continuidad operativa y la seguridad industrial.

3
 Es muy importante realizar un inventario de activos que incluya todos los
equipos y componentes de la red SCADA. Para todos los equipos se debe incluir,
siempre que sea posible y como mı́nimo: marca, modelo y fabricante, dirección
IP y la configuración base. Además, se deben identificar aquellos sistemas que
realicen funciones crı́ticas o contengan información sensible y que necesiten un
nivel adicional de protección.
Es necesario asegurarse que todos los sistemas están sujetos a controles es-
trictos de cambio. Se deben incluir asesorı́as de seguridad en estos procesos. A
diferencia de los sistemas tradicionales, las plataformas SCADA necesitan estar
continuamente operativas. Por lo tanto, los cambios que pueda ralentizar las
comunicaciones o interrumpir el servicio, no son aceptables.
Es recomendable que los cambios propuestos en el control sean aprobados
en conjunto por todos los departamentos involucrados o afectados, por ejemplo
modificar reglas en el cortafuego pueden estar sujetos al departamento de TI y
al de Mantenimiento.
Hay que dar formación al personal para minimizar la probabilidad de que los
empleados a cualquier nivel, filtren inconscientemente información sensible sobre
el diseño, operación o controles de seguridad de los sistemas SCADA. También
es importante definir de forma clara y explı́cita los roles, responsabilidades y los
permisos de los gerentes, administradores de sistemas y usuarios.

5 Conclusiones
Los sistemas SCADA se encuentran expuestos al mundo exterior y hay mucha in-
formación sobre ellos disponible, incluyendo especificaciones y vulnerabilidades,
lo que los hace un blanco fácil para un ataque.
Es importante abordar la seguridad de las plataformas SCADA con una
filosofı́a distinta a la que se tratan los sistemas de TI convencionales, teniendo en
cuenta las prioridades: interrupciones mı́nimas y no entorpecer las operaciones
diarias.
Hay que implementar polı́ticas y procedimientos que minimicen la probabili-
dad de errores, y faciliten la recuperación rápida en caso de cualquier incidente.
Estos se deben apoyar sobre una arquitectura de red con estrictos controles de
acceso y aislada dentro de lo posible del mundo exterior y sistemas robustos,
debidamente fortalecidos (hardened) y con los parches actualizados dentro de
lo posible.
Finalmente, es importante destacar que existe un peligro latente por las
innumerables fallas de seguridad que presentan, en mayor o menor medida,
todas las plataformas SCADA y que debe ser abordado lo antes posible por
todas las empresas.

References
[1] British Columbia Institute of Technology, Good Practice Guide on
Firewall Deployment for SCADA and Process Control Networks:
http://www.niscc.gov.uk/niscc/docs/re-20050223-00157.pdf
[2] Idaho National Laboratory, INL increases infrastructure security at SCADA
summit: http://www.inl.gov/featurestories/2006-09-28.shtml

4
[3] IT Security Expert Advisory Group, SCADA Security-Advice for CEOs:
http://www.ag.gov.au/agd/WWW/rwpattach.nsf/VAP/(CFD7369FCAE9B8F32F341DBE097801FF)˜19
[4] Keith Stouffer, Joe Falco, Karen Kent; Guide to Supervisory Control
and Data Acquisition (SCADA) and Industrial Control Systems Security:
http://csrc.nist.gov/publications/drafts/800-82/Draft-SP800-82.pdf

[5] Kevin Poulsen, Slammer worm crashed Ohio nuke plant network:
http://www.securityfocus.com/news/6767

[6] PA Consulting Group and National Infrastructure Security Co-ordination

Centre, Good Practice Guide Process Control and SCADA Security:
http://www.niscc.gov.uk/niscc/docs/re-20051025-00940.pdf
[7] Steven S. Smith, The SCADA Security Challenge: The Race Is On:
http://www.infosecwriters.com/texts.php?op=display&id=521