OpenCyber AcademyMapa de la lección
Lección 34 publicada. Mapa, ejemplo, EX100.
flowchart TD
N0["Resultados de aprendizaje"]
N1["34.1 Contrato de eventos"]
N2["34.2 Consumidores idempotentes"]
N3["34.3 Pruebas de contrato"]
N4["Nota práctica"]
N5["34.1b Mensajes fallidos y simulacros de esquema"]
N6["Nota de campo: cuarentena de eventos envenenados"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX100"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["34.1 Contrato de eventos"]
N2["34.2 Consumidores idempotentes"]
N3["34.3 Pruebas de contrato"]
N4["Nota práctica"]
N5["34.1b Mensajes fallidos y simulacros de esquema"]
N6["Nota de campo: cuarentena de eventos envenenados"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX100"]
[Resultados de aprendizaje]
|
v
[34.1 Contrato de eventos]
|
v
[34.2 Consumidores idempotentes]
|
v
[34.3 Pruebas de contrato]
|
v
[Nota práctica]
|
v
[34.1b Mensajes fallidos y simulacros de esquema]
|
v
[Nota de campo: cuarentena de eventos envenenados]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX100]
Resultados de aprendizaje
Usted podrá (1) integrar los eventos del monitor en el almacén de hallazgos; (2) definir consumidores idempotentes; (3) probar los contratos con datos de prueba.
34.1 Contrato de eventos
Eventos de denegar/permitir: versión del esquema, identificadores, marcas de tiempo UTC, origen, fc, registro, motivo, versión de la política. Los consumidores ignoran los campos desconocidos; los productores solo hacen cambios aditivos. El contrato de eventos de Lena en ABP tiene versión y se publica con datos de prueba para cada código de motivo. Cada evento lleva tanto la hora en que ocurrió como la hora en que se recibió, además de la fuente del reloj. Los productores pueden añadir campos, pero nunca eliminarlos ni renombrarlos dentro de una versión, de modo que los consumidores antiguos siguen funcionando. Los datos de prueba se guardan en el repositorio. Los cambios se revisan.
34.2 Consumidores idempotentes
El almacén de hallazgos indexa los eventos procesados por event_id. Reproducir el registro no debe crear hallazgos duplicados. Lena prueba la reproducción en el banco pasando dos veces por el consumidor el registro de eventos de un día completo y comprobando que el número de hallazgos no cambia. La prueba detectó un error en el que los eventos se indexaban por marca de tiempo en lugar de por event_id, lo que duplicó tres tickets durante una tormenta de reproducción antes de que llegara la corrección. Las pruebas de reproducción se ejecutan en la integración continua. Los fallos bloquean la fusión. La prueba se ejecuta cada noche.
34.3 Pruebas de contrato
JSON de datos de prueba para cada código de motivo del monitor, como register-out-of-range; las pruebas del consumidor comprueban los campos del ticket resultante. Se ejecutan en la integración continua con datos de prueba sintéticos.
Caso sintético — Ashford Batch Plant. Una tormenta de reproducción duplicó tres tickets hasta que llegó la idempotencia por event_id.
Las pruebas de contrato de Lena se ejecutan con cada solicitud de incorporación de cambios y de forma programada. Usan un dato de prueba para cada código de motivo y comprueban los campos del ticket que debería crear el consumidor, como el activo, la técnica y la severidad. Una ejecución programada contra el entorno de preproducción detecta los cambios de los productores aunque no haya ninguna solicitud abierta, de modo que la deriva se encuentra antes de una ventana y no durante ella.
34.4 Errores y límites
El desfase de los relojes enturbia las cronologías; prefiera la hora del evento más la hora de recepción. La vista de cronología de Lena en ABP muestra la hora del evento y la hora de recepción una al lado de la otra, para que el lector pueda ver cuándo el reloj de un dispositivo está mal. El laboratorio II inyectó más adelante un desfase de 90 segundos en el PLC-A y descubrió que dos eventos quedaban mal ordenados en el expediente hasta que se aplicó una corrección del desplazamiento. Las fuentes de reloj se registran en cada evento precisamente por esta razón. Lena mantiene los relojes sincronizados cuando es posible. La deriva genera alarma.
Nota práctica
Los eventos envenenados (marcas de tiempo futuras, versiones de política desconocidas) van a una cola de mensajes fallidos con una alerta: no a los hallazgos ni a /dev/null.
34.1b Mensajes fallidos y simulacros de esquema
Cada evento enviado a la cola de mensajes fallidos conserva el error de validación que lo rechazó. Los operadores lo reproducen tras corregir el productor. Una vez por periodo, el equipo del CNHP añade de extremo a extremo un campo opcional en un ensayo en el banco: productor, consumidor, datos de prueba, documentación. Los equipos que solo hacen evolucionar los esquemas en emergencias inventan atajos incompatibles. Una ejecución programada fallida abre un ticket para el equipo productor, no para el consumidor. La antigüedad de los mensajes fallidos es un gráfico de SLO junto a la latencia del camino de denegación.
ABP realiza un simulacro de esquema cada periodo lectivo. Los resultados de los simulacros se registran con las versiones del productor y del consumidor implicadas, como el simulacro que añadió la hora de recepción junto a la hora del evento en los eventos de denegación del PLC-A.
Nota de campo: cuarentena de eventos envenenados
Un error de un productor emitió eventos con marcas de tiempo de 2099. La cuarentena de mensajes fallidos los atrapó; no se creó ningún hallazgo contra equipos aleatorios. Los descartes invisibles habrían sido peores: al menos la cuarentena avisa a alguien.
El canario del consumidor del CNHP hace fallar el despliegue si los eventos envenenados del monitor no se ponen en cuarentena en menos de un minuto en preproducción.
Cada simulacro termina con el nuevo campo visible en un ticket de preproducción para una denegación sintética del PLC-A, y con la duración del simulacro registrada.
34.5 Ejemplo resuelto: integrar las alertas con el sistema de mantenimiento (ABP sintética)
Las alertas del CNHP fluyen hacia el sistema de gestión del mantenimiento de ABP para que una alerta de «descarga de programa al PLC-A» pueda asociarse a una orden de trabajo abierta. El contrato de eventos lleva un identificador de evento, la etiqueta del activo, la técnica de ATT&CK for ICS (T0843 Program Download), la hora con la fuente del reloj y el hash de la evidencia. El consumidor es idempotente respecto al identificador de evento, de modo que una alerta reproducida no crea dos órdenes de trabajo. Las pruebas de contrato se ejecutan en la integración continua con datos de prueba de ambas partes; un evento sin el campo de técnica se envía a una cola de mensajes fallidos y se revisa a diario, en lugar de descartarse. Una descarga sin orden de trabajo asociada se escala al jefe de turno en menos de cinco minutos.
Ejercicios — capítulo 34
- EX100 — Campo. ¿Por qué incluir policy_version en cada evento? Rúbrica: 3 = auditar qué reglas se aplicaron; 2 = vago; 1 = incorrecto; 0 = nada.
- EX101 — Reproducción. ¿Cómo evita event_id los hallazgos duplicados? Rúbrica: 3 = inserción o actualización / ignorar duplicados; 2 = vago; 1 = incorrecto; 0 = nada.
- EX102 — Datos de prueba. Dos datos de prueba necesarios antes de un nuevo código de motivo. Rúbrica: 3 = ejemplo del productor + ticket esperado del consumidor; 2 = uno; 1 = vago; 0 = nada.
Síntesis del capítulo
Contratos, consumidores idempotentes, pruebas con datos de prueba.
Siga estudiando — capítulo 34 de 50
← Capítulo 33 (borrador) · Índice de capítulos del curso · Capítulo 35 (borrador) →