Gestión de incidentes y brechas de seguridad

La gestión de incidentes y brechas de seguridad es una de esas expresiones que suenan a manual, a comité, a documento con membrete y a carpeta olvidada en algún servidor compartido. Y, sin embargo, detrás de esas palabras algo mustias se esconde una verdad bastante menos burocrática y mucho más incómoda: cualquier organización que maneje información, sistemas, correos, bases de datos, usuarios, proveedores o simples documentos digitales está expuesta a que algo falle, a que alguien meta la pata o a que un tercero intente hacer daño.

No hace falta imaginar a un hacker con capucha, tecleando furiosamente en una habitación azulada por el brillo de seis pantallas. A veces el incidente empieza de forma mucho más vulgar. Un correo aparentemente inocente. Una contraseña repetida desde tiempos de Maricastaña. Un portátil perdido. Un archivo enviado al destinatario equivocado. Una actualización mal aplicada. Un proveedor que sufre un ataque. Una cuenta comprometida. Un empleado que pulsa donde no debe. Una copia de seguridad que, cuando llega la hora de la verdad, resulta ser tan útil como un paraguas de papel en pleno diluvio.

Conviene decirlo sin paños calientes: la seguridad absoluta no existe. INCIBE lo resume con claridad cuando recuerda que las empresas deben estar preparadas para protegerse y reaccionar ante incidentes que puedan dañar su capacidad operativa o comprometer la continuidad del negocio. La clave no es vivir en la fantasía de que nunca ocurrirá nada, sino tener previsto qué hacer cuando ocurra.

Y ahí es donde entra la gestión de incidentes. No como un adorno documental ni como un trámite para quedar bien ante una auditoría, sino como una disciplina de supervivencia. La diferencia entre una organización seria y una organización dejada no está en que una sufra problemas y la otra no. Está en que una detecta, comunica, contiene, analiza, recupera y aprende; mientras la otra improvisa, niega, oculta, reza y acaba convertida en carne de expediente, de sanción o de titular.

Un incidente de seguridad es cualquier evento que compromete, o puede comprometer, la confidencialidad, la integridad, la disponibilidad, la autenticidad o la trazabilidad de la información. Dicho en cristiano viejo: algo que pone en peligro que los datos sigan siendo privados, correctos, accesibles, fiables y atribuibles. Puede ser un acceso no autorizado, una pérdida de información, una caída de sistemas, una configuración defectuosa, un malware, un ransomware, una fuga de datos, una suplantación de identidad, un error humano, un fallo de proveedor o una brecha de datos personales.

La palabra “brecha” tiene algo de grieta en muralla vieja. Y no anda desencaminada. Por esa grieta puede escaparse información sensible, pueden entrar terceros no autorizados o puede quedar expuesta la intimidad de personas que confiaron sus datos a una organización. La Agencia Española de Protección de Datos define la brecha de datos personales como un incidente que provoque destrucción, pérdida o alteración accidental o ilícita de datos personales, o bien comunicación o acceso no autorizado a esos datos.

Y entonces empieza la carrera. Porque cuando hay datos personales afectados no estamos sólo ante un problema técnico. Estamos ante una responsabilidad legal, reputacional y ética. La AEPD recuerda que, cuando exista riesgo para los derechos y libertades de las personas, la brecha debe notificarse a la autoridad de control en un plazo de 72 horas desde que la organización tiene constancia de ella. Y si el riesgo es alto, también puede ser necesario comunicarla a las personas afectadas.

Setenta y dos horas. Tres días. Incluidos fines de semana y festivos, según la guía de la propia AEPD. Nada de “ya lo miraremos el lunes”, “vamos a ver si se arregla solo” o “mejor no hacer ruido”. En seguridad, como en los naufragios, el silencio rara vez salva a nadie.

Por eso el primer mandamiento de la gestión de incidentes es la detección temprana. Hay que ver el humo antes de que arda el edificio entero. Y para eso no basta con herramientas técnicas, aunque sean necesarias. Hace falta cultura interna. Que cualquier empleado, colaborador, proveedor o usuario autorizado sepa que debe comunicar sin demora cualquier anomalía relevante: un acceso extraño, un correo sospechoso, una pérdida de dispositivo, una actividad inusual, una carpeta que desaparece, un sistema que se comporta de forma rara o una comunicación de un tercero alertando de un problema.

El peor enemigo en estos casos no siempre es el atacante. A veces es la vergüenza. El miedo a decir “he pulsado donde no debía”. El temor a una bronca. La tentación de esperar, de disimular, de cerrar la ventana rota y hacer como si no hubiera pasado nada. Esa cultura es letal. Una organización madura no convierte al mensajero en culpable. Lo escucha, registra el aviso y actúa. Porque una hora perdida al principio puede convertirse en una semana de desastre después.

Una vez detectado el incidente, hay que registrarlo. Y aquí empieza la parte menos literaria, pero más necesaria. Fecha y hora de detección. Persona que reporta. Descripción inicial. Sistemas o servicios afectados. Impacto preliminar. Medidas adoptadas. Evidencias disponibles. Todo debe quedar documentado desde el primer momento. No por amor a la burocracia, sino porque la memoria humana, cuando hay presión, nervios, llamadas cruzadas y jefes preguntando cada cinco minutos, vale menos que una moneda falsa.

