FACULTAD DE INGENIERÍA

DIVISIÓN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS

CARRERA DE INGENIERÍA DE REDES Y COMUNICACIONES

SEGURIDAD DE SERVICIOS DE RED

TEMA: SEGURIDAD EN SISTEMAS SCADA

INTEGRANTES:

Abril 2018

Seguridad de Servicios de Red Página 1

Contenido
1. INTRODUCCIÓN ........................................................................................ 3

2. SCADA: BREVE DEFINICIÓN .................................................................... 4

3. SEGURIDAD DE SISTEMAS SCADA......................................................... 6

4. “EXPLOTANDO” SISTEMAS SCADA ......................................................... 9

4.1. Tipos de Ataques ................................................................................ 12

4.1.1. Ataques al hardware: ....................................................................... 13

4.1.2. Ataques al software ......................................................................... 14

4.1.3. Ataques a las comunicaciones......................................................... 15

5. CASO REAL: STUXNET ........................................................................... 16

6. PROTECCIÓN DE SISTEMAS SCADA .................................................... 19

6.1. Pasos para proteger un sistema SCADA ............................................ 19

6.1.1. Establecer un marco de seguridad para el control de procesos ... 19

6.1.2. Implementar defensa en profundidad ........................................... 20

6.1.3. Entender el riesgo del negocio ..................................................... 20

6.1.4. Implementar una arquitectura segura ........................................... 21

6.1.5. Establecer capacidades de respuesta .......................................... 23

6.1.6. Definir Roles ................................................................................. 23

6.1.7. Mejorar el conocimiento y las habilidades .................................... 24

7. CONCLUSIONES Y RECOMENDACIONES ............................................ 25

8. BIBLIOGRAFÍA ......................................................................................... 27

Seguridad de Servicios de Red Página 2

1. INTRODUCCIÓN
Los sistemas y redes de control de supervisión y adquisición de datos
(SCADA) contienen computadoras y aplicaciones que desempeñan
funciones clave en el suministro de servicios básicos esenciales (por ejemplo,
electricidad, gas natural, gasolina, agua, tratamiento de residuos, transporte,
etc.) y automatización a nivel industrial. Como tales, forman parte de la
infraestructura crítica de las naciones y requieren protección contra una
variedad de amenazas que existen hoy en día en el ciberespacio. Al permitir
la recolección y análisis de datos y el control de equipos tales como bombas
y válvulas desde ubicaciones remotas, las redes SCADA proporcionan una
gran eficiencia y son ampliamente utilizadas. Sin embargo, también
presentan un riesgo para la seguridad. Las redes SCADA se diseñaron
inicialmente para maximizar la funcionalidad, con poca atención a la
seguridad. Como resultado, el rendimiento, la fiabilidad, la flexibilidad y la
seguridad de los sistemas de control distribuido/SCADA son robustos,
mientras que la seguridad de estos sistemas es a menudo débil o inexistente.
Esto hace que algunas redes SCADA sean potencialmente vulnerables a
interrupciones de servicio, redirección de procesos o manipulación de datos
operativos que podrían resultar en problemas de seguridad pública y/o serias
interrupciones en la infraestructura crítica de la nación o de las industrias que
las utilizan. Todas las organizaciones, gubernamentales o comerciales,
deben tomar medidas para proteger sus redes SCADA como parte del
esfuerzo por proteger adecuadamente la infraestructura crítica tanto pública
como privada.

Seguridad de Servicios de Red Página 3

2. SCADA: BREVE DEFINICIÓN
El control de supervisión y adquisición de datos (SCADA) es un sistema de
elementos de software y hardware que permite a las organizaciones
industriales:

 Controlar los procesos industriales localmente o en ubicaciones remotas

 Supervisar, recopilar y procesar datos en tiempo real
 Interactuar directamente con dispositivos como sensores, válvulas,
bombas, motores, etc. a través de software de interfaz hombre-máquina
(HMI).
 Grabar eventos en un archivo de registro

Los sistemas SCADA son cruciales para las operaciones de producción

industrial, ya que ayudan a mantener la eficiencia, procesan datos para tomar
decisiones más inteligentes y comunican los problemas del sistema para
ayudar a mitigar el tiempo de inactividad.

Los sistemas SCADA se distinguen históricamente de otros sistemas de

control industrial por ser procesos a gran escala que pueden incluir múltiples
sitios y grandes distancias. Estos procesos incluyen procesos industriales, de
infraestructura y basados en instalaciones.

La arquitectura básica de SCADA comienza con controladores lógicos

programables (PLCs) o unidades terminales (o de telemetría) remotas
(RTUs). Los PLCs y RTUs son microcomputadoras que se comunican con
una serie de objetos como maquinaria de producción, HMIs, sensores y
dispositivos finales, y luego enrutan la información de esos equipos a
computadoras con software SCADA. El software SCADA procesa, distribuye
y muestra los datos, ayudando a los operadores y otros empleados a analizar
los datos y a tomar decisiones importantes.

