CIP-008-6 exige tener por escrito un plan de respuesta a incidentes cibernéticos para los sistemas de impacto alto y medio, probarlo al menos cada 15 meses, actualizarlo después de cada prueba o incidente real y notificar los incidentes reportables al E-ISAC en una hora y los intentos de compromiso antes de que termine el día calendario siguiente. Las actualizaciones posteriores se envían en 7 días calendario.
Qué cubre CIP-008
CIP-008 trata lo que ocurre después de que algo sale mal en un sistema cibernético del sistema eléctrico: quién hace qué, cómo se decide si es un incidente que hay que reportar y a quién se avisa. Aplica a los sistemas de impacto alto y medio, clasificados según CIP-002, y a sus sistemas de control y monitoreo del acceso electrónico (EACMS). La versión descrita es CIP-008-6.
Tiene cuatro requisitos: el plan (R1), su aplicación y prueba (R2), su mantenimiento (R3) y las notificaciones (R4).
R1: qué debe tener el plan
Un plan escrito que incluya:
- Procesos para identificar, clasificar y responder a incidentes (parte 1.1).
- Procesos para decidir si un incidente es reportable o es un intento de compromiso, con criterios propios para definir qué es un intento, y para notificar según R4 (parte 1.2).
- Roles y responsabilidades de los grupos o personas que responden (parte 1.3).
- Procedimientos de manejo del incidente: contención, erradicación y recuperación (parte 1.4).
La parte 1.2 es la más difícil de escribir bien. La norma no fija qué es un intento de compromiso: obliga a la entidad a definirlo y a justificar sus criterios. Un plan que diga solo «se evaluará caso por caso» no cumple.
R2: aplicar y probar el plan
- Prueba cada 15 meses calendario (parte 2.1). Se cumple de tres formas: respondiendo a un incidente reportable real, con un ejercicio de mesa de un incidente reportable o con un ejercicio operativo.
- Usar el plan de verdad (parte 2.2). Cuando ocurre un incidente reportable, un intento de compromiso o un ejercicio, se sigue el plan y se documentan las desviaciones.
- Guardar los registros (parte 2.3) de los incidentes reportables y los intentos de compromiso, como indique el plan.
La evidencia típica incluye informes del incidente, registros y notas tomadas durante la respuesta, y un informe de lecciones aprendidas con el resumen de la prueba.
R3: mantener el plan al día
| Cuándo | Qué hay que hacer |
|---|---|
| Hasta 90 días calendario después de una prueba o de un incidente reportable real | Documentar las lecciones aprendidas, o documentar que no hubo; actualizar el plan con ellas; avisar de los cambios a cada persona o grupo con un rol en el plan |
| Hasta 60 días calendario después de un cambio en roles, responsables o tecnología que afecte la capacidad de ejecutar el plan | Actualizar el plan y avisar a cada persona o grupo con un rol |
La segunda fila es la que más se olvida: si cambia el equipo de operación, el proveedor de servicios gestionados o el firewall central, el plan se actualiza aunque no haya ocurrido ningún incidente.
R4: a quién se notifica y cuándo
Se notifica al E-ISAC (Electricity Information Sharing and Analysis Center) y, si la entidad está sujeta a la jurisdicción de Estados Unidos, al centro nacional de ciberseguridad de ese país (NCCIC o su sucesor), salvo que la ley lo prohíba.
| Situación | Plazo de la notificación inicial |
|---|---|
| Incidente reportable | Una hora después de determinarlo |
| Intento de comprometer un sistema cubierto | Antes de que termine el día calendario siguiente a la determinación |
| Datos nuevos o cambiados | Actualización dentro de 7 días calendario |
Las notificaciones iniciales y las actualizaciones incluyen, como mínimo y en lo que se conozca, tres atributos: impacto funcional, vector de ataque e intrusión lograda o intentada.
Qué significa esto en una subestación
Un plan útil responde preguntas concretas de operación, no solo de informática:
- Quién decide desconectar un enlace al centro de control y cómo se mantiene la operación local mientras tanto.
- Cómo se recuperan las configuraciones de relés, gateways y switches a partir de respaldos verificados. Ver gestión de configuración de IED y SCD.
- Qué registros existen para reconstruir lo ocurrido: sincronización de hora, registros de eventos y capturas de red. Ver sincronización de tiempo y detección de intrusos en redes de subestación.
- Quién del proveedor puede ser llamado y con qué acceso, coordinado con el acceso remoto seguro.
Aplicación fuera de Norteamérica
NERC CIP no es obligatoria en Colombia, y el E-ISAC y el NCCIC no son destinatarios de un agente colombiano. Lo transferible es la estructura: criterios de clasificación, roles, plazos de notificación, pruebas periódicas y lecciones aprendidas. El marco colombiano está en Acuerdo CNO 1960. La configuración base y la gestión de cambios y vulnerabilidades que pide CIP-010 están en NERC CIP-010: gestión de cambios y vulnerabilidades.
¿Necesita preparar su plan y su ejercicio?
En Tiza Group preparamos la parte técnica del plan de respuesta de subestaciones e industria: inventario de equipos, respaldos de configuración, registros y accesos, dentro de nuestro servicio de ciberseguridad de subestaciones y plantas. Le cotizamos según el alcance de su instalación. Cómo armar el plan, con roles, escalamiento y pruebas anuales, está en plan de respuesta a incidentes en una subestación.
Guías relacionadas
- NERC CIP: qué exige y qué se puede tomar en Colombia
- NERC CIP-005: perímetro electrónico y acceso remoto
- Detección de intrusos (IDS) en redes de subestación
- Gestión de configuración: versiones de ajustes y del SCD
- Ciberseguridad de subestaciones y plantas: normas y mapa
- Plan de respuesta a incidentes en una subestación
- NERC CIP-010: gestión de cambios y vulnerabilidades
Referencias
- NERC, CIP-008-6, Cyber Security – Incident Reporting and Response Planning: requisitos R1 a R4.
Preguntas frecuentes
¿Cada cuánto se debe probar el plan de respuesta?
Al menos una vez cada 15 meses calendario. La prueba puede ser la respuesta a un incidente reportable real, un ejercicio de mesa sobre un incidente reportable o un ejercicio operativo. Después de la prueba se tienen 90 días calendario para documentar las lecciones aprendidas y actualizar el plan.
¿En cuánto tiempo hay que notificar un incidente?
Una hora después de determinar que es un incidente reportable. Si fue un intento de comprometer un sistema cubierto, antes de que termine el día calendario siguiente a esa determinación. Las actualizaciones, si cambian los datos notificados, van dentro de 7 días calendario.
¿Qué datos debe tener la primera notificación?
Como mínimo, y en la medida en que se conozcan: el impacto funcional, el vector de ataque usado y el nivel de intrusión logrado o intentado.