Hoy compartimos una guía práctica para combinar los dos marcos de seguridad OT más autorizados del mundo en un programa que realmente resista en el campo. 

Antes de avanzar, no olvides revisar nuestra publicación anterior sobre la nueva caja de herramientas de seguridad de la cadena de suministro TIC de la UE, aquí. 

¿Por qué tener dos marcos y por qué usarlos juntos?

Un error común y comprensible es elegir un marco y construir un programa exclusivamente alrededor de él. Los gerentes de programas a menudo preguntan: ¿Es suficiente el IEC 62443 por sí solo? ¿Es suficiente el NIST SP 800-82? La respuesta a ambas preguntas es: no del todo, y aquí está el porqué.

IEC 62443 es un estándar de ingeniería desarrollado por ISA y adoptado por IEC con una profunda participación de ingenieros de sistemas de control, profesionales de seguridad de procesos y proveedores OT. Su ADN básico se encuentra en el suelo de la planta a través de zonas y corredores, niveles de seguridad, requisitos de componentes y la cadena de suministro del proveedor de servicios. Te dice qué propiedades de seguridad deben tener tus sistemas y, lo más importante, en qué grado.

NIST SP 800-82, con su última Revisión 3 (publicada en septiembre de 2023), es esencialmente un documento de orientación. Es descriptivo en lugar de prescriptivo y te dice qué debes considerar y cómo pensar sobre la seguridad ICS/OT. Se relaciona con el Marco Cibernético de Seguridad NIST (CSF 2.0), proporcionando niveles de implementación, perfiles y una taxonomía completa de amenazas, vulnerabilidades y arquitecturas OT.

02  Entendiendo Cada Marco en Profundidad

IEC 62443: La Serie de Estándares que Debes Conocer a Fondo

IEC 62443 no es un solo estándar, sino una familia de estándares organizados en cuatro series. Los practicantes que lo tratan como un solo documento cometen errores críticos de implementación. Aquí está lo que cubre cada serie y por qué importa operativamente:

El modelo de Nivel de Seguridad (SL) es la contribución definitoria de IEC 62443. SL1 a través de SL4 no son solo calificaciones de severidad: definen la capacidad del actor de amenaza que tus controles deben resistir:

NIST SP 800-82 Rev.3: Lo que Cambió y Por Qué Importa

La Revisión 3, publicada en septiembre de 2023, es una actualización sustancial de la Rev.2 (2015). Los cambios más importantes para los practicantes:

•  Alineación completa con NIST CSF 2.0, incluida la nueva función Gobernar. Esto eleva formalmente la gobernanza de ciberseguridad OT al nivel organizacional, no solo al nivel técnico.

•  Cobertura expandida de OT conectado a la nube, IIoT y arquitecturas de computación de borde no abordadas en la Rev.2, críticas para entornos modernos de petróleo y gas y manufactura avanzada.

•  Paisaje de amenazas actualizado incorporando malware específico de ICS post-2015: TRITON/TRISIS (ataque SIS), INDUSTROYER2 (red eléctrica), PIPEDREAM/INCONTROLLER (marco de ataque ICS multiplataforma).

• Se actualizaron las arquitecturas de referencia con diseños modernos de DMZ, defensa en profundidad para redes OT y orientación sobre integración de SOC OT.

•  Mapas de referencia cruzada explicita entre controles de SP 800-82 e IEC 62443, NERC CIP y otros marcos OT, permitiendo la alineación de cumplimiento de múltiples marcos.

 03  La arquitectura de integración: Haciendo que ambos marcos funcionen juntos

La idea clave para una integración exitosa es esta: usa NIST SP 800-82 / CSF como tu esqueleto de gestión del programa, e IEC 62443 como tu especificación de implementación técnica. Las seis funciones del CSF (Gobernar, Identificar, Proteger, Detectar, Responder, Recuperar) proporcionan la estructura del ciclo de vida. IEC 62443 llena cada función con contenido de ingeniería OT específico.

 04  Inventario de Activos y Evaluación de Riesgos: El Fundamento No Negociable

