Guía de Industriales

Sistemas de Control
(ICS) Seguridad
Sistemas de control de supervisión y adquisición de datos (SCADA), sistemas de
control distribuido (DCS) y otras configuraciones de sistemas de control, como
controladores lógicos programables(SOCIEDAD ANÓNIMA)

Kei
th
Stouffer
Victori
a
Pillitter
i
Suzann
e
Lightm
an
Marsha
ll
Abrams
Adán Hahn
 Esta publicación está disponible de forma gratuita en:
http://dx.doi.org/10.6028/NIST.SP.800-82r2

Guía de Control Industrial

Sistemas
(ICS)
Seguridad
De supervisor Controlar y Datos Adquisición (SCADA) sistemas, Repartido Controlar Sistemas (DCS),
y Otras configuraciones del sistema de control, como los controladores lógicos
programables. (SOCIEDAD ANÓNIMA)
 K
eith Stouffer
Inteligente
Sistemas
División
Ingenieria
Laboratorio

V
ictoria
Pillitteri
Suzanne
Hombre
ligero La
seguridad
informática
División
Tecnologías de la información Laboratorio

Marshall Abrams
El MITRE Sociedad

Adán Hahn
Estado de washington Universidad

Esta publicación está disponible de forma gratuita en:

http://dx.doi.org/10.6028/NIST.SP.800-82r2

Mayo 2015

Departamento de Comercio
Penny Pritzker, Secretario

Instituto Nacional de Normas y Tecnología

Willie May, Subsecretaria de Comercio para Estándares y Tecnología y Director
 Autoridad

Esta publicación ha sido desarrollada por NIST para cumplir con sus responsabilidades legales
conforme a la Ley Federal de Modernización de la Seguridad de la Información (FISMA) de 2014,
44 USC § 3541 et seq. , Derecho Público (PL) 113-283. El NIST es responsable de desarrollar
estándares y pautas de seguridad de la información, incluidos los requisitos mínimos para los
sistemas de información federales, pero dichos estándares y pautas no se aplicarán a los sistemas de
seguridad nacional sin la aprobación expresa de los funcionarios federales apropiados que ejercen la
autoridad política sobre dichos sistemas. Esta guía es consistente con los requisitos de la Circular A-
130 de la Oficina de Administración y Presupuesto (OMB), Sección 8b (3), Sistemas de
Información de la Agencia de Aseguramiento , según se analiza en la Circular A-130, Apéndice IV:
Análisis de Secciones Clave .
La información complementaria se proporciona en la Circular A-130, Apéndice III, Seguridad de
los recursos federales de información automatizada .

No debe tomarse nada en esta publicación para contradecir las normas y directrices obligatorias y
vinculantes para las agencias federales por el Secretario de Comercio bajo la autoridad legal.
Tampoco se deben interpretar estas pautas como alterar o reemplazar a las autoridades existentes del
Secretario de Comercio, Director de la OMB o cualquier otro funcionario federal. Esta publicación
puede ser utilizada por organizaciones no gubernamentales de forma voluntaria y no está sujeta a
derechos de autor en los Estados Unidos. La atribución, sin embargo, sería apreciada por el NIST.

Publicación especial del Instituto Nacional de Estándares y Tecnología

800-82, Revisión 2 Nacional . Inst. Estar. Tecnol. Especulación. Publ. 800-
82, Rev. 2, 247 páginas (mayo de 2015)

Esta publicación está disponible

de forma gratuita en:
http://dx.doi.org/10.6028/NIST.S
P.800-82r2 CODEN: NSPUE2

Los comentarios sobre esta publicación pueden ser enviados a:

Instituto Nacional de Estándares y Tecnología
 A la atención de: División de Seguridad Informática,
Laboratorio de Tecnología de la Información 100
Bureau Drive (Mail Stop 8930) Gaithersburg, MD
20899-8930 Correo electrónico: nist800-
82rev2comments@nist.gov

Informes sobre tecnología de sistemas informáticos

El Laboratorio de Tecnología de la Información (DIT) del Instituto Nacional de Estándares y

Tecnología (NIST) promueve la economía estadounidense y el bienestar público, proporcionando
liderazgo técnico para la infraestructura de medición y estándares de la ación N. ITL desarrolla
pruebas, métodos de prueba, datos de referencia, implementaciones de prueba de concepto y análisis
técnicos para avanzar en el desarrollo y uso productivo de la tecnología de la información.
Responsabilidades de ITL incluyen el desarrollo de la gestión, las normas administrativas, técnicas y
físicas y las directrices para la seguridad económica y la privacidad de otra que la información
relacionada con la seguridad nacional en los sistemas de información EDERAL f. La Publicación
Especial serie 800 informa sobre la investigación, las pautas y los esfuerzos de divulgación de ITL
en la seguridad del sistema de información y sus actividades de colaboración con la industria, el
gobierno y las organizaciones académicas.

Resumen
Este documento proporciona una guía sobre cómo proteger los Sistemas de control industrial
(ICS), incluidos los Sistemas de control de supervisión y Adquisición de datos (SCADA),
los Sistemas de control distribuido (DCS) y otras configuraciones de sistemas de control
como los Controladores lógicos programables (PLC), mientras abordan sus Requisitos
únicos de rendimiento, fiabilidad y seguridad. El documento proporciona una descripción
general de ICS y las topologías típicas de los sistemas, identifica las amenazas y
vulnerabilidades típicas de estos sistemas y proporciona las medidas de seguridad
recomendadas para mitigar los riesgos asociados.

Palabras clave

La seguridad informática; sistemas de control distribuido (DCS); sistemas de control

industrial (ICS); seguridad de información; red seguridad; programable lógica
controladores (SOCIEDAD ANÓNIMA); riesgoadministración; seguridad controles;
Control de supervisión y adquisición de datos (SCADA). sistemas
 Agradecimientos por la Revisión 2

Los autores reconocen con gratitud y aprecian las contribuciones significativas de

individuos y organizaciones en los sectores público y privado, cuyos comentarios
reflexivos y constructivos mejoraron la calidad general, la minuciosidad y la utilidad de
esta publicación. Un reconocimiento especial a Lisa Kaiser, Departamento de Seguridad
Nacional, el Grupo de Trabajo Conjunto del Sistema de Control Industrial del
Departamento de Seguridad Nacional (ICSJWG) y la Oficina del Subsecretario de
Defensa para Instalaciones y Medio Ambiente, personal de la Dirección de Integración de
Empresas Comerciales, Daryl Haegley y Michael Chipley, por sus excepcionales
contribuciones a esta publicación.

Agradecimientos por versiones anteriores

Los autores originales, Keith Stouffer, Joe Falco y Karen Scarfone de NIST, desean
agradecer a sus colegas que revisaron los borradores de la versión original del
documento y contribuyeron a su contenido técnico.Los autores desean especialmente
reconocer a Tim Grance, Ron Ross, Stu Katzke y Freemon Johnson de NIST por su
asistencia aguda y perspicaz a lo largo del desarrollo del documento. Los autores
también reconocen con gratitud y aprecian las numerosas contribuciones de los sectores
público y privado cuyos comentarios reflexivos y constructivos mejoraron la calidad y la
utilidad de la publicación. Los autores agradecen especialmente a los miembros de
ISA99. Los autores también desean agradecer al Centro Nacional de Protección de
Infraestructura Nacional (CPNI) del Reino Unido por permitir que partes de la Guía de
Buenas Prácticas sobre Implementación de Cortafuegos para SCADA y la Red de
Control de Procesos se utilicen en el documento, así como a ISA por permitir partes de
las Normas ISA-62443 que se utilizarán en el documento.

Nota para los lectores

Este documento es la segunda revisión de NIST SP 800-82, Guía para la seguridad de

los sistemas de control industrial (ICS). Las actualizaciones en esta revisión incluyen:

Actualizaciones a las amenazas y vulnerabilidades de ICS.

Actualizaciones a la gestión de riesgos de ICS, prácticas

recomendadas y arquitecturas. Actualizaciones a las
actividades actuales en seguridad ICS.
Actualizaciones de capacidades y herramientas de seguridad para ICS.
Alineación adicional con otros estándares y pautas de seguridad de ICS.
Nueva guía de adaptación para NIST SP 800-53, Revisión 4 controles de
seguridad, incluida la introducción de superposiciones.
Una superposición de ICS para los controles de seguridad NIST SP 800-53,
Revisión 4 que proporciona líneas de base de control de seguridad personalizadas
para ICS de bajo, moderado y alto impacto.
 Tabla de contenido

Ejecutivo Resumen 1
1. Introducción 1-1
1.1 Propósito y Alcance 1-1
1.2 Audiencia 1-1
1.3 Documento Estructura 1-2
2. Descripción de Industrial Controlar Sistemas 2-1
2.1 Evolución de la industria Controlar Sistemas 2-1
2.2 Sectores Industriales ICS y Su Interdependencias 2-2
2.2.1 Fabricación Industrias 2-2
2.2.2 Distribución Industrias 2-2
2.2.3 Las diferencias entre la fabricación y Distribución ICS 2-2
2.2.4 ICS y crítico Infraestructura Interdependencias 2-2
2.3 Operación ICS y Componentes 2-3
2.3.1 Sistema de ICS Diseño Consideraciones 2-4
2.3.2 SCADA Sistemas 2-5
2.3.3 Repartido Controlar Sistemas 2-10
2.3.4 Controlador lógico programable Basado Topologias 2-12
2.4 Comparando ICS y IT Sistemas Seguridad 2-14
2.5 Otros tipos de Controlar Sistemas 2-17
3. Gestión de Riesgos ICS y Evaluación 3-1
3.1 Gestión de riesgos 3-1
3.2 Introducción al Riesgo administración Proceso 3-2
3.3 Consideraciones especiales para hacer un ICS Evaluación de riesgos
3-4
3.3.1 Seguridad dentro de un ICS Seguridad de la información Riesgo Evaluación
3-4
3.3.2 Impactos físicos potenciales de una ICS Incidente 3-5
3.3.3 Impacto de la interrupción física de un ICS Proceso 3-5
3.3.4 Incorporando aspectos no digitales de ICS en Impacto Evaluaciones
3-6
3.3.5 Incorporando el impacto de La seguridad Sistemas 3-7
3.3.6 Considerando la propagación del impacto a Conectado Sistemas 3-
7
 4. Desarrollo del programa de seguridad de ICS y Despliegue
4-1
4.1 Caso de negocio para Seguridad 4-2
4.1.1 Beneficios 4-2
4.1.2 Potencial Consecuencias 4-3
4.1.3 Recursos para la construcción Caso de negocio 4-4
4.1.4 Presentando el caso de negocio a Liderazgo 4-4
4.2 Construir y entrenar a Multifuncional Equipo 4-5
4.3 Definir Carta y Alcance 4-5
4.4 Definir políticas de seguridad específicas de ICS y Procedimientos 4-6
4.5 Implementar un riesgo de seguridad ICS administración Marco de referencia
4-6
4.5.1 Categorizar sistemas ICS y Redes Bienes 4-7
4.5.2 Seleccione ICS Seguridad Controles 4-7
4.5.3 Realizar Evaluación de riesgos 4-8
4.5.4 Implementar el Seguridad Controles 4-8

5. ICS Seguridad Arquitectura 5-1

5.1 Segmentación de la red y Segregación 5-1
5.2 Límite Proteccion 5-3
5.3 Cortafuegos 5-4
5.4 Lógicamente Separado Controlar Red 5-6
5.5 Red Segregación 5-7
5.5.1 Equipo dual / interfaz de red dual Tarjetas (NIC) 5-7
5.5.2 Cortafuegos entre la red corporativa y Controlar Red 5-7
5.5.3 Cortafuegos y enrutador entre red corporativa y Controlar Red
5-9
5.5.4 Cortafuegos con DMZ entre Red Corporativa y Controlar Red
5-10
5.5.5 Cortafuegos entre redes corporativas y Controlar Red 5-
12
5.5.6 Segregación de red Resumen 5-13
5.6 Recomendado Defensa en profundidad Arquitectura 5-13
5.7 Políticas generales de firewall para ICS 5-14
5.8 Reglas de cortafuegos recomendadas para Específico Servicios 5-16
5.8.1 Nombre de dominio Sistema (DNS) 5-17
5.8.2 Transferencia de Hipertexto Protocolo (HTTP) 5-17
5.8.3 Transferencia de archivos FTP y Trivial Protocolo (TFTP) 5-17
5.8.4 Telnet 5-17
5.8.5 Configuración dinámica del host Protocolo (DHCP) 5-18
5.8.6 Seguro Cáscara (SSH) 5-18
5.8.7 Acceso a objetos simples Protocolo (JABÓN) 5-18
5.8.8 Transferencia de correo simple Protocolo (SMTP) 5-18
5.8.9 Gestión de red simple Protocolo (SNMP) 5-18
5.8.10 Objeto componente distribuido Modelo (DCOM) 5-19
5.8.11 SCADA y Industrial Protocolos 5-19
5,9 Dirección de red Traducción (NAT) 5-19
5,10 ICS específico Cortafuegos Cuestiones 5-20
5.10.1 Historiadores de datos 5-20
 5.10.2 Remoto Apoyo Acceso 5-20
5.10.3 Multidifusión Tráfico 5-20
5.11 Unidireccional Puertas de acceso 5-21
5.12 Puntos individuales de Fracaso 5-21
5.13 Redundancia y Culpa Tolerancia 5-21
5.14 Previniendo Hombre en el medio Los ataques 5-22
5.15 Autenticación y Autorización 5-24
5.15.1 ICS Implementación Consideraciones 5-25
5.16 Monitoreo, Registro, y Revisión de cuentas 5-25
5,17 Detección de incidentes, respuesta y Sistema Recuperación
5-25
6. Aplicando controles de seguridad a ICS 6-1
6.1 Ejecución de las tareas del Marco de Gestión de Riesgos para el
Control Industrial. Sistemas 6-1 6.1.1 Paso 1: Categorizar
Información Sistema 6-2
6.1.2 Paso 2: Seleccione Seguridad Controles 6-4
6.1.3 Paso 3: Implementar Seguridad Controles 6-5
6.1.4 Paso 4: Evaluar Seguridad Controles 6-5
6.1.5 Paso 5: Autorizar Información Sistema 6-5
6.1.6 Paso 6: Monitor Seguridad Controles 6-6
6.2 Orientación sobre la aplicación de los controles de seguridad. a ICS
6-6
6.2.1 Control de acceso 6-8

6.2.2 Conciencia y Formación 6-13

6.2.3 Auditoría y Responsabilidad 6-13
6.2.4 Evaluacion de seguridad y Autorización 6-15
6.2.5 Configuración administración 6-15
6.2.6 Contingencia Planificación 6-16
6.2.7 Identificación y autenticación 6-19
6.2.8 Respuesta al incidente 6-25
6.2.9 Mantenimiento 6-27
6.2.10 Medios de comunicación Proteccion 6-27
6.2.11 Física y Protección del medio ambiente 6-28
6.2.12 Planificación 6-31
6.2.13 Personal Seguridad 6-32
6.2.14 Riesgo Evaluación 6-33
6.2.15 Adquisición de sistemas y servicios 6-33
6.2.16 Protección de sistemas y comunicaciones 6-34
6.2.17 Sistema y Información Integridad 6-38
6.2.18 Programa administración 6-41
6.2.19 Intimidad Controles 6-41
 Lista de apendices

Apéndice A— Siglas y Abreviaturas A-1

Apéndice B: Glosario de términos ............................................
................................................ B-1
Apéndice C: Fuentes de amenazas, vulnerabilidades y Incidentes
................................................. .C-1

Apéndice D: Actividades actuales en la seguridad del sistema de control industrial

.................................... D-1 Apéndice E— Capacidades y herramientas de seguridad
de ICS .......................................... ........................ E-1 Apéndice F— Referencias
.............................................. .................................................. ....... F-1
Apéndice G— Superposición de ICS ..................................................
.................................................. .G-1

Lista de Figuras

Figura 2-1. ICS Operación 2-4