Por ejemplo, el sistema SCADA notifica rápidamente a un operador que un

lote de producto está mostrando una alta incidencia de errores. El operador
detiene la operación y visualiza los datos del sistema SCADA a través de una
HMI para determinar la causa del problema, revisa los datos y descubre que
la máquina 3 estaba funcionando mal. La capacidad del sistema SCADA para

Seguridad de Servicios de Red Página 4

 notificar al operador de un problema le ayuda a resolverlo y evitar más
pérdidas de producto.

Fig. 1: Diagrama básico de SCADA1

Es necesario hacer una diferenciación: SCADA es un sistema o conjunto de

sistemas diseñados para controlar equipos. Usualmente se suele confundir los
sistemas SCADA con PLCs o DCS (Distributed Control System). Estos dos
últimos son los equipos o conjunto de equipos que se conectan directamente a
los elementos a controlar, y se unifican para su supervisión en una plataforma
SCADA, la cual es suministrada por el fabricante de los equipos.

1 Adaptado de https://inductiveautomation.com/static/images/basic-scada-diagram.png

Seguridad de Servicios de Red Página 5

3. SEGURIDAD DE SISTEMAS SCADA
La seguridad de los sistemas SCADA y de tiempo real representa un reto
importante en el mundo actual. Las amenazas de ciberseguridad de alto perfil
son un fenómeno relativamente reciente (los ataques de Stuxnet o Night
Dragon). Sin embargo, los sistemas que ejecutan procesos industriales
críticos son típicamente más antiguos que estas amenazas. En
consecuencia, hay muchos sistemas heredados que pueden ser vulnerables
a los ataques cibernéticos dado que la seguridad cibernética simplemente no
era una consideración en el momento del diseño inicial e instalación. La
seguridad de los sistemas, incluso de los sistemas desplegados
recientemente, también puede ser un problema y a menudo hay informes en
los medios de comunicación sobre casos en los que los sistemas están
conectados a Internet con una protección inadecuada, o los fabricantes de
los equipos han utilizado nombres de usuario y contraseñas en códigos
duros, dotando así a los atacantes cibernéticos con conocimientos internos y
la capacidad de manipular la configuración del sistema.

Una organización puede estar más preocupada por el robo de propiedad

intelectual, personas que obtienen acceso a información financiera o
estratégica, o simplemente por la denegación de servicio en los sistemas de
TI. Aunque son serios para un negocio, estos riesgos son diferentes a los de
los sistemas de control industrial. En los sistemas SCADA o sistemas de
control en general, el hecho de que cualquier ejecución lógica dentro del
sistema tenga un impacto directo en el mundo físico dicta que la seguridad
sea primordial.

Seguridad de Servicios de Red Página 6

 Fig. 2: Riesgo de sistemas de negocios versus sistemas de control industrial 2

Siendo la primera línea frente a la vida humana y el medio ambiente, los

dispositivos de campo en los sistemas SCADA son considerados no menos
importantes que los equipos centrales. También ciertos sistemas operativos
y aplicaciones que se ejecutan en sistemas SCADA, que no son
convencionales para el personal de TI típico, pueden no funcionar
correctamente con soluciones comerciales de seguridad informática.
Adicionalmente, factores como la demanda de disponibilidad continua, la
criticidad de tiempo de respuesta, los recursos de computación limitados en
los dispositivos de borde (sensores o interfases), la gran base física instalada,
la amplia interfaz entre las señales digitales y analógicas, los temas sociales
incluyendo la rentabilidad y la renuencia del usuario al cambio, los problemas
heredados, etc., hacen que asegurar sistemas SCADA sea una tarea peculiar
de ingeniería de seguridad. Además, la reciente tendencia a la
estandarización del software y hardware utilizado en los sistemas SCADA
hace que sea aún más fácil montar ataques específicos de SCADA. Por lo
tanto, la seguridad de los sistemas SCADA ya no puede basarse en la
oscuridad o en la función de bloquear un sistema. Estos ataques pueden
perturbar y dañar operaciones críticas de infraestructura, causar grandes

2 Tomado de https://www.thalesgroup.com/sites/default/files/asset/document/thales-cyber-
security-for-scada-systems.pdf

Seguridad de Servicios de Red Página 7

 pérdidas económicas, contaminar el medio ambiente y, lo que es aún más
peligroso, causar la muerte de personas.

Seguridad de Servicios de Red Página 8

4. “EXPLOTANDO” SISTEMAS SCADA
Google Search es una herramienta común para la mayoría de los que
acceden a Internet. Funciona indexando el contenido de las páginas web para
permitir una rápida recuperación basada en los criterios de búsqueda del
usuario. Por otra parte, SHODAN es un motor de búsqueda similar a Google,
excepto que este motor de búsqueda indexa la información de cabecera
HTTP (mensaje web), lo que permite encontrar enrutadores, servidores,
semáforos y equipos y sistemas de control industrial (ICS).