Todo programa de seguridad OT que ha fallado (y muchos han fallado) fallaron en el paso fundamental en sí mismo. No puedes proteger lo que no sabes que existe. Y en entornos OT, la brecha entre el registro de activos documentado y lo que está realmente conectado a la red casi siempre es mayor de lo que la gestión cree.

Paso 1: Descubrimiento de Activos OT — Hazlo Bien

Nunca ejecutes herramientas de escaneo activas en redes OT en vivo. Esto no es una preferencia. En cambio, es un requisito de seguridad y operacional. Los escáneres activos envían sondas que pueden abrumar la capacidad de procesamiento limitado de PLCs más antiguos, corromper la memoria de algunos RTUs heredados y desencadenar un comportamiento inesperado en sistemas críticos para la seguridad. Esto ha sucedido en entornos reales. NIST SP 800-82 Rev.3 §6.2.1 advierte explícitamente contra el escaneo activo en entornos ICS en vivo sin validación del proveedor.

El enfoque correcto es el descubrimiento de activos pasivos: desplegar un tap de red pasivo o un puerto SPAN en switches de red OT y usar una herramienta de visibilidad OT consciente de protocolos para identificar dispositivos a partir del tráfico observado. Este enfoque, como se define en IEC 62443-3-2 §4.2, permite construir un inventario de activos que captura el tipo de dispositivo, proveedor, modelo, versión de firmware, protocolos en uso y patrones de comunicación, sin inyectar un solo paquete en la red OT.

Paso 2: Definición de Zona y Conducto (IEC 62443-3-2 §4.3)

Una vez que tienes una imagen completa de activos, agrupa los activos en zonas de seguridad según: requisitos de seguridad comunes, consecuencia del compromiso y función operacional. Una zona es un grupo lógico de activos que comparten el mismo nivel de seguridad. Un conducto es cualquier camino de comunicación entre zonas, y cada conducto debe estar documentado, controlado y protegido.

En un contexto de petróleo y gas, una estructura de zona típica se ve así: la capa de Seguridad (sistemas SIS/ESD, mínimo SL3) está completamente aislada y se comunica con la capa de Control Básico del Proceso (DCS, típicamente SL2) solo a través de un diodo de datos de hardware en la dirección saliente. La capa de Control Básico del Proceso se comunica con la capa de Supervisión (SCADA/Historiador, SL2) a través de un cortafuegos de conducto. La capa de Supervisión se comunica con la capa Empresarial/IT a través de una DMZ completamente aislada con inspección de capa de aplicación. Ninguna zona tiene una conexión directa que salte una capa. Esto no es elegancia arquitectónica; es cómo evitas que una infección de ransomware en una laptop corporativa con Windows alcance un ControlLogix de Rockwell.

Paso 3: Evaluación de Riesgos — Consecuencia Primero para OT

IEC 62443-3-2 define una metodología de evaluación de riesgos específica para IACS. La diferencia crítica con la evaluación de riesgos TI es que la consecuencia debe evaluarse en términos operacionales y de seguridad, no solo en términos financieros. Una brecha que cuesta $50,000 remediar en un contexto TI podría representar un riesgo catastrófico en un contexto OT si involucra pérdida de contención, liberación ambiental o derrota de una función de seguridad.

NIST SP 800-82 Rev.3 se alinea con esto al definir categorías de consecuencias para ICS: seguridad (lesiones/muerte personal), liberación ambiental, impacto en la producción y daño a equipos. Usa las definiciones de consecuencia de ambos marcos para construir una matriz de consecuencias que tu equipo de seguridad de procesos pueda validar, porque ellos son los expertos en el tema sobre lo que realmente significa una manipulación de punto de control DCS para la integridad del proceso.