Figura 2-2. Sistema SCADA General Diseño 2-6
Figura 2-3. SCADA básico Comunicación Topologias 2-7
Figura 2-4. SCADA grande Comunicación Topología 2-8
Figura 2-5. Ejemplo de implementación del sistema SCADA (Monitoreo de distribución
y Controlar) 2-9
Figura 2-6. Ejemplo de Implementación del Sistema SCADA (Monitoreo Ferroviario y
Controlar) 2-10
Figura 2-7. DCS Ejemplo de implementación 2-12
Figura 2-8. Sistema de Control PLC Implementación Ejemplo 2-13
Tabla 2-1. Resumen del sistema de TI y Diferencias de ICS 2-16

Figura 3-1. Proceso de gestión de riesgos aplicado la Niveles 3-2

Tabla 3-1. Categorías de ICS no digitales Controlar Componentes 3-6
Figura 5-1. Cortafuegos entre la red corporativa y Controlar Red 5-8
Figura 5-2. Cortafuegos y enrutador entre red corporativa y Controlar Red 5-9
Figura 5-3. Cortafuegos con DMZ entre Red Corporativa y Controlar Red 5-10
 Figura 5-4. Cortafuegos entre redes corporativas y Controlar Red 5-12
Figura 5-5. CSSP Recomendado Defensa en profundidad Arquitectura 5-14
Figura 6-1. Gestión de riesgos Marco de referencia Tareas 6-2
Tabla 6-1. Definiciones posibles para niveles de impacto de ICS basados en ISA99
6-3
Tabla 6-2. Definiciones posibles para los niveles de impacto de ICS según el producto
producido, la industria y Seguridad Preocupaciones 6-4
Figura C-1. Incidentes reportados ICS-CERT por año ..................................................
............ C-11
Tabla G-1 de control de seguridad de líneas de base ..................................................
................................... G-3
Figura G-1 Especificaciones detalladas de control de superposición ilustradas
.............................................. G-13

Lista de mesas

Tabla C-1. Amenazas al ICS ..................................................

.................................................. ... C-1

Tabla C-2. Políticas y procedimientos Vulnerabilidades y condiciones

predisponentes ........................ C-4 Tabla C-3. Vulnerabilidades de arquitectura y
diseño y condiciones predisponentes .................... C-6 Tabla C-4. Vulnerabilidades
de configuración y mantenimiento y condiciones predisponentes ........ C-6 Tabla C-
5. Vulnerabilidades físicas y condiciones predisponentes
............................................ C -8 Tabla C-6. Vulnerabilidades de desarrollo de
software y predisposición Condiciones ...................... C-9
Tabla C-7. Vulnerabilidades de comunicación y configuración de red y predisposición
Condiciones .................................................. ..................................................
................... C-9
Tabla C-8. Ejemplo Adversarial Incidentes .................................................
............................ C-10

Ejecutivo Resumen

Este documento proporciona una guía para establecer sistemas de control industrial seguros
(ICS). Estos ICS, que incluyen sistemas de control de supervisión y adquisición de datos
(SCADA), sistemas de control distribuido (DCS) y otras configuraciones de sistemas de
control tales como Controladores lógicos programables (PLC) se encuentran a menudo en
los sectores de control industrial. Los ICS se utilizan normalmente en industrias tales como
electricidad, agua y aguas residuales, petróleo y gas natural, transporte, productos químicos,
farmacéuticos, pulpa y papel, alimentos y bebidas, y manufactura discreta (por ejemplo,
bienes automotrices, aeroespacial y bienes duraderos). Sistemas SCADA se utilizan
generalmente para controlar activos dispersos mediante la adquisición de datos centralizada
y el control de supervisión. Los DCS se usan generalmente para controlar los sistemas de
producción dentro de un área local, como una fábrica que usa control supervisor y
regulatorio. Los PLC se utilizan generalmente para el control discreto para aplicaciones
específicas y generalmente proporcionan control regulatorio. Estos sistemas de control son
vitales para el funcionamiento de las infraestructuras críticas de los EE. UU. Que a menudo
son sistemas altamente interconectados y mutuamente dependientes. Es importante tener en
cuenta que aproximadamente el 90 por ciento de las infraestructuras críticas de la nación
son de propiedad y operación privada. Las agencias federales también operan muchos de los
ICS mencionados anteriormente; otros ejemplos incluyen control de tráfico aéreo y manejo
de materiales (por ejemplo, manejo de correo del Servicio Postal). Este documento
proporciona una descripción general de estos ICS y las topologías típicas de los sistemas,
identifica las amenazas y vulnerabilidades típicas de estos sistemas y proporciona medidas
de seguridad recomendadas para mitigar los riesgos asociados. .

Inicialmente, ICS tenía poca semejanza con los sistemas tradicionales de tecnología de la
información (TI) en la medida en que los ICS eran sistemas aislados que ejecutaban
protocolos de control de propiedad utilizando hardware y software especializados. Muchos
componentes de ICS estaban en áreas con seguridad física y los componentes no estaban
conectados a redes o sistemas de TI. Los dispositivos de Protocolo de Internet (IP) de gran
disponibilidad y bajo costo ahora están reemplazando las soluciones propietarias, lo que
aumenta la posibilidad de vulnerabilidades e incidentes de ciberseguridad. A medida que
ICS está adoptando soluciones de TI para promover la conectividad de los sistemas
empresariales corporativos y las capacidades de acceso remoto, y se están diseñando e
implementando utilizando computadoras, sistemas operativos (OS) y protocolos de red
estándar de la industria, están empezando a parecerse a los sistemas de TI. Esta integración
admite nuevas capacidades de TI , pero proporciona un aislamiento significativamente
menor para ICS del mundo exterior que los sistemas anteriores, lo que crea una mayor
necesidad de proteger estos sistemas. El uso creciente de redes inalámbricas pone a las
implementaciones de ICS en mayor riesgo por adversarios que se encuentran en una
proximidad física relativamente cercana pero que no tienen acceso físico directo al equipo.
Si bien las soluciones de seguridad se han diseñado para tratar estos problemas de seguridad
en los sistemas de TI típicos, se deben tomar precauciones especiales al introducir estas
mismas soluciones en los entornos de ICS. En algunos casos, se necesitan nuevas soluciones
de seguridad que se adapten al ICS ambiente.

Aunque algunas características son similares, los ICS también tienen características que
difieren de los sistemas tradicionales de procesamiento de información. Muchas de estas
diferencias se derivan del hecho de que la lógica ejecutada en ICS tiene un efecto directo en
el mundo físico. Algunas de estas características incluyen un riesgo significativo para la
salud y la seguridad de las vidas humanas y daños graves al medio ambiente, así como
problemas financieros graves, como pérdidas de producción, impacto negativo en la
economía de una nación y compromiso de información confidencial. Los ICS tienen
requisitos únicos de rendimiento y confiabilidad y, con frecuencia, utilizan sistemas
operativos y aplicaciones que pueden considerarse poco convencionales para el personal de
TI típico. Además, los objetivos de seguridad y eficiencia a veces entran en conflicto con la
seguridad en el diseño y operación de los sistemas de control.

Los programas de seguridad cibernética de ICS siempre deben formar parte de programas
de seguridad y confiabilidad de ICS más amplios en los sitios industriales y en los
programas de seguridad cibernética de las empresas, ya que la seguridad cibernética es
esencial para el funcionamiento seguro y confiable de los procesos industriales modernos.
Las amenazas a los sistemas de control pueden provenir de numerosas fuentes, incluidos
gobiernos hostiles, grupos terroristas, empleados descontentos, intrusos maliciosos,
complejidades, accidentes y desastres naturales, así como acciones malintencionadas o
accidentales por parte de personas con información privilegiada. Los objetivos de
seguridad de ICS generalmente siguen la prioridad de disponibilidad e integridad, seguidos
de la confidencialidad.

Los posibles incidentes que un ICS puede enfrentar incluyen los siguientes:

 Flujo de información bloqueado o retrasado a través de las redes de ICS, que podría
interrumpir el ICS operación.
 Cambios no autorizados a las instrucciones, comandos o umbrales de alarma, que
podrían dañar, deshabilitar o apagar equipos, crear impactos ambientales y / o poner
en peligro a personas. vida.
 Información inexacta enviada a los operadores del sistema, ya sea para disfrazar
cambios no autorizados o para hacer que los operadores inicien acciones inapropiadas,
que podrían tener varios efectos negativos.efectos
 Se modificó el software de ICS o los ajustes de configuración, o el software de ICS
se infectó con malware, lo que podría tener varios aspectos negativos. efectos
 Interferencia con el funcionamiento de los sistemas de protección de equipos, que
podrían poner en peligro costosos y difíciles de reemplazar. equipo.

 Interferencia con el funcionamiento de los sistemas de seguridad,

que podrían poner en peligro los vida.

Los principales objetivos de seguridad para una implementación de ICS

deben incluir los siguientes

:
 Restricción del acceso lógico a la red de ICS y la actividad de la red. Esto
puede incluir el uso de pasarelas unidireccionales, una arquitectura de red de zona
desmilitarizada (DMZ) con firewalls para evitar que el tráfico de red pase
 directamente entre las redes corporativas e ICS, y tener mecanismos y credenciales
de autenticación separados para los usuarios de las redes corporativas e ICS. El ICS
también debe usar una topología de red que tenga múltiples capas, con las
comunicaciones más importantes que se producen de la manera más segura y
confiable. capa.
 Restricción del acceso físico a la red y dispositivos de ICS. El acceso físico no
autorizado a los componentes podría causar una interrupción grave de la
funcionalidad del ICS. Se debe usar una combinación de controles de acceso
físico, como cerraduras, lectores de tarjetas y / o guardias
 Proteger los componentes individuales de ICS de la explotación. Esto incluye
implementar parches de seguridad de la manera más rápida posible, después de
probarlos en condiciones de campo; deshabilitar todos los puertos y servicios no
utilizados y garantizar que permanezcan deshabilitados; restringir los privilegios de
usuario de ICS a solo aquellos que son necesarios para el rol de cada persona;
seguimiento y seguimiento de pistas de auditoría; y el uso de controles de seguridad
como el software antivirus y el software de comprobación de la integridad de los
archivos donde sea técnicamente posible prevenir, disuadir, detectar y mitigar malware
 Restricción de la modificación no autorizada de datos. Esto incluye datos que
están en tránsito (al menos a través de los límites de la red) y en descanso.
 Detección de incidentes y eventos de seguridad. La detección de eventos de
seguridad, que aún no se han convertido en incidentes, puede ayudar a los defensores a
romper la cadena de ataque antes de que los atacantes alcancen sus objetivos. Esto
incluye la capacidad de detectar componentes ICS fallidos, servicios no disponibles y
agotados Los recursos que son importantes para proporcionar un funcionamiento
adecuado y seguro de la ICS.
 Mantener la funcionalidad en condiciones adversas. Esto implica diseñar el ICS
para que cada componente crítico tenga una contraparte redundante. Además, si un
componente falla, debería fallar de una manera que no genere tráfico innecesario en el
ICS u otras redes, o que no cause otro problema en otro lugar, como un evento en
cascada. El ICS también debe permitir una degradación elegante, como pasar de
"operación normal" con automatización completa a "operación de emergencia" con
operadores más involucrados y menos automatización a "operación manual" sin
automatización.

 Restaurando el sistema después de un incidente. Los incidentes son

inevitables y un plan de respuesta a incidentes es esencial. Una característica
importante de un buen programa de seguridad es la rapidez con que se puede
recuperar el sistema después de que se haya producido un incidente. ocurrió.
Para abordar adecuadamente la seguridad en un ICS, es esencial que un equipo de
ciberseguridad multifuncional comparta su variado conocimiento y experiencia de dominio
para evaluar y mitigar el riesgo para el ICS.El equipo de seguridad cibernética debe estar
compuesto por un miembro del personal de TI de la organización, ingeniero de control,
operador del sistema de control, experto en seguridad de redes y sistemas, un miembro del
personal de administración y un miembro del departamento de seguridad física como
mínimo. Para continuidad e integridad, el equipo de ciberseguridad debe consultar con el
proveedor del sistema de control y / o el integrador del sistema también. El equipo de
seguridad cibernética debe coordinar estrechamente con la administración del sitio (por
ejemplo, el superintendente de instalaciones) y el Director de información (CIO) o el
Director de seguridad (CSO) de la compañía, que a su vez, acepta la responsabilidad y la
responsabilidad completas de la seguridad cibernética del ICS, y para cualquier incidente de
seguridad, incidentes de confiabilidad o daños al equipo causados directa o indirectamente
por incidentes cibernéticos. Un programa de ciberseguridad efectivo para un ICS debe
aplicar una estrategia conocida como "defensa en profundidad", aplicando mecanismos de
seguridad de tal manera que se minimice el impacto de una falla en cualquier mecanismo.
Las organizaciones no deben confiar en la "seguridad por oscuridad".

En un ICS típico, esto significa una estrategia de defensa en profundidad que incluye:

 Desarrollar políticas de seguridad, procedimientos, capacitación y material

educativo que se aplique específicamente a la ICS.
 Considerando políticas y procedimientos de seguridad de ICS basados en el Aviso
de Seguridad Nacional Nivel de amenaza del sistema, implementando posturas de
seguridad cada vez más elevadas como el Nivel de amenaza aumenta
 Abordar la seguridad a lo largo del ciclo de vida del ICS desde el diseño de la
arquitectura hasta la adquisición, la instalación, el mantenimiento y el
desmantelamiento.
 Implementando una topología de red para el ICS que tiene múltiples capas,
con la mayoría de las comunicaciones críticas que se producen en la capa más
segura y confiable.
 Proporcionar separación lógica entre las redes corporativas e ICS (por
ejemplo, firewall (s) de inspección de estado entre las redes, pasarelas
unidireccionales).
 Emplear una arquitectura de red DMZ (es decir, evitar el tráfico directo entre las
redes corporativas e ICS).
 Asegurar que los componentes críticos sean redundantes y estén en redundancia redes
 Diseño de sistemas críticos para una degradación elegante (tolerante a fallas) para
evitar eventos catastróficos en cascada.
 Desactivar los puertos y servicios no utilizados en dispositivos ICS después de las
pruebas para asegurar que esto no afectará la operación de ICS.
 Restricción del acceso físico a la red ICS y dispositivos
 Restricción de los privilegios de usuario de ICS solo a aquellos que están
obligados a realizar el trabajo específico de su puesto (es decir, establecer un
 control de acceso basado en roles y configurar cada rol según el principio de
privilegios mínimos).
 Uso de mecanismos y credenciales de autenticación independientes para los
usuarios de la red de ICS y la red corporativa (es decir, las cuentas de red de ICS
no utilizan usuarios de la red corporativa).
 Usando tecnología moderna, como tarjetas inteligentes para la verificación de identidad
personal (PIV).
 Implementar controles de seguridad como el software de detección de intrusos,
software antivirus y software de verificación de integridad de archivos, donde sea
técnicamente posible, para prevenir, disuadir, detectar y mitigar la introducción,
exposición y propagación de software malicioso hacía, dentro y desde el ICS.
 Aplicación de técnicas de seguridad tales como cifrado y/o hashes criptográficos al
almacenamiento de datos y comunicaciones de ICS cuando se determine apropiado.
 Implementación rápida de parches de seguridad después de probar todos los
parches bajo condiciones de campo en un sistema de prueba si es posible, antes de
la instalación en el ICS.
 Seguimiento y monitoreo de los circuitos de auditoría en áreas críticas del ICS.
 Empleando protocolos y servicios de red confiables y seguros donde sea factible.

El Instituto Nacional de Estándares y Tecnología (NIST), en cooperación con la comunidad

de ICS del sector público y privado, ha desarrollado una guía específica sobre la aplicación
de los controles de seguridad en la Publicación Especial (SP) 800-53 del NIST, Revisión 4,
Controles de seguridad y privacidad para sistemas y organizaciones de información federal
[22], a ICS.

Si bien muchos controles en el Apéndice F de NIST SP 800-53 son aplicables a ICS tal
como están escritos, muchos controles requieren una interpretación y / o aumento
específicos de ICS al agregar uno o más de los siguientes al control:

 La Guía suplementaria de ICS proporciona a las organizaciones información