El proyecto SHINE3 (SHodan Intelligence Extraction), descubrió que más de

un millón de sistemas SCADA / ICS están conectados a Internet con
direcciones IP únicas, y esta cifra está creciendo entre 2000 - 8000 / día. Es
muy probable que muchos de estos dispositivos sean inseguros y
explotables. Todo lo que el atacante necesita hacer es usar SHODAN para
determinar el dispositivo frente a Internet basándose en la información del
encabezado que revela la versión del software en el lugar u otra información
similar, recuperar el código de explotación apropiado para ese dispositivo
desde un repositorio como Metasploit, configurar una conexión proxy usando
TOR o similar, y luego “explotar” el sistema remoto.

Es comúnmente reconocido que la robustez de SCADA/ICS frente a un

ataque cibernético directo es pobre, ya que muchos sistemas no fueron
diseñados para conectarse a Internet. Estos deben diseñarse de manera que
haya controles de seguridad, tales como firewalls/diodos de datos (permiten
que la información fluya en una sola dirección) y sistemas de gestión de
identidad y acceso, entre los sistemas en tiempo real e Internet.

El estado actual de los sistemas SCADA/ICS es considerado como

lamentable por los investigadores de seguridad. Es común encontrar
controles ActiveX; los enfoques de programación segura son raros y muchos
sistemas son tan frágiles que son incapaces de resistir los escaneos y
sondeos de seguridad. Las cuentas administrativas de puerta trasera
(backdoor accounts) están presentes, y en algunos casos se utilizan

3 https://www.securityweek.com/project-shine-reveals-magnitude-internet-connected-critical-
control-systems

Seguridad de Servicios de Red Página 9

 credenciales de autenticación en código duro, que si se conocen garantizan
el acceso de los hackers. En algunos casos, ataques básicos causan que
algunos ICS colapsen siendo los desbordamientos de búferes un problema
serio, y muchos no tienen timeouts de contraseñas permitiendo intentos de
acceso por fuerza bruta.

El hackeo de ICS se facilita con plug-ins ya preparados para el framework

Metasploit y Nessus, que permiten a los hackers un fácil acceso a los
sistemas en tiempo real. Una vez que un sistema ha sido "poseído", como un
PLC, entonces se puede cargar una nueva "lógica de escalera" (Ladder
logic4). Durante el ataque a Natanz con Stuxnet, se reportó que la lógica del
controlador fue cambiada para causar que las centrífugas
aceleren/disminuyan rápidamente. Un enfoque similar podría adoptarse en
otros sistemas para ignorar múltiples bloqueos de seguridad con efectos
catastróficos. Tal vez los PLCs están duplicados por seguridad y
disponibilidad, pero si el ataque cibernético cambia la lógica en todos los
sistemas, entonces no podemos esperar nada bueno.

Los ataques cibernéticos a SCADA/ICS son raros, pero van en aumento. La

tentación es siempre minimizar el problema; sin embargo, una presentación
de Blackhat en 20135 demostró que, si se colocaba un honeypot en Internet
simulando un sistema en tiempo real, algunas conexiones cambiaban la
configuración a niveles potencialmente peligrosos.

4 Lenguaje de programación gráfico muy popular para PLC debido a que está basado en los
esquemas eléctricos de control clásicos
5 https://media.blackhat.com/us-13/US-13-Wilhoit-The-SCADA-That-Didnt-Cry-Wolf-Whos-
Really-Attacking-Your-ICS-Devices-Slides.pdf

Seguridad de Servicios de Red Página 10

Seguridad de Servicios de Red Página 11
 Figs. 3, 4, 5: Distribución de ataques por origen y tipo 6

Esto era sólo un honeypot virtual, no un sistema SCADA real, pero el

resultado de que hackers externos se conecten a sistemas reales y cambien
la configuración puede tener serias implicaciones. Si es posible, se deben
usar productos SCADA/ICS robustos, con seguridad incorporada, no que sea
parte de una idea posterior. Sin embargo, esto puede no ser práctico, siendo
crítico el separar estos sistemas de redes de alto riesgo como Internet, y
ciertamente no permitir que los números IP para SCADA/ICS sean
directamente accesibles desde Internet, a menos que exista una buena razón
y se establezcan controles de seguridad adecuados.

4.1. Tipos de Ataques

Los ataques cibernéticos contra sistemas SCADA pueden tomar rutas a
través de conexiones a Internet, conexiones a redes empresariales o de
negocios y/o conexiones a otras redes, a la capa de redes de control y luego
al nivel de dispositivos de campo. Más específicamente, los vectores de
ataque comunes son:

6 Trend Micro research paper: “The SCADA That Didn’t Cry Wolf”

Seguridad de Servicios de Red Página 12

  Puertas traseras y agujeros en el perímetro de la red
 Vulnerabilidades en los protocolos comunes
 Ataques a dispositivos de campo por medios cibernéticos
 Ataques a bases de datos
 Hijacking de comunicaciones y ataques man-in-the-middle.