05  Controles de Protección: Donde IEC 62443-3-3 FR1–FR7 Hace el Trabajo Pesado

IEC 62443-3-3 define siete Requisitos Fundamentales (FRs) y 51 Requisitos del Sistema (SRs) que describen las capacidades de seguridad específicas que un sistema debe demostrar en cada Nivel de Seguridad. NIST SP 800-82 Rev.3 mapea sus categorías de control a estos mismos FRs. Aquí se explica cómo implementarlos operativamente:

FR1: Control de Identificación y Autenticación

Cada usuario y dispositivo que accede a sistemas OT debe ser identificado y autenticado. En la práctica, esto significa: eliminar cuentas compartidas en sistemas HMI y EWS; imponer credenciales únicas por ingeniero, operador y proveedor; implementar autenticación multifactor en todas las rutas de acceso remoto. Para la autenticación de dispositivos en SL2+, use autenticación basada en certificados donde el componente OT lo soporte — OPC-UA soporta autenticación mutua basada en certificados y debe usarse en preferencia al OPC-DA heredado con autenticación DCOM. En SL3 (sistemas SIS), requiera tokens de hardware o autentificación fuerte equivalente para cualquier acceso a estaciones de trabajo de ingeniería que puedan modificar la lógica SIS.

FR2: Control de Uso

La autenticación no es suficiente: se debe hacer cumplir la autorización. Separe roles en: Solo lectura (operadores que monitorean el proceso), Control (operadores que ejecutan comandos), Ingeniería (modificación de lógica), Administración (configuración del sistema) y Proveedor (acceso controlado por sesión y con tiempo limitado). El fallo más común de FR2 en ambientes OT es que todos usan la cuenta de administrador porque nadie se tomó el tiempo para construir una matriz de roles adecuada. Esto significa que un contratista que necesita verificar una lectura de diagnóstico tiene acceso completo para escribir en la configuración del DCS, un privilegio innecesario y peligroso.

Para el acceso remoto, haga cumplir la autorización basada en sesiones: cada sesión de acceso remoto de un proveedor o ingeniero requiere aprobación explícita a través de un flujo de trabajo definido, tiene una duración máxima de sesión, se lleva a cabo a través de un servidor de salto con grabación de sesión y se termina y registra. No hay túneles de VPN siempre activos en las redes OT. Sin excepciones.

FR3 y FR4: Integridad y Confidencialidad de Datos

Los protocolos heredados OT — Modbus TCP, DNP3 (sin Autenticación Segura), OPC-DA clásico — fueron diseñados para la confiabilidad, no la seguridad. No tienen mecanismos integrados de integridad o confidencialidad. Esto significa que un atacante con acceso a la red puede leer todos los datos de proceso, inyectar comandos falsos y reproducir comandos legítimos capturados. NIST SP 800-82 Rev.3 §6.2.4 e IEC 62443-3-3 FR3/FR4 abordan esta realidad con la misma orientación pragmática: donde no puedas reemplazar el protocolo, compensa con controles de red (aislamiento estricto de zonas, cortafuegos conscientes de aplicaciones, detección de anomalías); y donde puedas reemplazar o complementar el protocolo (OPC-UA, DNP3-SA, túneles IPsec), hazlo.

FR5: Flujo de Datos Restringido

Este es el modelo de zona y conducto en práctica. Cada camino de comunicación entre zonas debe estar explícitamente permitido, no al revés. La postura predeterminada es negar. Las reglas de cortafuegos entre zonas OT deben ser tan específicas como sea posible: IP de origen, IP de destino, puerto y protocolo. Cualquier regla "any-to-any" en un cortafuegos OT es un hallazgo crítico. Para los caminos de consecuencias más altas (SIS a DCS, por ejemplo), implementa puertas de seguridad unidireccionales (diodos de datos de hardware) que impiden físicamente cualquier tráfico de fluir en la dirección de alta seguridad. Los firewall de solo software, sin importar cuán bien configurados estén, pueden ser mal configurados o explotados — los diodos de datos de hardware no pueden pasar tráfico en la dirección incorrecta por física.