adicional sobre la aplicación de los controles de seguridad y las mejoras de control
en el Apéndice F del NIST SP 800-53 a ICS y los entornos en los que operan estos
sistemas especializados. La Guía complementaria también proporciona
información sobre por qué un control de seguridad particular o una mejora de
control puede no ser aplicable en algunos entornos de ICS y puede ser un
candidato para la adaptación (es decir, la aplicación de la guía de alcance y / o los
controles de compensación). La Guía suplementaria de ICS no reemplaza la Guía
suplementaria original en el Apéndice F de NIST SP 800-53.
 Mejoras de ICS (una o más) que proporcionan aumentos de mejora a la
Control original que puede ser requerido para algunos ICS.
 Guía complementaria de mejora de ICS que proporciona orientación
sobre cómo la mejora de control se aplica o no a ICS ambientes
El método más exitoso para asegurar un ICS es recopilar las prácticas recomendadas por la industria y participar
en un esfuerzo proactivo de colaboración entre la administración, el ingeniero de controles y el operador, la
organización de TI y un asesor de automatización confiable. Este equipo debe aprovechar la gran cantidad de
información disponible del gobierno federal en curso, los grupos de la industria, los proveedores y las
actividades organizativas de estándares que se enumeran en el Apéndice D—.
1. Introducción
1.1 Propósito y alcance
El propósito de este documento es proporcionar
una guía para asegurar los sistemas de control
industrial (ICS), incluidos los sistemas de control
de supervisión y adquisición de datos (SCADA),
los sistemas de control distribuido (DCS) y otros
sistemas que realizan funciones de control. El
documento proporciona una visión general
nocional de ICS, revisa las topologías y
arquitecturas típicas de los sistemas, identifica
las amenazas y vulnerabilidades conocidas de
estos sistemas y proporciona las medidas de
seguridad recomendadas para mitigar los riesgos
asociados. Además, presenta una superposición
de control de seguridad adaptada a ICS, basada
en NIST SP 800-53 Rev. 4 [22], para
proporcionar una personalización de los
controles según se aplican a las características
únicas del dominio ICS. El cuerpo del
documento proporciona contexto para la
superposición, pero la superposición está
diseñada para ser independiente.
Los ICS se encuentran en muchas industrias
tales como electricidad, agua y aguas
residuales, petróleo y gas natural, productos
químicos, farmacéuticos, pulpa y papel,
alimentos y bebidas, y manufactura discreta
(por ejemplo, bienes automotrices,
aeroespacial y bienes duraderos). Debido a
que hay muchos tipos diferentes de ICS con
diferentes niveles de riesgo e impacto
potencial, el documento proporciona una
lista de muchos métodos y técnicas
diferentes para asegurar el ICS. El
documento no debe utilizarse únicamente
como una lista de verificación para asegurar
un sistema específico.
Se recomienda a los lectores que realicen
una evaluación basada en el riesgo en sus
sistemas y que adapten las pautas y
soluciones recomendadas para cumplir
con sus requisitos específicos de
seguridad, negocios y operativos. El rango
de aplicabilidad de los conceptos básicos
para asegurar los sistemas de control
presentados en este documento continúa
expandiéndose.
Relación con la Orden ejecutiva 13636
"Mejora de la seguridad cibernética de la
infraestructura crítica" Reconociendo que
la seguridad nacional y económica de los
Estados Unidos depende de la
funcionalidad confiable de la
infraestructura crítica, el Presidente bajo la
Orden Ejecutiva "Mejora de la
ciberseguridad de la infraestructura
crítica" [82] dirigió a NIST a trabajar con las
partes interesadas para desarrollar un
marco voluntario para reducir los riesgos
cibernéticos para la infraestructura crítica.
El Marco de Ciberseguridad (CSF) [83]
consta de estándares, directrices y mejores
prácticas para promover la protección de
la infraestructura crítica. El enfoque
prioritario, flexible, repetible, basado en el
rendimiento y rentable del Marco ayudará
a los propietarios y operadores de
infraestructura crítica a gestionar el riesgo
relacionado con la seguridad cibernética, al
tiempo que protege la confidencialidad
empresarial, la privacidad individual y las
libertades civiles. El CSF inicial, publicado
en febrero de 2014, dio como resultado un
marco a nivel nacional que es lo
suficientemente flexible para aplicarse en
múltiples sectores y para diferentes
entornos operativos. El CSF fue
desarrollado en base a los aportes de las
partes interesadas para ayudar a
garantizar que el trabajo existente dentro
de los diversos sectores pueda ser utilizado
dentro del Marco. Los estándares,
directrices y prácticas de seguridad
cibernética del sistema de control
industrial pueden aprovecharse para
abordar las funciones de CSF en el
contexto del programa de gestión de
riesgos de una organización.
1.2 Audiencia

Este documento cubre detalles específicos

de ICS. Los lectores de este documento
deben familiarizarse con los conceptos
generales de seguridad informática y los
protocolos de comunicación, como los que
se utilizan en las redes. El documento es
de naturaleza técnica; sin embargo,
proporciona los antecedentes necesarios
para comprender los temas que se
discuten.

La audiencia prevista es variada e incluye lo siguiente:

 Ingenieros de control, integradores y arquitectos que diseñan o implementan de forma

segura ICS.
 Administradores de sistemas, ingenieros y otros profesionales de la
tecnología de la información (TI) Quien administre, parche o asegure. ICS.
 Consultores de seguridad que realizan evaluaciones de seguridad y pruebas de penetración
de ICS.
 Los gerentes que son responsables de ICS.
 Altos directivos que intentan comprender las implicaciones y consecuencias que
justifican. y aplique un programa de ciberseguridad de ICS para ayudar a mitigar los
impactos en las empresas funcionalidad
 Los investigadores y analistas que intentan comprender las necesidades de seguridad
únicas de ICS.
 Los proveedores que están desarrollando productos que se implementarán como parte de
un ICS.

1.3 Estructura del documento

El resto de esta guía se divide en las siguientes secciones principales:

 La Sección 2 proporciona una descripción general de ICS que incluye una comparación
entre ICS y TI sistemas
  La sección 3 proporciona una discusión de la gestión de riesgos de ICS y evaluación.
 La Sección 4 proporciona una descripción general del desarrollo y la
implementación de un programa de seguridad de ICS Para mitigar el riesgo de las
vulnerabilidades identificadas en el Apéndice. DO.
 La Sección 5 proporciona recomendaciones para integrar la seguridad en las
arquitecturas de red que normalmente se encuentran en ICS, con énfasis en la
segregación de la red. practicas
 La Sección 6 proporciona un resumen de los controles de gestión, operativos y
técnicos identificados en la Publicación especial 800-53 de NIST, Controles de
seguridad y privacidad para sistemas y organizaciones de información federales , y
proporciona una guía inicial sobre cómo se aplican estos controles de seguridad a ICS.
La guía también contiene varios apéndices con material de apoyo, como sigue:

 El Apéndice A: proporciona una lista de las siglas y abreviaturas utilizadas en este

documento.
Apéndice B: proporciona un glosario de términos utilizados en este documento.
Apéndice C: proporciona una lista de amenazas, vulnerabilidades e incidentes de ICS
.
Apéndice D: proporciona una lista de seguridad de ICS ocupaciones.
Apéndice E: proporciona una lista de herramientas y capacidades de seguridad de
ICS
Apéndice F: proporciona una lista de referencias utilizadas en el desarrollo de este
documento.
Apéndice G: proporciona una superposición de ICS, una lista de controles de
seguridad, mejoras y orientación complementaria que se aplican específicamente a
ICS.

2. Resumen de Sistemas de Control Industrial

Sistema de control industrial (ICS) es un término general que abarca varios tipos de
sistemas de control, incluidos los sistemas de control de supervisión y adquisición de datos
(SCADA), sistemas de control distribuido (DCS) y otras configuraciones de sistemas de
control tales como Controladores lógicos programables (PLC) a menudo. Se encuentra en
los sectores industriales e infraestructuras críticas. Un ICS consiste en combinaciones de
componentes de control (p. Ej., Eléctrico, mecánico, hidráulico, neumático) que actúan
conjuntamente para lograr un objetivo industrial (p. Ej., Fabricación, transporte de materia o
energía). La parte del sistema que se ocupa principalmente de producir la salida se
denomina proceso. La parte de control del sistema incluye el Especificación de la salida o
rendimiento deseado. El control puede ser completamente automatizado o puede incluir un
humano en el bucle. Los sistemas se pueden configurar para operar en modo de bucle
abierto, de bucle cerrado y manual. En los sistemas de control de bucle abierto, la salida se
controla mediante los ajustes establecidos. En los sistemas de control de circuito cerrado, la
salida tiene un efecto en la entrada de tal manera que mantiene el objetivo deseado. En
modo manual el sistema está completamente controlado por humanos. La parte del sistema
que se ocupa principalmente de mantener la conformidad con las especificaciones se conoce
como el controlador (o control). Un ICS típico puede contener numerosos bucles de control,
interfaces hombre-máquina (HMI) y herramientas de diagnóstico y mantenimiento remotas
creadas utilizando una serie de protocolos de red. Los procesos industriales de control de
ICS se utilizan normalmente en electricidad, agua y aguas residuales,Petróleo y gas natural,
productos químicos, transporte, productos farmacéuticos, pulpa y papel, alimentos y
bebidas, y fabricación discreta (por ejemplo, automotriz, aeroespacial y bienes duraderos).

Los ICS son críticos para el funcionamiento de las infraestructuras críticas de los EE. UU.
Que a menudo son sistemas altamente interconectados y mutuamente dependientes. Es
importante tener en cuenta que aproximadamente el 85 por ciento de las infraestructuras
críticas de la nación son de propiedad y operación privada 1 . Las agencias federales también
operan muchos de los procesos industriales mencionados anteriormente, así como el control
del tráfico aéreo. Esta sección proporciona una descripción general de los sistemas SCADA,
DCS y PLC, incluidas las topologías y componentes típicos. Se presentan varios diagramas
para representar la topología de la red, las conexiones, los componentes y los protocolos que
generalmente se encuentran en cada sistema para facilitar la comprensión de estos sistemas.
Estos ejemplos solo intentan identificar conceptos de topología nocional. Las
implementaciones reales de ICS pueden ser híbridos que desdibujan la línea entre los
sistemas DCS y SCADA. Tenga en cuenta que los diagramas en esta sección no se centran
en la protección de ICS. La arquitectura de seguridad y los controles de seguridad se tratan
en la Sección 5 y la Sección 6 de este documento, respectivamente.

2.1 Evolución del control industrial. Sistemas

Muchos de los ICS de hoy evolucionaron desde la inserción de capacidades de TI en los

sistemas físicos existentes, a menudo reemplazando o complementando los mecanismos
de control físico. Por ejemplo, los controles digitales integrados reemplazaron los
controles mecánicos analógicos en máquinas rotativas y motores. Las mejoras en el costo
y el rendimiento han fomentado esta evolución, dando como resultado muchas de las
tecnologías "inteligentes" de la actualidad, como la red eléctrica inteligente, el transporte
inteligente, los edificios inteligentes y la fabricación inteligente. Si bien esto aumenta la
conectividad y la criticidad de estos sistemas, también crea una mayor necesidad de
adaptabilidad, resistencia, seguridad y seguridad.

La ingeniería de ICS continúa evolucionando para proporcionar nuevas capacidades a la vez que
mantiene los ciclos de vida largos típicos de estos sistemas. La introducción de las capacidades
de TI en los sistemas físicos presenta un comportamiento emergente que tiene implicaciones de
seguridad. Los modelos y análisis de ingeniería están evolucionando para abordar estas
propiedades emergentes, incluidas las interdependencias de seguridad, protección, privacidad e
impacto ambiental.

1
http://www.dhs.gov/critical-infrastructure-sector-partnerships (última actualización, abril de 2014)
2.2 Sectores Industriales ICS Y Sus Interdependencias

Los sistemas de control se utilizan en muchos sectores industriales diferentes e

infraestructuras críticas, que incluyen fabricación, distribución y transporte.

2.2.1 Fabricación Industrias

La fabricación presenta un sector industrial grande y diverso con muchos procesos

diferentes, que se pueden clasificar en la fabricación basada en procesos y en la discreción
.

Las industrias de fabricación basadas en procesos suelen utilizar dos procesos principales [1] :

Procesos de fabricación continua. Estos procesos se ejecutan continuamente, a

menudo con transiciones para hacer diferentes calidades de un producto. Los procesos
típicos de fabricación continua incluyen el flujo de combustible o vapor en una central
eléctrica, el petróleo en una refinería y la destilación en una sustancia química. planta.
Procesos de fabricación por lotes. Estos procesos tienen distintos pasos de
procesamiento, realizados en una cantidad de material. Hay un paso de inicio y fin
distinto para un proceso por lotes con la posibilidad de operaciones breves de estado
estable durante los pasos intermedios. Los procesos típicos de fabricación por lotes
incluyen la fabricación de alimentos .
Las industrias manufactureras de base discreta suelen realizar una serie de pasos en
un solo dispositivo para crear el producto final. El montaje de piezas electrónicas y
mecánicas y el mecanizado de piezas son ejemplos típicos de este tipo de industria.

Tanto las industrias basadas en procesos como las industrias discretas utilizan los mismos
tipos de sistemas de control, sensores y redes. Algunas instalaciones son un híbrido de
fabricación discreta y basada en procesos.

2.2.2 Distribución Industrias

Los ICS se utilizan para controlar los activos geográficamente dispersos, a menudo
dispersos en miles de kilómetros cuadrados, incluidos los sistemas de distribución como
la distribución de agua y los sistemas de recolección de aguas residuales, sistemas de
riego agrícola, oleoductos y gasoductos naturales, redes eléctricas y sistemas de transporte
ferroviario.

2.2.3 Diferencias entre fabricación y distribución ICS

Si bien los sistemas de control utilizados en las industrias de fabricación y distribución son
muy similares en operación, son diferentes en algunos aspectos. Las industrias
manufactureras generalmente están ubicadas dentro de una fábrica confinada o un área
centrada en la planta, en comparación con las industrias de distribución geográficamente
dispersas. Las comunicaciones en las industrias manufactureras generalmente se realizan
utilizando tecnologías de red de área local (LAN) que suelen ser más confiables y de alta
velocidad en comparación con las redes de área extensa (WAN) de comunicación a larga
distancia y las tecnologías inalámbricas / RF (radiofrecuencia) utilizadas por la distribución.
industrias Los ICS utilizados en las industrias de distribución están diseñados para manejar
los desafíos de la comunicación a larga distancia, como los retrasos y la pérdida de datos
causados por los diversos medios de comunicación utilizados. Los controles de seguridad
pueden diferir entre la red. tipos

2.2.4 Interdependencias ICS e Infraestructura Crítica

La infraestructura crítica de EE. UU. Se suele denominar "sistema de sistemas" debido

a las interdependencias que existen entre sus diversos sectores industriales, así como a
las interconexiones entre socios comerciales [8] [9]. Las infraestructuras críticas están
altamente interconectadas y son mutuamente dependientes en formas complejas, tanto
físicamente como a través de multitud de tecnologías de la información y las
comunicaciones. Un incidente en una infraestructura puede afectar directa e
indirectamente a otras infraestructuras a través de fallas en cascada y en aumento.

Tanto la industria de transmisión eléctrica como la red de distribución utilizan tecnología

de control SCADA distribuida geográficamente para operar sistemas altamente
interconectados y dinámicos que consisten en miles de servicios públicos y privados y
cooperativas rurales para suministrar electricidad a los usuarios finales. Algunos sistemas
SCADA monitorean y controlan la distribución de electricidad al recopilar datos y emitir
comandos a estaciones de control de campo geográficamente remotas desde una
ubicación centralizada. Los sistemas SCADA también se usan para monitorear y
controlar la distribución de agua, petróleo y gas natural, incluyendo tuberías, barcos,
camiones y sistemas ferroviarios, así como sistemas de recolección de aguas residuales.

Los sistemas SCADA y DCS a menudo están conectados en red. Este es el caso de los
centros de control de energía eléctrica y las instalaciones de generación de energía
eléctrica. Aunque la operación de la instalación de generación de energía eléctrica está
controlada por un DCS, el DCS debe comunicarse con el sistema SCADA para coordinar
la producción de salida con las demandas de transmisión y distribución.