Desde el punto de vista de un ingeniero de control, los posibles ataques

pueden agruparse en las siguientes categorías:

 Datos de entrada falsos al controlador introducidos por sensores

comprometidos y/o enlaces de red explotados entre el controlador y los
sensores.
 Datos de salida manipulados hacia los actuadores/reactores del
controlador debido a actores/reactores manipulados o enlaces de red
comprometidos entre el controlador y los actuadores.
 Historiador de controladores7.
 Denegación de Servicio - no cumplir con los tiempos límites de las
acciones de tareas requeridas.

Separándolos por el objetivo a atacar, los podemos dividir en:

4.1.1. Ataques al hardware:

Los atacantes pueden obtener acceso remoto no autenticado a los
dispositivos y cambiar sus valores de referencia de datos. Esto puede
causar que los dispositivos fallen a un valor umbral muy bajo o que una
alarma no se active cuando debería. Otra posibilidad es que el atacante,
después de obtener acceso no autenticado, pueda cambiar los valores de
la pantalla del operador de modo que cuando una alarma realmente se
dispare, el operador no sea consciente de ello. Esto podría retrasar la
respuesta humana a una emergencia que podría afectar negativamente a
la seguridad de las personas en las proximidades de la planta.

7 Software complejo que se utiliza para almacenar y analizar datos vitales industriales y de
procesos y ofrece varios beneficios como ecuaciones de análisis predefinidas y compatibilidad
con otros paquetes de software industrial.

Seguridad de Servicios de Red Página 13

 4.1.2. Ataques al software
SCADA emplea una variedad de software para satisfacer sus demandas
de funcionalidad. Además, hay grandes bases de datos que residen en
historiadores de datos, además de muchas aplicaciones de bases de
datos relacionales utilizadas en sesiones corporativas y de planta. Al
alojar bases de datos centralizadas, los historiadores de datos contienen
información de procesos vital y potencialmente confidencial. Estos datos
no sólo son indispensables por consideraciones técnicas, como el hecho
de que muchos algoritmos de control se basan en datos de procesos
anteriores para tomar decisiones correctas, sino también con fines
comerciales, como la tarificación de la electricidad.

Aunque hemos asumido que los algoritmos de estos softwares son

confiables, todavía hay vulnerabilidades asociadas con sus
implementaciones. El fallo de implementación más común es el
desbordamiento de búfer entre otros, tales como formato de cadena de
caracteres, desbordamiento de enteros, etc. El hecho de que la mayoría
de las aplicaciones de control estén escritas en C nos obliga a tomar
precauciones adicionales con este tipo de vulnerabilidad.

Otros tipos de ataque al SW aprovecha que no hay separación de

privilegios en sistemas operativos incrustados, tales como VxWorks.
VxWorks en sí mismo es esencialmente un núcleo monolítico con
aplicaciones implementadas como tareas de kernel, lo que significa que
todas las tareas generalmente se ejecutan con los privilegios más altos y
hay poca protección de memoria entre estas tareas.

Muchos ataques se reducen a causar desbordamiento de búfer como un

posible medio para corromper el comportamiento previsto del programa y
hacer que se descontrole. Algunos métodos generales son el stack
smashing y la manipulación del puntero de función. El efecto de estos
ataques puede adoptar formas como el restablecimiento de contraseñas,
la modificación de contenido, la ejecución de código malicioso, etc.

Seguridad de Servicios de Red Página 14

 4.1.3. Ataques a las comunicaciones
Tenemos ataques a nivel de la capa de red, de transporte, aplicación e
implementación de protocolos. El servicio de depuración de VxWorks
ejecuta UDP en el puerto 17185, y está habilitado por defecto. Un atacante
puede ejecutar los siguientes ataques sin necesidad de autenticación y
manteniendo un cierto nivel de sigilo: volcado de memoria remoto, parche
de memoria remoto, llamadas remotas a funciones, gestión remota de
tareas.

Los protocolos SCADA, particularmente aquellos que se ejecutan sobre

protocolos de transporte como TCP/IP tienen vulnerabilidades que
podrían ser explotadas por el atacante a través de metodologías tan
simples como inyectar paquetes malformados para causar que el
dispositivo receptor responda o se comunique de manera inapropiada y
resulte en que el operador pierda completamente la visión o el control del
dispositivo de control.

En la actualidad, no existe un fuerte control de seguridad en los protocolos

utilizados en los sistemas SCADA, como DNP38 sin autenticación segura,
Modbus, Object Linking and Embedding (OLE) para Control de Procesos
(OPC), o Inter-Control Center Communications Protocol (ICCP). No hay
autenticación en la fuente ni en los datos, por lo que aquellos que tienen
acceso a un dispositivo a través de un protocolo SCADA, a menudo
también pueden leer y escribir. El acceso de escritura y las funciones de
diagnóstico de estos protocolos son particularmente vulnerables a los
ataques físicos cibernéticos y cibernéticos.