FR6: Respuesta Oportuna a Eventos

No puedes responder a eventos que no puedes ver. Esto requiere monitoreo específico de seguridad OT. Las herramientas SIEM IT sin conocimiento de protocolos OT generarán un enorme ruido en las redes OT y perderán los indicadores reales y significativos de compromiso. La arquitectura ideal es una plataforma de visibilidad OT desplegada en modo pasivo que entiende protocolos ICS, alimenta alertas normalizadas a una función de monitoreo centralizada (SOC OT) y correlaciona eventos a través de zonas. NIST SP 800-82 Rev.3 §6.2.8 proporciona orientación de arquitectura para monitoreo OT que se alinea con los requisitos FR6 de IEC 62443.

FR7: Disponibilidad de Recursos

Los sistemas OT deben permanecer disponibles, a menudo más críticamente de lo que deben permanecer confidenciales. Esto significa que la resiliencia y redundancia son controles de seguridad, no solo elecciones de diseño de ingeniería. Para sistemas OT críticos, verifica: redundancia de controladores (espera activa), redundancia de ruta de red (HSR, PRP o RSTP con rápido cambio), redundancia de potencia (UPS con respaldo de generador), e integridad de respaldo de configuración. Críticamente, prueba la restauración — un respaldo que nunca ha sido restaurado es una suposición, no una capacidad. NIST SP 800-82 Rev.3 §6.2.7 y IEC 62443-3-3 FR7 requieren ambos capacidad de recuperación probada, no solo procedimientos documentados.

6  Detección, Respuesta y Recuperación: Cerrando el Ciclo

Construyendo una Capacidad de Detección OT

El paisaje de amenazas OT ha cambiado fundamentalmente desde 2017. El ataque TRITON/TRISIS demostró que los adversarios sofisticados apuntan específicamente a Sistemas Instrumentados de Seguridad — la última línea de defensa antes de que un proceso físico se vuelva peligroso. PIPEDREAM/INCONTROLLER, divulgado en 2022, demostró un marco de ataque modular capaz de apuntar a las principales plataformas OT de Schneider Electric, OMRON y otras, utilizando protocolos ICS nativos. Estas no son amenazas teóricas, son capacidades documentadas en el mundo real desplegadas contra infraestructura crítica.

La detección en este entorno requiere capacidades específicas de OT que las herramientas de seguridad IT carecen. Un sistema de detección de intrusiones de red que no comprende los códigos de función Modbus, el contenido de la capa de aplicación DNP3 o las operaciones de servicio OPC-UA no puede detectar la manipulación maliciosa del protocolo OT, porque para él, todo el tráfico OT parece ruido. Una inspección profunda de paquetes consciente de protocolos, ajustada específicamente para entornos OT, no es opcional para entornos SL2+.

Respuesta a Incidentes OT: La Interfaz de Seguridad de Procesos

El aspecto más subestimado de la respuesta a incidentes OT es la interfaz entre un evento cibernético y un evento de seguridad de procesos. Un ciberataque a un DCS no se presenta como un incidente de seguridad IT — puede manifestarse inicialmente como desviaciones de proceso inexplicables, discrepancias en la posición de válvulas o lecturas de instrumentos que parecen anómalas. El ataque TRITON fue notado primero por un ingeniero de control de procesos que vio un comportamiento inusual del SIS, no por un analista de seguridad.