A menudo se piensa que la energía eléctrica es una de las fuentes más frecuentes de
interrupciones de las infraestructuras críticas interdependientes. Como ejemplo, una falla en
cascada puede ser iniciada por una interrupción de la red de comunicaciones de microondas
utilizada para un sistema SCADA de transmisión de energía eléctrica. La falta de
capacidades de monitoreo y control podría hacer que una gran unidad generadora se
desconecte, un evento que podría llevar a una pérdida de energía en una subestación de
transmisión. Esta pérdida podría causar un desequilibrio importante, provocando una falla
en cascada en la red eléctrica. Esto podría ocasionar apagones en grandes áreas que podrían
afectar la producción de petróleo y gas natural, operaciones de refinería, sistemas de
tratamiento de agua, sistemas de recolección de aguas residuales y sistemas de transporte
por tuberías que dependen de la red para la energía eléctrica.
2.3 Operación ICS y Componentes

La operación básica de un ICS se muestra en la Figura 2-1 [2] . Algunos procesos críticos
también pueden incluir sistemas de seguridad. Los componentes clave incluyen lo
siguiente:

Un ICS típico contiene numerosos bucles de control, interfaces humanas y herramientas de

diagnóstico y mantenimiento remotas creadas utilizando una serie de protocolos de red en
arquitecturas de red en capas. Un circuito de control utiliza sensores, actuadores y
controladores (por ejemplo, PLC) para manipular un proceso controlado. Un sensor es un
dispositivo que produce una medición de alguna propiedad física y luego envía esta
información como variables controladas al controlador. El controlador interpreta las señales
y genera las correspondientes variables manipuladas, basadas en un algoritmo de control y
puntos de ajuste de destino, que transmite a los actuadores. Los actuadores como válvulas
de control, interruptores, interruptores y motores se utilizan para manipular directamente el
proceso controlado según los comandos del controlador.

Los operadores e ingenieros utilizan interfaces humanas para monitorear y configurar los
puntos de ajuste, los algoritmos de control y para ajustar y establecer parámetros en el
controlador. La interfaz humana también muestra información de estado del proceso e
información histórica. Las utilidades de diagnóstico y mantenimiento se utilizan para
prevenir, identificar y recuperarse de operaciones anormales o fallas.

A veces, estos bucles de control están anidados y / o en cascada, por lo que el punto de
ajuste para un bucle se basa en la variable de proceso determinada por otro bucle. Los
bucles de nivel de supervisión y los bucles de nivel inferior funcionan de manera continua
durante un proceso con tiempos de ciclo que van del orden de milisegundos a minutos.
 Figura 2-1. Operación ICS

Para apoyar las discusiones posteriores, esta sección define los componentes clave de ICS
que se utilizan en el control y la red. Algunos de estos componentes pueden describirse
genéricamente para su uso en sistemas SCADA, DCS y PLC, mientras que otros son
únicos para uno. El Glosario de términos en el Apéndice B contiene una lista más
detallada de los componentes de control y redes. Además, la Figura 2-5 y la Figura 2-6
muestran ejemplos de implementación de SCADA; La Figura 2-7 muestra un ejemplo de
implementación de DCS y la Figura 2-8 muestra un ejemplo de implementación de PLC
que incorpora estos componentes.

2.3.1 Consideraciones de diseño del sistema ICS

Si bien la Sección 2.3 introdujo los componentes básicos de un ICS, el diseño de un ICS,
incluido el uso de topologías basadas en SCADA, DCS o PLC, depende de muchos
factores. Esta sección identifica los factores clave que impulsan las decisiones de diseño
con respecto a las propiedades de control, comunicación, confiabilidad y redundancia del
ICS. Debido a que estos factores influyen en gran medida en el diseño del ICS, también
ayudarán a determinar las necesidades de seguridad del sistema.

Requisitos de tiempo de control. Los procesos de ICS tienen una amplia gama de
requisitos relacionados con el tiempo, que incluyen muy alta velocidad, consistencia,
regularidad y sincronización. Los seres humanos pueden no ser capaces de cumplir de
 manera confiable y consistente estos requisitos; controladores automáticos pueden ser
necesarios. Algunos sistemas pueden requerir que el cálculo se realice lo más cerca
posible del sensor y los actuadores para reducir la latencia de la comunicación y
realizar las acciones de control necesarias en tiempo.
Distribución geográfica. Los sistemas tienen diferentes grados de distribución, desde
un sistema pequeño (por ejemplo, un proceso controlado por PLC local) hasta sistemas
grandes y distribuidos (por ejemplo, oleoductos, redes eléctricas). Por lo general, una
mayor distribución implica la necesidad de un área amplia (por ejemplo, líneas
arrendadas, conmutación de circuitos y conmutación de paquetes) y dispositivos
móviles. comunicación.
Jerarquía. El control de supervisión se utiliza para proporcionar una ubicación
central que puede agregar datos de varias ubicaciones para respaldar las decisiones de
control basadas en el estado actual del sistema. A menudo, se utiliza un control
jerárquico / centralizado para proporcionar a los operadores humanos una visión
integral de todo el sistema.
Control de Complejidad. A menudo, las funciones de control se pueden realizar
mediante controladores simples y algoritmos preestablecidos. Sin embargo, los
sistemas más complejos (por ejemplo, el control del tráfico aéreo) requieren que los
operadores humanos se aseguren de que todas las acciones de control sean
apropiadas para cumplir con los objetivos más grandes del sistema.
Disponibilidad. Los requisitos de disponibilidad (es decir, confiabilidad) del
sistema también son un factor importante en el diseño. Los sistemas con fuertes
requisitos de disponibilidad / tiempo de actividad pueden requerir más redundancia o
implementaciones alternativas en todas las comunicaciones y controlar.
Impacto de las fallas. El fallo de una función de control podría incurrir en impactos
sustancialmente diferentes en los dominios. Los sistemas con mayor impacto a menudo
requieren la capacidad de continuar las operaciones a través de controles redundantes,
o la capacidad de operar en un estado degradado. El diseño debe abordar estos
requisitos.
 La seguridad. El área de requisitos de seguridad del sistema también es un factor
importante en el diseño. Los sistemas deben ser capaces de detectar condiciones
inseguras y desencadenar acciones para reducir las condiciones inseguras a
condiciones seguras. En La mayoría de las operaciones críticas para la seguridad, la
supervisión humana y el control de un proceso potencialmente peligroso son una parte
esencial de la seguridad. sistema.

2.3.2 SCADA Sistemas

Los sistemas SCADA se utilizan para controlar activos dispersos donde la adquisición de
datos centralizada es tan importante como el control [3] [4]. Estos sistemas se utilizan en
sistemas de distribución como la distribución de agua y los sistemas de recolección de
aguas residuales, oleoductos y gasoductos naturales, sistemas de transmisión y distribución
de servicios eléctricos, y sistemas ferroviarios y otros sistemas de transporte público. Los
sistemas SCADA integran sistemas de adquisición de datos con sistemas de transmisión de
datos y software HMI para proporcionar un sistema de monitoreo y control centralizado
para numerosas entradas y salidas de procesos. Los sistemas SCADA están diseñados para
recopilar información de campo, transferirla a una instalación central de computadoras y
mostrar la información al operador de manera gráfica o textual, lo que le permite
monitorear o controlar un sistema completo desde una ubicación central casi en tiempo real.
Basado en la sofisticación y configuración del sistema individual, el control de cualquier
sistema individual, operación o tarea puede ser automático,o puede ser ejecutado por
comandos del operador.

El hardware típico incluye un servidor de control ubicado en un centro de control, equipo de

comunicaciones (por ejemplo, radio, línea telefónica, cable o satélite) y uno o más sitios de
campo distribuidos geográficamente que consisten en Unidades Terminales Remotas (RTU)
y / o PLC, que Controles de actuadores y / o monitores de sensores. El servidor de control
almacena y procesa la información de las entradas y salidas de la RTU, mientras que la RTU
o el PLC controlan el proceso local. El hardware de comunicaciones permite la transferencia
de información y datos entre el servidor de control y las RTU o PLC. El software está
programado para indicar al sistema qué y cuándo debe monitorearse, qué rangos de
parámetros son aceptables y qué respuesta se debe iniciar cuando los parámetros cambian
fuera de los valores aceptables. Un dispositivo electrónico inteligente (IED), como un relé
de protección,puede comunicarse directamente con el servidor de control, o una RTU local
puede sondear los IED para recopilar los datos y pasarlos al servidor de control. Los IED
proporcionan una interfaz directa para controlar y monitorear equipos y sensores. Los IED
pueden ser interrogados y controlados directamente por el servidor de control y en la
mayoría de los
los casos tienen una programación local que permite que el IED actúe sin instrucciones
directas del centro de control. Los sistemas SCADA generalmente están diseñados para ser
sistemas tolerantes a fallas con una redundancia significativa integrada en el sistema. La
redundancia puede no ser una contramedida suficiente ante un ataque malicioso.

La Figura 2-2 muestra los componentes y la configuración general de un sistema SCADA.

El centro de control alberga un servidor de control y los enrutadores de comunicaciones.
Otros componentes del centro de control incluyen el HMI, las estaciones de trabajo de
ingeniería y el historiador de datos, que están todos conectados por una LAN. El centro de
control recopila y registra la información recopilada por los sitios de campo, muestra
información a la HMI y puede generar acciones basadas en los eventos detectados. El centro
de control también es responsable de alarmas centralizadas, análisis de tendencias e
informes. El sitio de campo realiza el control local de los actuadores y controla los sensores
(tenga en cuenta que los sensores y los actuadores solo se muestran en la Figura 2-5). ). Los
sitios de campo a menudo están equipados con una capacidad de acceso remoto para
permitir a los operadores realizar diagnósticos remotos y reparaciones, generalmente a
través de un módem de acceso telefónico o una conexión WAN independientes. Los
protocolos de comunicación estándar y patentados que se ejecutan a través de
comunicaciones en serie y en red se utilizan para transportar información entre el centro de
control y los sitios de campo utilizando técnicas de telemetría como línea telefónica, cable,
fibra y frecuencia de radio, como transmisión, microondas y satélite.

Las topologías de comunicación SCADA varían entre implementaciones. En la Figura 2-3

se muestran las diversas topologías utilizadas, incluidas las de punto a punto, las series, las
estrellas en serie y las múltiples gotas [5] .
Punto a punto es funcionalmente el tipo más simple; sin embargo, es caro debido a los
canales individuales necesarios para cada conexión. En una configuración en serie, el
número de canales utilizados se reduce; sin embargo, compartir canales tiene un impacto
en la eficiencia y complejidad de las operaciones de SCADA.
De manera similar, el uso de las configuraciones en serie y en varias etapas de un canal por
dispositivo da como resultado una menor eficiencia y una mayor complejidad del sistema.

Figura 2-2. Disposición general del sistema SCADA

Las cuatro topologías básicas de la Figura 2-3 pueden aumentarse aún más utilizando
dispositivos dedicados para gestionar los intercambios de comunicación, así como el
intercambio de mensajes y el almacenamiento en búfer. Los grandes sistemas SCADA que
contienen cientos de RTUs a menudo emplean un servidor de control secundario para
aliviar la carga del servidor primario. Este tipo de topología se muestra en la Figura 2-4.

Figura 2-5 Muestra un ejemplo de la implementación de un sistema SCADA. Este sistema

SCADA en particular consiste en un centro de control primario y tres sitios de campo. Un
segundo centro de control de respaldo proporciona redundancia en caso de un mal
funcionamiento del centro de control primario. Las conexiones punto a punto se utilizan
para todas las comunicaciones del centro de control al sitio de campo, con dos conexiones
que utilizan radio telemetría. El tercer sitio de campo es local al centro de control y utiliza la
WAN para las comunicaciones. Un centro de control regional reside sobre el centro de
control primario para un nivel más alto de control de supervisión. La red corporativa tiene
acceso a todos los centros de control a través de la WAN, y se puede acceder a los sitios de
campo de forma remota para la solución de problemas y las operaciones de mantenimiento.
El centro de control primario consulta los dispositivos de campo en busca de datos a
intervalos definidos (por ejemplo, 5 segundos,60 segundos) y puede enviar nuevos puntos
de ajuste a un dispositivo de campo según sea necesario. Además de sondear y emitir
comandos de alto nivel, el servidor de control también observa las interrupciones de
prioridad provenientes de la alarma del sitio de camposistemas
Figura 2-3. Topologías básicas de comunicación SCADA
Figura 2-4. Topología de comunicación SCADA grande
 Figura 2-5. Ejemplo de Implementación del Sistema SCADA (Monitoreo y Control de
Distribución)

La Figura 2-6 muestra una implementación de ejemplo para monitoreo y control

ferroviario. Este ejemplo incluye un centro de control ferroviario que alberga el
sistema SCADA y tres secciones de un sistema ferroviario. El sistema SCADA
sondea las secciones ferroviarias en busca de información como el estado de los
trenes, los sistemas de señal, los sistemas de electrificación de tracción y las
máquinas expendedoras de boletos. Esta información también se envía a las
consolas del operador en la estación HMI dentro del centro de control ferroviario.
El sistema SCADA también supervisa las entradas del operador en el centro de
control del riel y dispersa los comandos del operador de alto nivel a los
componentes de la sección del riel. Además, el sistema SCADA supervisa las
condiciones en las secciones individuales de los rieles y emite comandos basados
en estas condiciones (por ejemplo, detener un tren para evitar que ingrese a un
área que se haya determinado que esté inundada u ocupada por otro tren según el
monitoreo de condición) .
 Figura 2-6. Ejemplo de implementación del sistema SCADA (monitoreo y control
ferroviario)

2.3.3 Control distribuido Sistemas

DCS se utiliza para controlar los sistemas de producción dentro de la misma ubicación
geográfica para industrias tales como refinerías de petróleo, tratamiento de agua y aguas
residuales, plantas de generación de energía eléctrica, plantas de fabricación de productos
químicos, producción automotriz e instalaciones de procesamiento farmacéutico. Estos
sistemas suelen ser sistemas de control de procesos o de control de partes discretas.

DCS se integra como una arquitectura de control que contiene un nivel de control de
supervisión que supervisa múltiples subsistemas integrados que son responsables de
controlar los detalles de un proceso localizado. Un DCS utiliza un circuito de control de
supervisión centralizado para mediar en un grupo de controladores localizados que
comparten las tareas generales de llevar a cabo un proceso de producción completo [6]. El
control de productos y procesos generalmente se logra al implementar retroalimentación o
ciclos de control de avance hacia adelante, por lo que las condiciones clave del producto y /
o proceso se mantienen automáticamente alrededor de un punto de ajuste deseado. Para
lograr el producto deseado y / o la tolerancia del proceso en torno a un punto de ajuste
específico, se emplean en el campo controladores de proceso específicos, o PLC más
capaces, y se ajustan para proporcionar la tolerancia deseada, así como la tasa de
autocorrección durante los trastornos del proceso. Al modularizar el sistema de producción,
un DCS reduce el impacto de un solo fallo en el sistema en general. En muchos sistemas
modernos, el DCS está interconectado con la red corporativa para brindar a las operaciones
comerciales una visión de la producción.

En la Figura 2-7 se muestra una implementación de ejemplo que muestra los componentes y
la configuración general de un DCS. Este DCS abarca una instalación completa desde los
procesos de producción de nivel inferior hasta la capa corporativa o empresarial. En este
ejemplo, un controlador supervisor (servidor de control) se comunica con sus subordinados
a través de una red de control. El supervisor envía puntos de referencia y solicita datos de
los controladores de campo distribuidos. Los controladores distribuidos controlan sus
actuadores de proceso en función de los comandos del servidor de control y la
retroalimentación del sensor del proceso sensores

Figura 2-7 da ejemplos de controladores de bajo nivel encontrados en un sistema DCS.

Los dispositivos de control de campo que se muestran incluyen un PLC, un controlador de
proceso, un controlador de bucle único y un controlador de máquina. El controlador de
bucle único interconecta sensores y actuadores que utilizan cableado punto a punto,
mientras que los otros tres dispositivos de campo incorporan redes de bus de campo para
interactuar con sensores de proceso y actuadores. Las redes de bus de campo eliminan la
necesidad de cableado punto a punto entre un controlador y sensores y actuadores de
campo individuales. Además, un bus de campo permite una mayor funcionalidad más allá
del control, incluidos los diagnósticos del dispositivo de campo, y puede llevar a cabo
algoritmos de control dentro del bus de campo, evitando así el enrutamiento de la señal de
regreso al PLC para cada operación de control. Protocolos de comunicación industrial
estándar diseñados por grupos de la industria como Modbus y Fieldbus. [7] se utilizan a
menudo en redes de control y redes de bus de campo.