8Distributed Network Protocol: IEEE Std 1815-2010 para Comunicaciones de Sistemas de

Energía Eléctrica

Seguridad de Servicios de Red Página 15

5. CASO REAL: STUXNET
En 2010, muchos expertos en control industrial se preocuparon por un
"gusano" de origen desconocido que se estaba extendiendo por todo el
mundo e integrándose en estos sistemas de control. Miles de computadoras
en lugares como la India y los Estados Unidos habían sido infectadas. Pero
la mayor parte de las infecciones (aproximadamente el 60 por ciento) se
encontraban en Irán. Esto llevó a muchos expertos a inferir que o bien Irán
tenía defensas cibernéticas bastante deficientes para sus programas
relacionados con SCADA, lo que lo hacía más vulnerable, o bien un virus se
había dirigido en un principio a algún sitio en Irán y, según un informe,
"fracasó en su propósito principal y se extendió incontrolablemente a
objetivos no deseados en todo el mundo, demostrando así lo indiscriminados
y destructivos que probablemente serían las armas cibernéticas". Pero esto
estaba bien lejos de ser cierto. Conforme se iba analizando, se descubrió que
era una pieza de malware extraordinariamente compleja como ninguna que
el mundo haya vivista hasta ese momento. Tuvo por lo menos cuatro nuevos
"zero day" (vulnerabilidades previamente desconocidas), utilizó firmas
digitales con las claves privadas de dos certificados robados de empresas
conocidas y trabajó en todos los sistemas operativos Windows incluyendo
hasta Windows 95. Destacó especialmente el número de vulnerabilidades
zero day utilizadas. Utilizar cuatro a la vez no tenía precedentes y era casi
ilógico dado que bastaba con una puerta abierta. Era una señal inconfundible
de que los creadores de Stuxnet contaban con enormes recursos y querían
estar absolutamente seguros de que penetrarían en su objetivo.

Pero ¿Cuál era su objetivo? Stuxnet no buscaba computadoras o incluso

aplicaciones Windows en general, sino un tipo específico de programa
utilizado en el software de control SCADA WinCC/PCS 7 de Siemens. Si este
software no estaba presente, el gusano tenía controles incorporados para
tornarse inerte. Además, en lugar de tratar de diseminarse lo más posible,
como era la meta con los gusanos comunes, Stuxnet sólo permitía que cada
equipo infectado propagara el gusano a no más de otros tres. Incluso llegó
con una protección final; un mecanismo de autodestrucción hizo que se
borrara en 2012. Stuxnet sólo perseguía un controlador industrial específico,

Seguridad de Servicios de Red Página 16

 fabricado por Siemens, configurado para operar una serie de centrífugas
nucleares, pero no cualquier centrífuga nuclear antigua que se pueda tener
por ahí, sino una "cascada" de centrífugas de cierto tamaño y número (984)
conectadas entre sí. No tan casualmente, este fue el montaje exacto en la
instalación nuclear de Natanz, un lugar sospechoso en el programa de armas
nucleares ilícitas de Irán.

Ahora bien, Stuxnet no detuvo las centrífugas de manera obvia. En su lugar,

ejecutó una serie de subrutinas: una de ellas causó pequeños ajustes en la
presión dentro de las centrifugadoras. Otra manipuló la velocidad de los
motores de rotación de las centrifugadoras, haciendo que se desaceleraran
y luego se aceleraran de nuevo, llevando los motores fuera de control y
arruinando su trabajo. Además, cada cierto tiempo el malware forzaba las
velocidades de la centrifugadora más allá del máximo previsto. Por lo tanto,
las centrifugadoras no sólo estaban fallando en la producción de combustible
de uranio refinado, sino que con frecuencia se descomponían y se
paralizaban a causa de las vibraciones dañinas causadas por las diversas
sobrecargas aleatorias. En otras ocasiones, las máquinas estaban
literalmente girando fuera de control y explotando.

Por más de un año, Stuxnet había estado dentro de las redes iraníes, pero
los científicos nucleares inicialmente pensaron que sus instalaciones estaban
sufriendo una serie de averías al azar. Los científicos solo seguían
reemplazando las centrifugadoras averiadas por otras nuevas, que se
infectaban y se dañaban de nuevo. Sin embargo, pronto se preguntaron si les
estaban vendiendo piezas defectuosas o si estaban sufriendo algún tipo de
sabotaje de hardware. Pero las máquinas siempre funcionaban
perfectamente, excepto por el hecho de que nada funcionaba como debía.

Stuxnet fue el ataque de integridad por excelencia. No sólo corrompió el

proceso, sino que ocultó sus efectos de los operadores y explotó su confianza
en que los sistemas informáticos describirían con exactitud y correctamente
lo que estaba ocurriendo. Los ingenieros iraníes ni siquiera sospechaban un
ataque cibernético; sus sistemas estaban aislados de la Web, y hasta ese
momento los gusanos y virus siempre habían tenido un efecto obvio en las