Por lo tanto, tu Plan de Respuesta a Incidentes OT debe incluir: disparadores explícitos para la escalada al equipo de respuesta de emergencias de seguridad de procesos; roles definidos para el equipo de Revisión de Seguridad Pre-Arranque (PSSR) si el sistema OT debe ser devuelto al servicio después de un incidente cibernético; y autoridad para Operaciones para aislar un sistema comprometido de la red de control de procesos sin esperar la aprobación IT/ciberseguridad si la seguridad está en riesgo inmediato. NIST SP 800-82 Rev.3 §6.2.9 e IEC 62443-2-1 §4.3.6 abordan ambos la respuesta a incidentes, pero ni uno aborda adecuadamente la interfaz seguridad-ciber en detalle — tu programa debe llenar este vacío usando entradas específicas de sitio de HAZOP y evaluación de riesgos.

Recuperación: La Función Olvidada

IEC 62443-3-3 FR7 y la función Recuperar de NIST CSF requieren ambos capacidad de recuperación probada y documentada. En contextos OT, la recuperación es significativamente más compleja que la recuperación IT porque: los sistemas OT pueden requerir procedimientos de restauración específicos del proveedor; las descargas de lógica a PLCs y controladores DCS deben seguir secuencias definidas; el reinicio de procesos después de un paro prolongado implica consideraciones de seguridad de procesos (purga, comprobaciones de presión, verificación de instrumentos) que pueden tomar días o semanas; y los requisitos de informes regulatorios pueden aplicarse a incidentes cibernéticos que afecten los sistemas de seguridad de procesos.

Define Objetivos de Tiempo de Recuperación (RTOs) para cada zona OT en base a la tolerancia operativa, no basada en estándares IT. Un RTO IT de 24 horas para un sistema no crítico puede estar bien; un RTO OT de 24 horas para un sistema SCADA de oleoducto significa un día de operación ciega de un sistema de transmisión presurizado, lo cual no es aceptable. Estos RTOs deben ser validados por operaciones e ingeniería de procesos, no determinados por TI.

07  Hoja de Ruta de Implementación: Construcción Realista del Programa en 24 Meses

Construir un programa de ciberseguridad OT es un esfuerzo de varios años. La siguiente hoja de ruta se basa en el enfoque de doble marco y se estructura en torno a la realidad de las limitaciones operativas de OT: no puedes interrumpir operaciones, no puedes superar la capacidad de absorción de cambio de tu organización, y no puedes ignorar el ciclo de ventana de mantenimiento.

MESES 1–3 · FASE 1: FUNDACIÓN

Establecer Gobernanza y Visibilidad de Línea Base

Antes de cualquier control técnico, necesitas aceptación organizacional, roles definidos y una imagen real de activos. Sin esto, cada actividad subsecuente se construye sobre arena.

•  Redactar y ratificar la Política de Ciberseguridad OT alineada a los requisitos CSMS de IEC 62443-2-1

•  Definir roles de seguridad OT (Líder de Seguridad OT, Representantes de Seguridad OT del Sitio, función de supervisión de proveedores) y formalizarlos en descripciones de trabajo o RACI

•  Desplegar descubrimiento pasivo de activos OT en todos los sitios, construir el registro de activos definitivo

•  Realizar mapeo inicial de Zonas y Conductos según IEC 62443-3-2 §4.3

•  Establecer una plantilla de registro de riesgos OT específica alineada tanto a IEC 62443-3-2 como a las categorías de consecuencias de NIST SP 800-82

• Línea base actual del Nivel de Seguridad Alcanzado (SL-A) contra FR1–FR7 de IEC 62443-3-3

MESES 3–6 · FASE 2: EVALUACIÓN DE RIESGOS

Completar Evaluación de Riesgos y Definir Estado Objetivo

Con la visibilidad establecida, completa la evaluación formal de riesgos. Este es el entregable más importante en todo el programa; todo lo demás fluye de esto.

•       Completar evaluación de riesgos IEC 62443-3-2 para todas las zonas; establecer SL-T para cada zona

•       Identificar y priorizar todas las brechas de SL (SL-T menos SL-A); estas se convierten en tu carga de remediación

•       Realizar modelado de amenazas alineado a NIST SP 800-82 Rev.3 incluyendo actores y TTPs específicos de ICS