Además de los bucles de control de nivel de supervisión y de campo, también pueden

existir niveles de control intermedios. Por ejemplo, en el caso de un DCS que controla una
instalación de fabricación de partes discretas, podría haber un supervisor de nivel
intermedio para cada celda dentro de la planta. Este supervisor abarcaría una celda de
fabricación que contiene un controlador de máquina que procesa una parte y un
controlador de robot que maneja el stock en bruto y los productos finales. Podría haber
varias de estas celdas que administran los controladores de nivel de campo bajo el circuito
de control de supervisión principal de DCS.
 Figura 2-7. Ejemplo de implementación DCS

2.3.4 Topologías basadas en controlador lógico programable

Los PLC se utilizan en los sistemas SCADA y DCS como componentes de control de un
sistema jerárquico general para proporcionar la gestión local de los procesos a través del
control de retroalimentación como se describe en las secciones anteriores. En el caso de
los sistemas SCADA, pueden proporcionar la misma funcionalidad de las RTU. Cuando
se utilizan en DCS, los PLC se implementan como controladores locales dentro de un
esquema de control de supervisión.

Además del uso de PLC en SCADA y DCS, los PLC también se implementan como el
controlador principal en configuraciones de sistemas de control más pequeños para
proporcionar control operacional de procesos discretos como líneas de ensamblaje de
automóviles y controles de sopladores de hollín de centrales eléctricas. Estas topologías
difieren de SCADA y DCS en que por lo general, carecen de un servidor de control central
y de HMI y, por lo tanto, proporcionan principalmente el control de bucle cerrado sin la
participación directa del ser humano. Los PLC tienen una memoria programable por el
usuario para almacenar instrucciones con el fin de implementar funciones específicas como
control de E / S, lógica, temporización, conteo, control proporcional-derivado-modo (PID)
de tres modos, comunicación, aritmética y datos y archivos. tratamiento.

La Figura 2-8 muestra el control de un proceso de fabricación realizado por un PLC a

través de una red de bus de campo. Se puede acceder al PLC a través de una interfaz de
programación ubicada en una estación de trabajo de ingeniería, y los datos se almacenan en
un historiador de datos, todo conectado en una LAN.

Figura 2-8. Ejemplo de implementación del sistema de control PLC

2.4 Comparando ICS y sistemas de TI Seguridad

ICS controla el mundo físico y los sistemas de TI gestionan los datos. Los ICS tienen
muchas características que difieren de los sistemas de TI tradicionales, incluidos los
diferentes riesgos y prioridades. Algunos de estos incluyen un riesgo significativo para la
salud y la seguridad de las vidas humanas, daños graves al medio ambiente y problemas
financieros, como pérdidas de producción, y un impacto negativo en la economía de una
nación. Los ICS tienen diferentes requisitos de rendimiento y confiabilidad, y también usan
sistemas operativos y aplicaciones que pueden considerarse no convencionales en un
entorno de red de TI típico. Las protecciones de seguridad deben implementarse de manera
que se mantenga la integridad del sistema durante las operaciones normales, así como
durante los tiempos de ciberataque [17].

Inicialmente, ICS tenía poca semejanza con los sistemas de TI, ya que los ICS eran
sistemas aislados que ejecutaban protocolos de control de propiedad utilizando hardware y
software especializados. Los dispositivos Ethernet y de protocolo de Internet (IP) de gran
disponibilidad y bajo costo ahora están reemplazando las tecnologías propietarias más
antiguas, lo que aumenta la posibilidad de vulnerabilidades e incidentes de ciberseguridad.
A medida que ICS está adoptando soluciones de TI para promover la conectividad
corporativa y las capacidades de acceso remoto, y se están diseñando e implementando
utilizando computadoras, sistemas operativos (OS) y protocolos de red estándar de la
industria, están empezando a parecerse a los sistemas de TI. Esta integración admite nuevas
capacidades de TI, pero proporciona un aislamiento significativamente menor para ICS del
mundo exterior que los sistemas anteriores, lo que crea una mayor necesidad de proteger
estos sistemas.
Si bien las soluciones de seguridad se han diseñado para tratar estos problemas de
seguridad en los sistemas de TI típicos, se deben tomar precauciones especiales al
introducir estas mismas soluciones en los entornos de ICS. En algunos casos, se necesitan
nuevas soluciones de seguridad que se adapten al entorno de ICS.

Los entornos en los que ICS y los sistemas de TI operan están cambiando constantemente.
Los entornos de operación incluyen, pero no se limitan a: el espacio de amenaza;
vulnerabilidades misiones / funciones de negocios; misión / procesos de negocio;
arquitecturas empresariales y de seguridad de la información; tecnologías de la
información; personal; instalaciones; relaciones de la cadena de suministro; gobierno
organizacional / cultura; procesos de adquisición / adquisición; políticas / procedimientos
organizacionales; supuestos organizacionales, restricciones, tolerancia al riesgo y
prioridades / compensaciones).

A continuación se enumeran algunas consideraciones especiales al considerar la seguridad para

ICS:

Requisitos de oportunidad y rendimiento. Los ICS son generalmente críticos con el

tiempo, con el criterio de niveles aceptables de retraso y fluctuación de fase dictados
por la instalación individual. Algunos sistemas requieren respuestas confiables y
deterministas. El alto rendimiento generalmente no es esencial para ICS. En contraste,
los sistemas de TI normalmente requieren un alto rendimiento y, por lo general,
pueden soportar cierto nivel de demora y fluctuación. Para algunos ICS, el tiempo de
respuesta automatizado o la respuesta del sistema a la interacción humana es muy
importante. Algunos ICS se basan en sistemas operativos en tiempo real (RTOS),
 donde el tiempo real se refiere a los requisitos de puntualidad. Las unidades de tiempo
real son muy dependientes de la aplicación y deben indicarse explícitamente.
requisitos de disponibilidad. Muchos procesos de ICS son de naturaleza continua.
Las interrupciones inesperadas de los sistemas que controlan los procesos industriales
no son aceptables. Las interrupciones a menudo deben planificarse y programarse con
días o semanas de anticipación. Las pruebas exhaustivas previas a la implementación
son esenciales para garantizar una alta disponibilidad (es decir, confiabilidad) para el
ICS. Los sistemas de control a menudo no se pueden detener y poner en marcha
fácilmente sin afectar la producción. En algunos casos, los productos que se producen o
los equipos que se utilizan son más importantes que la información que se transmite.
Por lo tanto, el uso de estrategias de TI típicas, como el reinicio de un componente,
generalmente no son soluciones aceptables debido al impacto adverso en los requisitos
de alta disponibilidad, confiabilidad y capacidad de mantenimiento del ICS. Algunos
ICS emplean componentes redundantes, que a menudo se ejecutan en paralelo,para
proporcionar continuidad cuando los componentes primarios no están disponibles.

Requisitos de gestión de riesgos. En un sistema de TI típico, la confidencialidad y la

integridad de los datos suelen ser las principales preocupaciones. Para un ICS, las
principales preocupaciones son la seguridad humana y la tolerancia a fallas para evitar
la pérdida de vidas o el peligro para la salud o la confianza pública, el cumplimiento
normativo, la pérdida de equipos, la pérdida de propiedad intelectual o los productos
perdidos o dañados. El personal responsable de operar, asegurar y mantener el ICS debe
comprender el vínculo importante entre la seguridad y la protección. Cualquier medida
de seguridad que perjudique la seguridad es inaceptable.
Efectos físicos. Los dispositivos de campo ICS (por ejemplo, PLC, estación del
operador, controlador DCS) son directamente responsables del control de los procesos
físicos. ICS puede tener interacciones muy complejas con los procesos físicos y las
consecuencias en el dominio de ICS que pueden manifestarse en eventos físicos. La
comprensión de estos efectos físicos potenciales a menudo requiere la comunicación
entre expertos en sistemas de control y en el dominio físico particular.
funcionamiento del sistema. Los sistemas operativos (OS) y las redes de control de
ICS a menudo son bastante diferentes de las contrapartes de TI, ya que requieren
diferentes habilidades, experiencia y niveles de experiencia. Las redes de control
normalmente son administradas por ingenieros de control, no por personal de TI. Los
supuestos de que las diferencias no son significativas pueden tener consecuencias
desastrosas en el sistema operaciones
Restricciones de recursos. ICS y sus sistemas operativos en tiempo real a
menudo son sistemas con recursos limitados que no incluyen las capacidades de
seguridad de TI contemporáneas típicas. Los sistemas heredados a menudo carecen de
recursos comunes en los sistemas de TI modernos. Es posible que muchos sistemas no
tengan las características deseadas, incluidas las capacidades de cifrado, el registro de
errores y la protección de contraseña. El uso indiscriminado de las prácticas de
 seguridad de TI en ICS puede causar la disponibilidad y las interrupciones de tiempo.
Es posible que no haya recursos informáticos disponibles en los componentes de ICS
para adaptar estos sistemas con las capacidades de seguridad actuales. La adición de
recursos o características no puede ser posible.
 Communications. Communication protocols and media used by ICS environments
for field device control and intra-processor communication are typically different
from most IT environments, and may beproprietary.
 Change Management. Change management is paramount to maintaining the
integrity of both IT and control systems. Unpatched software represents one of the
greatest vulnerabilities to a sistema.
Software updates on IT systems, including security patches, are typically applied in a
timely fashion based on appropriate security policy and procedures. In addition, these
procedures are often automated using server-based tools. Software updates on ICS
cannot always be implemented on a timely basis. These updates need to be thoroughly
tested by both the vendor of the industrial control application and the end user of the
application before being implemented. Additionally, the ICS owner must plan and
schedule ICS outages days/weeks in advance. The ICS may also require revalidation as
part of the update process. Another issue is that many ICS utilize older versions of
operating systems that are no longer supported by the vendor. Consequently, available
patches may not be applicable. Change management is also applicable to hardware and
firmware. The change management process, when applied to ICS, requires careful
assessment by ICS experts (eg, control engineers) working in conjunction with security
and IT personnel.
 Managed Support. Typical IT systems allow for diversified support styles, perhaps
supporting disparate but interconnected technology architectures. For ICS, service
support is sometimes via a single vendor, which may not have a diversified and
interoperable support solution from another vendor. In some instances, third-party
security solutions are not allowed due to ICS vendor license and service agreements,
and loss of service support can occur if third party applications are installed without
vendor acknowledgement or aprobación.

 Component Lifetime. Typical IT components have a lifetime on the order of 3 to 5

years, with brevity due to the quick evolution of technology. For ICS where technology
has been developed in many cases for very specific use and implementation, the
lifetime of the deployed technology is often in the order of 10 to 15 years and
sometimes más.
 Component Location. Most IT components and some ICS are located in business
and commercial facilities physically accessible by local transportation. Remote
locations may be utilized for backup facilities. Distributed ICS components may be
isolated, remote, and require extensive transportation effort to reach. Component
location also needs to consider necessary physical and environmental security
medidas
La Tabla 2-1 resume algunas de las diferencias típicas entre los sistemas de TI y ICS.
Tabla 2-1. Resumen de las diferencias del sistema de TI y de ICS
Categoría Sistema de tecnologia de informacion
Requisitos de No en tiempo real
desempeño La respuesta debe ser
consistente. Se exige un
alto rendimiento.
Alto retardo y fluctuación de fase
pueden ser aceptables. Menos
interacción crítica de emergencia.
El control de acceso restringido se
puede implementar en la medida
necesaria para la seguridad
Requisitos de Las respuestas como el reinicio son
disponibilidad aceptables. Las deficiencias de
(confiabilidad) disponibilidad a menudo pueden ser
Tolerado, dependiendo del sistema.
requerimientos operacionales
Requisitos de Gestionar datos
Gestión de La confidencialidad e
Riesgos integridad de los datos es
primordial.
La tolerancia a fallos es menos
importante: el tiempo de
inactividad momentáneo no es un
riesgo importante
El mayor impacto del riesgo es
el retraso de las operaciones
comerciales
Operación Los sistemas están diseñados para
del sistema su uso con sistemas operativos
típicos
Las actualizaciones son sencillas
con la disponibilidad de
herramientas de implementación
automatizadas
Restricciones Los sistemas se especifican con
de recursos recursos suficientes para admitir la
adición de aplicaciones de terceros,
como soluciones de seguridad
Sistema de control industrial
Tiempo real
La respuesta es crítica en el tiempo.
El rendimiento modesto es aceptable
Alto retardo y / o jitter no es aceptable
La respuesta a la interacción
humana y de otra emergencia es
crítica.
El acceso a ICS debe estar
estrictamente controlado, pero no
debe obstaculizar o interferir con
la interacción hombre-máquina.
Es posible que las respuestas
como el reinicio no sean
aceptables debido a los requisitos
de disponibilidad del proceso
Los requisitos de disponibilidad
pueden requerir sistemas
redundantes.
Las interrupciones deben ser
planificadas y programadas con
días / semanas de anticipación
La alta disponibilidad requiere
pruebas exhaustivas previas al
despliegue
Controlar el mundo fisico
La seguridad humana es
primordial, seguida por la
protección del proceso.
La tolerancia a fallos es esencial,
incluso el tiempo de inactividad
momentáneo puede no ser aceptable
Los principales impactos de riesgo
son el incumplimiento normativo,
los impactos ambientales, la
pérdida de vidas, el equipo o la
producción.
Sistemas operativos diferentes y
posiblemente propietarios, a
menudo sin capacidades de
seguridad integradas
Los cambios de software se deben
realizar con cuidado, generalmente
por parte de los proveedores de
software, debido a los algoritmos de
control especializados y, tal vez, al
hardware y software modificado que
intervienen
Los sistemas están diseñados para
admitir el proceso industrial previsto y
es posible que no tengan suficiente
memoria y recursos informáticos para
 admitir la adición de seguridad
capacidades

Categoría Sistema de tecnologia de Sistema de control industrial

informacion
Comunicaciones Protocolos de comunicaciones Muchos protocolos de
estándar Principalmente redes comunicación
cableadas con algunas redes propietarios y estándar.
inalámbricas localizadascapacidades Se utilizan varios tipos de medios de
Prácticas típicas de redes de TI comunicación, incluidos cables e
inalámbricos dedicados (radio y
satélite)
Las redes son complejas y, a veces,
requieren la experiencia de los
ingenieros de control.
Gestión del Los cambios de software se aplican Los cambios de software deben
cambio de manera oportuna en presencia probarse exhaustivamente e
de una buena política y implementarse de forma incremental
procedimientos de seguridad. Los en todo el sistema para garantizar que
procedimientos son a menudo se mantiene la integridad del sistema
automatizados. de control. Las interrupciones de ICS a
menudo deben planificarse y
programarse con días / semanas de
anticipación. ICS puede usar sistemas
operativos que ya no son compatibles
Soporte Permitir estilos de soporte El servicio de asistencia suele ser a
gestionado diversificados través de un único proveedor.
Vida útil de Vida útil del orden de 3 a 5 años. Vida útil del orden de 10 a 15 años.
los
componentes
Ubicación de Los componentes suelen ser Los componentes pueden ser
los locales y de fácil acceso. aislados, remotos y requieren un
componentes gran esfuerzo físico para acceder a
ellos

En resumen, las diferencias operativas y de riesgo entre los sistemas de ICS y de TI crean
la necesidad de una mayor sofisticación en la aplicación de la ciberseguridad y las
estrategias operativas. Un equipo multifuncional de ingenieros de control, operadores de
sistemas de control y profesionales de seguridad de TI debe trabajar estrechamente para
comprender las posibles implicaciones de la instalación, operación y mantenimiento de las
soluciones de seguridad junto con la operación del sistema de control. Los profesionales
de TI que trabajan con ICS deben comprender los impactos de confiabilidad de las
tecnologías de seguridad de la información antes de la implementación. Es posible que
algunos de los sistemas operativos y aplicaciones que se ejecutan en ICS no funcionen
correctamente con soluciones de ciberseguridad de TI comerciales (COTS) debido a las
arquitecturas de entorno de ICS especializadas.
2.5 Otros tipos de control Sistemas

