4.3.1.-Ciberresiliencia
4.3.1. Ciberresiliencia y vuelta a la normalidad¶
Idea principal
La ciberresiliencia no consiste solo en evitar incidentes. Consiste en que la organización pueda resistir, seguir prestando servicios críticos, recuperarse de forma segura y aprender para quedar mejor preparada.
En los puntos anteriores hemos seguido una línea de trabajo: primero estudiamos el proceso completo de respuesta, después vimos cómo convertirlo en un plan de respuesta y finalmente bajamos ese plan a playbooks y runbooks. Este tema da un paso más: analiza qué hace que esa respuesta sea ciberresiliente.
Dicho de forma sencilla, una respuesta ciberresiliente no se limita a "apagar el fuego". También se pregunta:
- qué servicios deben seguir funcionando aunque haya un incidente;
- qué degradación del servicio es aceptable durante la crisis;
- cómo se recuperan los sistemas sin reintroducir la causa del incidente;
- cómo se confirma que la organización ha vuelto realmente a la normalidad;
- qué capacidades se refuerzan para responder mejor la próxima vez.
Definición
La ciberresiliencia es la capacidad de una organización para anticipar, resistir, responder, recuperarse y adaptarse ante incidentes de ciberseguridad, manteniendo sus servicios esenciales y mejorando después de la experiencia.
| Código | Descripción |
|---|---|
| RA4 | Implementa medidas de ciberseguridad en redes y sistemas respondiendo a los incidentes detectados y aplicando las técnicas de protección adecuadas. |
| CE b) | Se han preparado respuestas ciberresilientes ante incidentes que permitan seguir prestando los servicios de la organización y fortaleciendo las capacidades de identificación, detección, prevención, contención, recuperación y cooperación con terceros. |
| CE d) | Se han llevado a cabo las tareas de restablecimiento de los servicios afectados por un incidente hasta confirmar la vuelta a la normalidad. |
Qué deberías saber al terminar
Al acabar este tema deberías poder:
- explicar la diferencia entre ciberseguridad y ciberresiliencia;
- relacionar la ciberresiliencia con la respuesta a incidentes;
- identificar qué capacidades deben reforzarse antes, durante y después de un incidente;
- definir criterios para mantener servicios críticos durante una crisis;
- comprobar si un servicio se ha restablecido de forma segura y puede volver a la normalidad.
1. Ciberseguridad y ciberresiliencia no son lo mismo¶
La ciberseguridad intenta reducir la probabilidad de que ocurra un incidente y limitar su impacto. Incluye controles como autenticación multifactor, copias de seguridad, segmentación de red, EDR, hardening, gestión de vulnerabilidades, monitorización o formación del personal.
La ciberresiliencia parte de una idea más realista: aunque se apliquen buenos controles, algunos incidentes pueden ocurrir. Por eso no se centra solo en prevenir, sino también en resistir, mantener servicios esenciales, recuperar y mejorar.
| Concepto | Pregunta principal | Ejemplo |
|---|---|---|
| Ciberseguridad | ¿Cómo evitamos o reducimos el incidente? | Aplicar MFA para reducir compromisos de cuentas. |
| Ciberresiliencia | ¿Cómo seguimos funcionando y nos recuperamos si el incidente ocurre? | Mantener un servicio mínimo, restaurar desde copias verificadas y reforzar controles después. |
Idea clave
La ciberseguridad reduce la probabilidad y el impacto. La ciberresiliencia añade continuidad, recuperación validada y aprendizaje.
2. Dónde encaja en la respuesta a incidentes¶
La ciberresiliencia atraviesa todo el proceso de respuesta, pero no lo sustituye. No vamos a repetir aquí las fases del proceso, porque ya se trabajan en el punto 4.1.1. Lo importante ahora es ver qué aporta la mirada resiliente en cada momento.
flowchart LR
A[Antes del incidente] --> B[Durante el incidente]
B --> C[Restablecimiento]
C --> D[Vuelta a la normalidad]
D --> E[Mejora continua]
A --> A1[Servicios críticos\nRTO/RPO\ncopias\nproveedores]
B --> B1[Servicio mínimo\ncontención\ncomunicación\ncooperación]
C --> C1[Restauración limpia\nvalidación técnica\nvalidación funcional]
D --> D1[Monitorización reforzada\nconfirmación de estabilidad\ncierre]
E --> E1[Lecciones aprendidas\nacciones correctivas\npruebas]La figura anterior resume la idea central: la ciberresiliencia conecta preparación, continuidad, recuperación y mejora.
En la práctica, esto significa que la organización debe preparar respuestas que no dependan de improvisar en mitad de la crisis. Por ejemplo, si un ransomware afecta a un servidor de ficheros, la pregunta no es solo "¿cómo limpiamos el servidor?", sino también:
- qué áreas necesitan seguir trabajando;
- qué datos son prioritarios;
- qué copia de seguridad es segura;
- qué servicio alternativo se puede usar temporalmente;
- quién valida que los datos restaurados son correctos;
- qué señales indicarían una reinfección.
3. Capacidades que debe fortalecer una organización ciberresiliente¶
El CE b) indica que una respuesta ciberresiliente debe permitir seguir prestando servicios y fortalecer capacidades concretas. Estas capacidades no son una lista abstracta: cada una se traduce en decisiones y evidencias observables.
| Capacidad | Qué significa en respuesta a incidentes | Evidencia esperable |
|---|---|---|
| Identificación | Conocer activos, servicios críticos, dependencias y responsables. | Inventario, mapa de servicios, propietarios, matriz de criticidad. |
| Detección | Descubrir comportamientos anómalos con rapidez suficiente. | Alertas, reglas SIEM, EDR, logs centralizados, umbrales de aviso. |
| Prevención | Reducir la probabilidad de incidentes similares. | Parches, MFA, hardening, segmentación, formación, control de accesos. |
| Contención | Limitar el daño sin paralizar innecesariamente la organización. | Aislamiento selectivo, bloqueo de indicadores, segmentación temporal. |
| Recuperación | Restaurar sistemas y datos de forma segura y verificable. | Copias probadas, orden de restauración, pruebas de integridad. |
| Cooperación con terceros | Coordinarse con proveedores, CERT/CSIRT, soporte externo o autoridades cuando proceda. | Contactos, acuerdos, canales alternativos, registro de comunicaciones. |
No confundir capacidad con herramienta
Tener una herramienta no garantiza resiliencia. Una organización puede tener copias de seguridad, SIEM o EDR y aun así no ser resiliente si no sabe quién decide, cómo se usan, cuándo se restauran o cómo se valida la vuelta al servicio.
4. Mantener servicios durante el incidente¶
Una organización ciberresiliente no siempre puede mantener todos sus servicios al 100 %. Lo que sí debe saber es qué servicios son esenciales, qué nivel mínimo puede aceptar y durante cuánto tiempo.
Para ello conviene clasificar los servicios antes del incidente:
| Nivel | Tipo de servicio | Ejemplo | Decisión resiliente |
|---|---|---|---|
| Crítico | Si se detiene, la organización no puede operar. | Gestión clínica, facturación, atención al cliente, producción. | Debe tener prioridad de protección, continuidad y recuperación. |
| Importante | Afecta al trabajo, pero puede degradarse temporalmente. | Intranet, repositorio documental, herramientas internas. | Puede funcionar en modo reducido o con procedimiento alternativo. |
| No esencial | Puede esperar sin impacto grave inmediato. | Servicios auxiliares o informativos. | Se recupera cuando lo crítico está estabilizado. |
Dicho de forma práctica, seguir prestando servicios puede significar varias cosas:
- mantener el servicio principal con funcionalidad reducida;
- activar un procedimiento manual temporal;
- redirigir el servicio a una plataforma alternativa;
- priorizar clientes, áreas o procesos críticos;
- aplazar servicios no esenciales para concentrar recursos;
- trabajar con proveedores para sostener una parte del servicio.
Ejemplo breve
Si el sistema de gestión documental queda aislado por sospecha de malware, la organización puede mantener un canal temporal de intercambio de archivos solo para procesos críticos, con permisos restringidos, registro de accesos y revisión posterior. No es la situación ideal, pero evita una parada total mientras se contiene y recupera el servicio original.
5. Restablecer servicios no es solo restaurar una copia¶
El CE d) se centra en el restablecimiento de los servicios afectados hasta confirmar la vuelta a la normalidad. Este punto es importante: restaurar una máquina o levantar una aplicación no significa automáticamente que el servicio esté recuperado.
Para que el restablecimiento sea seguro deben cumplirse tres condiciones:
- La causa del incidente está controlada. No tiene sentido restaurar un servidor si la cuenta comprometida sigue activa o si la vulnerabilidad explotada continúa abierta.
- Los datos y sistemas restaurados son fiables. Hay que comprobar integridad, fecha de la copia, ausencia de malware y coherencia funcional.
- El servicio funciona de forma estable para las personas usuarias. No basta con que el servidor arranque: debe prestar el servicio esperado y no mostrar señales de reinfección o fallo.
6. Criterios para confirmar la vuelta a la normalidad¶
La vuelta a la normalidad debe basarse en criterios claros, no en una sensación de "parece que ya funciona". Una forma práctica de revisarlo es separar la validación en cuatro bloques.
| Bloque de validación | Preguntas de comprobación |
|---|---|
| Validación técnica | ¿Los sistemas arrancan? ¿Los servicios responden? ¿Los logs no muestran actividad anómala? |
| Validación de seguridad | ¿Se ha eliminado la causa? ¿Se han rotado credenciales? ¿Se han cerrado vulnerabilidades? ¿Se mantiene monitorización reforzada? |
| Validación funcional | ¿Las personas usuarias pueden realizar las tareas críticas? ¿Los datos son coherentes? ¿Los propietarios del servicio lo confirman? |
| Validación organizativa | ¿Dirección, responsables técnicos y propietarios del servicio aceptan el retorno? ¿Quedan riesgos residuales documentados? |
Monitorización reforzada
Después de recuperar un servicio conviene mantener una vigilancia especial durante un periodo definido. La organización debe buscar señales de reinfección, accesos anómalos, errores repetidos, degradación del rendimiento o intentos de volver a explotar la misma debilidad.
Un criterio de cierre podría redactarse así:
El servicio se considera restablecido cuando los sistemas afectados han sido recuperados desde fuentes fiables, la causa del incidente ha sido mitigada, las personas responsables del servicio han validado su funcionamiento, no se observan indicadores de compromiso activos y queda documentado el seguimiento posterior.
7. Cooperación con terceros¶
La ciberresiliencia rara vez depende solo de recursos internos. Muchos servicios actuales se apoyan en proveedores cloud, mantenimiento externo, comunicaciones, software como servicio, soporte especializado o cadenas de suministro.
Por eso, antes de un incidente deben estar claras estas cuestiones:
- qué proveedores son críticos para cada servicio;
- qué contactos se usan en horario laboral y fuera de horario;
- qué acuerdos de nivel de servicio existen;
- qué evidencias puede aportar cada tercero;
- cuándo hay que contactar con CERT/CSIRT, autoridades o equipos externos;
- cómo se registra cada comunicación para el informe final.
Relación con el plan de respuesta
Los contactos, canales, autorizaciones y criterios de escalado deben estar definidos en el plan de respuesta. Este tema no sustituye al plan; explica qué debe comprobarse para que la respuesta sea resiliente.
8. Ejemplo guiado: ransomware en un servidor de ficheros¶
Supongamos que se detecta cifrado masivo en un servidor de ficheros compartido. Desde el punto de vista del proceso de respuesta, habría que detectar, analizar, contener, erradicar y recuperar. Desde el punto de vista de la ciberresiliencia, además, hay que mantener la actividad esencial y validar la vuelta a la normalidad.
| Momento | Decisión resiliente |
|---|---|
| Antes | El servidor está clasificado como servicio crítico, existen copias probadas y se conoce el orden de restauración. |
| Durante | Se aísla el servidor afectado, pero se habilita un canal temporal para documentación imprescindible. |
| Contención | Se bloquean cuentas sospechosas y se evita que el cifrado alcance copias o recursos compartidos. |
| Recuperación | Se restaura desde una copia limpia, se valida integridad y se revisan permisos. |
| Vuelta a la normalidad | El área propietaria confirma que puede trabajar, seguridad mantiene monitorización reforzada y se documentan acciones pendientes. |
| Mejora | Se revisan permisos excesivos, segmentación, MFA, alertas de cifrado y pruebas de restauración. |
Lo importante es observar que la organización no solo "recupera un servidor". Mantiene una forma mínima de trabajo, restaura de manera segura y refuerza sus capacidades para que el mismo incidente sea menos probable o menos dañino.
9. Checklist de respuesta ciberresiliente¶
Antes de considerar que una respuesta ha sido ciberresiliente, revisa si se han cumplido estos puntos:
- se han identificado servicios críticos y dependencias;
- se conoce el impacto de la interrupción del servicio;
- existen alternativas temporales para procesos esenciales;
- las copias de seguridad han sido probadas antes del incidente;
- se han definido responsables técnicos y propietarios de servicio;
- se han usado canales de comunicación adecuados y alternativos;
- se ha contenido el incidente sin generar una interrupción innecesaria;
- se ha recuperado desde fuentes fiables;
- se ha validado la seguridad antes de devolver el servicio;
- las personas usuarias o propietarias han confirmado el funcionamiento;
- se ha mantenido monitorización reforzada tras la recuperación;
- se han documentado mejoras para identificación, detección, prevención, contención, recuperación y cooperación.
10. Resumen¶
En este tema has aprendido que:
- la ciberresiliencia amplía la respuesta a incidentes con continuidad, recuperación validada y mejora;
- una respuesta resiliente busca que la organización siga prestando los servicios esenciales, aunque sea de forma degradada o temporal;
- restablecer un servicio no es solo encender sistemas, sino validar seguridad, funcionamiento, datos y estabilidad;
- la vuelta a la normalidad debe confirmarse con criterios técnicos, funcionales, de seguridad y organizativos;
- la cooperación con terceros es parte de la resiliencia, especialmente cuando los servicios dependen de proveedores o soporte externo.
La idea principal es esta: una organización ciberresiliente no es la que nunca sufre incidentes, sino la que está preparada para resistirlos, seguir operando, recuperarse con seguridad y aprender de ellos.
Fuentes y referencias¶
- NIST, Computer Security Incident Handling Guide, Special Publication 800-61 Revision 2.
- INCIBE, recursos divulgativos y guías sobre ciberresiliencia, continuidad y mejora de capacidades ante incidentes.
- Documento de teoría 4.1.1. Proceso completo de respuesta a incidentes.
- Documento de teoría 4.1.2. Planes de respuesta a incidentes.
- Documento de teoría 4.1.3. Playbooks y runbooks de respuesta a incidentes.
Presentación¶
Presentación asociada
Si se crea o actualiza una presentación Reveal.js para este punto, debe enlazarse aquí y en los índices correspondientes del repositorio.