Seguridad de Servicios de Red Página 17

 computadoras, no en el hardware. Eventualmente, los científicos iraníes
sufrieron de baja moral, pensando que no podían hacer nada bien; setenta
años antes, un grupo de estadounidenses había construido una bomba
atómica usando reglas de cálculo, y ni siquiera podían hacer funcionar sus
equipos mucho más modernos.

Fig. 6: Diagrama de funcionamiento de Stuxnet

Seguridad de Servicios de Red Página 18

6. PROTECCIÓN DE SISTEMAS SCADA
Los estándares y soluciones ampliamente utilizados para asegurar los
sistemas de TI son a menudo inadecuados para el entorno de control de
procesos industriales. Aunque los sistemas de control de procesos se basan
ahora frecuentemente en tecnologías de TI estándar, sus entornos operativos
difieren significativamente del entorno de TI corporativo. Aunque se pueden
utilizar algunas herramientas y técnicas de seguridad estándar para proteger
los sistemas de control de procesos, es posible que necesiten una aplicación
o adaptación cuidadosa. Otras medidas de seguridad pueden ser
completamente inapropiadas o no estar disponibles para su uso en un
entorno de control.

Por ejemplo, puede que no sea posible instalar protección antivirus en los
sistemas de control de procesos, debido a la falta de potencia de los
procesadores en los sistemas heredados, la antigüedad de los sistemas
operativos o la falta de certificación de los proveedores. Además, las pruebas
de seguridad en los sistemas de control de procesos también deben
abordarse con extrema precaución: un escaneo de seguridad puede afectar
seriamente el funcionamiento de muchos dispositivos de control 9. Rara vez
existen entornos de prueba dedicados y hay pocas oportunidades de
desconectar los sistemas para realizar pruebas, parches y mantenimiento de
rutina.

6.1. Pasos para proteger un sistema SCADA

Estos son algunos pasos básicos para proteger una red SCADA y sus
componentes:

6.1.1. Establecer un marco de seguridad para el control de procesos

La elaboración de un marco de seguridad para cualquier sistema no es
sólo cuestión de implementar medidas de protección. Es importante ser
capaz de detectar posibles ataques y responder de forma adecuada para
minimizar los impactos.

9Esto debido a limitantes de procesamiento, memoria e inclusive implementaciones reducidas

de protocolos de red.

Seguridad de Servicios de Red Página 19

 Proteger: Implementar medidas de protección específicas para prevenir
y desalentar los ataques electrónicos contra los sistemas de control de
procesos.

Detectar: Establecer mecanismos para identificar rápidamente ataques

electrónicos reales o presuntos.

Responder: Emprender las acciones apropiadas en respuesta a

incidentes de seguridad confirmados contra los sistemas de control de
procesos.

6.1.2. Implementar defensa en profundidad

Cuando se ha desplegado una única medida de protección para proteger
un sistema, existe el riesgo de que, si se detecta y explota una
vulnerabilidad en esa medida, no se proporcione protección alguna.
Ninguna medida de seguridad en sí misma es infalible, ya que las
vulnerabilidades y debilidades pueden ser identificadas en cualquier
momento. Un modelo de seguridad mucho más eficaz es aprovechar los
beneficios del firewall corporativo con otro de control de procesos
dedicado y desplegar otras medidas de protección tales como software
antivirus y detección de intrusos. Este modelo de seguridad multicapa se
denomina defensa en profundidad.

6.1.3. Entender el riesgo del negocio

Una organización debe adquirir un conocimiento detallado de los riesgos
a los que se enfrenta la empresa, derivados de las amenazas a los
sistemas de control de procesos, con el fin de identificar e impulsar el nivel
adecuado de protección de la seguridad requerido. Para esto, debe:

Evaluar el riesgo del negocio: Entender los sistemas, las amenazas, el

impacto de estas y las vulnerabilidades del sistema.

Evaluar continuamente el riesgo de negocio: Cualquier cambio en los

parámetros del sistema podría cambiar el riesgo del negocio. En
consecuencia, se requiere un proceso continuo de gestión de riesgos para
identificar cualquiera de estos cambios, reevaluar el riesgo empresarial e
iniciar las mejoras de seguridad apropiadas.

Seguridad de Servicios de Red Página 20

 6.1.4. Implementar una arquitectura segura
Basándose en la evaluación del riesgo de negocio, las organizaciones
deben seleccionar e implementar medidas de protección técnicas,
procedimentales y de gestión para aumentar la seguridad de los sistemas
de control de procesos.

Fig. 7: Separación de redes: empresarial e industrial10

Estas medidas deben comprender (no solo) los siguientes puntos:

 identificar todos los puntos de conexión al sistema de control de

procesos, minimizarlos y de ser posible, separarlos de otras redes.
 Implementar infraestructura dedicada para sistemas de misión o de