El registro inicial permite reconstruir lo ocurrido. También permite justificar decisiones. Y, llegado el caso, demostrar diligencia. Porque no es lo mismo sufrir un incidente y poder acreditar que se actuó con rapidez, orden y proporcionalidad, que aparecer después con cuatro notas sueltas, tres correos inconexos y una explicación improvisada. La trazabilidad, esa palabra tan fea y tan imprescindible, es la columna vertebral de una respuesta seria.

Después llega la clasificación. No todos los incidentes son iguales. No es lo mismo un correo sospechoso bloqueado a tiempo que una base de datos expuesta. No es lo mismo una caída breve de un servicio secundario que un ransomware cifrando servidores. No es lo mismo una incidencia interna sin datos personales comprometidos que una filtración de información sensible de clientes, colegiados, empleados, usuarios o proveedores.

Clasificar es poner orden en el caos. Naturaleza del incidente. Criticidad. Alcance. Urgencia. Impacto operativo. Riesgo legal. Posible afectación a datos personales. Servicios afectados. Personas implicadas. Necesidad de escalar. Todo eso permite priorizar. Porque cuando todo parece urgente, nada se gestiona bien. Hay que saber qué se apaga primero, qué se aísla, a quién se avisa y qué decisiones no pueden esperar.

La fase de contención es la del bombero que corta el gas antes de discutir el origen de la chispa. Se trata de impedir que el problema crezca. Aislar equipos. Bloquear accesos. Revocar credenciales. Suspender servicios. Desconectar sistemas comprometidos. Parar temporalmente una funcionalidad. Cortar comunicaciones sospechosas. Preservar evidencias. Activar copias de seguridad. Lo necesario para limitar la propagación o agravamiento del incidente.

Aquí conviene no confundir rapidez con atropello. Contener no significa arrasar. Si se actúa sin criterio, se pueden destruir evidencias, empeorar la situación o dejar a la organización sin capacidad operativa. Pero si no se actúa, el incidente puede extenderse como una mancha de aceite. Por eso la respuesta debe estar coordinada. Seguridad, sistemas, protección de datos, dirección, comunicación, responsables funcionales y proveedores críticos deben saber cuál es su papel antes de que suene la alarma.

Después viene el análisis y diagnóstico. La pregunta ya no es sólo qué ha pasado, sino por qué ha pasado, hasta dónde ha llegado y qué consecuencias puede tener. Hay que identificar la causa raíz, el vector de entrada, los sistemas afectados, los datos comprometidos, las cuentas utilizadas, la duración de la exposición, los posibles terceros implicados y los riesgos regulatorios asociados.

No basta con decir “ha sido un virus” o “se ha caído el sistema”. Eso es como diagnosticar una enfermedad diciendo que el paciente tiene mala cara. Hay que saber si el origen fue un phishing, una vulnerabilidad sin parchear, una contraseña débil, una mala configuración, una negligencia interna, un proveedor comprometido o una concatenación de pequeñas miserias técnicas y organizativas. Porque si no se entiende la causa, sólo se barre el polvo debajo de la alfombra.

En ciberseguridad, improvisar tarde suele salir más caro que prepararse a tiempo

El escalado es otra pieza esencial. Hay incidentes que puede resolver el equipo técnico sin levantar demasiada polvareda. Otros deben llegar de inmediato a los responsables de seguridad, al delegado de protección de datos si existe, a la dirección, al área jurídica, a comunicación o a los responsables de los servicios afectados. No por dramatizar, sino porque algunas decisiones tienen consecuencias legales, económicas y reputacionales. Y esas decisiones no pueden tomarlas a ciegas quienes sólo están viendo una parte del tablero.

La comunicación interna debe ser clara, sobria y útil. Nada de mensajes alarmistas ni de silencios soviéticos. Quienes necesitan saber, deben saber. Quienes deben actuar, deben recibir instrucciones. Quienes pueden agravar el problema por desconocimiento, deben ser advertidos. En una crisis de seguridad, el rumor es otro malware. Infecta rápido, distorsiona la realidad y puede provocar decisiones torpes.

Cuando el incidente afecta a datos personales, la organización debe abrir una evaluación específica. Hay que determinar si estamos ante una brecha de seguridad de datos personales, qué tipo de datos han sido afectados, cuántas personas pueden verse comprometidas, qué consecuencias puede tener para ellas y qué medidas se han adoptado para reducir el riesgo. La AEPD permite incluso realizar una notificación inicial dentro del plazo cuando aún no se dispone de toda la información, ampliándola después con información adicional.

Este punto es importante porque muchas organizaciones caen en una trampa peligrosa: esperar a tenerlo todo claro antes de mover ficha. Pero en una brecha de datos personales, esperar demasiado puede ser precisamente el problema. La diligencia no exige omnisciencia. Exige actuar sin dilación, evaluar con seriedad y comunicar cuando corresponda. No se trata de correr como pollo sin cabeza, sino de no esconder la cabeza bajo el ala.

