Capítulo 5 — Alfabetización en seguridad

Mapa de la lección

Lección 05 publicada. Mapa, ejemplo, EX013.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["5.1 Términos básicos"]
  N2["5.2 Prioridades en un servicio esencial"]
  N3["5.3 Prevenir, detectar, recuperar"]
  N4["5.4 Leer incidentes públicos"]
  N5["5.6 Actividad práctica: una ficha de control"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX013"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["5.1 Términos básicos"]
  N2["5.2 Prioridades en un servicio esencial"]
  N3["5.3 Prevenir, detectar, recuperar"]
  N4["5.4 Leer incidentes públicos"]
  N5["5.6 Actividad práctica: una ficha de control"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX013"]

[Resultados de aprendizaje y conexión]
    |
    v
[5.1 Términos básicos]
    |
    v
[5.2 Prioridades en un servicio esencial]
    |
    v
[5.3 Prevenir, detectar, recuperar]
    |
    v
[5.4 Leer incidentes públicos]
    |
    v
[5.6 Actividad práctica: una ficha de control]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX013]

Resultados de aprendizaje y conexión

Al terminar este capítulo, usted debería ser capaz de:

• usar el vocabulario básico (activo, amenaza, vulnerabilidad, exposición, control, riesgo, incidente, evidencia) de forma precisa y coherente;
• explicar en qué se diferencian las prioridades de seguridad de un servicio esencial de las de una oficina corriente: la disponibilidad y la seguridad física del servicio suelen ir primero;
• describir un control por lo que previene, detecta o ayuda a recuperar, y por la evidencia de que funciona;
• leer un informe público de incidente para extraer sus lecciones sin convertirlo en una técnica.

Los capítulos 1 a 4 trataban de informática. Este capítulo aporta el lenguaje común que usará con operadores, directivos, auditores y proveedores durante el resto del libro. Las palabras imprecisas causan fallos reales: «el PLC es seguro» no significa nada; «el PLC acepta escrituras solo desde la subred del retransmisor, verificado mediante una revisión de flujos el 3 de octubre» significa algo.

5.1 Términos básicos

• Activo: cualquier cosa de valor para el servicio: un controlador de bomba, un historiador, una credencial, un conjunto de datos, el conocimiento de una persona.
• Amenaza: una causa potencial de daño: un grupo criminal, un cambio descuidado, una inundación, un proveedor que falla.
• Vulnerabilidad: una debilidad que una amenaza podría aprovechar: un fallo sin parchear, una contraseña compartida, un camino no documentado, una copia de seguridad sin probar.
• Exposición: si una amenaza puede alcanzar realmente la vulnerabilidad. Un fallo sin parchear en un dispositivo aislado está menos expuesto que el mismo fallo alcanzable desde internet.
• Control: una medida que reduce el riesgo: técnica (una regla de cortafuegos), de procedimiento (una aprobación de cambios) o física (un armario cerrado con llave).
• Riesgo: la combinación de lo probable que es un daño y lo grave que sería, para las personas que dependen del servicio. El capítulo 13 lo concreta.
• Incidente: un suceso que realmente daña, o amenaza con dañar, la confidencialidad, la integridad o la disponibilidad o, en la infraestructura crítica, la seguridad física.
• Evidencia: un registro que permite a alguien distinto de usted comprobar una afirmación.

El Marco de Ciberseguridad 2.0 del NIST organiza los resultados en Gobernar, Identificar, Proteger, Detectar, Responder y Recuperar (NIST CSWP 29); es un mapa útil del territorio, no una lista de casillas que marcar.

5.2 Prioridades en un servicio esencial

La seguridad de la TI de oficina suele describirse en términos de confidencialidad, integridad y disponibilidad, con la confidencialidad en primer lugar. En una red de agua, un hospital o un sistema de transporte, el orden cambia. La primera preocupación suele ser que el servicio físico continúe y que nadie sufra daños; la integridad de los datos de control y de medición le sigue de cerca (un operador que actúa sobre una lectura falsa puede causar daños); la confidencialidad importa (historias clínicas, datos de clientes, diagramas de red), pero rara vez justifica una interrupción. La guía de TO del NIST analiza en qué se diferencian estas prioridades en la tecnología operativa (SP 800-82 Rev. 3).

Esto tiene consecuencias prácticas para un implementador. Un control que podría detener un proceso (un bloqueo automático en una estación de trabajo de operador, un reinicio forzado para aplicar un parche) necesita en TO una aprobación y un momento distintos que en una oficina. Un control que en TI falla «cerrado» puede necesitar fallar «abierto» en un sistema relevante para la seguridad física, y esa elección deben tomarla deliberadamente personas que entienden el proceso, no venir por defecto en la configuración de un proveedor.

5.3 Prevenir, detectar, recuperar

Clasificar los controles por su función ayuda a ver las lagunas. Los controles preventivos impiden que algo ocurra (autenticación, segmentación, listas de permitidos). Los controles detectivos advierten que está ocurriendo (alertas, comprobaciones de integridad, revisiones). Los controles correctivos o de recuperación restablecen el servicio (copias de seguridad, equipos de repuesto, procedimientos de operación manual). Un servicio protegido solo por controles preventivos no tiene forma de advertir cuándo fallan; uno con solo controles detectivos advierte el daño sin poder detenerlo ni deshacerlo. Todo riesgo importante debería tener al menos un control de cada tipo, y todo control debería tener una pieza de evidencia declarada que muestre que funciona, no solo que está configurado.

5.4 Leer incidentes públicos

Los informes públicos de incidentes son el mejor material didáctico de que dispone el sector, si se leen correctamente. Léalos en busca de supuestos fallidos y lecciones: ¿qué creía el operador que no era cierto? El aviso de CISA sobre el suceso de 2021 en la planta de tratamiento de agua de Oldsmar (Florida) describió el software de acceso remoto, las contraseñas compartidas y un sistema conectado a internet como condiciones que había que corregir (CISA AA21-042A); un antiguo responsable municipal declaró más tarde que el suceso fue probablemente un error de un empleado y no una intrusión (WUSF, 13 April 2023). Ambos relatos enseñan la misma lección al implementador: el acceso remoto a un sistema de control con credenciales compartidas y un registro deficiente hace imposible saber después qué ocurrió. Fíjese también en la lección sobre la evidencia: un primer relato puede revisarse.

5.5 Ejemplo resuelto: reescribir afirmaciones vagas (sintético)

Un informe de situación de FSTS dice: «LANTERN es seguro. Los cortafuegos están instalados. Las copias de seguridad se hacen. La monitorización está activa». Reescrito con el vocabulario de este capítulo, y con evidencia:

Tabla de la lección; desplázate para ver todas las columnas →

5.6 Actividad práctica: una ficha de control

Elija un control de LANTERN de los capítulos 2 a 4 (por ejemplo, el validador de mensajes). Escriba una ficha de control de una página: nombre; riesgo que aborda; tipo (prevenir / detectar / recuperar); dónde se implementa; responsable; cómo podría fallar; evidencia de que funciona; fecha de la última evidencia. Ampliará estas fichas en el capítulo 18. Para el validador de mensajes, una ficha completa dice: riesgo, mensajes de estación falsificados, reproducidos o mal formados que llegan al historiador; tipo, prevenir; implementado en la ruta de entrada del retransmisor; responsable, FSTS Platform; podría fallar si el estado de reproducción se pierde al reiniciar o si la lista de permitidos va por detrás de una estación nueva como PS-11; evidencia, las tres aceptaciones, seis rechazos y dos cuarentenas del Lab 3, más los recuentos de rechazos del retransmisor; última evidencia, la fecha de la ejecución más reciente.

5.7 Errores frecuentes y límites

• Usar «seguro» como un estado en lugar de describir protecciones concretas y su evidencia.
• Tratar la confidencialidad como la máxima prioridad en un sistema de control y aceptar el riesgo de interrupción para protegerla.
• Contar controles en lugar de preguntar qué previene, detecta o recupera cada uno.
• Leer los informes de incidentes como guías prácticas, o repetir un primer relato después de que se haya revisado.
• Llamar incidente a cualquier suceso, lo que agota a quienes responden; o no llamar incidente a nada, lo que retrasa la respuesta.

Tres de estos errores aparecen en el informe de situación de este capítulo antes de reescribirse. «LANTERN es seguro» es el primero. «Los cortafuegos están instalados» cuenta un control sin decir que hubo que cerrar un camino no declarado de la zona corporativa a PS-04 con el cambio CHG-121. «La monitorización está activa» ocultaba que la regla B solo detectó 7 de 10 pruebas.

Ejercicios — capítulo 5

EX013 — Precisión terminológica. Objetivo: usar el vocabulario correctamente. Entradas: la frase «La cuenta del proveedor es una amenaza porque la RTU es un riesgo sin control». Restricciones: reescríbala en no más de tres frases. Pasos: (1) identifique cada término mal usado; (2) reescríbala correctamente usando activo, vulnerabilidad, exposición, amenaza y control. Evidencia esperada: texto reescrito con una nota de una línea por corrección. Rúbrica: 3 = la cuenta del proveedor se identifica como vulnerabilidad o vía de exposición (no como amenaza), la RTU como activo, el riesgo se describe como probabilidad y consecuencia, se nombra un control concreto que falta; 2 = casi todo correcto; 1 = cambios cosméticos; 0 = nada.

EX014 — Prevenir, detectar, recuperar. Objetivo: ver las lagunas de control por función. Entradas: el riesgo «un cambio de configuración en el retransmisor hace que se descarten datos de las estaciones». Restricciones: un control por función, implementable por FSTS. Pasos: (1) proponga un control preventivo, uno detectivo y uno de recuperación; (2) indique para cada uno la evidencia de que funciona. Evidencia esperada: tabla de tres filas. Rúbrica: 3 = por ejemplo, aprobación de cambios con revisión por pares (prevenir), alerta de integridad de archivos y alerta de silencio de estación (detectar), configuración versionada con vuelta atrás probada (recuperar), cada uno con evidencia comprobable; 2 = uno débil; 1 = todos preventivos; 0 = nada.

EX015 — Lectura de un informe de incidente. Objetivo: extraer lecciones para el implementador de una fuente pública. Entradas: CISA AA21-042A y el artículo de WUSF. Restricciones: solo lecciones; ninguna técnica de ataque. Pasos: (1) enumere tres condiciones que el aviso recomendaba corregir; (2) indique qué cambia el relato posterior y qué no; (3) escriba una regla de diseño de LANTERN que respalde cada lección. Evidencia esperada: nota de media página que cite ambas fuentes. Rúbrica: 3 = condiciones como el software de acceso remoto, las credenciales compartidas y la exposición a internet extraídas correctamente del aviso; reconoce que la revisión cambia la atribución, no el valor de las lecciones de higiene; las reglas de diseño son concretas; 2 = un elemento débil; 1 = repite el primer relato como un hecho establecido; 0 = nada.

Síntesis del capítulo

El vocabulario preciso es un control de seguridad: hace comprobables las afirmaciones. En los servicios esenciales, la continuidad y la seguridad física del servicio suelen ir primero, lo que cambia cómo se eligen los controles, cuándo se aplican y cómo se les permite fallar. Describa cada control por lo que previene, detecta o recupera, y por la evidencia de que funciona. Lea los incidentes públicos en busca de supuestos fallidos y siga sus revisiones.