Cómo lograr resultados reales de seguridad OT con la evaluación de riesgos IEC 62443

Resumen: vaya mucho más allá de solo cumplir con los requisitos con IEC 62443. Aprenda cómo una evaluación de riesgos IEC 62443 puede ser utilizada para establecer Niveles de Seguridad (SLs) verificables para su entorno OT/ICS. Esta es una guía práctica.

Antes de comenzar, no olvide revisar nuestra publicación anterior sobre “Por qué la gobernanza de seguridad OT no puede esperar más: Un llamado a la acción del CISO” aquí. Estoy seguro que encontrará útil esta publicación.  

Comencemos entendiendo por qué las evaluaciones de seguridad OT generalmente no cumplen con las expectativas o se convierten en un ejercicio que solo se ve bien en papel. 

Por qué está fallando su evaluación de riesgos OT

Hace una semana alguien le dijo que necesita una evaluación de riesgos de Tecnología Operacional (OT). Así que, contrata a un proveedor de evaluación de riesgos o recurre a un OEM. Pasan semanas entrevistando personas, revisando diagramas de red, verificando aplicaciones de escritorio y realizando búsquedas en Google sobre “Cómo llevar a cabo una evaluación de seguridad OT”.

Recibe un informe de 18 páginas lleno de riesgos "Altos", "Medios" y "Bajos", y una lista de brechas aleatorias con recomendaciones vagas para "parchear sistemas" y "mejorar la segmentación". El informe incluye detalles extensos del lado de TI, pero por alguna razón, las recomendaciones y hallazgos no tienen sentido en el lado OT.

Luego se acerca a un verdadero proveedor de evaluación de seguridad OT como Shieldworkz para que revise el informe y ¿qué encontramos?

· El informe es solo una plantilla en la que se ha añadido jerga aleatoria para que el contenido parezca extenso y completo.

· En un estudio más profundo, vemos activos y procesos listados que ni siquiera pertenecen al cliente.

· Mientras el evaluador afirma haber hecho un informe basado en IEC 62443, no hay evidencia de eso.

· El informe es básicamente de muy poco uso para el cliente  

Entonces, ¿qué salió mal? No realizó una evaluación de riesgos; completó una verificación de cumplimiento y contrató al proveedor de evaluación incorrecto.

Este es un escenario que encontramos muchas veces.

En el mundo de los Sistemas de Control Industrial (ICS), todo el ejercicio de evaluación de riesgos no es solo una auditoría. Es un proceso de reingeniería que se lleva a cabo en cámara lenta. La serie IEC 62443, específicamente IEC 62443-3-2: Evaluación de Riesgos de Seguridad para el Diseño del Sistema, habla sobre entender los riesgos que emergen de los sistemas y contrarrestarlos con un diseño robusto de sistema, proceso y red para construir un entorno que se ofrezca a la defensa.

El poder bruto de IEC 62443: De "Riesgo" a "Requisitos verificables"

Esto es esencialmente el concepto más importante de entender: El objetivo de una evaluación de riesgos 62443 no es crear un compendio de riesgos y vulnerabilidades.

En su lugar, el objetivo es determinar el Nivel de Seguridad Objetivo (SL-T) para diferentes partes de su planta y descubrir qué le impide alcanzar ese nivel.

Piénselo como un esencial de seguridad, como una auditoría de incendio para un edificio alto como el One World Trade. No solo dice, "Que el diseño de un aspecto en particular es 'de alto riesgo'." Dice, "Ese aspecto debe lograr un Nivel de Integridad de Seguridad (SIL) 3." Este nivel SIL-3 viene con un conjunto de requisitos de ingeniería específicos, no negociables y verificables.

IEC 62443 aplica esta misma lógica a la ciberseguridad.

•    Nivel de Seguridad 1 (SL-1): Protege contra el uso indebido accidental.

•    Nivel de Seguridad 2 (SL-2): Protege contra "hacktivistas" con herramientas simples o un mayor nivel de uso indebido.