Aunque esta guía proporciona una guía para asegurar el ICS, otros tipos de sistemas de
control comparten características similares y muchas de las recomendaciones de esta guía
son aplicables y podrían utilizarse como referencia para proteger dichos sistemas contra
amenazas de ciberseguridad. Por ejemplo, aunque muchos sistemas de construcción,
transporte, médicos, seguridad y logística utilizan diferentes protocolos, puertos y
servicios, y están configurados y operan en modos diferentes a los ICS, comparten
características similares a los ICS tradicionales [18]. Ejemplos de algunos de estos
sistemas y protocolos incluyen:

Otros tipos de sistemas de control

Infraestructura de medición avanzada .

Sistemas de automatización de edificios .
Sistemas de control de gestión de edificios .
Circuito cerrado de televisión (CCTV) Sistemas.
CO2 Monitoring.
Sistemas de señalización digital.
Sistemas de gestión de vídeo digital .
Sistemas de seguridad electrónica .
Sistemas de gestión de emergencias .

Energy Management Systems.

Sistemas de control de iluminación exterior .
Sistemas de alarma contra incendios .
Sistemas de rociadores contra incendios.
Sistemas de control de iluminación interior .
Sistemas de detección de intrusos .
Sistemas de control de acceso físico .
Seguridad Pública / Móviles Terrestres radios.
renovables de energía geotérmica sistemas.
Photo Sistemas energías renovables .
Sistemas de control de sombra.
Sistemas de humo y purga .
Sistema de Transporte vertical (ascensores y escaleras mecánicas).
Sistemas de control de instrumentos de laboratorio.
Sistemas de gestión de información de laboratorio (LIMS).

Protocolos / Puertos y Servicios

 Modbus: maestro / esclavo - Puerto 502.
BACnet 2 : Maestro / Esclavo - Puerto 47808.
LonWorks / LonTalk 3 : Punto a punto: puerto 1679.
DNP3: Maestro / Esclavo - Puerto 19999 cuando se usa la Seguridad de la capa de
transporte (TLS), Puerto 20000 cuando no se usa TLS.
IEEE 802.x - Punto a punto.
ZigBee - Peer to Peer.
Bluetooth - Maestro / Esclavo.

Los controles de seguridad provistos en el Apéndice G— de esta guía son generales y lo

suficientemente flexibles como para evaluar otros tipos de sistemas de control, pero los
expertos en la materia deberían revisar los controles y adaptarlos según corresponda para
abordar la singularidad de otros tipos de sistemas de control. No existe una "talla única para
todos", y los riesgos pueden no ser los mismos, incluso dentro de un grupo en particular.
Por ejemplo, un edificio tiene muchos subsistemas diferentes, tales como automatización
de edificios, alarma contra incendios, control de acceso físico, señalización digital, CCTV,
etc. Los sistemas de seguridad vital críticos, como la alarma contra incendios y los sistemas
de control de acceso físico, pueden impulsar el nivel de impacto a ser "Alto", mientras que
los otros sistemas generalmente serán "Bajo". Una organización puede decidir evaluar cada
subsistema individualmente o decidir utilizar un enfoque agregado. La evaluación de los
sistemas de control debe estar acoplada al Impacto de Negocios,Plan de contingencia y
Plan de respuesta a incidentes para garantizar que las funciones y operaciones críticas de la
organización puedan recuperarse y restaurarse según lo definido por los Objetivos de
tiempo de recuperación de la organización.

2
http://www.bacnet.org/
3
http://en.wikipedia.org/wiki/LonWorks

3. ICS Risk Management y Evaluación

3.1 Riesgo administración

Las organizaciones gestionan el riesgo todos los días en el cumplimiento de sus objetivos de
negocio. Estos riesgos pueden incluir el riesgo financiero, el riesgo de falla del equipo y el
riesgo de seguridad del personal, entre otros. Las organizaciones deben desarrollar procesos
para evaluar los riesgos asociados con su negocio y decidir cómo lidiar con esos riesgos
según las prioridades de la organización y las limitaciones internas y externas. Esta gestión
de riesgos se realiza como un proceso continuo e interactivo como parte de las operaciones
normales. Las organizaciones que utilizan ICS históricamente han gestionado los riesgos a
través de buenas prácticas en seguridad e ingeniería. Las evaluaciones de seguridad están
bien establecidas en la mayoría de los sectores y con frecuencia se incorporan a los
requisitos reglamentarios. La gestión de riesgos de seguridad de la información es una
dimensión adicional que puede ser complementaria.El proceso de gestión de riesgos y el
marco descrito en esta sección se pueden aplicar a cualquier evaluación de riesgos que
incluya tanto safety and information seguridad.

A risk management process should be employed throughout an organization, using a three-

tiered approach to address risk at the (i) organization level; (ii) mission/business process
level; and (iii) information system level (IT and ICS). The risk management process is
carried out seamlessly across the three tiers with the overall objective of continuous
improvement in the organization's risk-related activities and effective inter-tier and intra-
tier communication among all stakeholders having a shared interest in the mission/business
success of the organization.

This section focuses primarily on ICS considerations at the information system level,
however, it is important to note that the risk management activities, information, and
artifacts at each tier impact and inform the other tiers . Section 6 extends the concepts
presented here to the control family level and provides ICS-specific recommendations to
augment security control families. Throughout the following discussion of risk
management, ICS considerations will be highlighted and the impact that these
considerations have on the risk management process will be discussed.

For more information on multi-tiered risk management and the risk management process,
refer to NIST Special Publication 800-39, Managing Information Security Risk:
Organization, Mission and Information System View [20]. NIST Special Publication 800-37
Revision 1, Guide for Applying the Risk Management Framework to Federal Information
Systems: A Security Life Cycle Approach [21] , provides guidelines for applying the Risk
Management Framework to federal information systems to include conducting the activities
of security categorization, 4 security control selection and implementation, security control
assessment, information system authorization, 5 and security control monitoring. NIST
Special Publication 800-30, Guide for Conducting Risk Assessments , provides a step-by-
step process for organizations on: (i) how to prepare for risk assessments; (ii) how to
conduct risk assessments; (iii) how to communicate risk assessment results to key
organizational personnel; and (iv) how to maintain the risk assessments over time [79] .
4
FIPS 199 provides security categorization guidance for non-national security systems [15]. CNSS Instruction
1253 provides similar guidance for national security systems.
5
Security authorization is the official management decision given by a senior organizational official to authorize
operation of an information system and to explicitly accept the risk to organizational operations and assets,
individuals, other organizations, and the Nation based on the implementation of an agreed-upon set of security
controls.

3.2 Introduction to the Risk Management Proceso

As shown in Figure 3-1, the risk management process has four components: framing ,
assessing , responding and monitoring . These activities are interdependent and often occur
simultaneously within an organization. For example, the results of the monitoring
component will feed into the framing component. As the environment in which
organizations operate is always changing, risk management must be a continuous process
where all components have on-going activities. It is important to remember that these
components apply to the management of any risk whether information security, physical
security, safety or financial.

Figure 3-1. Risk Management Process Applied Across the Tiers

El componente de estructura en el proceso de gestión de riesgos consiste en desarrollar un

marco para las decisiones de gestión de riesgos que se tomarán. El nivel de riesgo que una
organización está dispuesta a aceptar es su tolerancia al riesgo [21, p.6].
El componente de estructura debe incluir la revisión de la documentación existente, como
las evaluaciones de riesgo anteriores. Puede haber actividades relacionadas; como la
planificación de la gestión de desastres en toda la comunidad que también debe
considerarse, ya que afectan los requisitos que debe tener en cuenta una evaluación de
riesgos.

La evaluación del riesgo requiere que las organizaciones identifiquen sus amenazas y
vulnerabilidades, el daño que tales amenazas y vulnerabilidades pueden causar a la
organización y la probabilidad de que ocurran eventos adversos derivados de esas
amenazas y vulnerabilidades.
6
MIL-STD-882E, Práctica estándar - Seguridad del sistema , Departamento de Defensa (DoD), 11 de mayo de
2012, https://acc.dau.mil/CommunityBrowser.aspx?id=683694
7
http://www.dhs.gov/about-national-cybersecurity-communications-integration-center
8
https://ics-cert.us-cert.gov/

El componente que responde se basa en el concepto de una respuesta coherente en toda la

organización para la identificación de riesgos. La respuesta a la identificación del riesgo
(a diferencia de la respuesta a un incidente) requiere que las organizaciones identifiquen
primero los posibles cursos de acción para abordar el riesgo, evalúen esas posibilidades a
la luz de la tolerancia al riesgo de la organización y otras consideraciones determinadas
durante el paso del marco, y elijan la La mejor alternativa para la organización. El
componente de respuesta incluye la implementación del curso de acción elegido para
abordar el riesgo identificado: aceptación, evitación, mitigación, intercambio,
transferencia o cualquier combinación de esas opciones 9 .

El monitoreo es el cuarto componente de las actividades de gestión de riesgos. Las

organizaciones deben monitorear el riesgo de manera continua, incluyendo: la
implementación de las estrategias de gestión de riesgos elegidas; los cambios en el entorno
 que pueden afectar el cálculo del riesgo; y, la efectividad y eficiencia de las actividades de
reducción de riesgos. Las actividades en el componente de monitoreo impactan a todos los
otros componentes.

3.3 Consideraciones especiales para hacer un riesgo de ICS Evaluación

La naturaleza de ICS significa que cuando una organización realiza una evaluación de
riesgos, puede haber consideraciones adicionales que no existen al realizar una evaluación
de riesgos de un sistema de TI tradicional. Debido a que el impacto de un incidente
cibernético en un ICS puede incluir efectos físicos y digitales, las evaluaciones de riesgo
deben incorporar esos efectos potenciales. Esta sección proporcionará un examen más
profundo de lo siguiente:

Impactos en la seguridad y uso de la seguridad. evaluaciones

Impacto físico de un incidente cibernético en un ICS, incluido el entorno
físico más amplio; Efecto en el proceso controlado, y el efecto físico en el ICS. sí
mismo.
Las consecuencias para las evaluaciones de riesgo de
componentes de control no digitales dentro de un ICS.

3.3.1 Seguridad dentro de un ICS Riesgo de seguridad de la información

Evaluación

The culture of safety and safety assessments is well established within the majority of the
ICS user community. Information security risk assessments should be seen as
complementary to such assessments though the assessments may use different approaches
and cover different areas. Safety assessments are concerned primarily with the physical
world. Information security risk assessments primarily look at the digital world. However,
in an ICS environment, the physical and the digital are intertwined and significant overlap
may occur.

It is important that organizations consider all aspects of risk management for safety (eg,
risk framing, risk tolerances), as well as the safety assessment results, when carrying out
risk assessments for information security. The personnel responsible for the information
security risk assessment must be able

9
Para obtener información adicional sobre cómo aceptar, evitar, mitigar, compartir o transferir riesgos, consulte la
publicación especial NIST 800-39 [20].

para identificar y comunicar los riesgos identificados que podrían tener implicaciones de
seguridad. A la inversa, el personal encargado de las evaluaciones de seguridad debe estar
familiarizado con los posibles impactos físicos y su probabilidad desarrollada por la
evaluación de riesgos de seguridad de la información. proceso.
3.3.2 Impactos físicos potenciales de un ICS Incidente

La evaluación del daño físico potencial de un incidente cibernético debe incorporar: i)

cómo un incidente podría manipular el funcionamiento de los sensores y actuadores para
impactar el entorno físico; ii) qué controles redundantes existen en el ICS para evitar un
impacto; y iii) cómo podría surgir un incidente físico basado en estas condiciones. Un
impacto físico podría afectar negativamente al mundo circundante a través de múltiples
medios, incluida la liberación de materiales peligrosos (por ejemplo, contaminación,
petróleo crudo), fuerzas cinéticas dañinas (por ejemplo, explosiones) y exposición a fuentes
de energía (por ejemplo, electricidad, vapor). El incidente físico podría impactar
negativamente el ICS y la infraestructura de soporte, los diversos procesos realizados por el
ICS o el entorno físico más amplio. Una evaluación de los impactos físicos potenciales
debe incluir todas las partes de un ICS,Comenzando con la evaluación de los impactos
potenciales en el conjunto de sensores y actuadores.
Cada uno de estos dominios será explorado a continuación.

La evaluación del impacto de un incidente cibernético en el entorno físico debe centrarse

en los posibles daños a la seguridad humana, el entorno natural y otras infraestructuras
críticas. Los impactos en la seguridad humana deben evaluarse en función de si es posible
que se produzcan lesiones, enfermedades o la muerte debido a un mal funcionamiento del
ICS. Esto debe incorporar cualquier evaluación de impacto de seguridad realizada
previamente por la organización con respecto a los empleados y al público en general. Los
impactos ambientales también deben ser abordados. Este análisis debe incorporar cualquier
evaluación de impacto ambiental disponible realizada por la organización para determinar
cómo un incidente podría impactar los recursos naturales y la vida silvestre a corto o largo
plazo. Además, se debe tener en cuenta que el ICS no puede estar ubicado dentro de una
solaubicación controlada y puede distribuirse en una amplia área física y exponerse a
entornos no controlados. Finalmente, el impacto en el entorno físico debe explorar en qué
medida un incidente podría dañar las infraestructuras externas al ICS (por ejemplo,
generación / entrega eléctrica, infraestructuras de transporte y servicios de agua).

3.3.3 Impacto de la interrupción física de un ICS Proceso

Además del impacto en el entorno físico, la evaluación de riesgos también debe evaluar los
efectos potenciales del proceso físico realizado por el ICS en consideración, así como otros
sistemas. Un incidente que afecte el ICS e interrumpa el proceso dependiente puede causar
impactos en cascada en otros procesos relacionados del ICS y la dependencia del público
en general de los productos y servicios resultantes. El impacto en los procesos de ICS
relacionados podría incluir tanto sistemas como procesos dentro de la organización (por
ejemplo, un proceso de fabricación que depende del proceso controlado por el sistema en
consideración) o sistemas y procesos externos a la organización (por ejemplo, una empresa
de servicios públicos que vende energía generada a un planta cercana).

Un incidente cibernético también puede tener un impacto negativo en el ICS físico en

consideración. Este tipo de impacto incluye principalmente la infraestructura física de la
planta (por ejemplo, tanques, válvulas, motores), junto con los mecanismos de control
digital y no digital (por ejemplo, cables, PLC, manómetro). Los daños en el ICS o en la
planta física pueden causar interrupciones a corto o largo plazo, según el grado del
incidente. Un ejemplo de un incidente cibernético que afecta al ICS es el malware Stuxnet,
que causó daños físicos a las centrífugas e interrumpió los procesos dependientes.

3.3.4 Incorporación de aspectos no digitales de ICS en evaluaciones de

impacto

Los impactos en el ICS no se pueden determinar adecuadamente al centrarse solo en los

aspectos digitales del sistema, ya que a menudo hay mecanismos no digitales disponibles
que proporcionan tolerancia a fallas y evitan que el ICS actúe fuera de los parámetros
aceptables. Por lo tanto, estos mecanismos pueden ayudar a reducir cualquier impacto
negativo que un incidente digital en el ICS pueda tener y debe ser incorporado en el proceso
de evaluación de riesgos. Por ejemplo, los ICS a menudo tienen mecanismos de control no
digitales que pueden evitar que el ICS funcione fuera de un límite seguro y, por lo tanto,
limitar el impacto de un ataque (por ejemplo, una válvula de presión de alivio mecánico).
Además, se pueden usar mecanismos analógicos (por ejemplo, medidores, alarmas) para
observar el estado físico del sistema para proporcionar a los operadores datos confiables si
las lecturas digitales no están disponibles o están dañadas. La Tabla 3-1 proporciona una
clasificación de los mecanismos de control no digital que podrían estar disponibles para
reducir el impacto de un incidente de ICS .

Tabla 3-1. Categorías de componentes de control ICS no digitales

Tipo de sistema Descripción

