De cuatro fases a seis funciones

La guía anterior (Rev 2, de 2012) dibujaba la respuesta como cuatro fases en círculo: preparación; detección y análisis; contención, erradicación y recuperación; y actividad posterior al incidente, que alimentaba de nuevo la preparación. Funcionaba cuando los incidentes eran raros, acotados y se cerraban en uno o dos días.

La Rev 3 (abril de 2025, que sustituye a la anterior) parte de otra realidad: los incidentes son frecuentes, hacen más daño y recuperarse puede llevar semanas o meses. Por eso trata la respuesta como una parte de la gestión del riesgo de ciberseguridad, repartida por toda la organización, y organiza sus recomendaciones como un perfil comunitario de CSF 2.0: un conjunto de resultados del marco, priorizados, que sirve de base común a varias organizaciones.

Las seis funciones son Govern (gobernar), Identify (identificar), Protect (proteger), Detect (detectar), Respond (responder) y Recover (recuperar). La Rev 3 explica que Govern, Identify y Protect ayudan a prevenir algunos incidentes y a prepararse para los que ocurran, mientras que Detect, Respond y Recover son los que descubren, gestionan, contienen, erradican y recuperan.

Abre la estación y lee inventario-de-actividades.csv: las diez actividades del plan de Nereo ya traen la función de CSF 2.0 en su última columna. Cuenta las que caen en Govern, Identify o Protect, incluida la que cae en la categoría de mejora de Identify.

En el modelo anterior la cuarta fase era la actividad posterior al incidente: reunirse, revisar qué falló y escribir lecciones. En CSF 2.0 no hay una función con ese nombre. Esas lecciones viven en la categoría Improvement (ID.IM) de la función Identify, y la Rev 3 las dibuja como una capa continua que recibe lo aprendido de todas las funciones y lo devuelve a todas, sin esperar a que el incidente termine.

La tabla fases-a-funciones.txt de la estación lo muestra de otra forma: la fase anterior de preparación se reparte en tres funciones y la mejora se asoma en las tres filas restantes.

El círculo antiguo dejaba las lecciones para el final: se cerraba el incidente, se hacía la reunión y las mejoras entraban en la siguiente vuelta. La Rev 3 dice que cuando recuperarse tarda semanas o meses, las lecciones deben compartirse en cuanto se identifican, no esperar a que acabe la recuperación.

Un ejemplo corriente: al tercer día de un incidente largo el equipo descubre que nadie sabe quién puede autorizar apagar un servidor. Esperar a la reunión final es seguir perdiendo tiempo con el mismo hueco.