•    Nivel de Seguridad 3 (SL-3): Protege contra "atacantes capacitados" (por ejemplo, espionaje industrial).

•    Nivel de Seguridad 4 (SL-4): Protege contra actores "nacionales" con vastos recursos y capacidad para llevar a cabo ataques profundos.

Su evaluación de riesgos es la secuencia formal de pruebas que utiliza para justificar decir, "Esta línea de producción (Zona) debe ser SL-2, pero este sistema crítico de seguridad de calderas (Zona) debe ser SL-3." Todo requiere evidencia.

Una vez que tiene ese SL-T, ha delineado su plano. Pero aún tenemos más cosas por hacer. Simplemente recurren a IEC 62443-3-3 (Requisitos de Seguridad del Sistema) y obtienen una lista completa de requisitos (como "imponer contraseñas seguras," "usar protocolos encriptados," "restringir flujos de datos") que su sistema debe tener para lograr ese Nivel de Seguridad específico.

Y voilà. Su evaluación de riesgos ya no es un informe vago o un proceso indefinido. Es una especificación de construcción.

Imagine, el 3i Atlas interestelar se convirtiera en una nave nodriza lanzando sondas hostiles, ¿simplemente se quedará esperando hasta que ataquen o iniciaría una serie de ejercicios predefinidos para contener la amenaza? [Esa es solo una línea que se me ocurrió mientras escribía esto]. La idea es asegurarnos de darle al esfuerzo un nivel adecuado de atención y reflexión.    

Zonificación basada en consecuencias

Estos días todo se trata de consecuencias.

Entonces, ¿cómo determina el objetivo SL? Utiliza la herramienta más poderosa (y más incomprendida) en el estándar 62443: Zonas y Conductos.

Ésta es la perspicacia única: Deje de dibujar sus zonas basándose exclusivamente en su diagrama de red.

La mayoría de la gente se equivoca en esto. Miran un diagrama de red, ven un firewall y dicen: "Esa es una zona." Esto es un pensamiento basado en activos, y es débil. Primero que nada, el diagrama de red en sí mismo podría ser erróneo o la última actualización fue cuando Oumuamua fue descubierto por primera vez.

Una Zona IEC 62443 es una agrupación de activos que comparten una consecuencia común.

En lugar de comenzar con activos, empiece por preguntar a sus ingenieros y gerentes de seguridad estas preguntas fundamentales:

¿Cuál es la peor cosa física que puede suceder aquí?

· Posible respuesta: "Una explosión catastrófica de caldera o fuga de gas." (Consecuencia de Seguridad)

¿Cuál es el peor episodio operacional que puede ocurrir?

· Posible respuesta: "Toda la línea de producción 'Batch 1' deja de funcionar por 24 horas." (Consecuencia de Disponibilidad)

¿Cuál es la peor consecuencia relacionada con el producto que puede manifestarse?

· Posible respuesta: "Alguien roba la fórmula secreta de nuestro producto o información sobre el proceso." (Consecuencia de Confidencialidad)

Trabaje al revés desde ahí.

· Zona 1: Seguridad de Calderas. Agrupe cada activo que pueda causar o prevenir esa explosión de caldera: el PLC de seguridad, su HMI, la estación de trabajo de ingeniería utilizada para programarlo y la red de sensores. Esta es su "Zona de Seguridad de Calderas."

· Zona 2: Producción de Batch 1. Agrupe todos los PLCs, robots y HMIs que operan esa línea específica. Esta es su "Zona de Batch 1."

No importa si están en el mismo VLAN o incluso en el mismo conmutador físico. Ahora están agrupados por una consecuencia compartida a la que están etiquetados. Ahora puede realizar una evaluación de riesgos detallada sobre esa consecuencia específica.