Pantallas analógicas o Mecanismos no digitales que miden y muestran el estado del sistema
alarmas físico (por ejemplo, temperatura, presión, voltaje, corriente) y pueden
proporcionar al operador información precisa en situaciones en las que
las pantallas digitales no están disponibles o están dañadas. La
información se puede proporcionar al operador en alguna pantalla no
digital (por ejemplo, termómetros, manómetros) y a través de
alarmas sonoras.
Mecanismos Los mecanismos de control manual (por ejemplo, controles de válvulas
de control manuales, interruptores de interruptores físicos) brindan a los operadores
manual la capacidad de controlar manualmente un actuador sin
Confiando en el sistema de control digital. Esto asegura que un
actuador puede ser controlado incluso si el sistema de control no está
disponible o está comprometido.
Sistemas de control Los sistemas de control analógico utilizan sensores y actuadores no
analógico digitales para monitorear y controlar un proceso físico. Estos pueden
evitar que el proceso físico ingrese a un estado no deseado en
situaciones en las que el sistema de control digital está
no disponible o corrompido. Los controles analógicos incluyen
dispositivos como reguladores, gobernadores y relés electromecánicos.

La determinación del impacto potencial que un incidente cibernético puede tener en el

ICS debe incorporar el análisis de todos los mecanismos de control no digitales y la
medida en que pueden mitigar los posibles impactos negativos en el ICS. Existen
múltiples consideraciones al considerar los posibles efectos de mitigación de los
mecanismos de control no digitales, tales como:

Los mecanismos de control no digitales pueden requerir tiempo

adicional y participación humana para realizar las funciones necesarias de monitoreo
o control, y estos esfuerzos pueden ser sustanciales. Por ejemplo, tales mecanismos
pueden requerir que los operadores viajen a un sitio remoto para realizar ciertas
funciones de control. Dichos mecanismos también pueden depender de los tiempos de
respuesta humanos, que pueden ser más lentos que los controles automatizados.

Los sistemas manuales y analógicas no pueden proporcionar capacidades de

seguimiento o control con el mismo grado de precisión y fiabilidad que el sistema de
control digital. Esto puede presentar un riesgo si el sistema de control primario no está
disponible o está dañado debido a la reducción de la calidad, la seguridad o la
eficiencia del sistema. Por ejemplo, un relé de protección digital / numérico
proporciona más precisión y detección confiable de fallas que los relés analógicos /
estáticos, por lo tanto, es probable que el sistema muestre un disparo de relé falso si los
relés digitales no están disponible.

3.3.5 Incorporando el Impacto de la Seguridad. Sistemas

Los sistemas de seguridad también pueden reducir el impacto de un incidente cibernético

en el ICS. Los sistemas de seguridad a menudo se implementan para llevar a cabo
funciones específicas de monitoreo y control para garantizar la seguridad de las personas,
el medio ambiente, el proceso y el ICS. Si bien estos sistemas se implementan
tradicionalmente para ser completamente redundantes con respecto al ICS primario,
pueden no proporcionar una redundancia completa de incidentes cibernéticos,
específicamente de un atacante sofisticado. El impacto de los controles de seguridad
implementados en el sistema de seguridad debe evaluarse para determinar que no afecten
negativamente al sistema.

3.3.6 Teniendo en cuenta la propagación de impacto a Connected Sistemas

La evaluación del impacto de un incidente también debe incorporar cómo el impacto del
ICS podría propagarse a un ICS o sistema físico conectado. Un ICS puede estar
interconectado con otros sistemas, de modo que las fallas en un sistema o proceso pueden
fácilmente conectarse a otros sistemas dentro o fuera de la organización. La propagación
del impacto podría ocurrir debido a dependencias tanto físicas como lógicas. Una
comunicación adecuada de los resultados de las evaluaciones de riesgo a los operadores de
sistemas y procesos conectados o interdependientes es una forma de mitigar dichos
impactos.
 El daño lógico a un ICS interconectado podría ocurrir si el incidente cibernético se
propagó a los sistemas de control conectados. Un ejemplo podría ser si un virus o gusano
se propagó a un ICS conectado y luego impactó ese sistema. El daño físico también
podría propagarse a otros ICS interconectados. Si un incidente afecta el entorno físico de
un ICS, también puede afectar otros dominios físicos relacionados. Por ejemplo, el
impacto podría resultar en un peligro físico que degrada los entornos físicos cercanos.
Además, el impacto también podría degradar las dependencias compartidas comunes
(por ejemplo, la fuente de alimentación), o resultar en una escasez de material necesario
para una etapa posterior en un proceso industrial.

4. Programa de Seguridad ICS para el Desarrollo y Despliegue

La Sección 2 aborda las diferencias operacionales críticas entre los sistemas de ICS y de TI,
y la Sección 3 aborda la administración de riesgos. Esta sección combina estas dos
preocupaciones al abordar cómo las organizaciones deben desarrollar e implementar un
programa de seguridad de ICS. Los planes y programas de seguridad de ICS deben ser
coherentes e integrados con la experiencia, los programas y las prácticas de seguridad de TI
existentes, pero deben tener en cuenta los requisitos y características específicos de las
tecnologías y los entornos de ICS. Las organizaciones deben revisar y actualizar sus planes
y programas de seguridad de ICS con regularidad para reflejar los cambios en las
tecnologías, operaciones, estándares y regulaciones, así como las necesidades de seguridad
de las instalaciones específicas.

Esta sección proporciona una descripción general del desarrollo y la implementación de

un programa de seguridad de ICS. La Sección 4.1 describe cómo establecer un caso de
negocios para un programa de seguridad de ICS, incluido el contenido sugerido para el
caso de negocios. Las secciones 4.2 a 4.5 analizan el desarrollo de un programa de
seguridad de ICS integral y brindan información sobre varios pasos importantes en la
implementación del programa. La información sobre los controles de seguridad
específicos que podrían implementarse como parte del programa de seguridad se
proporciona en la Sección 6 .

La integración efectiva de la seguridad en un ICS requiere la definición y ejecución de un

programa integral que aborde todos los aspectos de la seguridad, desde la identificación de
objetivos hasta la operación diaria y las auditorías continuas para el cumplimiento y la mejora.
Se debe identificar un gerente de seguridad de la información de ICS con el alcance, la
responsabilidad y la autoridad adecuados. Esta sección describe el proceso básico para
desarrollar un programa de seguridad, que incluye lo siguiente:

Desarrollar un caso de negocio para seguridad.

Construir y entrenar una función cruzada. equipo.
Definir carta y alcance.
Definir políticas y procedimientos específicos de ICS .
Implementar un marco de gestión de riesgos de seguridad ICS .
o Definir e inventariar ICS. bienes.
o Desarrollar plan de seguridad para sistemas ICS .
o Realizar un riesgo evaluación.
o Definir la mitigación. controles
Proporcionar capacitación y aumentar la conciencia de seguridad para ICS personal.
En ISA-62443-2-1 Seguridad para sistemas de control y automatización industrial se
proporciona información más detallada sobre los distintos pasos : Establecimiento de un
programa de seguridad para sistemas de control y automatización industrial [34] .

The commitment to a security program begins at the top. Senior management must
demonstrate a clear commitment to information security. Information security is a
business responsibility shared by all members of the enterprise and especially by leading
members of the business, process, and management teams. Information security programs
with adequate funding and visible, top-level support from organization leaders are more
likely to achieve compliance, function more smoothly, and have greater success than
programs that lack that support.

Whenever a new system is being designed and installed, it is imperative to take the time to
address security throughout the lifecycle, from architecture to procurement to installation
to maintenance to decommissioning. There are serious risks in deploying systems to
production based on the assumption that they will be secured later. If there is insufficient
time and resources to secure the system properly before deployment, it is unlikely that
there will be sufficient time and resources later to address security.

Designing and implementing a new system is quite rare. It is much more common to
improve, expand, or update an existing system. Everything in this section, indeed in this
document, applies to managing the risk of existing ICS. Building an ICS Security Program
and applying it to existing systems is much more complex and challenging.

4.1 Caso de negocio para Seguridad

El primer paso para implementar un programa de seguridad de la información para ICS es

desarrollar un caso de negocios convincente para las necesidades únicas de la
organización. El caso de negocios debe reflejar las preocupaciones comerciales de la alta
gerencia mientras se basa en la experiencia de quienes ya están lidiando con muchos de
los mismos riesgos. El caso de negocio proporciona el impacto comercial y la justificación
financiera para crear un programa integrado de seguridad de la información. Debe incluir
información detallada sobre lo siguiente:

beneficios, incluida la mejora de la confiabilidad y disponibilidad del

sistema de control, de crear una seguridad integrada programa.
Priorizar costos potenciales y escenarios de daños si no se implementa un programa
de seguridad de la información para el ICS.
visión general de alto nivel del proceso requerido para implementar, operar,
monitorear, revisar, mantener y mejorar la seguridad de la información programa.
Costos y recursos necesarios para desarrollar, implementar y mantener la seguridad.
programa.
Antes de presentar el caso de negocios a la gerencia, debe haber un plan de costos y una
implementación de seguridad bien pensados y desarrollados. Por ejemplo, simplemente
solicitar un firewall es insuficiente.

4.1.1 Beneficios

La política de administración de riesgos responsable exige que la amenaza al ICS se mida y

controle para proteger los intereses de los empleados, el público, los accionistas, los
clientes, los proveedores, la sociedad y la nación. El análisis de riesgo permite sopesar los
costos y beneficios para que se puedan tomar decisiones informadas sobre las acciones de
protección. Además de reducir los riesgos, ejercer la diligencia debida y mostrar
responsabilidad también ayuda a las organizaciones a:

Mejora de la seguridad, fiabilidad y fiabilidad del sistema de control. disponibilidad.

Mejorar la moral, lealtad y retención de los empleados.
Reduciendo la comunidad. preocupaciones
Inversor creciente confianza.
Reducir las obligaciones legales .
Reunión regulatoria requisitos
Mejora de la imagen corporativa y reputación.
Ayudando con la cobertura del seguro y costo.
Mejora del inversor y la banca. relaciones.

Un programa sólido de gestión de la seguridad y la seguridad de la información es

fundamental para un modelo de negocio sostenible.

La seguridad mejorada de los sistemas de control y las políticas de seguridad específicas

del sistema de control pueden potencialmente mejorar la confiabilidad y disponibilidad
del sistema de control. Esto también incluye minimizar los impactos no intencionales de
seguridad de la información del sistema de control a partir de pruebas, políticas y
sistemas mal configurados inapropiados.

4.1.2 Potencial Consecuencias

La importancia de los sistemas seguros debe enfatizarse aún más a medida que aumenta la
dependencia empresarial de la interconectividad. Los ataques de denegación de servicio
(DoS) y el malware (por ejemplo, gusanos, virus) se han vuelto muy comunes y ya han
afectado a ICS. Los ataques cibernéticos pueden tener impactos físicos significativos y
consecuentes. La gestión de riesgos se aborda en la Sección 3. Las principales categorías
de impactos son las siguientes:

Impactos físicos. Los impactos físicos abarcan el conjunto de consecuencias

directas de la falla de ICS. Los efectos potenciales de importancia primordial
incluyen lesiones personales y pérdida de vidas. Otros efectos incluyen la pérdida
de propiedad (incluidos los datos) y el daño potencial al ambiente.
Impactos económicos. Los impactos económicos son un efecto de segundo orden de
los impactos físicos que se derivan de un incidente de ICS. Los impactos físicos
podrían tener repercusiones en las operaciones del sistema, que a su vez causan una
mayor pérdida económica en las instalaciones, la organización u otras personas
dependientes del ICS. La falta de disponibilidad de infraestructura crítica (p. Ej.,
Energía eléctrica, transporte) puede tener un impacto económico que va mucho más allá
de los sistemas que sufren daños directos y físicos. Estos efectos podrían tener un
impacto negativo en el ámbito local, regional, nacional o posiblemente global.
economía.
Impactos sociales. Otro efecto de segundo orden, la consecuencia de la pérdida de la
confianza nacional o pública en una organización, se pasa por alto muchas veces. Sin
embargo, es una consecuencia muy real que podría resultar de un incidente de ICS .
El programa para controlar tales riesgos se aborda en la Sección 3 . Tenga en cuenta
que los elementos de esta lista no son independientes. De hecho, uno puede llevar a
otro. Por ejemplo, la liberación de material peligroso puede provocar lesiones o la
muerte. A continuación se enumeran ejemplos de posibles consecuencias de un
incidente de ICS:

Impacto en la seguridad nacional: facilitar un acto de terrorismo.

Reducción o pérdida de producción en un sitio o sitios múltiples simultaneamente.
Lesión o muerte de empleados.
Lesiones o muerte de personas en el comunidad.
Daño a equipo.
Liberación, desvío o robo de materiales peligrosos. materiales
Daño ambiental.
Violación de la normativa. requisitos
la contaminación del producto.
legales penales o civiles pasivos.
Pérdida de propiedad o confidencialidad. información.
Pérdida de imagen de marca o cliente. confianza.
Los incidentes indeseables de cualquier tipo restan valor al valor de una
organización, pero los incidentes de protección y seguridad pueden tener impactos
negativos a más largo plazo que otros tipos de incidentes en todas las partes
interesadas: empleados, accionistas, clientes y las comunidades en las que opera una
organización.

La lista de posibles consecuencias comerciales debe priorizarse para centrarse en las

consecuencias comerciales particulares que la alta dirección considerará más convincentes.
Los elementos de mayor prioridad mostrados en

la lista de consecuencias empresariales priorizadas debe evaluarse para obtener una

estimación del impacto comercial anual, preferiblemente pero no necesariamente en
términos financieros.

La Ley Sarbanes-Oxley requiere que los líderes corporativos firmen el cumplimiento de la

precisión de la información y la protección de la información corporativa. 10 Además, la
mayoría de las firmas de auditoría interna y externa requieren la demostración de la
diligencia debida para satisfacer a los accionistas y otras partes interesadas de la
organización. Al implementar un programa integral de seguridad de la información, la
administración está ejerciendo la diligencia debida.

4.1.3 Recursos para el caso de negocio de la construcción

Se pueden encontrar recursos significativos de información para ayudar a formar un caso

de negocios en recursos externos en otras organizaciones en líneas de negocios similares,
ya sea individualmente o en intercambios de información, organizaciones comerciales y de
estándares, firmas consultoras, y recursos internos en programas relacionados de gestión de
riesgos o Ingeniería y operaciones. Las organizaciones externas a menudo pueden
proporcionar consejos útiles sobre qué factores influyeron más en la administración para
respaldar sus esfuerzos y qué recursos dentro de sus organizaciones resultaron más útiles.
Para diferentes industrias, estos factores pueden ser diferentes, pero puede haber
similitudes en los roles que pueden desempeñar otros especialistas en gestión de riesgos. El
Apéndice D: proporciona una lista y una breve descripción de algunas de las actividades
actuales en seguridad de ICS.

Los recursos internos en los esfuerzos relacionados con la gestión de riesgos (por ejemplo,
seguridad de la información, salud, seguridad y riesgo ambiental, seguridad física,
continuidad del negocio) pueden proporcionar una asistencia tremenda en función de su
experiencia con incidentes relacionados en la organización. Esta información es útil desde el
punto de vista de priorizar amenazas y estimar el impacto en el negocio. Estos recursos
también pueden proporcionar una idea de qué gerentes se enfocan en lidiar con qué riesgos
y, por lo tanto, qué gerentes pueden ser los más apropiados o receptivos para servir como
campeones. Los recursos internos en la ingeniería y las operaciones de los sistemas de
 control pueden proporcionar información sobre los detalles de cómo se implementan los
sistemas de control dentro de la organización, como los siguientes:

Cómo las redes se dividen y se dividen típicamente .

¿Qué conexiones de acceso remoto son generalmente empleado
Cómo los sistemas de control de alto riesgo o los sistemas instrumentados de seguridad son
típicamente diseñado.
¿Qué contramedidas de seguridad son comúnmente usado.

4.1.4 Presentando el Caso de Negocio a Liderazgo

La Sección 3 describe un enfoque de tres niveles que aborda el riesgo en: (i) nivel de
organización ; (ii) nivel de misión / proceso de negocio ; y (iii) nivel de sistema de
información . El proceso de gestión de riesgos se lleva a cabo sin interrupciones en los tres
niveles, con el objetivo general de mejorar continuamente las actividades relacionadas con
los riesgos de la organización y la comunicación efectiva entre niveles e inter-niveles entre
todas las partes interesadas que tienen un interés compartido en la misión / éxito empresarial
de la organización.