•       Identificar todos los hallazgos inmediatos/críticos que requieran tratamiento independiente de las fases del programa planificadas

•       Integrar el registro de riesgos en el marco de gestión de riesgos empresarial; presentar a la gestión superior

•       Actualizar o redactar los requisitos de seguridad para proveedores alineados a IEC 62443-2-4

MESES 6–12 · FASE 3: CONTROLES CENTRALES

Implementar Controles de Protección Prioritarios

Aborda las brechas críticas y de alta prioridad. Enfócate primero en la arquitectura de red (el mayor impacto en la seguridad OT) y el control de acceso.

• Implementar o remediar la segmentación de red: arquitectura DMZ entre OT e IT; hacer cumplir los límites de zona con cortafuegos apropiados para OT

•  Desplegar diodos de datos en caminos de datos SIS a DCS donde se apunte a SL3

•  Eliminar credenciales predeterminadas en todos los dispositivos OT; implementar control de acceso basado en roles alineado a FR1–FR2

•  Desplegar servidor de salto con grabación de sesión para todo acceso remoto a zonas OT; hacer cumplir MFA en el acceso remoto

•  Implementar escaneo de medios (Solución de Escaneo de Medios de Shieldworkz o equivalente) para todos los medios removibles que ingresen a entornos OT

•  Desplegar plataforma de visibilidad OT en modo de monitoreo pasivo; establecer procedimientos de triage de alertas

•  Desarrollar y ejercer el primer ejercicio de respuesta a incidentes OT en mesa, incluyendo la escalación de ciberseguridad a seguridad de procesos

MESES 12–18 · FASE 4: MADUREZ DE DETECCIÓN Y RESPUESTA

Construir Capacidad de Detección y Respuesta Sostenida

Pasa de reactivo a proactivo: monitoreo continuo, capacidad de caza de amenazas y procedimientos de respuesta probados.

• Establecer función SOC OT (interna o gestionada) con casos de uso y manuales de detección específicos de OT

• Integrar alertas de plataforma de visibilidad OT en SIEM empresarial con reglas de correlación apropiadas para OT

•  Implementar proceso de gestión de parches OT alineado a IEC 62443-2-3: coordinación de proveedores, prueba de entorno de prueba, programación de ventana de mantenimiento

•  Realizar evaluación de vulnerabilidades OT en todos los sistemas críticos utilizando métodos de bajo impacto/pasivos

•  Completar planificación de Continuidad de Negocios y Recuperación de Desastres OT; probar la restauración de respaldo de configuración

•  Lanzar programa de capacitación sobre seguridad OT para operadores, ingenieros y contratistas

MESES 18–24 · FASE 5: MEJORA CONTINUA

Institucionalizar, medir y mejorar

Un programa de ciberseguridad que no mejora continuamente se degrada. Las amenazas evolucionan, los sistemas cambian, la gente rota. Construye los mecanismos que sostienen el programa más allá de la construcción inicial.

•       Establecer informes trimestrales de rendimiento de seguridad OT a la gestión superior: KPIs incluyendo porcentaje de cumplimiento de parches, ítems de riesgo abierto, métricas de incidentes, finalización de capacitación

•       Integrar la revisión de ciberseguridad OT en todos los procesos de gestión de cambio (MOC) OT

•       Evaluación anual de riesgos IEC 62443-3-2; actualizar SL-T y registro de riesgos

•       Ejercicio anual de respuesta a incidentes OT (escalar de ejercicio de mesa a simulacro en vivo donde sea seguro)

•       Actualización de estándares de adquisiciones: todas las adquisiciones OT nuevas requieren certificación SL de componentes IEC 62443-4-2 o evidencia SDL equivalente del proveedor

•       Evaluación de seguridad de la cadena de suministro: evaluar a los principales proveedores OT contra los requisitos de IEC 62443-2-4

08  Gobernanza: La diferencia entre un programa y un proyecto