El riesgo de que falle la "Zona de Seguridad de Calderas" es catastrófico. Su evaluación de riesgos casi ciertamente demandará un alto Nivel de Seguridad Objetivo, como SL-3. La "Zona de Batch 1" podría ser una falla operacional costosa, pero no catastrófica, por lo que tal vez su evaluación de riesgos termine en SL-2.

Acabas de usar el riesgo para crear una arquitectura de seguridad práctica, defendible y segmentada.

Un plan de acción en 5 pasos para una evaluación de riesgos basada en IEC 62443-3-2

¿Me sigue hasta aquí?

¿Está listo para realizar tal evaluación en su infraestructura? Aquí hay un proceso de acción paso a paso.

Paso 1: Reúna a sus "Vengadores"

No puede hacer esto solo con TI. Necesita un equipo núcleo de:

•    OT/Ingeniería: Las personas que construyeron y mantienen el proceso. Ellos conocen las consecuencias físicas.

•    TI/Ciberseguridad: Las personas que entienden las amenazas, vulnerabilidades y la arquitectura de la red.

•    Seguridad: Las personas que ya han realizado las evaluaciones de riesgos físicos (por ejemplo, HAZOP) y entienden los peligros reales del mundo.

Paso 2: RA de Alto Nivel (definir consecuencias)

Ponga a ese equipo en una sala. Olvide la tecnología por una hora. Haga una lluvia de ideas y documente las peores consecuencias físicas, operacionales y de negocio para su instalación. Estos son sus criterios de "impacto." Esto es el "qué" está protegiendo.

Paso 3: Particionamiento (Dibuje sus zonas reales)

Ahora, saque los diagramas de proceso (P&IDs) y los diagramas de red. Basado en las consecuencias del Paso 2, comience a agrupar activos.

•    "Todos estos dispositivos son parte del proceso de 'Tratamiento de Aguas Residuales'. Si fallan, tenemos un derrame ambiental." -> Esta es una Zona.

•    "Estos dos PLCs se comunican entre sí a través de este cable específico para gestionar la línea 'Batch 1'." -> Este es un Conducto.

Está construyendo un modelo de su planta basado en consecuencia y comunicación.

Paso 4: RA Detallada (Determine sus SLs objetivos)

Para cada Zona y Conducto que acaba de definir, ahora realiza la evaluación de riesgos "clásica".

◦       Identifique amenazas: ¿Quién podría atacar esto? (por ejemplo, Insiders, Hacktivistas)

◦       Identifique vulnerabilidades: ¿Cuáles son las debilidades? (por ejemplo, Sin parches, contraseñas predeterminadas)

◦       Determine probabilidad: ¿Qué tan probable es este ataque?

◦       Determine consecuencia: ¡Ya lo hizo! (por ejemplo, Explosión de caldera)

Ahora, lo coloca en una matriz de riesgo. La tolerancia al riesgo de su compañía le dirá qué es aceptable. Si el riesgo es inaceptablemente alto, debe reducirlo. ¿Cómo? Asignando un Nivel de Seguridad Objetivo (SL-T). Está diciendo formalmente, "Para reducir el riesgo de una explosión de caldera a un nivel aceptable, esta Zona debe estar diseñada para SL-3."

Paso 5: El análisis de brechas (AKA plan de proyecto)

Bien, hemos llegado al paso final. Para cada Zona, tiene un Objetivo (SL-T). Ahora, mida lo que tiene actualmente (su Nivel de Seguridad Alcanzado, o SL-A).

•    Zona: RTUs

•    Objetivo (SL-T): SL-3

•    Alcanzado (SL-A): SL-1

La brecha percibida entre SL-T 3 y SL-A 1 no es más que su plan de proyecto. Consulta IEC 62443-3-3, extrae todos los requisitos para SL-3 y ahora tiene una hoja de ruta priorizada, basada en riesgos y orientada a la ingeniería para asegurar su planta.

Si puede hacer todo esto, entonces ya no está solo "evaluando". De hecho, está diseñando seguridad.

Hablemos más.

Descubra nuestra solución OT NDR.