Idioma / Language: Español · English
Comprende la guía a fondo: todo lo que necesitas hacer, explicado con claridad.
Un lunes por la mañana, la pantalla de un ordenador de la administración muestra un mensaje en inglés que exige un pago en criptomoneda. Los archivos ya no se abren. En cuestión de minutos, la pregunta deja de ser técnica y se vuelve jurídica: ¿qué ha pasado exactamente, a quién hay que avisar, en cuánto tiempo, y podremos demostrar más adelante que actuamos como debíamos? Responder a ese cúmulo de preguntas con orden, y no a ciegas, es justo lo que enseña la guía CCN-STIC-817, «Esquema Nacional de Seguridad. Gestión de Ciberincidentes», del Centro Criptológico Nacional.
Un idioma común para el peor día
La 817 es una de las guías más prácticas del catálogo del CCN. Mientras otras explican cómo configurar un servidor o cómo cumplir con una norma, esta se ocupa de algo que tarde o temprano toca vivir: el momento en que la seguridad ya ha fallado y hay que reaccionar. Su propósito, según la propia guía, es ofrecer una tipificación de los ciberincidentes, unos criterios para medir su gravedad y una metodología para notificarlos al CCN-CERT según el momento y el tipo de incidente. La versión de referencia se actualizó en abril de 2020 y su taxonomía llegó a servir de base a la guía de buenas prácticas de ENISA, la agencia europea de ciberseguridad.
Conviene aclarar desde el principio un matiz que recorre todo el texto. La 817 nació dentro del Esquema Nacional de Seguridad (ENS), el marco que obliga a las administraciones públicas españolas y a sus proveedores a proteger la información con un nivel adecuado al riesgo. Por eso su interlocutor natural es el sector público y su CERT de referencia es el gubernamental, el CCN-CERT. Ahora bien, la lógica que propone —clasificar, medir, notificar y preservar— es universal, y cualquier empresa o particular puede adoptarla, apoyándose en el CERT que le corresponde, que en su caso es el INCIBE-CERT. Este artículo recorre primero la guía con la mirada del profesional del derecho y del perito, y después la traduce a un plan de actuación para quien dirige una empresa o simplemente quiere proteger lo suyo.
La ciberseguridad se ha acostumbrado a hablar de prevención, de cortafuegos y de copias de seguridad. La 817 recuerda una verdad menos cómoda: la seguridad absoluta no existe, y lo que distingue a una organización solvente de una negligente es su forma de responder cuando el ataque ya ha ocurrido. Tener un idioma común para nombrar lo que pasa, una vara común para medir su gravedad y un protocolo común para avisar y para guardar las pruebas es lo que convierte el caos de un mal día en un proceso ordenado que resiste después el escrutinio de una auditoría o de un juzgado.
Un problema que no deja de crecer
El contexto ayuda a entender por qué una guía así importa tanto. En sus dos décadas de trayectoria, el CCN-CERT ha gestionado más de treinta mil ciberincidentes catalogados de peligrosidad muy alta o crítica, y la cifra anual no ha dejado de subir. El ransomware, el programa que secuestra los datos y exige un rescate para devolverlos, se ha convertido en la amenaza más rentable para el crimen organizado, y ninguna entidad es demasiado pequeña o demasiado modesta para quedar fuera de su punto de mira. La experiencia demuestra que los atacantes buscan el eslabón débil, y con frecuencia lo encuentran en la pyme o en el ayuntamiento que se creía a salvo por su tamaño.
A ese panorama se suma un endurecimiento del marco legal. La Directiva europea NIS2, que España está incorporando a su ordenamiento, amplía de forma notable el número de sectores obligados a gestionar y notificar sus incidentes, y acorta los plazos para hacerlo. La gestión ordenada de los ciberincidentes, que hace unos años era una buena práctica reservada a los más diligentes, se está transformando en una obligación legal para una parte cada vez mayor del tejido económico. Entender la 817 hoy es, por tanto, anticiparse a un deber que llamará pronto a muchas puertas.
El ciclo de vida de un incidente
Antes de entrar en las clasificaciones conviene entender que un ciberincidente es un proceso que se despliega en el tiempo, más que un suceso instantáneo. La guía organiza su gestión en fases encadenadas, y comprender esa secuencia ayuda a situar cada decisión en su momento.
La primera fase es la de preparación, y ocurre antes de que pase nada. Es el trabajo previo: constituir y formar un equipo de respuesta a ciberincidentes, dotarse de las herramientas necesarias y, sobre la base de un análisis de riesgos, desplegar las medidas de seguridad que exigen los anexos del ENS. Una organización que llega al incidente sin esta preparación improvisa, y la improvisación, en este terreno, se paga cara.
Llega después la fase de detección, análisis y notificación. Aquí la organización advierte que algo va mal —una alerta, un comportamiento anómalo, un aviso externo—, analiza qué está ocurriendo para entender su alcance y dispara, si procede, los procesos de notificación que veremos más adelante. Es la fase más delicada, porque de la calidad del análisis inicial depende todo lo que viene después.
Sigue la fase de contención, erradicación y recuperación. Contener es frenar la hemorragia, evitar que el incidente se extienda a más sistemas; erradicar es expulsar al atacante y eliminar el problema de raíz; recuperar es devolver los servicios a la normalidad con garantías de que la amenaza no sigue agazapada. Cada uno de estos pasos exige decisiones que tienen consecuencias tanto técnicas como probatorias, un equilibrio sobre el que volveremos.
El ciclo se cierra con la actividad posterior al incidente. Los responsables elaboran un informe que detalla la causa que originó el ataque y su coste, y se extraen lecciones para reforzar las defensas. Que la guía convierta esta reflexión final en una fase con entidad propia tiene un valor evidente: obliga a aprender de cada golpe, en lugar de limitarse a taponar y olvidar.
En el centro de todas estas fases hay siempre un protagonista humano: el equipo de respuesta a incidentes, conocido por sus siglas inglesas como CSIRT o CERT. Puede ser un departamento propio en una gran organización o un servicio externo contratado por una empresa mediana, pero su papel es el mismo: coordinar la reacción, tomar las decisiones técnicas bajo presión y servir de interlocutor con las autoridades. La guía insiste en que ese equipo debe existir y estar formado antes del incidente, porque improvisarlo el día del ataque es garantía de errores. Para el jurista conviene retener este dato, porque la existencia y la profesionalidad del equipo de respuesta figuran entre los elementos que se valoran al juzgar si una organización actuó con la diligencia que le era exigible.
Parte I · Para el profesional del derecho y el perito
Ponerle nombre al ataque: la taxonomía de la 817
La primera aportación de la guía es un vocabulario. Sin un lenguaje compartido, cada organización llamaría a lo mismo de forma distinta y sería imposible comparar, agregar o coordinar la respuesta a escala nacional. La 817 resuelve ese problema con una taxonomía de nueve clases de incidente que se despliegan en treinta y seis subtipos. Las nueve clases son las siguientes.
Contenido abusivo: ataques dirigidos a dañar la imagen de la organización o a usar sus medios para fines ilícitos, como el correo basura, el acoso, la extorsión o la difusión de material delictivo. Código dañino: el software concebido para infiltrarse o dañar un sistema sin conocimiento de su responsable, familia en la que entran los virus, los troyanos, el spyware y el temido ransomware. Obtención de información: las acciones destinadas a recabar datos que preparen ataques más sofisticados, ya sea mediante ingeniería social o rastreando vulnerabilidades. Intento de intrusión e intrusión propiamente dicha, que separan la tentativa del compromiso consumado de una cuenta o un sistema. Disponibilidad: todo lo que golpea la continuidad del servicio, con la denegación de servicio distribuida como ejemplo más conocido. Compromiso de la información: el acceso o la modificación no autorizados de datos. Fraude: el uso no autorizado de recursos, la suplantación o la infracción de derechos. Y una categoría para la política de seguridad y los casos que no encajan en las anteriores.
Para el criminólogo y para el jurista, esta clasificación es mucho más que un archivador ordenado. Cada clase describe, en el fondo, un tipo de conducta con su propia motivación y su propio autor probable, desde el activista que busca notoriedad hasta la organización criminal que persigue un rescate. Traducir el incidente técnico a una de estas categorías es el primer paso para conectarlo con el tipo penal correspondiente y para orientar la investigación hacia el perfil de quien hay detrás.
Cada una de esas nueve clases se subdivide, además, en subtipos más finos, hasta sumar los treinta y seis que contempla la guía. Dentro del código dañino se distingue, por ejemplo, entre el que infecta un sistema, el que se limita a distribuirse y el que instala una puerta trasera para el control remoto; dentro del fraude, entre la suplantación de identidad, el phishing y el uso no autorizado de recursos. Este grado de detalle no responde a un afán burocrático. Permite que dos analistas de dos organismos distintos, ante un mismo hecho, lo etiqueten igual, y esa homogeneidad es la que hace posible sumar los incidentes de todo el país, detectar campañas coordinadas que golpean a la vez a varias entidades y construir la inteligencia de amenazas que después alimenta la prevención. Para el criminólogo, esa base de datos homogénea es también una mina para el estudio de las tendencias delictivas en el ciberespacio nacional, porque convierte miles de sucesos dispersos en un mapa legible de cómo, cuándo y contra quién ataca la delincuencia digital.
Medir la gravedad: peligrosidad e impacto
Nombrar el ataque no basta; hay que medir cuánto importa. Y aquí la 817 introduce una distinción que se pasa por alto con frecuencia y que resulta decisiva. La guía mide cada incidente con dos varas independientes, cada una con cinco niveles: crítico, muy alto, alto, medio y bajo.
La primera vara es la peligrosidad. Responde a una pregunta técnica: ¿cómo de grave es la amenaza en sí misma, por su naturaleza y su potencial de daño, con independencia de a quién golpee? Un programa capaz de cifrar una red entera es intrínsecamente peligroso, se haya cebado con una gran administración o con un pequeño ayuntamiento.
La segunda vara es el impacto. Responde a una pregunta muy distinta: ¿qué consecuencias reales ha tenido para esta organización en concreto? Aquí entran la sensibilidad de la información comprometida, los servicios que se han visto afectados, el número de sistemas alcanzados, el perjuicio económico, el daño a la imagen y las implicaciones legales. Un mismo programa malicioso puede tener un impacto devastador en una entidad que gestiona datos de salud y uno modesto en otra que apenas trata información sensible.
La consecuencia práctica de separar ambos ejes es enorme, y es este segundo eje, el del impacto, el que dispara la obligación de notificar. Lo que obliga a avisar es el daño real que el ataque causa a bienes jurídicos merecedores de protección, con independencia de lo espectacular que resulte en el plano técnico. Para el analista forense, además, esta doble medición es una herramienta de discernimiento: permite distinguir el incidente que prosperó por una negligencia evidente del que superó unas defensas robustas mediante técnicas de alta sofisticación, una diferencia que pesa mucho a la hora de repartir responsabilidades.
En la práctica, ambos ejes se combinan para orientar la respuesta y, sobre todo, su urgencia. Un incidente que reúne una peligrosidad crítica y un impacto crítico —pensemos en un cifrado masivo que paraliza un servicio esencial y compromete a la vez datos sensibles de miles de ciudadanos— exige una reacción inmediata y una notificación al máximo nivel, con la coordinación del organismo nacional. En el extremo opuesto, un correo basura sin más consecuencias se gestiona internamente y no dispara obligación alguna. Entre uno y otro se despliega toda una escala de grises, y la virtud de la guía consiste en dar criterios para situar cada caso en su lugar, de modo que ni se dramatice lo insignificante ni se reste importancia a lo grave. Ese juicio de proporcionalidad, tan familiar para cualquier jurista, es el corazón de una buena gestión, y también la mejor defensa frente a quien, andando el tiempo, pretenda reprochar que se hizo demasiado poco o demasiado tarde.
La obligación de avisar: ENS, RGPD y la herramienta LUCIA
Detectado y medido el incidente, se abre uno de los terrenos donde más se juega una organización: el de la notificación. Y conviene entenderlo bien, porque las obligaciones son varias y pueden solaparse.
En el ámbito del sector público, el ENS —desarrollado hoy por el Real Decreto 311/2022— impone notificar los ciberincidentes al CCN-CERT. El cauce para hacerlo es LUCIA, acrónimo de Listado Unificado de Coordinación de Incidentes y Amenazas, la plataforma que el propio CCN-CERT ha desarrollado para gestionar y coordinar los incidentes de las entidades bajo el paraguas del ENS. LUCIA aporta precisamente lo que la guía persigue: un lenguaje común de clasificación y peligrosidad, la trazabilidad completa del incidente y un registro oficial de su cronología y de las medidas adoptadas. Para el perito, ese registro es una fuente documental de primer orden, porque fija en el tiempo quién supo qué y cuándo actuó.
A esa obligación se superpone otra que alcanza a todos, públicos y privados: la del Reglamento General de Protección de Datos. Cuando el incidente afecta a datos personales, su artículo 33 obliga al responsable del tratamiento a notificar la brecha a la autoridad de control —en España, la Agencia Española de Protección de Datos— sin dilación indebida y, de ser posible, en un plazo máximo de setenta y dos horas desde que se tiene constancia de ella. Si se supera ese plazo, la notificación debe acompañarse de las razones de la demora. Y cuando la brecha entraña un alto riesgo para los derechos y libertades de las personas, el artículo 34 añade una segunda obligación: comunicarla también a los propios afectados, en un lenguaje claro y sencillo, para que puedan protegerse.
El peso de estas obligaciones no es simbólico. El incumplimiento de los deberes de notificación de los artículos 33 y 34 figura entre las infracciones que el RGPD sanciona con multas de hasta diez millones de euros o, si la cifra resulta superior, el dos por ciento del volumen de negocio anual mundial del ejercicio anterior. Ese reloj de setenta y dos horas empieza a correr en el peor momento, cuando la organización aún está aturdida por el golpe, y esa es exactamente la razón por la que la preparación previa que exige la guía deja de ser una recomendación para convertirse en una necesidad.
El mapa de la notificación se ha vuelto, además, más poblado. Junto al CCN-CERT para el sector público y el INCIBE-CERT para el ámbito privado y ciudadano, el CNPIC atiende a los operadores de infraestructuras críticas, y la ya citada Directiva NIS2 añade nuevos deberes de comunicación con plazos escalonados: para determinados sujetos, una primera alerta temprana en apenas veinticuatro horas, seguida de un informe más completo en las setenta y dos y de un informe final semanas después. Coordinar todas estas ventanillas sin duplicar ni omitir avisos es en sí mismo un reto de gestión, y explica por qué las organizaciones más maduras designan de antemano a un responsable único que centralice las notificaciones y lleve la cuenta de los plazos. Para el asesor jurídico de una empresa, dominar este mapa se ha convertido en una competencia tan necesaria como el conocimiento del propio articulado de protección de datos.
Que la prueba aguante en el juzgado: la cadena de custodia
Llegamos al punto donde la ciberseguridad y el derecho se dan la mano, y donde el trabajo del perito resulta insustituible. De poco sirve saber qué ha pasado si después no se puede demostrar con garantías. La evidencia digital tiene una fragilidad que la prueba física no conoce: un dato puede alterarse sin dejar rastro visible, y basta esa sombra de duda para que un tribunal la descarte. Por eso la gestión de un incidente que aspire a tener consecuencias legales debe cuidar, desde el primer minuto, la cadena de custodia.
Preservar la evidencia digital descansa sobre un principio que la doctrina forense denomina de mismidad: la garantía de que la pieza analizada es exactamente la misma que se obtuvo en origen, sin alteración, contaminación ni sustitución a lo largo de todo el proceso. Alcanzar esa garantía exige método. El documento de referencia internacional en esta materia, el RFC 3227, publicado en 2002, establece una regla que gobierna cualquier recogida de pruebas: respetar el orden de volatilidad, es decir, recolectar primero lo que antes desaparece. La memoria RAM y las cachés se esfuman al apagar el equipo; las conexiones de red activas y los procesos en ejecución duran un poco más; los datos en disco persisten. Quien altera ese orden, o quien apaga sin más un equipo comprometido, destruye pruebas que quizá eran las decisivas.
A ese principio se suman las herramientas que blindan la integridad. El uso de funciones hash —hoy SHA-256 como referencia— genera una huella digital única de cada evidencia, de modo que cualquier manipulación posterior, por mínima que sea, se detecta al instante porque la huella deja de coincidir. Los bloqueadores de escritura, dispositivos que permiten leer un soporte sin poder modificar ni un solo bit del original, y la práctica de trabajar siempre sobre copias forenses —imágenes bit a bit, nunca sobre el original— completan un procedimiento que la norma internacional ISO/IEC 27037 sistematiza para la identificación, recogida, adquisición y preservación de la evidencia digital.
Todo ello se documenta en un registro que responde, para cada pieza y en cada momento, a cuatro preguntas: quién tuvo acceso a la evidencia, cuándo, cómo y por qué. Ese registro es la cadena de custodia propiamente dicha, y es lo que permite a un perito sostener ante el tribunal que la prueba que presenta es fiable. Para el profesional del derecho, la existencia de estos procedimientos antes del incidente demuestra un nivel de diligencia que refuerza la credibilidad de cualquier prueba pericial presentada después; su ausencia, en cambio, abre la puerta a que la defensa impugne con éxito toda la investigación.
Conviene saber que la norma ISO/IEC 27037 no viaja sola. Forma parte de una familia que cubre todo el ciclo de vida de la evidencia digital, con la 27041 sobre la garantía de idoneidad de los métodos de investigación, la 27042 sobre el análisis e interpretación de las pruebas y la 27043 sobre los principios generales del proceso. Este cuerpo normativo ofrece al perito un respaldo internacional cuando tiene que justificar ante el tribunal por qué hizo lo que hizo y por qué su método es fiable. Un ejemplo ilumina su importancia. La captura de la memoria RAM de un equipo comprometido, realizada antes de apagarlo, puede conservar las claves de cifrado, los procesos maliciosos en marcha y las conexiones activas con el servidor del atacante, información que se volatiliza por completo con el apagado y que en muchos casos constituye la única prueba directa de la autoría. Un perito que no la recoja, o que la recoja sin método, puede estar dejando escapar la pieza decisiva del caso. Los tribunales españoles se han vuelto exigentes en esta materia, y no faltan resoluciones que han restado valor probatorio a pruebas digitales por defectos en su obtención o en su custodia, con la consiguiente frustración de investigaciones largas y costosas.
Un caso para verlo todo junto
Quizá se entienda mejor viendo cómo encajan todas las piezas en un supuesto concreto. Un organismo detecta, un martes de madrugada, que sus servidores han quedado cifrados y que una nota exige un pago en criptomoneda. El equipo de respuesta, constituido y formado de antemano, resiste el impulso de apagar las máquinas: aísla la red para frenar la propagación y captura primero la memoria volátil, consciente de su fugacidad. Clasifica el incidente como código dañino de tipo ransomware, le asigna una peligrosidad muy alta y, al comprobar que se han visto afectados datos personales de ciudadanos, un impacto también muy alto. Ese impacto dispara dos relojes al mismo tiempo: la notificación al CCN-CERT a través de LUCIA y la comunicación a la Agencia Española de Protección de Datos dentro de las setenta y dos horas. Mientras el equipo técnico contiene y erradica la amenaza y restaura los sistemas desde copias seguras, un perito genera las huellas hash de las evidencias recogidas y documenta cada movimiento en la cadena de custodia. Semanas más tarde, cuando el caso llega al juzgado, esa documentación meticulosa es lo que permite sostener la investigación y aspirar a atribuir el ataque a sus autores. Nada de lo que se hizo aquella madrugada fue fruto de la improvisación; todo estaba previsto, y esa previsión marca la diferencia entre una organización que sale reforzada de la crisis y otra que se hunde en ella.
Parte II · Para la empresa y el particular
Hasta aquí, la guía vista con ojos de jurista. Pero la mayoría de quienes sufren un ciberataque no dirigen un equipo de peritos ni conocen el articulado del RGPD. Un autónomo, una pyme, una familia que ve su ordenador secuestrado necesitan otra cosa: saber qué hacer, y sobre todo qué no hacer, en las horas más confusas. La buena noticia es que la lógica de la 817 se traduce en un plan sencillo que cualquiera puede seguir.
Los primeros minutos: qué hacer cuando descubres el ataque
Lo primero es lo más difícil: no dejarse llevar por el pánico ni por el impulso de «arreglarlo» a toda prisa. La reacción instintiva —apagar el equipo, borrar lo sospechoso, reinstalar— suele ser el mayor error posible, porque destruye justo la información que después haría falta para entender lo ocurrido y para reclamar.
El primer gesto correcto es aislar sin apagar. Desconecta el equipo o el dispositivo afectado de la red, retirando el cable o desactivando el wifi, para cortar la comunicación con el atacante y frenar la propagación a otros equipos. Pero mantenlo encendido si puedes, porque en su memoria viva se conserva información valiosísima que se perderá para siempre en cuanto se apague. Esa distinción, tan sencilla de aplicar, es la versión doméstica del orden de volatilidad que respetan los peritos.
El segundo gesto es documentarlo todo. Anota la hora en que descubriste el problema, describe qué viste exactamente y haz fotografías de la pantalla con el móvil, incluido cualquier mensaje de rescate o texto sospechoso. Esa cronología improvisada, hecha con un cuaderno y un teléfono, puede convertirse más adelante en una prueba de primer orden y en el punto de partida de la investigación.
El tercer gesto es no jugar a ser el investigador. Cada vez que se abre un archivo, se navega por las carpetas o se ejecuta un antivirus por curiosidad, se dejan huellas nuevas que contaminan la escena y dificultan el trabajo posterior de un profesional. Lo mismo que nadie tocaría los objetos en el escenario de un delito físico, conviene tratar el equipo comprometido como lo que es: una escena que debe preservarse.
Esta comparación con la escena de un delito no es una simple figura retórica. Un investigador que llega a un domicilio donde se ha cometido un robo sabe que cada objeto movido y cada superficie tocada pueden borrar una huella o sembrar una pista falsa. En el mundo digital ocurre exactamente igual, con el agravante de que las huellas son invisibles y se destruyen con una facilidad pasmosa: basta abrir un archivo para cambiar su fecha de último acceso, o reiniciar el equipo para vaciar la memoria donde vivía la prueba. Por eso el mejor favor que un usuario sin conocimientos técnicos puede hacer a la investigación futura es, aunque suene extraño, no hacer nada: dejar el equipo tal como está, apuntar la hora y llamar a quien sabe. La contención del impulso de actuar es, en estos casos, la forma más alta de actuar bien.
Los tres ataques que más vas a ver
Aunque las variantes son incontables, casi todo lo que sufre una empresa pequeña o un particular cae en tres grandes familias, y reconocerlas ayuda a reaccionar con cabeza en lugar de con miedo. El ransomware secuestra los archivos cifrándolos y pide un rescate a cambio de la clave; frente a él, la mejor defensa es disponer de una copia de seguridad reciente y desconectada, y la peor decisión es pagar, porque financia el delito y no garantiza recuperar nada. El phishing es el correo o el mensaje que suplanta a un banco, a una administración o a un proveedor para robar contraseñas o datos; su antídoto es la desconfianza y la costumbre de verificar siempre por otro canal antes de hacer clic o de facilitar una clave. Y el llamado fraude del CEO, conocido en inglés como Business Email Compromise, en el que alguien se hace pasar por un directivo para ordenar una transferencia urgente y confidencial, se combate con procedimientos internos que exijan una segunda confirmación para cualquier pago que se salga de lo habitual. Saber a cuál de estas familias pertenece lo que nos está ocurriendo es el primer paso para no caer en la trampa que el atacante ha preparado con esmero.
No mates la prueba sin querer
Merece la pena detenerse en los errores concretos que echan a perder una investigación antes de que empiece, porque casi todos nacen de la buena intención. Reinstalar el sistema operativo para «dejarlo limpio» borra el rastro del atacante. Restaurar una copia de seguridad encima del equipo afectado pisa la evidencia. Pagar el rescate, además de no garantizar nada y de financiar la actividad delictiva, rara vez recupera todo y elimina la urgencia de investigar. Y manipular los soportes sin cuidado —conectarlos a otro ordenador, copiar archivos de aquí para allá— altera fechas y metadatos que quizá eran la clave.
La regla de oro para el profano es tan simple como contraintuitiva: ante la duda, no toques y llama a alguien que sepa. Un disco duro comprometido conserva su valor probatorio mientras nadie escriba sobre él; en el momento en que se usa con normalidad, ese valor empieza a evaporarse. Guardar el equipo tal como quedó, apartado y sin usar, es a menudo la decisión más inteligente que puede tomar quien no es especialista.
A quién avisar, y en cuánto tiempo
Saber a quién dirigirse evita perder un tiempo precioso. Para los ciudadanos y las empresas privadas, el punto de contacto de referencia en España es el INCIBE-CERT, que ofrece ayuda tanto a particulares como a organizaciones; las administraciones públicas, por su parte, se dirigen al CCN-CERT a través de LUCIA. Y si el ataque ha supuesto un delito —una estafa, una extorsión, un acceso no autorizado—, procede además denunciar ante la policía o la Guardia Civil, que cuentan con unidades especializadas en delincuencia tecnológica.
Hay un supuesto que conviene tener muy presente, porque afecta a casi cualquier negocio: si en el ataque han quedado expuestos datos personales de clientes, empleados o usuarios, y de ello puede derivarse un riesgo para esas personas, existe la obligación legal de notificar la brecha a la Agencia Española de Protección de Datos, en principio dentro de las setenta y dos horas siguientes a tener constancia de ella. Y si el riesgo para los afectados es alto, hay que avisarles también a ellos. No es un trámite menor ni opcional: es una obligación cuyo incumplimiento se sanciona con dureza. Ante la duda sobre si un incidente entra en este supuesto, lo prudente es consultar cuanto antes con un profesional, porque el reloj corre desde el primer momento.
Mejor prevenir: lo que puedes hacer hoy
Todo lo anterior describe cómo reaccionar cuando el daño ya está hecho, pero la mejor gestión de un incidente es la que evita que llegue a producirse. Unas pocas costumbres, todas al alcance de cualquiera, reducen de forma drástica el riesgo. La primera y más importante es la copia de seguridad. Conviene seguir la regla conocida como tres-dos-uno: mantener tres copias de los datos importantes, en dos soportes distintos, con al menos una guardada fuera del alcance de la red, de modo que un cifrado no pueda alcanzarla. Con una copia así, el ransomware pierde casi toda su capacidad de chantaje, porque siempre se puede restaurar lo secuestrado. La segunda costumbre es mantener el sistema operativo y las aplicaciones al día, ya que la mayoría de los ataques se cuelan por agujeros conocidos para los que hacía tiempo que existía un parche que nadie llegó a aplicar. La tercera es activar la verificación en dos pasos en el correo, la banca y las redes sociales, una barrera sencilla que frena en seco la mayor parte de los robos de contraseña, incluso cuando la clave ya se ha filtrado. La cuarta es usar contraseñas largas y distintas para cada servicio, apoyándose en un gestor que las recuerde por nosotros y nos libere de la tentación de repetir siempre la misma. Y la quinta, quizá la más decisiva, es la formación: la inmensa mayoría de los incidentes empiezan con un clic humano sobre un enlace engañoso, de manera que enseñar a la plantilla, o a la propia familia, a desconfiar de lo inesperado y a mirar dos veces antes de pulsar protege más que cualquier programa. Ninguna de estas medidas es cara ni complicada, y todas juntas transforman a la víctima fácil en un objetivo incómodo que el atacante, siempre a la búsqueda del camino de menor resistencia, casi siempre prefiere esquivar.
Una lista de comprobación para el peor día
Puestos a resumir el plan en algo que quepa en la puerta de la nevera o en el manual de la empresa, estos son los pasos, por orden.
Primero, conserva la calma y aísla el equipo de la red sin apagarlo. Segundo, haz fotos y anota la hora y todo lo que observes. Tercero, no reinstales, no borres, no restaures copias encima y no trastees el equipo. Cuarto, avisa a un profesional de confianza o al INCIBE-CERT. Quinto, si hay datos personales de terceros en juego, valora la notificación a la AEPD dentro del plazo de setenta y dos horas y la comunicación a los afectados si el riesgo es alto. Sexto, denuncia ante las fuerzas de seguridad si ha habido delito. Y séptimo, cuando todo pase, aprende del incidente: revisa qué falló, actualiza tus defensas y guarda una copia de seguridad, esta vez desconectada, para que la próxima vez el golpe encuentre a alguien preparado.
Lo que la 817 nos deja a todos
La guía CCN-STIC-817 fue escrita pensando en la Administración, pero su mensaje trasciende ese marco. Nos dice que responder bien a un ciberataque es cuestión de método, lejos de depender de la suerte o de los heroísmos improvisados: nombrar con precisión lo que ocurre, medir su gravedad por lo que de verdad daña, avisar a quien corresponde en el plazo debido y custodiar las pruebas como si algún día fueran a mirarse bajo la lupa de un tribunal, porque a menudo así sucede. Para el jurista y el perito, la 817 ofrece el andamiaje técnico que sostiene una investigación sólida. Para la empresa y el particular, ofrece una tranquilidad más modesta pero igual de valiosa: la de saber que, incluso en el peor día, hay una manera correcta de actuar, y que está al alcance de cualquiera que se haya molestado en conocerla de antemano.
La seguridad completa seguirá sin existir. La diligencia debida, en cambio, sí está a nuestro alcance, y en el terreno digital esa diligencia se demuestra sobre todo por la forma en que reaccionamos cuando algo sale mal.
Esta guía forma parte de una serie que el Centro Criptológico Nacional pone a disposición de todos de manera gratuita, y que en Actum Forense Press venimos recorriendo con vocación divulgativa, convencidos de que el conocimiento técnico deja de ser un privilegio de especialistas en cuanto alguien se molesta en explicarlo con claridad. Comprender cómo se gestiona un ciberincidente no exige convertirse en informático, igual que entender los rudimentos de un atestado no exige vestir un uniforme. Basta con asimilar la lógica de fondo, que es sencilla y poderosa: ante un ataque existe una forma correcta de actuar, esa forma puede aprenderse de antemano, y las decisiones que se toman en los primeros minutos, con serenidad y método, condicionan todo lo que viene después, incluida la suerte que corra el asunto si algún día termina sobre la mesa de un juez. Quien haya llegado hasta aquí ya sabe más que la mayoría, y ese conocimiento, el día menos pensado, puede marcar la diferencia entre un susto y una catástrofe. Comprender la 817, aunque sea a grandes rasgos, es un buen primer paso para no quedar indefensos el día en que el mensaje de rescate aparezca en nuestra pantalla.
Bibliografía
Agencia Española de Protección de Datos. (s. f.). Notificación de brechas de seguridad de los datos personales a la autoridad de control. AEPD. https://www.aepd.es/derechos-y-deberes/cumple-tus-deberes/medidas-de-cumplimiento/notificacion-brechas-seguridad
Brezinski, D., & Killalea, T. (2002). Guidelines for evidence collection and archiving (RFC 3227). Internet Engineering Task Force. https://doi.org/10.17487/RFC3227
Centro Criptológico Nacional. (2020). CCN-STIC-817. Esquema Nacional de Seguridad. Gestión de ciberincidentes [Guía de seguridad de las TIC]. CCN-CERT. https://www.ccn-cert.cni.es/es/series-ccn-stic/800-guia-esquema-nacional-de-seguridad/988-ccn-stic-817-gestion-de-ciberincidentes
International Organization for Standardization. (2012). ISO/IEC 27037:2012. Information technology — Security techniques — Guidelines for identification, collection, acquisition and preservation of digital evidence. ISO.
Jefatura del Estado. (2018). Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales. Boletín Oficial del Estado, 294. https://www.boe.es/eli/es/lo/2018/12/05/3
Ministerio de Asuntos Económicos y Transformación Digital. (2022). Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad. Boletín Oficial del Estado, 106. https://www.boe.es/eli/es/rd/2022/05/03/311
Parlamento Europeo y Consejo de la Unión Europea. (2016). Reglamento (UE) 2016/679, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales (Reglamento General de Protección de Datos). Diario Oficial de la Unión Europea, L 119. https://eur-lex.europa.eu/eli/reg/2016/679/oj
▲ Volver al español / Back to Spanish
CCN-STIC-817 Guide — Cyber incident management: classification, notification and preserving the evidence of a cyberattack
Understand the guide in depth: everything you need to do, explained clearly.
One Monday morning, the screen of a public-sector computer displays a message in English demanding a payment in cryptocurrency. The files will no longer open. Within minutes, the question stops being technical and turns legal: what exactly has happened, who must be told, how soon, and will we be able to prove later that we acted as we should have? Answering that cluster of questions in an orderly way, rather than blindly, is precisely what the CCN-STIC-817 guide, «National Security Framework. Cyber Incident Management», from Spain’s National Cryptologic Centre (CCN), sets out to teach.
A common language for the worst day
The 817 is one of the most practical guides in the CCN’s catalogue. While others explain how to configure a server or how to comply with a standard, this one deals with something everyone eventually has to live through: the moment when security has already failed and a response is needed. Its purpose, according to the guide itself, is to offer a way of classifying cyber incidents, criteria for gauging their severity, and a methodology for notifying the CCN-CERT depending on the moment and the type of incident. The reference version was updated in April 2020, and its taxonomy went on to serve as the basis for the good-practice guide of ENISA, the European cybersecurity agency.
One nuance that runs through the whole text is worth clearing up from the start. The 817 was born within the National Security Framework (ENS), the regime that requires Spanish public administrations and their suppliers to protect information at a level appropriate to the risk. That is why its natural interlocutor is the public sector and its reference CERT is the governmental one, the CCN-CERT. That said, the logic it proposes —classify, measure, notify and preserve— is universal, and any company or individual can adopt it, leaning on whichever CERT corresponds to them, which in their case is the INCIBE-CERT. This article first walks through the guide with the eyes of the legal professional and the forensic expert, and then translates it into a plan of action for anyone running a business or simply wanting to protect what is theirs.
Cybersecurity has grown used to talking about prevention, firewalls and backups. The 817 recalls a less comfortable truth: absolute security does not exist, and what sets a sound organisation apart from a negligent one is the way it responds once the attack has already happened. Having a common language to name what is going on, a common yardstick to measure its severity and a common protocol to raise the alarm and to safeguard the evidence is what turns the chaos of a bad day into an orderly process that later withstands the scrutiny of an audit or a court.
A problem that keeps growing
The context helps to understand why a guide like this matters so much. Over its two decades of activity, the CCN-CERT has handled more than thirty thousand cyber incidents rated as very high or critical in dangerousness, and the annual figure has not stopped climbing. Ransomware, the software that hijacks data and demands a ransom to return it, has become the most profitable threat for organised crime, and no organisation is too small or too modest to fall outside its sights. Experience shows that attackers look for the weak link, and they often find it in the small business or the town council that believed itself safe on account of its size.
To this picture a tightening of the legal framework must be added. The European NIS2 Directive, which Spain is incorporating into its law, significantly broadens the number of sectors obliged to manage and report their incidents, and shortens the deadlines for doing so. The orderly management of cyber incidents, which a few years ago was a good practice reserved for the most diligent, is turning into a legal obligation for an ever-larger part of the economy. Understanding the 817 today is, therefore, a way of getting ahead of a duty that will soon knock on many doors.
The life cycle of an incident
Before turning to the classifications, it helps to understand that a cyber incident is a process that unfolds over time, more than an instantaneous event. The guide organises its management into linked phases, and grasping that sequence helps to place each decision in its proper moment.
The first phase is preparation, and it happens before anything occurs. It is the groundwork: setting up and training an incident response team, equipping it with the necessary tools and, on the basis of a risk analysis, deploying the security measures required by the annexes of the ENS. An organisation that reaches the incident without this preparation improvises, and improvisation, in this field, comes at a high price.
Next comes the phase of detection, analysis and notification. Here the organisation realises that something is wrong —an alert, an anomalous behaviour, an external warning—, analyses what is happening to understand its scope, and triggers, where appropriate, the notification processes we will look at later. It is the most delicate phase, because everything that follows depends on the quality of the initial analysis.
Then follows the phase of containment, eradication and recovery. Containing means stopping the bleeding, preventing the incident from spreading to more systems; eradicating means expelling the attacker and removing the problem at its root; recovering means returning services to normal with assurances that the threat is not still lurking. Each of these steps calls for decisions with consequences that are at once technical and evidentiary, a balance we will return to.
The cycle closes with the post-incident activity. Those in charge draw up a report detailing the cause that gave rise to the attack and its cost, and lessons are drawn to strengthen the defences. That the guide turns this final reflection into a phase in its own right has an obvious value: it forces the organisation to learn from every blow, rather than merely plugging the hole and forgetting.
At the heart of all these phases there is always a human protagonist: the incident response team, known by its English acronyms as CSIRT or CERT. It may be an in-house department in a large organisation or an outsourced service hired by a medium-sized firm, but its role is the same: to coordinate the reaction, take the technical decisions under pressure and serve as the point of contact with the authorities. The guide insists that this team must exist and be trained before the incident, because improvising it on the day of the attack is a recipe for mistakes. Lawyers should retain this point, because the existence and professionalism of the response team are among the elements weighed when judging whether an organisation acted with the diligence it owed.
Part I · For the legal professional and the forensic expert
Putting a name to the attack: the 817 taxonomy
The guide’s first contribution is a vocabulary. Without a shared language, each organisation would call the same thing by a different name, and it would be impossible to compare, aggregate or coordinate the response on a national scale. The 817 solves that problem with a taxonomy of nine classes of incident that unfold into thirty-six subtypes. The nine classes are as follows.
Abusive content: attacks aimed at damaging the organisation’s image or using its resources for unlawful ends, such as spam, harassment, extortion or the distribution of criminal material. Malicious code: software designed to infiltrate or damage a system without the knowledge of the person responsible, the family that includes viruses, trojans, spyware and the dreaded ransomware. Information gathering: actions intended to collect data that pave the way for more sophisticated attacks, whether through social engineering or by scanning for vulnerabilities. Intrusion attempt and intrusion proper, which separate the try from the accomplished compromise of an account or a system. Availability: everything that strikes the continuity of service, with distributed denial of service as the best-known example. Information compromise: the unauthorised access to or modification of data. Fraud: the unauthorised use of resources, impersonation or the infringement of rights. And a category for the security policy and the cases that do not fit the previous ones.
For the criminologist and the lawyer, this classification is much more than a tidy filing cabinet. Each class describes, deep down, a type of conduct with its own motivation and its own likely author, from the activist seeking notoriety to the criminal organisation after a ransom. Translating the technical incident into one of these categories is the first step towards connecting it with the corresponding criminal offence and towards steering the investigation towards the profile of whoever is behind it.
Each of those nine classes is further divided into finer subtypes, up to the thirty-six the guide sets out. Within malicious code, for instance, a distinction is drawn between what infects a system, what merely spreads itself and what installs a back door for remote control; within fraud, between identity impersonation, phishing and the unauthorised use of resources. This level of detail is not a bureaucratic whim. It allows two analysts from two different bodies, faced with the same event, to label it the same way, and that homogeneity is what makes it possible to add up the incidents of an entire country, to detect coordinated campaigns that strike several entities at once, and to build the threat intelligence that later feeds prevention. For the criminologist, that homogeneous database is also a goldmine for the study of criminal trends in the national cyberspace, because it turns thousands of scattered events into a legible map of how, when and against whom digital crime strikes.
Measuring severity: dangerousness and impact
Naming the attack is not enough; its importance has to be measured. And here the 817 introduces a distinction that is often overlooked and that proves decisive. The guide measures each incident with two independent yardsticks, each with five levels: critical, very high, high, medium and low.
The first yardstick is dangerousness. It answers a technical question: how serious is the threat in itself, by its nature and its potential for harm, regardless of whom it strikes? A program capable of encrypting an entire network is intrinsically dangerous, whether it has preyed on a large administration or on a small town council.
The second yardstick is impact. It answers a very different question: what real consequences has it had for this particular organisation? Here the sensitivity of the compromised information, the services affected, the number of systems reached, the financial harm, the damage to reputation and the legal implications all come into play. The same piece of malware may have a devastating impact on an entity handling health data and a modest one on another that barely processes sensitive information.
The practical consequence of separating the two axes is enormous, and it is this second axis, that of impact, that triggers the duty to notify. What compels an alert is the real harm the attack causes to legal interests deserving of protection, regardless of how spectacular it may be on the technical plane. For the forensic analyst, moreover, this dual measurement is a tool of discernment: it allows the incident that prospered through plain negligence to be told apart from the one that overcame robust defences through highly sophisticated techniques, a difference that weighs heavily when responsibilities are apportioned.
In practice, both axes combine to guide the response and, above all, its urgency. An incident that combines critical dangerousness and critical impact —think of a mass encryption that paralyses an essential service and at the same time compromises sensitive data of thousands of citizens— demands an immediate reaction and notification at the highest level, with the coordination of the national body. At the opposite end, a piece of spam with no further consequences is handled internally and triggers no obligation at all. Between one and the other lies a whole scale of greys, and the guide’s virtue lies in giving criteria to place each case in its slot, so that neither is the trivial dramatised nor the grave played down. That judgement of proportionality, so familiar to any lawyer, is the heart of good management, and also the best defence against anyone who, in time, seeks to reproach that too little was done, or too late.
The duty to report: ENS, GDPR and the LUCIA tool
Once the incident has been detected and measured, one of the areas where an organisation has most at stake opens up: notification. And it is worth understanding well, because the obligations are several and may overlap.
In the public sector, the ENS —today developed by Royal Decree 311/2022— requires cyber incidents to be reported to the CCN-CERT. The channel for doing so is LUCIA, the acronym for Unified List for the Coordination of Incidents and Threats, the platform the CCN-CERT itself has developed to manage and coordinate the incidents of entities under the ENS umbrella. LUCIA provides exactly what the guide is after: a common language of classification and dangerousness, the full traceability of the incident, and an official record of its timeline and of the measures adopted. For the forensic expert, that record is a documentary source of the first order, because it fixes in time who knew what and when they acted.
Onto that obligation another is superimposed, one that reaches everyone, public and private: that of the General Data Protection Regulation. When the incident affects personal data, its Article 33 requires the data controller to notify the breach to the supervisory authority —in Spain, the Spanish Data Protection Agency— without undue delay and, where feasible, within a maximum of seventy-two hours of becoming aware of it. If that deadline is exceeded, the notification must be accompanied by the reasons for the delay. And where the breach entails a high risk to the rights and freedoms of individuals, Article 34 adds a second obligation: to communicate it to the affected persons as well, in clear and plain language, so that they can protect themselves.
The weight of these obligations is not symbolic. Failure to comply with the notification duties of Articles 33 and 34 is among the infringements the GDPR sanctions with fines of up to ten million euros or, if higher, two per cent of the total worldwide annual turnover of the preceding financial year. That seventy-two-hour clock starts running at the worst possible moment, when the organisation is still reeling from the blow, and that is exactly why the prior preparation the guide demands stops being a recommendation and becomes a necessity.
The notification map has, moreover, grown more crowded. Alongside the CCN-CERT for the public sector and the INCIBE-CERT for the private and citizen sphere, the CNPIC attends to critical-infrastructure operators, and the aforementioned NIS2 Directive adds new reporting duties with staggered deadlines: for certain subjects, an early warning within just twenty-four hours, followed by a fuller report within seventy-two and a final report weeks later. Coordinating all these windows without duplicating or omitting notices is in itself a management challenge, and it explains why the most mature organisations designate in advance a single person to centralise notifications and keep track of the deadlines. For a company’s legal adviser, mastering this map has become a competence as necessary as knowledge of the data-protection rules themselves.
Making the evidence hold up in court: the chain of custody
We reach the point where cybersecurity and the law join hands, and where the work of the forensic expert becomes irreplaceable. Knowing what has happened is of little use if it cannot afterwards be proven with guarantees. Digital evidence has a fragility that physical evidence does not know: a piece of data can be altered without leaving a visible trace, and that shadow of doubt is enough for a court to discard it. That is why the management of an incident that aspires to legal consequences must look after the chain of custody from the very first minute.
Preserving digital evidence rests on a principle that forensic doctrine calls sameness: the guarantee that the piece analysed is exactly the one obtained at source, without alteration, contamination or substitution throughout the whole process. Achieving that guarantee requires method. The international reference document in this field, RFC 3227, published in 2002, establishes a rule that governs any collection of evidence: to respect the order of volatility, that is, to collect first what disappears soonest. RAM and caches vanish when the machine is switched off; active network connections and running processes last a little longer; data on disk persists. Whoever alters that order, or simply powers down a compromised machine, destroys evidence that may have been the decisive kind.
To that principle the tools that safeguard integrity are added. The use of hash functions —today SHA-256 as the reference— generates a unique digital fingerprint of each piece of evidence, so that any subsequent tampering, however slight, is detected instantly because the fingerprint no longer matches. Write blockers, devices that allow a medium to be read without being able to modify a single bit of the original, and the practice of always working on forensic copies —bit-by-bit images, never on the original— complete a procedure that the international standard ISO/IEC 27037 systematises for the identification, collection, acquisition and preservation of digital evidence.
All of it is recorded in a log that answers, for each item and at each moment, four questions: who had access to the evidence, when, how and why. That log is the chain of custody proper, and it is what allows a forensic expert to maintain before the court that the evidence presented is reliable. For the legal professional, the existence of these procedures before the incident demonstrates a level of diligence that reinforces the credibility of any expert evidence presented afterwards; their absence, by contrast, opens the door for the defence to successfully challenge the entire investigation.
It is worth knowing that ISO/IEC 27037 does not travel alone. It is part of a family covering the whole life cycle of digital evidence, with 27041 on assuring the suitability of investigation methods, 27042 on the analysis and interpretation of evidence, and 27043 on the general principles of the process. This body of standards gives the forensic expert international backing when they must justify before the court why they did what they did and why their method is reliable. One example illustrates its importance. Capturing the RAM of a compromised machine, done before switching it off, can preserve encryption keys, malicious processes in progress and active connections to the attacker’s server, information that vanishes entirely on shutdown and that in many cases is the only direct proof of authorship. An expert who fails to collect it, or collects it without method, may be letting the decisive piece of the case slip away. Spanish courts have grown demanding on this matter, and there is no shortage of rulings that have stripped digital evidence of its probative value for defects in its collection or its custody, with the consequent frustration of long and costly investigations.
A case to see it all together
Perhaps it is best understood by seeing how all the pieces fit in a concrete scenario. A public body detects, one Tuesday in the small hours, that its servers have been encrypted and that a note demands a payment in cryptocurrency. The response team, set up and trained in advance, resists the urge to switch off the machines: it isolates the network to halt the spread and first captures the volatile memory, aware of how fleeting it is. It classifies the incident as malicious code of the ransomware type, assigns it a very high dangerousness and, on finding that personal data of citizens have been affected, a very high impact too. That impact sets two clocks running at once: notification to the CCN-CERT through LUCIA and communication to the Spanish Data Protection Agency within seventy-two hours. While the technical team contains and eradicates the threat and restores the systems from safe backups, a forensic expert generates the hash fingerprints of the collected evidence and documents every move in the chain of custody. Weeks later, when the case reaches the court, that meticulous documentation is what allows the investigation to be sustained and the attack to be attributed to its authors. Nothing done that early morning was the fruit of improvisation; everything was foreseen, and that foresight is the difference between an organisation that emerges from the crisis stronger and one that sinks into it.
Part II · For the company and the individual
So far, the guide seen through a lawyer’s eyes. But most of those who suffer a cyberattack do not run a team of forensic experts nor know the wording of the GDPR. A freelancer, a small business, a family watching its computer held hostage need something else: to know what to do, and above all what not to do, in the most confusing hours. The good news is that the logic of the 817 translates into a simple plan anyone can follow.
The three attacks you will see most
Although the variants are countless, almost everything a small business or an individual suffers falls into three broad families, and recognising them helps to react with a cool head rather than with fear. Ransomware hijacks the files by encrypting them and demands a ransom for the key; against it, the best defence is having a recent, disconnected backup, and the worst decision is to pay, because it funds the crime and guarantees nothing. Phishing is the email or message that impersonates a bank, an administration or a supplier to steal passwords or data; its antidote is distrust and the habit of always verifying through another channel before clicking or handing over a credential. And so-called CEO fraud, known in English as Business Email Compromise, in which someone poses as an executive to order an urgent and confidential transfer, is fought with internal procedures that require a second confirmation for any payment out of the ordinary. Knowing which of these families what is happening to us belongs to is the first step to avoiding the trap the attacker has carefully laid.
The first minutes: what to do when you discover the attack
The first thing is the hardest: not letting yourself be carried away by panic or by the urge to «fix it» in a hurry. The instinctive reaction —switching off the machine, deleting the suspicious, reinstalling— is usually the greatest possible mistake, because it destroys the very information that would later be needed to understand what happened and to make a claim.
The first correct move is to isolate without switching off. Disconnect the affected computer or device from the network, pulling the cable or turning off the wifi, to cut communication with the attacker and slow the spread to other machines. But keep it powered on if you can, because its live memory holds priceless information that will be lost forever the moment it shuts down. That distinction, so simple to apply, is the domestic version of the order of volatility that forensic experts respect.
The second move is to document everything. Note the time you discovered the problem, describe exactly what you saw and take photographs of the screen with your phone, including any ransom message or suspicious text. That improvised timeline, made with a notebook and a telephone, may later become first-rate evidence and the starting point of the investigation.
The third move is to not play investigator. Every time a file is opened, folders are browsed or an antivirus is run out of curiosity, fresh traces are left that contaminate the scene and hinder a professional’s later work. Just as no one would touch the objects at the scene of a physical crime, it is best to treat the compromised machine for what it is: a scene that must be preserved.
That comparison with the scene of a crime is not a mere figure of speech. An investigator arriving at a home where a burglary has taken place knows that every object moved and every surface touched may erase a fingerprint or plant a false lead. In the digital world it happens in exactly the same way, with the aggravating factor that the traces are invisible and are destroyed with astonishing ease: merely opening a file changes its last-access date, and restarting the machine empties the memory where the evidence lived. That is why the best favour a non-technical user can do for the future investigation is, strange as it sounds, to do nothing: leave the machine as it is, note the time and call someone who knows. Holding back the urge to act is, in these cases, the highest form of acting well.
Don’t kill the evidence by mistake
It is worth pausing on the specific mistakes that ruin an investigation before it begins, because almost all of them are born of good intentions. Reinstalling the operating system to «leave it clean» erases the attacker’s trail. Restoring a backup on top of the affected machine tramples the evidence. Paying the ransom, besides guaranteeing nothing and funding criminal activity, rarely recovers everything and removes the urgency to investigate. And handling the media carelessly —connecting them to another computer, copying files here and there— alters dates and metadata that may have been the key.
The golden rule for the layperson is as simple as it is counterintuitive: when in doubt, don’t touch and call someone who knows. A compromised hard drive keeps its probative value as long as no one writes over it; the moment it is used normally, that value begins to evaporate. Keeping the machine just as it was left, set aside and unused, is often the most intelligent decision a non-specialist can make.
Who to notify, and how quickly
Knowing whom to turn to saves precious time. For citizens and private companies, the reference point of contact in Spain is the INCIBE-CERT, which offers help to individuals and organisations alike; public administrations, for their part, turn to the CCN-CERT through LUCIA. And if the attack has amounted to a crime —a scam, an extortion, an unauthorised access—, it is also fitting to report it to the police or the Civil Guard, which have units specialised in technological crime.
There is one situation worth bearing very much in mind, because it affects almost any business: if the attack has exposed personal data of customers, employees or users, and this may give rise to a risk for those people, there is a legal obligation to notify the breach to the Spanish Data Protection Agency, in principle within the seventy-two hours following awareness of it. And if the risk to those affected is high, they must be warned too. This is neither a minor formality nor an optional one: it is an obligation whose breach is severely punished. When in doubt as to whether an incident falls into this category, the prudent course is to consult a professional as soon as possible, because the clock is running from the first moment.
Better to prevent: what you can do today
Everything above describes how to react once the harm is done, but the best incident management is the one that prevents the incident from happening at all. A few habits, all within anyone’s reach, sharply reduce the risk. The first and most important is the backup. It is wise to follow the rule known as three-two-one: keep three copies of the important data, on two different media, with at least one stored beyond the reach of the network, so that an encryption cannot touch it. With a backup like that, ransomware loses almost all its power to blackmail, because what is hijacked can always be restored. The second habit is to keep the operating system and applications up to date, since most attacks slip in through known holes for which a patch had long existed that no one applied. The third is to enable two-step verification on email, banking and social networks, a simple barrier that stops most password thefts dead, even when the credential has already leaked. The fourth is to use long, distinct passwords for each service, relying on a manager that remembers them for us and frees us from the temptation to repeat the same one. And the fifth, perhaps the most decisive, is training: the vast majority of incidents begin with a human click on a deceptive link, so teaching the staff, or the family itself, to distrust the unexpected and to look twice before pressing protects more than any program. None of these measures is costly or complicated, and together they turn the easy victim into an awkward target that the attacker, always in search of the path of least resistance, almost always prefers to avoid.
A checklist for the worst day
To boil the plan down to something that fits on the fridge door or in the company manual, these are the steps, in order.
First, keep calm and isolate the machine from the network without switching it off. Second, take photos and note the time and everything you observe. Third, do not reinstall, do not delete, do not restore backups on top and do not tinker with the machine. Fourth, call a trusted professional or the INCIBE-CERT. Fifth, if third parties’ personal data are at stake, consider notifying the Data Protection Agency within the seventy-two-hour deadline and communicating with those affected if the risk is high. Sixth, report it to law enforcement if a crime has occurred. And seventh, when it is all over, learn from the incident: review what failed, update your defences and keep a backup, this time disconnected, so that next time the blow finds someone prepared.
What the 817 leaves us all
The CCN-STIC-817 guide was written with the Administration in mind, but its message goes beyond that frame. It tells us that responding well to a cyberattack is a matter of method, far from depending on luck or improvised heroics: naming precisely what is happening, measuring its severity by what truly harms, alerting whoever is due within the required time, and safeguarding the evidence as if one day it were to be examined under a court’s lens, because that is often how it turns out. For the lawyer and the forensic expert, the 817 offers the technical scaffolding that supports a solid investigation. For the company and the individual, it offers a more modest but equally valuable reassurance: the knowledge that, even on the worst day, there is a right way to act, and that it is within reach of anyone who has bothered to learn it in advance.
Complete security will still not exist. Due diligence, on the other hand, is within our reach, and in the digital realm that diligence is demonstrated above all by the way we react when something goes wrong. This guide is part of a series that the National Cryptologic Centre makes freely available to everyone, and which at Actum Forense Press we have been working through with a mind to plain explanation, convinced that technical knowledge ceases to be the preserve of specialists the moment someone bothers to explain it clearly. Understanding how a cyber incident is managed does not require becoming a computer scientist, just as grasping the rudiments of a police report does not require wearing a uniform. It is enough to absorb the underlying logic, which is simple and powerful: in the face of an attack there is a right way to act, that way can be learned beforehand, and the decisions taken in the first minutes, with composure and method, condition everything that follows, including the fate the matter meets should it one day end up on a judge’s desk. Anyone who has read this far already knows more than most, and that knowledge, when least expected, may make the difference between a scare and a catastrophe.
References
Brezinski, D., & Killalea, T. (2002). Guidelines for evidence collection and archiving (RFC 3227). Internet Engineering Task Force. https://doi.org/10.17487/RFC3227
Council of the European Union & European Parliament. (2016). Regulation (EU) 2016/679 of 27 April 2016 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union, L 119. https://eur-lex.europa.eu/eli/reg/2016/679/oj
International Organization for Standardization. (2012). ISO/IEC 27037:2012. Information technology — Security techniques — Guidelines for identification, collection, acquisition and preservation of digital evidence. ISO.
National Cryptologic Centre. (2020). CCN-STIC-817. National Security Framework. Cyber incident management [ICT security guide]. CCN-CERT. https://www.ccn-cert.cni.es/es/series-ccn-stic/800-guia-esquema-nacional-de-seguridad/988-ccn-stic-817-gestion-de-ciberincidentes
Spanish Data Protection Agency. (n.d.). Notification of personal data security breaches to the supervisory authority. AEPD. https://www.aepd.es/en
Deja una respuesta