Es fundamental para el éxito del programa de seguridad de ICS que la administración a nivel
de la organización se comprometa y participe en el programa de seguridad de ICS. La
gestión de nivel de organización de nivel 1 que abarca las operaciones de TI e ICS tiene la
perspectiva y la autoridad para comprender y asumir la responsabilidad de los riesgos.

El liderazgo empresarial de Nivel 1 será responsable de aprobar y dirigir las políticas de

seguridad de la información, asignar roles y responsabilidades de seguridad e implementar
el programa de seguridad de la información en toda la organización. La financiación para
todo el programa se puede hacer generalmente en fases. Mientras algunos

10 Se puede encontrar
más información sobre la Ley Sarbanes-Oxley y una copia de la
ley misma en http://www.sec.gov/about/laws.shtml .

se puede requerir financiamiento para iniciar la actividad de seguridad de la información, se

puede obtener financiamiento adicional más adelante a medida que se comprenden mejor
las vulnerabilidades de seguridad y las necesidades del programa y se desarrollan estrategias
adicionales. Además, los costos (tanto directos como indirectos) deben considerarse para la
adaptación del ICS para la seguridad, en primer lugar, para abordar la seguridad.

A menudo, un buen enfoque para obtener la participación de la administración para abordar

el problema es fundamentar el caso de negocios en un ejemplo real exitoso de un tercero.
El caso de negocios debe presentar a la gerencia que la otra organización tuvo el mismo
problema y luego presentar que encontraron una solución y cómo la resolvieron. A
menudo, esto provocará que la administración pregunte cuál es la solución y cómo podría
ser aplicable a su organización.

4.2 Construir y entrenar una función cruzada Equipo

It is essential for a cross-functional information security team to share their varied domain
knowledge and experience to evaluate and mitigate risk in the ICS. At a minimum, the
information security team should consist of a member of the organization's IT staff, a
control engineer, a control system operator, security subject matter experts, and a member of
the enterprise risk management staff. Security knowledge and skills should include network
architecture and design, security processes and practices, and secure infrastructure design
and operation. Contemporary thinking that both safety and security are emergent properties
of connected systems with digital control suggests including a safety expert. For continuity
and completeness, the information security team should also include the control system
vendor and/or system integrator.

The information security team should report directly to the information security manager
at the mission/business process or organization tier, who in turn reports to the
mission/business process manager (eg, facility superintendent) or enterprise information
security manager (eg, the company's CIO/CSO), respectively. Ultimate authority and
responsibility rests in the Tier 1 risk executive function that provides a comprehensive,
organization-wide approach to risk management. The risk executive function works with
the top management to accept a level of residual risk and accountability for the
information security of the ICS. Management level accountability will help ensure an
ongoing commitment to information security efforts.

While the control engineers will play a large role in securing the ICS, they will not be able
to do so without collaboration and support from both the IT department and management.
IT often has years of security experience, much of which is applicable to ICS. As the
cultures of control engineering and IT are often significantly different, their integration will
be essential for the development of a collaborative security design and operation.

4.3 Define Charter and Alcance

The information security manager should establish policy that defines the guiding charter of
the information security organization and the roles, responsibilities, and accountabilities of
system owners, mission/business process managers, and users. The information security
manager should decide upon and document the objective of the security program, the
business organizations affected, all the computer systems and networks involved, the
budget and resources required, and the division of responsibilities.
The scope can also address business, training, audit, legal, and regulatory
requirements, as well as timetables and responsibilities. The guiding charter of the
information security organization is a constituent of the information security
architecture which is part of the enterprise architecture, as discussed in Section 3.
Es posible que ya haya un programa de seguridad de la información implementado o en
desarrollo para los sistemas de negocios de TI de la organización. El administrador de
seguridad de la información de ICS debe identificar qué prácticas existentes se deben
aprovechar y qué prácticas son específicas del sistema de control. A la larga, será más fácil
obtener resultados positivos si el equipo puede compartir recursos con otros miembros de la
organización que tienen objetivos similares.

4.4 Definir políticas de seguridad específicas de ICS y Procedimientos

Las políticas y los procedimientos están en la raíz de cada programa de seguridad exitoso.
Siempre que sea posible, las políticas y procedimientos de seguridad específicos de ICS
deben integrarse con las políticas y procedimientos operativos / de gestión existentes. Las
políticas y los procedimientos ayudan a garantizar que la protección de la seguridad sea
coherente y actual para proteger contra las amenazas en evolución. El Apéndice C cita la
falta de política de seguridad como una vulnerabilidad importante. El Apéndice G—, la
superposición de ICS, contiene muchas recomendaciones de políticas de seguridad de la
información de ICS. Después de que se haya realizado un análisis de riesgos de seguridad
de la información, el gerente de seguridad de la información debe examinar las políticas de
seguridad existentes para ver si abordan adecuadamente los riesgos para el ICS. Si es
necesario, se deben revisar las políticas existentes o crear nuevas políticas.

Como se discutió en la Sección 3, la administración del Nivel 1 es responsable de

desarrollar y comunicar la tolerancia al riesgo de la organización, el nivel de riesgo que la
organización está dispuesta a aceptar, lo que le permite al gerente de seguridad de la
información determinar el nivel de mitigación de riesgo que se debe tomar. Reducir el
riesgo residual a niveles aceptables. El desarrollo de las políticas de seguridad debe basarse
en una evaluación de riesgos que establezca las prioridades de seguridad y los objetivos de
la organización para que los riesgos planteados por las amenazas se mitiguen lo suficiente.
Los procedimientos que apoyan las políticas deben desarrollarse para que las políticas se
implementen de manera completa y adecuada para el ICS. Los procedimientos de
seguridad deben documentarse, probarse y actualizarse periódicamente en respuesta a los
cambios de políticas, tecnología y amenazas.

4.5 Implementar un ICS Security Risk Management Marco de referencia

Desde un punto de vista abstracto, la gestión de los riesgos de ICS es otro riesgo agregado a
la lista de riesgos que enfrenta una organización (por ejemplo, finanzas, seguridad, TI,
medio ambiente). En cada caso, los gerentes responsables de la misión o el proceso de
negocios establecen y conducen un programa de administración de riesgos en coordinación
con la función ejecutiva de riesgos de la alta gerencia. Publicación especial 800-39 de NIST,
Gestión de riesgos de seguridad de la información: organización, misión y vista del sistema
de información [20] , es la base de tal programa de gestión de riesgos. Al igual que las otras
áreas de misión / procesos de negocios, el personal relacionado con ICS aplica su
conocimiento especializado en materia de temas para establecer y llevar a cabo la gestión de
riesgos de seguridad de ICS y para comunicarse con la administración de la empresa para
respaldar la administración de riesgos efectiva en toda la empresa. La publicación especial
NIST 800-37, Guía para aplicar el marco de gestión de riesgos a los sistemas de
información federales [21], presenta el marco de gestión de riesgos que aborda el proceso
de implementación del marco. Las siguientes secciones resumen este proceso y aplican el
RMF a un entorno ICS.

El proceso de RMF incluye un conjunto de tareas bien definidas relacionadas con el riesgo
que deben ser realizadas por individuos o grupos seleccionados dentro de roles
organizacionales bien definidos (por ejemplo, función ejecutiva de riesgos, funcionario
autorizador, representante autorizado oficial designado, información principal) oficial
principal de seguridad de la información, arquitecto de empresas, arquitecto de seguridad
de la información, propietario / administrador de la información, propietario del sistema de
información, proveedor de control común, oficial de seguridad del sistema de información
y asesor de control de seguridad). Muchos roles de administración de riesgos tienen roles
de contraparte definidos en los procesos rutinarios del ciclo de vida del desarrollo del
sistema. Las tareas de RMF se ejecutan al mismo tiempo o como parte de los procesos del
ciclo de vida del desarrollo del sistema, teniendo en cuenta las dependencias apropiadas.

Las organizaciones también pueden desear consultar ISA-62443-2-1, Seguridad para

sistemas de control y automatización industrial: establecer un programa de seguridad de
sistemas de control y automatización industrial , que describa otra vista de los elementos
contenidos en un sistema de gestión de ciberseguridad para uso en la industria. Entorno de
automatización y control de sistemas [34]. Proporciona orientación sobre cómo cumplir los
requisitos descritos para cada elemento. Las secciones 4 a 6 corresponden más
estrechamente a NIST SP 800-39; otras secciones corresponden a otras Publicaciones
especiales de NIST y a la superposición de ICS en el Apéndice G— de este documento.
Todos estos documentos de orientación reconocen que una talla no se ajusta a todas; más
bien, el conocimiento del dominio se debe aplicar para adaptar o adaptar la guía a la
organización específica.

4.5.1 Categorizar sistemas y redes de ICS Bienes

El equipo de seguridad de la información debe definir, inventariar y clasificar las

aplicaciones y los sistemas informáticos dentro del ICS, así como las redes dentro del ICS y
su interfaz. El enfoque debe estar en los sistemas en lugar de solo en los dispositivos, y debe
incluir PLC, DCS, SCADA y sistemas basados en instrumentos que utilizan un dispositivo
de monitoreo como un HMI. Los activos que utilizan un protocolo enrutable o son de acceso
telefónico deben estar documentados. El equipo debe revisar y actualizar la lista de activos
de ICS anualmente y después de cada adición o eliminación de activos.

Existen varias herramientas comerciales de inventario de TI empresarial que pueden

identificar y documentar todo el hardware y software que reside en una red. Se debe tener
cuidado antes de usar estas herramientas para identificar los activos de ICS; Los equipos
deben realizar primero una evaluación de cómo funcionan estas herramientas y qué
impacto podrían tener en los equipos de control conectados. La evaluación de la
herramienta puede incluir pruebas en entornos de sistemas de control similares, que no
sean de producción, para asegurar que las herramientas no impacten adversamente en los
sistemas de producción. El impacto podría deberse a la naturaleza de la información o al
volumen de tráfico de la red. Si bien este impacto puede ser aceptable en los sistemas de
TI, puede no serlo en un ICS.

Un sistema de gestión automatizada para el inventario (por ejemplo, Sistema de gestión de

mantenimiento computarizado (CMMS), Sistema de gestión de instalaciones asistidas por
computadora (CAFM), Modelo de información de construcción (BIM), Sistema de
información geoespacial (GIS), Datos de intercambio de información de construcción de
operaciones de construcción (COBie, El intercambio de información de Gestión de
Automatización de Edificios (BAMie), el Sistema de Gestión de Mantenimiento (SMS)
Builder permite a una organización mantener una cuenta precisa de lo que hay en el
sistema por razones de seguridad y también de presupuesto.

4.5.2 Seleccione ICS Security Controles

Los controles de seguridad seleccionados en función de la categorización de seguridad del

ICS se documentan en el plan de seguridad para proporcionar una descripción general de
los requisitos de seguridad para el programa de seguridad de la información del ICS y
describen los controles de seguridad establecidos o planificados para cumplir esos
requisitos. El desarrollo de los planes de seguridad se aborda en la publicación especial
NIST 800-18 Revisión 1, Guía para el desarrollo de planes de seguridad para sistemas de
información federales [19]. El plan de seguridad puede ser un documento, o puede ser el
conjunto de todos los documentos que abordan los problemas de seguridad de un sistema y
los planes para contrarrestar estos problemas. Además de los controles de seguridad, la
publicación especial NIST 800-53 Revisión 4, Controles de seguridad y privacidad para
los sistemas de información federales y las organizaciones [20] , proporciona un conjunto
de controles de gestión de programas de seguridad de la información (PM) que
normalmente se implementan en el nivel de la organización y no están dirigidos a los
sistemas de información de la organización individual. Esta sección trata sobre cómo una
organización establece y lleva a cabo estos controles de gestión de programas.

La implementación exitosa de los controles de seguridad para los sistemas de información

de la organización depende de la implementación exitosa de los controles de gestión del
programa en toda la organización. La manera en que las organizaciones implementan los
controles de gestión del programa depende de las características organizativas específicas
que incluyen, por ejemplo, el tamaño, la complejidad y los requisitos de misión / negocio de
la organización.

respectivas organizaciones. Los controles de administración del programa complementan

los controles de seguridad y se centran en los requisitos programáticos de seguridad de la
información de toda la organización que son independientes de cualquier sistema de
información particular y son esenciales para administrar los programas de seguridad de la
información.
Las organizaciones documentan los controles de gestión del programa en el plan del
programa de seguridad de la información . El plan del programa de seguridad de la
información en toda la organización complementa los planes de seguridad individuales
desarrollados para cada sistema de información de la organización. Juntos, los planes de
seguridad para los sistemas de información individuales y el programa de seguridad de la
información cubren la totalidad de los controles de seguridad empleados por la organización
.

4.5.3 Realizar Riesgo Evaluación

Debido a que cada organización tiene un conjunto limitado de recursos, las organizaciones
deben evaluar los impactos en las operaciones de la organización (es decir, misión,
funciones, imagen y reputación), los activos de la organización, los individuos, otras
organizaciones y la Nación (por ejemplo, usando FIPS 199 [15 ] o un enfoque más
granular). Como se discutió en la Sección 3, las organizaciones pueden experimentar las
consecuencias / el impacto de los eventos adversos a nivel del sistema de ICS individual (p.
ej., no realizar lo que se requiere), a nivel de proceso de misión / negocio (p. ej., no cumplir
plenamente los objetivos de misión / negocio) y a nivel organizativo nivel (por ejemplo, no
cumplir con los requisitos legales o reglamentarios, dañar la reputación o las relaciones o
socavar la viabilidad a largo plazo). Un evento adverso puede tener múltiples consecuencias
y diferentes tipos de impacto, a diferentes niveles y en diferentes marcos de tiempo. NIST
SP 800-53 [22] y la superposición de ICS en el Apéndice G: incorporan controles de
seguridad de línea de base que se derivan de esta determinación de impacto.

La organización puede realizar una evaluación de riesgos detallada para los sistemas de
mayor impacto y evaluaciones para los sistemas de menor impacto según se considere
prudente y según lo permitan los recursos. La evaluación de riesgos ayudará a identificar
cualquier debilidad que contribuya a los riesgos de seguridad de la información y los
enfoques de mitigación para reducir los riesgos. Las evaluaciones de riesgo se realizan
varias veces durante el ciclo de vida de un sistema. El enfoque y el nivel de detalle varían
según la madurez del sistema.

4.5.4 Implementar la seguridad Controles

Las organizaciones deben analizar la evaluación detallada de riesgos y los impactos en las
operaciones de la organización (es decir, misión, funciones, imagen y reputación), los
activos de la organización, los individuos, otras organizaciones y la Nación, y priorizar la
selección de controles de mitigación. Las organizaciones deben enfocarse en mitigar el
riesgo con el mayor impacto potencial. La implementación del control de seguridad es
consistente con la arquitectura empresarial de la organización y la arquitectura de
seguridad de la información.

Los controles para mitigar un riesgo específico pueden variar entre los tipos de sistemas. Por
ejemplo, los controles de autenticación de usuarios pueden ser diferentes para ICS que para
los sistemas de nómina corporativos y los sistemas de comercio electrónico. El
administrador de seguridad de la información de ICS debe documentar y comunicar los
controles seleccionados, junto con los procedimientos para usar los controles. Se pueden
identificar algunos riesgos que pueden mitigarse con soluciones de "solución rápida":
prácticas de bajo costo y alto valor que pueden reducir significativamente el riesgo.
Ejemplos de estas soluciones son restringir el acceso a Internet y eliminar el acceso al
correo electrónico en las estaciones de control del operador o consolas. Las organizaciones
deben identificar, evaluar e implementar soluciones de solución rápida adecuadas tan pronto
como sea posible. como sea posible para reducir los riesgos de seguridad y lograr rápidos
beneficios. El Departamento de Energía (DOE) tiene un documento de “21 pasos para
mejorar la seguridad cibernética de las redes SCADA” [33] que se podría usar como punto
de partida para delinear acciones específicas para aumentar la seguridad de los sistemas
SCADA y otros ICS.