Luego llega la recuperación. Una vez contenido el incidente y eliminada la causa, hay que restaurar servicios, sistemas o procesos afectados de forma segura y progresiva. No basta con encender de nuevo las máquinas y brindar porque “ya funciona”. Hay que verificar que el origen del incidente ha sido corregido, que no quedan accesos indebidos, que las credenciales han sido revisadas, que las copias de seguridad son fiables, que los parches se han aplicado y que los sistemas vuelven a operar en condiciones aceptables.

La recuperación debe ser controlada. Una organización que se precipita puede reabrir la puerta al mismo atacante. Es el clásico error de volver al edificio antes de comprobar que no quedan brasas bajo las vigas. La continuidad de negocio importa, desde luego. Pero recuperar mal puede ser peor que recuperar despacio. La prisa sin verificación suele ser sólo una forma elegante de reincidir.

Después debe llegar el cierre formal. Y aquí muchos fallan. Cuando el sistema vuelve a funcionar, todo el mundo quiere pasar página. Se respira, se apagan los teléfonos, alguien dice “menos mal” y el asunto se archiva mentalmente. Error. Un incidente no termina cuando vuelve el servicio. Termina cuando queda documentado qué ocurrió, cuál fue el impacto real, qué medidas se adoptaron, quién asumió responsabilidades, cuándo se cerró y qué queda pendiente de mejorar.

El cierre formal no es un entierro administrativo. Es el acta de una batalla. Sirve para aprender, para rendir cuentas y para evitar que dentro de seis meses alguien vuelva a tropezar con la misma piedra, en el mismo pasillo y con idéntica cara de sorpresa. La organización que no documenta sus incidentes está condenada a repetirlos con la solemnidad estúpida de quien llama mala suerte a su propia dejadez.

Y finalmente llegan las lecciones aprendidas. La parte más incómoda y, por eso mismo, la más valiosa. ¿Qué falló? ¿La formación? ¿La configuración? ¿La supervisión de proveedores? ¿Las copias de seguridad? ¿La gestión de accesos? ¿La rapidez de comunicación? ¿La falta de responsables claros? ¿La ausencia de simulacros? ¿La confianza excesiva en que “eso aquí no pasa”?

Las lecciones aprendidas deben traducirse en mejoras concretas. No en frases bonitas. Nuevos controles. Revisión de permisos. Refuerzo de autenticación. Formación interna. Actualización de procedimientos. Pruebas periódicas de recuperación. Revisión de contratos con proveedores. Mejoras en monitorización. Simulacros. Indicadores. Responsables. Fechas. Seguimiento.

Porque la mejora continua, cuando se toma en serio, no es una consigna de PowerPoint. Es la diferencia entre una organización que madura y una que simplemente envejece.

También conviene medir. Número de incidentes registrados. Tipologías. Tiempos de detección. Tiempos de respuesta. Tiempo de recuperación. Incidentes recurrentes. Áreas más afectadas. Orígenes más habituales. Proveedores implicados. Costes. Impacto operativo. Necesidad de notificación. Todo eso permite ver tendencias. Y las tendencias, cuando se observan con honestidad, cuentan historias que a veces nadie quiere escuchar.

Si cada tres meses se repiten incidentes por contraseñas débiles, el problema no es la mala suerte. Si los errores de configuración son habituales, quizá falla el control de cambios. Si los proveedores aparecen demasiadas veces en el mapa de riesgos, habrá que revisar contratos, exigencias y responsabilidades. Si nadie reporta incidentes, no significa necesariamente que no existan. Puede significar que nadie sabe detectarlos o que nadie se atreve a contarlos.

La gestión de incidentes y brechas de seguridad debe perseguir una finalidad clara: asegurar una respuesta estructurada, proporcionada y trazable que minimice el impacto operativo, legal, económico y reputacional sobre la organización. Dicho de otro modo: evitar que un problema se convierta en catástrofe por culpa de la improvisación.

No hay épica en un procedimiento, lo sé. Nadie compone cantares de gesta sobre registros de incidentes, matrices de criticidad o informes de cierre. Pero en estos asuntos la épica verdadera está en la disciplina. En hacer lo correcto cuando todo invita al nerviosismo. En comunicar a tiempo. En no ocultar. En no improvisar. En no culpar al primero que levanta la mano. En no tratar la seguridad como un gasto molesto hasta que llega el día en que el gasto se llama sanción, rescate, pérdida de confianza o caída de servicio.

Una organización preparada no es la que presume de invulnerable. Esa suele ser la primera en caer con estrépito. Una organización preparada es la que acepta que el riesgo existe, que los errores ocurren, que los atacantes insisten y que los sistemas fallan. Y precisamente por eso establece un procedimiento formal, entrena a su gente, define responsabilidades, documenta actuaciones, evalúa impactos, comunica cuando debe y aprende después.

Porque en el mundo digital, como en la vida, no basta con cerrar la puerta. También hay que saber qué hacer cuando alguien llama de madrugada diciendo que ha visto luz dentro.