ENS desde dentro (XXV): Gestión de incidentes (op.exp.7) — de la alerta del EDR al registro que un auditor puede leer

Un proceso intenta modificar una clave de registro del sensor de seguridad en un servidor. El EDR lo bloquea en segundos. Para el sistema, ahí termina el problema. Para op.exp.7, ahí es donde empieza el trabajo de verdad.

Este artículo forma parte de la serie ENS desde dentro.

👉 Puedes ver la guía completa aquí:

https://www.handersonboratto.com/ens-desde-dentro/

👉 Si es tu primera vez en la serie, empieza por aquí:

https://www.handersonboratto.com/blog/que-es-ens/

👉 O continúa con el artículo anterior:

https://www.handersonboratto.com/blog/ens-proteccion-codigo-danino-op-exp-6/

Si op.exp.6 se ocupaba de que el antivirus y el EDR funcionen como deben, op.exp.7 se ocupa de lo que pasa cuando, pese a todo, algo salta: un proceso sospechoso, un correo de phishing, un intento de acceso que no debería haber ocurrido. La pregunta que exige responder no es "¿lo detectaste?", sino "¿queda constancia de qué pasó, cómo se clasificó y cómo se cerró?"

Qué cuenta como incidente

Un incidente de seguridad es, según el ENS, cualquier suceso inesperado o no deseado con consecuencias en detrimento de la seguridad del sistema. También cuenta si lo que se detecta no es un incidente consumado sino una vulnerabilidad o debilidad que podría llegar a serlo. Cualquier usuario que detecte uno de estos dos casos tiene que notificarlo al Responsable de Seguridad o al Responsable de Sistemas, y ese incidente se registra —en una plantilla dedicada o en un sistema de ticketing— con, como mínimo, su clasificación, la fecha y hora de detección y de notificación, quién lo recibe y su estado.

Lo interesante no es la lista de campos obligatorios, que es sencilla, sino la clasificación. El ENS no deja "es un incidente" como categoría única: distingue entre contenido dañino, intentos de intrusión, intrusión consumada, problemas de disponibilidad, compromiso de la información, fraude, sistemas vulnerables expuestos y varias más. Esa clasificación no es papeleo decorativo: determina, junto con la peligrosidad y el impacto potencial estimado, si el incidente se queda en un registro interno o si hay que escalarlo fuera de la organización.

Cómo se ve en la práctica

El registro no tiene que ser complicado para ser útil. Cuatro ejemplos reales, ya cerrados, ilustran bien la variedad de lo que puede entrar ahí en cuestión de meses.

El primero: el EDR detecta, mediante análisis de comportamiento, un archivo sospechoso durante un escaneo rutinario y lo pone en cuarentena automáticamente antes de que nadie tenga que intervenir. Clasificación: contenido dañino, peligrosidad alta, impacto alto. Cierre en menos de tres horas, con la única acción humana siendo confirmar que el equipo quedaba limpio.

El segundo y el tercero son casi gemelos, separados por unas semanas: un proceso ejecutado desde un directorio temporal —asociado a una herramienta de desinstalación de antivirus de terceros— intenta modificar las claves de registro que usa el sensor de seguridad en un servidor. El EDR bloquea la operación automáticamente. Se revisa el proceso implicado, se verifica que el servidor y la protección siguen íntegros, y se cierra sin que haya hecho falta restaurar nada. Clasificación: intento de intrusión, peligrosidad alta, impacto alto.

El cuarto es distinto en naturaleza: la directora financiera de la organización reporta un correo que huele a suplantación de identidad. El filtro antispam del correo ya lo había parado, pero el registro no se cierra con eso —se verifica que el equipo no se vio afectado y se notifica al equipo de seguridad para valorar medidas adicionales. Clasificación: compromiso de la información, peligrosidad alta, impacto medio.

Ningún registro cuenta una historia límite. Todos comparten el mismo patrón: qué pasó, quién lo detectó o lo notificó, qué se hizo, qué sistemas se vieron afectados y cómo se confirmó el cierre. Eso es exactamente lo que un auditor va a querer ver, y es exactamente lo que un sistema de ticketing normal ya captura si se usa con disciplina.

Cuándo el incidente sale de casa

La mayoría de estos registros no salen nunca de la organización. Pero cuando la peligrosidad estimada es alta, muy alta o crítica, el ENS obliga a comunicar el incidente al CCN-CERT o al INCIBE-CERT, con una descripción lo más detallada posible y un contacto de referencia. Y si el incidente implica una violación de seguridad de datos personales, entra en juego el Delegado de Protección de Datos, que decide si hay que informar a la AEPD, a los responsables del tratamiento o a los propios interesados —para lo cual necesita saber, como mínimo, cuántos datos se vieron afectados, de qué tipo eran y si la exposición fue interna, externa o pública.

Hay un tercer hilo que conecta con el resto de la serie: el seguimiento mensual de los avisos del CCN-CERT. No es un trámite aislado —es la fuente de la reconfiguración dinámica: cambios en reglas de firewall, listas de control de acceso o parámetros del sistema de detección de intrusiones que se aplican como respuesta directa a una alerta publicada, antes de que esa alerta se convierta en un incidente propio.

La lección práctica

Si algo me llevo de este control es que la mayoría de los "incidentes" que vas a registrar no son películas de hackers, son el sistema haciendo exactamente lo que tiene que hacer: bloquear, poner en cuarentena, avisar. El valor de op.exp.7 no está en que pase algo grave, está en que quede constancia de que lo pequeño también se vio, se clasificó y se cerró.

Mi recomendación: no dejes el registro para los incidentes que "merecen la pena". Si tu EDR pone algo en cuarentena a las tres de la madrugada y nadie lo anota en ningún sitio, ese hueco es exactamente lo que un auditor va a encontrar primero.

Este post forma parte de la serie "ENS desde dentro", donde comparto cómo se implementan y auditanen la práctica las medidas del Esquema Nacional de Seguridad. Si te está siendo útil, puedes suscribirte a la newsletter para recibir cada entrega, o descargar el checklist "Documentación para una auditoría ENS" con los 8 bloques de evidencia que un auditor va a pedirte.