Controles técnicos sin gobernanza se degradan. El programa de ciberseguridad OT debe ser sostenido por mecanismos organizacionales que sobrevivan al personal individual, los ciclos presupuestarios y la atención de la gestión. IEC 62443-2-1 define el Sistema de Gestión de Seguridad Cibernética (CSMS), el sistema organizacional que asegura que la ciberseguridad sea una función continua de gestión, no un proyecto de una sola vez.

El CSMS debe ser específico de OT

Una de las fallas de gobernanza más comunes es aplicar directamente la política de seguridad IT de la organización, o incluso el ISMS IT (ISO 27001), directamente a OT sin modificación. IT y OT tienen prioridades, tolerancias al riesgo y restricciones operativas fundamentalmente diferentes. Una política IT que requiere MFA en todo acceso al sistema es correcta y apropiada para IT. Aplicada ingenuamente a OT, mandataría MFA para un operador que necesita reconocer una alarma de alta prioridad en dos segundos o arriesgar un incidente de proceso, lo cual es por qué el CSMS OT debe definir controles específicos de OT con contexto operacional.

La gestión del cambio es un control de seguridad

Cada cambio en hardware OT, software, configuración de red o proceso es un evento potencial de seguridad. El proceso de Gestión de Cambio (MOC) debe incluir un paso obligatorio de revisión de ciberseguridad OT. Esto significa que antes de que se ejecute cualquier cambio en el entorno OT, la función de seguridad OT lo revisa en función del impacto de ciberseguridad. Nuevas conexiones de proveedores, actualizaciones de firmware, reconfiguraciones de red, nuevos dispositivos añadidos a la red OT, todos deben pasar por esta puerta. NIST SP 800-82 Rev.3 §6.2.3 y IEC 62443-2-1 §4.2.3 ambos definen la gestión del cambio como un requisito central de gestión de seguridad.

Riesgo de proveedor y cadena de suministro

En entornos OT, la cadena de suministro es la superficie de ataque. Los proveedores OT, integradores de sistemas y proveedores de servicios tienen acceso remoto rutinario a los sistemas OT de los clientes para diagnóstico remoto, soporte de emergencia y mantenimiento planificado. El ataque de SolarWinds demostró a gran escala lo que los practicantes de seguridad OT han entendido durante años: las conexiones de proveedores confiables son vectores de ataque de confianza si la postura de seguridad del proveedor es inadecuada.

IEC 62443-2-4 define los requisitos de seguridad que puedes exigir contractualmente a los proveedores de servicios OT. Los requisitos mínimos para cualquier proveedor con acceso a red OT: prácticas de seguridad documentadas; uso de equipos dedicados, escaneados para malware, para trabajo OT; acceso basado en sesión solamente (no conexiones siempre activas); aceptación de grabación de sesión; y obligaciones de notificación de incidentes. Audita estos requisitos, no solo colectes atestaciones firmadas.

Métricas que suman algo

La mayoría de las métricas de seguridad OT reportadas a la gestión son métricas de actividad: número de políticas escritas, número de sesiones de capacitación completadas, número de activos escaneados. Estas miden esfuerzo, no seguridad. Las métricas que importan son métricas de resultado alineadas a tu registro de riesgos:

Este artículo refleja las posturas técnicas y la experiencia operacional de los autores. Está destinado a profesionales de ciberseguridad y operaciones en entornos industriales. Nada en este documento constituye asesoría legal, normativa o de ingeniería de seguridad. Todas las referencias de marco son a estándares públicamente disponibles; los lectores deben consultar las versiones publicadas actuales para requisitos autorizados. IEC 62443 es una serie de estándares activa y partes individuales están sujetas a revisión.

Conéctate con nosotros para aprender más sobre cómo puedes aprovechar IEC 62443 y NIST SP 100-82 para construir un programa de ciberseguridad.

Descarga nuestra lista de verificación sobre la integración de IEC 62443 y NIST SP 100-82, aquí