control de procesos críticos para la seguridad.
 Eliminar, en la medida de lo posible, las conexiones TCP/IP entre
sistemas de seguridad (por ejemplo, sistemas de parada de

10 Tomada de https://www.thalesgroup.com/sites/default/files/asset/document/thales-cyber-
security-for-scada-systems.pdf

Seguridad de Servicios de Red Página 21

 emergencia) y sistemas de control de procesos u otras redes. Cuando
esto no sea posible, deberá realizarse un análisis de riesgos.
 Implementar firewalls con reglas bastante estrictas, manteniendo
estrictos controles de cambios, administración y monitoreo.
 Identificar todas las posibles formas de acceso remoto, ya sea a través
de VPN o módems; reducirlas al mínimo posible y las que queden
deben contar con una justificación válida. Todas las conexiones
remotas deben usar autenticación fuerte, y deben ser auditadas
constantemente. De ser posible, se debe restringir las conexiones
remotas a horarios, usuarios y equipos específicos.
 Realizar un “hardening” de los sistemas de control de procesos:
deshabilitar servicios y puertos no usados (tales como servidores web
incrustados). De ser posible, se debe deshabilitar el uso de medios
removibles como disquetes, CDs o memorias USB. Si se presenta la
necesidad de usarlas, debe existir procedimientos para su revisión
previo a su uso.
 Mantener un backup actualizado tanto de las configuraciones como de
las estaciones de trabajo desde donde se monitorean los sistemas de
control de procesos. Asimismo, estos respaldos deben ser probados
regularmente.
 Se debe implementar los controles adecuados de seguridad física,
para proteger los sistemas de ataques físicos y acceso no autorizado.
 Monitorear la red de los sistemas de control de procesos para poder
identificar comportamientos inusuales, que podrían estar ligados a
actividad maliciosa; esto debe estar apoyado por IDS e IPS, pero
diseñados o configurados para entornos de control de procesos
industriales.
 El uso de redes inalámbricas para comunicación de dispositivos de
control industrial debe ser evaluado cuidadosamente, teniendo en
cuenta la relación riesgo / beneficio que conlleva. Si se opta por
implementar comunicación inalámbrica, se debe verificar que los
mecanismos de seguridad de esta sean comprendidos y
correctamente configurados.

Seguridad de Servicios de Red Página 22

  El manejo de usuarios y contraseñas debe ser tan o más estricto que
el de sistemas de negocio.
 Documentar: inventario de sistemas de control, el marco que provee la
seguridad; este debe incluir el detalle de la evaluación de riesgos, las
presunciones hechas, vulnerabilidades conocidas y las medidas de
seguridad desplegadas.
 Infraestructura: redes redundantes, ambientes adecuados y de ser
necesario, sistemas anti incendios.
 Administración de cambios: todos los sistemas deben estar sujetos a
un estricto proceso de control de cambios, el cual debe incluir una
evaluación de seguridad de tales cambios

6.1.5. Establecer capacidades de respuesta

Las amenazas a la seguridad y al funcionamiento de los sistemas de
control de procesos se desarrollan y evolucionan con el tiempo, por lo que
las organizaciones deben realizar una evaluación continua de la seguridad
de sus sistemas. Esto incluye la identificación, evaluación y capacidad de
reacción ante nuevas vulnerabilidades, cambios en las amenazas de
seguridad e incidentes de seguridad electrónica (por ejemplo, ataques de
gusanos o hackers). El establecimiento de procesos formales de gestión
de respuestas garantiza que cualquier cambio en los riesgos se identifique
lo antes posible y se adopten rápidamente las medidas correctivas
necesarias.

6.1.6. Definir Roles

El personal de empresa debe comprender las expectativas específicas
asociadas con la protección de los recursos de tecnología de la
información mediante la definición de funciones y responsabilidades
claras y lógicas. Además, el personal clave debe tener suficiente autoridad
para llevar a cabo las responsabilidades que se le han asignado. Con
demasiada frecuencia, la buena seguridad cibernética se deja a la
iniciativa del individuo, lo que suele dar lugar a implementaciones
incoherentes y a una seguridad ineficaz. Se debe establecer una
estructura organizativa de seguridad cibernética que defina funciones y

Seguridad de Servicios de Red Página 23

 responsabilidades e identifique claramente cómo se intensifican los
problemas de seguridad cibernética y a quién se notifica en caso de
emergencia. Por tanto, es importante que las personas rindan cuentas de
su desempeño en lo que respecta a la ciberseguridad. Esto incluye
gerentes, administradores de sistemas, técnicos y usuarios/operadores.

6.1.7. Mejorar el conocimiento y las habilidades

Un enfoque holístico de la seguridad incluye la apreciación técnica,
procedimental y social; el éxito de cualquier medida de protección de la
seguridad técnica o procedimental depende en última instancia del
componente humano. Los empleados son a la vez el recurso más
importante y la mayor amenaza para la seguridad. El personal de sistemas
de control de procesos a menudo no está familiarizado con la seguridad
de TI y el personal de seguridad de TI a menudo no está familiarizado con
los sistemas de control de procesos y su entorno operativo. Esta situación
puede mejorarse aumentando la comprensión a través de programas
generales de sensibilización y educación y aumentando las habilidades a
través de la capacitación.

Seguridad de Servicios de Red Página 24

7. CONCLUSIONES Y RECOMENDACIONES
Los sistemas SCADA se utilizan para controlar y monitorear los procesos
industriales, como por ejemplo la transmisión de electricidad, el transporte de
gas y petróleo en oleoductos, la distribución de agua, los semáforos y otros
sistemas utilizados como base de la sociedad moderna. La seguridad de estos
sistemas SCADA es importante porque el compromiso o la destrucción de estos
sistemas impactaría múltiples áreas de la sociedad muy lejos del incidente
original. Por ejemplo, un apagón causado por un sistema SCADA eléctrico
comprometido causaría pérdidas financieras a todos los clientes que recibieron
electricidad de esa fuente. Queda por ver cómo afectará la seguridad al SCADA
heredado y a las nuevas implementaciones.

Las redes SCADA tienen ya más de 50 años de existencia, habiendo sido

optimizadas para dar confiabilidad y seguridad, pero en la operación de procesos
industriales donde los tiempos de respuesta y la precisión de las señales de
control son críticos para la ejecución de los procesos. Sin embargo, debido a la
necesidad de conectar estos sistemas con otros, o inclusive para poder
monitorearlos a distancia, se hizo necesario transmitir esta información a través
de redes de uso público, como Internet.

El campo de la seguridad informática en relación con los sistemas SCADA y de

control industrial es bastante complejo, y las consecuencias de ignorar las
amenazas o implementar controles inadecuados pueden tener consecuencias
significativas, tal vez con la pérdida de vidas humanas si se lanza un ataque que
logra el objetivo final.

La seguridad informática y de SCADA es ahora una de las principales

preocupaciones de todas las infraestructuras industriales. La naturaleza de la
amenaza exige una toma de decisiones rápida, precisa e informada para
garantizar que la seguridad, la protección y la eficacia operativa se mantengan
independientemente de cualquier incidente o accidente que pueda ocurrir. Esto
requiere la aplicación de soluciones de seguridad holísticas, proporcionadas por
organizaciones especializadas que sean capaces de proporcionar sistemas de
seguridad integrados diseñados específicamente para hacer frente a las

Seguridad de Servicios de Red Página 25

crecientes amenazas y garantizar que las operaciones críticas reciban la mejor
protección.

Este trabajo pretende demostrar que las industrias y servicios vulnerables deben
adoptar un enfoque holístico para proteger sus sistemas SCADA. Las
vulnerabilidades de TI informáticas, físicas e industriales interrelacionadas deben
gestionarse con eficacia desde el principio para hacer frente a las nuevas
amenazas.

Seguridad de Servicios de Red Página 26

8. BIBLIOGRAFÍA
Thales Security Group: Cyber Security for SCADA Systems,
https://www.thalesgroup.com/sites/default/files/asset/document/thales-cyber-
security-for-scada-systems.pdf

Departamento de Energía de los EEUU:

21 Steps to Improve Cyber Security of SCADA Networks:
https://www.energy.gov/sites/prod/files/oeprod/DocumentsandMedia/21_Steps_
-_SCADA.pdf

Bonnie Zhu, Anthony Joseph, Shankar Sastry: A Taxonomy of Cyber Attacks on

SCADA Systems, Department of Electrical Engineering and Computer Sciences
University of California at Berkeley, CA,
https://people.eecs.berkeley.edu/~adj/publications/paper-
files/ZhuJosephSastry_SCADA_Attack_Taxonomy_FinalV.pdf

Kyle Wilhoit: Trend Micro research paper: The SCADA That Didn’t Cry Wolf,
https://scadahacker.com/files/reference/BH_US13-Trend-The-SCADA-That-
Didnt-Cry-Wolf-Whos-Really-Attacking-Your-ICS-Devices-Slides.pdf

Centre for the Protection of National Infrastructure, UK: Good Practice Guide -
Process Control and SCADA Security,
https://scadahacker.com/library/Documents/Best_Practices/CPNI%20-
%20GPG%20-
%2000%20Process%20Control%20and%20SCADA%20Security.pdf

Department of Homeland Security - NCCIC/ICS-CERT: Seven Steps to

Effectively Defend Industrial Control Systems,
https://scadahacker.com/library/Documents/Best_Practices/DHS%20-
%207%20Steps%20to%20Effectively%20Defend%20Industrial%20Control%20
Systems.pdf

John Maddison, Fortinet: Innovation Insights: Defending Today’s OT (Operational

Technology) Environments, https://www.fortinet.com/blog/business-and-
technology/executive-insights-defending-today-s-ot-environments.html

Seguridad de Servicios de Red Página 27