Respuesta a incidentes y continuidad de negocio
Objetivos: Al terminar este tema, podrás…
- Distinguir un evento sospechoso de un incidente de seguridad y asignarle una severidad que puedas revisar a medida que llega información
- Recorrer el ciclo de respuesta de NIST SP 800-61 sobre un caso concreto y explicar qué se decide en cada fase
- Tomar una decisión de contención con información incompleta y nombrar lo que esa decisión te cuesta
- Fijar y justificar un RTO y un RPO para un sistema a partir de lo que su operación tolera perder
- Redactar un primer mensaje de crisis que diga lo que se sabe, lo que no se sabe y lo que la persona afectada debe hacer
Apertura: la decisión que ya tomaste una vez
En la clase 02 tu grupo tuvo diez minutos para decidir si el equipo de tecnología de Keralty debía desconectar sus sistemas o mantenerlos funcionando mientras investigaba. El ataque ya lo conocías desde la clase 01, y en ese momento lo que te pedían era escoger entre dos principios: proteger la confidencialidad o proteger la disponibilidad. Piensa ahora en lo que te faltaba saber para decidir con más certeza. Probablemente aparece alguna de estas tres preguntas: qué tan lejos había llegado el atacante, quién tenía autoridad para apagar los sistemas de un hospital y a quién había que avisarle primero.
Esas tres preguntas se responden con un procedimiento acordado antes de que pase nada, que diga quién decide, con qué información y en qué orden; un principio, por sí solo, no alcanza para contestarlas. Hoy vas a aprender ese procedimiento y lo vas a usar dos veces sobre un incidente que avanza mientras decides, con una diferencia importante respecto a la clase 02: esta vez no todos en tu grupo van a tener la misma información.
Antes de empezar
Escribe en una línea qué crees que debería hacer primero un equipo que recibe una alerta de ataque a las tres de la mañana. Guárdala: la vas a releer al final de la clase.
Explicación: qué es un incidente y cómo se responde
Evento e incidente
Todos los días pasan cosas raras en un sistema: alguien escribe mal su contraseña cinco veces, un servidor tarda más de lo normal, llega un correo con un enlace extraño. Cada una de esas cosas es un evento, algo observable que quedó registrado. Un evento se vuelve un incidente de seguridad cuando alguien con autoridad para hacerlo confirma que una de las propiedades que viste en la clase 02 fue violada o está en peligro inmediato: que alguien leyó lo que no debía, alteró lo que no debía o tumbó lo que tenía que estar funcionando. La diferencia importa porque declarar un incidente pone en marcha cosas caras (despertar gente, cortar servicios, avisar a autoridades), y no declararlo a tiempo deja al atacante trabajando. Por eso la primera decisión de cualquier respuesta consiste en saber si lo que estás viendo ya merece ese nombre, y esa decisión no es técnica.
Severidad
Una vez declarado el incidente, hay que decidir qué tan urgente es, y para eso sirve la severidad. Cada organización fija su propia escala, y lo hace según qué tan crítico es el sistema afectado, si hay datos personales de por medio y cuánta gente se ve afectada. La idea te va a sonar conocida, porque la severidad es la misma combinación de probabilidad e impacto que usaste para priorizar riesgos en la clase 04, aplicada esta vez a algo que ya está pasando. La severidad inicial se asigna con lo poco que sabes en los primeros minutos y se revisa cada vez que llega información nueva, hacia arriba o hacia abajo. Cuando dudes entre dos niveles, escoge el más alto: sobreactuar ante una falsa alarma cuesta unas horas de sueño, y subestimar un incidente real le regala tiempo al atacante. Al final de la página, en la lectura «El ciclo de respuesta en detalle», tienes una escala de ejemplo con cuatro niveles y tiempos de respuesta; tómala como ilustración de cómo se ve una escala, no como una norma.
El ciclo de NIST SP 800-61
NIST es el instituto de estándares del gobierno de Estados Unidos. Sus guías son públicas y gratuitas, y muchas organizaciones fuera de Estados Unidos las adoptan como referencia. Durante más de una década, la referencia de respuesta a incidentes fue la revisión 2 de su guía SP 800-61, publicada en 2012 (NIST SP 800-61 Rev. 2), que organiza la respuesta en cuatro fases: preparación; detección y análisis; contención, erradicación y recuperación; y actividad posterior al incidente. En abril de 2025 NIST publicó la revisión 3 (NIST SP 800-61 Rev. 3), que reemplazó a la anterior y ya no presenta la respuesta como un ciclo aparte: la reparte entre las funciones de su marco general de ciberseguridad, el CSF 2.0. En esta clase vas a trabajar con las cuatro fases de 2012 por una razón práctica: siguen siendo un vocabulario muy extendido para hablar de respuesta a incidentes, y la revisión de 2025 conserva las mismas actividades aunque las ordene de otra forma. Si buscas la guía y encuentras la versión nueva, vas a encontrar el mismo trabajo ordenado de otra manera, y no una contradicción con lo que viste aquí.
La preparación es todo lo que se hace antes de que pase nada: escribir el plan, decidir quién tiene cada rol, guardar los registros y los respaldos donde un atacante no los alcance. La detección y análisis empieza con la alerta y termina cuando sabes qué pasó y qué tan grave es; su materia prima son los registros (en inglés, logs), la lista que guarda un sistema de qué se pidió, a qué hora y desde dónde. La tercera fase junta tres momentos distintos, contención, erradicación y recuperación, que se explican enseguida. La cuarta, la actividad posterior al incidente, la vas a ver al final de la clase sobre lo que hayas vivido en la simulación. Las fases tienen un orden, pero la información nueva te obliga a retroceder con frecuencia. Si en plena recuperación descubres que el respaldo del que ibas a restaurar también estaba al alcance del atacante, vuelves a la contención: ese respaldo ya no sirve hasta que compruebes que está limpio.
Contención, erradicación y recuperación
Contener es impedir que el daño siga creciendo, y casi siempre tiene un precio. La contención a corto plazo es lo que haces en los primeros minutos para frenar al atacante sin destruir lo que necesitas para entender qué pasó: aislar un servidor de la red en vez de apagarlo, porque al apagarlo se borra lo que solo existe mientras la máquina está encendida, como las conexiones abiertas en ese momento. La contención a largo plazo es lo que sostienes mientras preparas la limpieza: bloquear una cuenta, cerrar un formulario, poner el servicio en modo de mantenimiento. Las dos te cuestan algo, porque interrumpes a usuarios legítimos y además le avisas al atacante que lo viste. La erradicación es quitar la causa y todo lo que el atacante dejó: corregir la falla por la que entró, borrar cuentas que haya creado, cambiar las credenciales que pudo ver. Va antes de la recuperación por una razón simple: si restauras el servicio sin haber cerrado la puerta, el atacante vuelve a entrar por el mismo sitio. La recuperación es volver a operar con normalidad, y su pregunta central es desde dónde: desde un respaldo, desde el servidor limpiado o desde uno nuevo.
Quién responde
Un equipo de respuesta reúne roles distintos, y sus prioridades chocan. Quien lidera la parte técnica quiere preservar lo que permite entender el ataque y no tocar nada sin comprenderlo. Quien comunica necesita decir algo pronto, porque el silencio también se lee. La dirección tiene que mantener funcionando la organización, y quien responde por lo legal piensa en las obligaciones ante la SIC y en que todo lo que se diga hoy quedará como prueba de lo que se sabía. En Colombia existe además ColCERT, el equipo nacional de respuesta a incidentes que ya apareció en la clase 09, que coordina los incidentes que afectan al país. En la simulación de hoy, cada persona de tu grupo va a ocupar uno de esos cuatro roles: Líder técnico, Comunicaciones, Dirección y Cumplimiento legal.
Comunicación de crisis
Durante un incidente, cada persona a la que le avisas cambia lo que puedes hacer después, así que la comunicación también se planea. Primero se entera el equipo que tiene que contener, con todos los detalles técnicos, porque sin ellos no puede trabajar. Después, quien dirige la organización, en cuanto el incidente se confirma, porque hay decisiones que no le corresponden al equipo técnico, como cerrar un servicio el día que más se usa. Luego, el cliente o la organización dueña de los datos y, cuando ya haya instrucciones que darles, las personas afectadas, porque un aviso sin instrucciones les quita la calma sin darles nada que hacer. Y la autoridad que la ley señala, que en Colombia es la SIC cuando hay datos personales en riesgo, como viste en la clase 09. Por eso la comunicación de crisis va por momentos. Al principio dices que hay un incidente en investigación y qué precaución tomar; cuando sabes más, qué datos se vieron afectados y qué debe hacer cada persona; al cerrar, qué pasó y qué cambió. En cada momento, un buen mensaje dice lo que sabes, reconoce lo que todavía no sabes y le dice a quien lo lee qué hacer, sin especular sobre lo que no has confirmado. Un mensaje que después tienes que desmentir te obliga a explicar dos veces y le enseña a quien lo leyó a no creerte el siguiente. La tabla de qué decir y qué evitar en cada momento, y el detalle del reporte a la SIC con su plazo, están en la lectura «El ciclo de respuesta en detalle».
Simulación, ronda 1: las 3:15 AM
MicroPréstamos es un caso ficticio construido para esta clase. Tu equipo desarrolló y mantiene desde hace tres meses la aplicación de una ONG de microfinanzas que presta pequeñas sumas a 200 emprendedoras de Ciudad Bolívar. A las 2:47 de la madrugada, el servicio que vigila si la aplicación responde te envía una alerta: la página de la aplicación muestra “Error del servidor”. Te conectas y lees el registro de la aplicación, que se copia cada cinco minutos al servicio del proveedor de alojamiento:
02:03:51 POST /login desde 185.xx.xx.17 acceso concedido: admin
02:04:02 GET /admin/exportar-usuarios desde 185.xx.xx.17
02:05:40 GET /admin/exportar-prestamos desde 185.xx.xx.17
02:06:13 fin de sesión desde 185.xx.xx.17
02:06–02:47 la aplicación responde cada vez más lento hasta dejar de responder
Nadie de tu equipo inició sesión como administrador esa noche. Son las 3:15 y tu equipo tiene que decidir qué hacer antes de las 4:00.
El registro, leído otra vez
En el registro de MicroPréstamos, ¿cuál de las líneas es la que convierte un evento en incidente? Si esa línea no existiera y solo tuvieras la última, la de la aplicación cada vez más lenta, ¿qué severidad le pondrías y qué tendrías que averiguar primero?
Explicación: continuidad, RTO, RPO y ransomware
Plan de respuesta y plan de continuidad
El plan de respuesta a incidentes y el plan de continuidad de negocio se escriben pensando en el mismo mal día, pero contestan preguntas distintas. El de respuesta dice cómo devolverle la seguridad al sistema: quién investiga, quién contiene, cómo se limpia. El de continuidad dice cómo sigue funcionando la organización mientras el sistema no está: qué se hace a mano, con qué formatos, quién lo autoriza y hasta cuándo se aguanta así. Recuerda el ataque a IFX Networks con el que abrió la clase 03: cuando la Rama Judicial suspendió términos, eso fue una decisión de continuidad: no arreglaba nada técnico, pero impedía que los procesos vencieran mientras nadie podía trabajar.
Una oficina sin sistema
Elige una oficina pública o un servicio presencial que conozcas de verdad, como la notaría de tu barrio, la registraduría o la biblioteca de tu colegio, y nómbralo. La próxima vez que vayas, pregunta o fíjate si tienen a la vista algún formato en papel para cuando el sistema no funciona, y describe cuál es. Si su sistema se cae un lunes a las 8:00, ¿qué tendría que estar ya escrito y guardado en papel para que siga atendiendo, y cuánto tiempo crees que aguantaría así?
RTO y RPO
El RTO (tiempo objetivo de recuperación, del inglés Recovery Time Objective) es el máximo que un sistema puede estar caído antes de que el daño deje de ser aceptable. El RPO (punto objetivo de recuperación, Recovery Point Objective) es la máxima cantidad de trabajo, medida en tiempo, que la organización acepta perder: si tu RPO es de una hora, necesitas una copia de los datos al menos cada hora, porque todo lo que pasó después de la última copia se pierde. Ninguno de los dos números lo decide el equipo técnico solo. Piensa en el sistema de inscripción de materias de una universidad. Un martes cualquiera de octubre puede estar caído un día entero sin que nadie lo note, pero en la semana de inscripciones cada hora caída es un grupo que se llena con quien sí alcanzó a entrar, así que el RTO de ese mismo sistema depende del calendario. Y si se pierden las inscripciones de la última hora, alguien tiene que volver a inscribir a mano a cada estudiante afectado, así que el RPO sale de cuánto trabajo manual está dispuesta a absorber la oficina de registro. Por eso los dos números se fijan en una conversación entre quien conoce la operación y quien conoce la infraestructura, y por eso un sistema sin RTO ni RPO escritos no está libre de ellos: tiene los que le tocaron. Fijarlos más exigentes cuesta más, porque un RPO cercano a cero exige copiar los datos casi en tiempo real y un RTO cercano a cero exige tener otro sistema listo para reemplazar al primero. En la lectura «El ciclo de respuesta en detalle» tienes una tabla de ejemplos con sistemas cercanos y la pregunta de la operación de la que sale cada número.
Ransomware: qué cambia en la respuesta
En la tabla de cierre de la clase 03, el ransomware y la doble extorsión quedaron asignados a esta sesión. Qué es ya lo sabes; lo que falta es qué cambia en la respuesta. Cuando el ataque cifra los archivos, la contención se vuelve una carrera: el programa que cifra se mueve por la red buscando más equipos y más copias, así que aislar rápido salva lo que todavía no alcanzó. La recuperación depende casi por completo de tener una copia que el ataque no haya podido tocar, y por eso la vieja regla 3-2-1 sigue vigente: tres copias de los datos, en dos tipos de almacenamiento distintos, una de ellas fuera del lugar y, para el ransomware, desconectada de la red. La agencia de ciberseguridad de Estados Unidos lo recomienda en esos términos: mantener copias de respaldo cifradas y desconectadas de los datos críticos (CISA, Ransomware Guide). Un caso conocido de una recuperación que dependió de una sola copia aislada es el de la naviera Maersk en 2017, que reconstruyó su red a partir de un único servidor en Ghana que estaba desconectado por un corte de luz cuando llegó el ataque (Wired, “The Untold Story of NotPetya”); lo tienes completo en la lectura «Dos respuestas reales y un caso resuelto».
La lectura de la clase 03 ya te advirtió que el respaldo resuelve solo la mitad del problema. Con la doble extorsión, el grupo criminal se llevó una copia antes de cifrar, y el respaldo te devuelve la disponibilidad pero no deshace que tus datos estén en manos de otro. Piensa en el ataque a Keralty de la clase 01: como leíste en la clase 03, el grupo terminó publicando parte de la información, y ningún respaldo, por perfecto que fuera, le habría devuelto a la EPS la confidencialidad de esos datos. Por eso la decisión de pagar o no pagar no se reduce a saber si hay respaldo.
Un respaldo desconectado
Supón que MicroPréstamos hubiera tenido un respaldo desconectado, hecho anoche a medianoche. Con lo que sabían Dirección de la ONG y Cumplimiento legal en la ronda 2 (lo tienes en «Dos respuestas reales y un caso resuelto», al final de la página), ¿qué parte del problema de esa mañana habría desaparecido y cuál seguiría exactamente igual? Toma posición sobre si el mensaje de cuatro líneas a las beneficiarias habría cambiado, y escribe el argumento más fuerte en contra de tu posición.
Simulación, ronda 2: las 8:00 AM
Son las 8:00 de la mañana. La sede de la ONG empieza a llenarse para el día de desembolsos, y lo que tu equipo encuentra ahora depende de lo que decidió a las 3:15. Lo que queda por decidir es la parte del ciclo que mira hacia adelante: desde dónde se vuelve a operar, cuánto tiempo y cuántos datos se pueden perder, y qué se les dice a las beneficiarias.
Revelación y puesta en común
En un equipo de respuesta real, nadie tiene toda la información al mismo tiempo. Quien mira los registros no sabe qué día es para la operación, quien atiende a la prensa no sabe qué se puede afirmar sin mentir, y quien conoce los plazos legales no sabe qué se puede apagar. Por eso un plan de respuesta, además de repartir tareas, fija en qué momento se reúnen los roles y quién tiene la última palabra cuando sus prioridades chocan. Las cuatro hojas de cada ronda, junto con las tres tarjetas de consecuencia, están reunidas en la lectura «Dos respuestas reales y un caso resuelto», para que puedas ver qué sabía cada rol y qué decisión habría cambiado con ese dato.
Debrief y cierre: lecciones aprendidas
La última fase del ciclo empieza cuando todo vuelve a funcionar, y es la que más fácil se deja para después porque el equipo lleva horas sin dormir. Se llama actividad posterior al incidente, y su herramienta es el post-mortem: una revisión escrita que se hace después del incidente, que reconstruye la línea de tiempo, separa la causa técnica (en MicroPréstamos, un formulario que pegaba el texto del usuario dentro de una orden a la base de datos, el mismo error de la clase 05) de la causa del sistema (nadie revisó ese formulario antes de publicarlo, y nadie se enteró del ataque durante 44 minutos), y termina en una lista de acciones con nombre de responsable y fecha. Su regla central es la que más le cuesta cumplir a un equipo: el post-mortem busca qué permitió el error, no quién lo cometió. Si la revisión termina señalando a la persona que escribió la consulta insegura, el equipo aprende a esconder sus errores, y el próximo se descubre tarde. Si termina preguntando por qué eso llegó a producción sin que nadie lo viera, el equipo cambia el proceso.
La comunicación es la otra mitad de las lecciones. El caso Equifax que viste en la clase 02 es recordado tanto por la falla como por la respuesta: la empresa descubrió la brecha en julio y no la hizo pública sino hasta septiembre, y en ese intervalo un directivo vendió sus acciones usando lo que sabía, por lo que la comisión de valores de Estados Unidos lo acusó de uso de información privilegiada (SEC, comunicado 2018-40). Lo tienes desarrollado en la lectura, junto con Maersk, que es el caso opuesto.
Lo que practicaste hoy sobre MicroPréstamos es lo que el capítulo 9 de la entrega final te va a pedir sobre tu propio sistema. En la lectura de esta clase tienes el ciclo con sus tablas de referencia, el caso MicroPréstamos resuelto con las tres tarjetas, los casos Maersk y Equifax completos, y los términos de la clase con su definición corta en «Conceptos clave». La próxima clase cambia de lado: en vez de reconstruir lo que un atacante hizo, vas a ver qué puede saber de una organización antes de atacarla, solo con lo que esa organización ya publicó.
Lectura disponible — El ciclo de respuesta en detalle
Una escala de severidad de ejemplo
La tabla que sigue es un ejemplo de escala: cada organización fija la suya, con sus propios niveles y tiempos. Sirve para ver cómo se traduce la idea de severidad en una regla que alguien puede aplicar a las tres de la mañana sin tener que pensarla desde cero.
| Severidad | Descripción | Ejemplos | Tiempo de respuesta (ejemplo) |
|---|---|---|---|
| Crítica | Compromiso activo de sistemas esenciales o de datos sensibles en gran cantidad | Ransomware en producción, extracción de una base de datos en curso | Inmediato (minutos) |
| Alta | Compromiso confirmado que puede extenderse | Cuenta de administrador comprometida, programa malicioso en la red interna | Menos de 1 hora |
| Media | Actividad sospechosa que requiere investigación | Intentos de acceso inusuales, alertas de detección | Menos de 4 horas |
| Baja | Evento menor sin impacto inmediato en la operación | Correo de phishing reportado sin abrir, sondeo externo de la red | Menos de 24 horas |
Lo que mueve un incidente de un nivel a otro son tres preguntas: qué tan crítico es el sistema afectado para la operación, si hay datos personales de por medio y cuántas personas se ven afectadas. En MicroPréstamos, el registro de las 2:03 ya muestra un acceso de administrador que nadie del equipo hizo, seguido de dos exportaciones de tablas con datos personales y financieros: eso basta para ubicarlo arriba en cualquier escala razonable. Si después se confirma que el atacante volvió (la tarjeta C), la severidad sube otra vez, aunque ya estuviera alta, porque el daño dejó de ser algo que pasó y se volvió algo que sigue pasando. La severidad funciona como una estimación que se corrige con cada dato nuevo, y en la duda se corrige hacia arriba.
Las dos revisiones de SP 800-61
La revisión 2 de la guía de NIST, publicada en 2012 (NIST SP 800-61 Rev. 2), describía la respuesta a incidentes como un ciclo propio de cuatro fases, y fue la versión vigente de la guía durante más de una década. Es la versión con la que trabajaste en clase, y la razón para usarla es que su vocabulario (preparación, detección y análisis, contención, erradicación y recuperación, actividad posterior) sigue siendo el que vas a oír con frecuencia cuando se habla del tema.
La revisión 3, de abril de 2025 (NIST SP 800-61 Rev. 3), reemplazó a la anterior. Su título completo la presenta como un perfil comunitario del CSF 2.0, el marco general de ciberseguridad de NIST, y eso describe el cambio: en vez de tratar la respuesta como un ciclo aparte, la reparte entre las funciones de ese marco general, de modo que la preparación, la detección o la recuperación quedan conectadas con el resto de la gestión de riesgos de la organización. Para ti, en este punto del curso, la consecuencia práctica es pequeña: las actividades son las mismas, ordenadas de otra manera.
Las tres opciones de recuperación
| Opción | Ventajas | Riesgos |
|---|---|---|
| Restaurar desde un respaldo | Se vuelve a un estado anterior al ataque | Se pierde todo lo que pasó después del respaldo; ¿el respaldo también fue comprometido? |
| Limpiar el servidor comprometido | No se pierden datos | ¿Encontraste todo lo que dejó el atacante? |
| Servidor nuevo + restaurar datos | Estado limpio y datos recuperados | Toma más tiempo, pero es el enfoque más seguro |
La tabla deja abierta la pregunta que decide la elección: ¿el respaldo también está comprometido? Si el respaldo estaba guardado en el mismo lugar al que llegó el atacante, como en MicroPréstamos, no puedes darlo por limpio solo porque se hizo antes del ataque; primero tienes que comprobar que nadie lo tocó. Si no puedes comprobarlo, la recuperación desde ese respaldo se vuelve una apuesta. La segunda pregunta es cuánto se pierde, y ahí entra el RPO: un respaldo de hace seis días en un sistema que registra pagos todos los días significa seis días de trabajo que alguien tiene que reconstruir, si es que existe de dónde reconstruirlo. La tercera es la erradicación: cualquiera de las tres opciones que vuelva a poner en línea el mismo código con la misma falla le devuelve al atacante la puerta por la que entró.
La comunicación por momentos
| Momento | Qué comunicar | Qué evitar |
|---|---|---|
| Inmediatamente | Que hay un incidente en investigación y qué precaución tomar | Dar detalles técnicos, especular sobre el alcance |
| Cuando tengas claridad | Qué datos se vieron afectados y qué debe hacer cada persona | Minimizar o suavizar la realidad |
| Después de resolverlo | Qué pasó, qué se hizo y qué cambió para que no vuelva a pasar | Desaparecer sin cierre |
Un buen mensaje de crisis dice lo que sabes, reconoce lo que todavía no sabes y le dice a quien lo lee qué hacer, sin especular sobre lo que no has confirmado. Una plantilla útil para el primer momento tiene cuatro partes: qué detectaste, qué datos pueden estar afectados, qué estás haciendo y cuándo vas a volver a informar. Fíjate en que ninguna de las cuatro partes promete algo que todavía no sabes.
El reporte a la SIC
La Ley 1581 de 2012, que conociste en la clase 09, incluye entre los deberes del responsable del tratamiento el de informar a la SIC cuando se violen sus medidas de seguridad y haya riesgo para la información de los titulares. En la práctica, la SIC recibe ese reporte por el Registro Nacional de Bases de Datos, y su propia guía pide hacerlo dentro de los quince días hábiles siguientes a conocer el incidente (SIC, instructivo del Registro Nacional de Bases de Datos). Que la ley te dé quince días hábiles no significa que tengas quince días para pensar qué decir: a las beneficiarias de MicroPréstamos les sirve más un aviso imperfecto a las 7:00 que uno perfecto dentro de dos semanas.
La regla 3-2-1 en detalle
Cada número de la regla responde a una forma distinta de perder los datos. Son tres copias porque una falla rara vez daña dos copias a la vez, y con tres todavía te queda una cuando falla la segunda. Son dos tipos de almacenamiento distintos porque un mismo defecto, de fabricación o de configuración, puede afectar a todos los discos de un mismo tipo al mismo tiempo. Y una copia está fuera del lugar, y desconectada de la red, porque el incendio, la inundación y el ransomware tienen algo en común: llegan a todo lo que está junto o conectado. MicroPréstamos incumplía las tres partes: tenía una sola copia, en el mismo disco y en el mismo servidor que el atacante alcanzó.
La regla tiene un límite que ya viste en la explicación: protege la disponibilidad y la integridad de tus datos, porque te permite volver a tenerlos tal como estaban, pero no protege su confidencialidad. Si el atacante se llevó una copia antes de cifrar, que es lo que hace la doble extorsión, la regla 3-2-1 te devuelve tus sistemas y te deja el mismo problema con los datos que ya están en manos de otro.
RTO y RPO de ejemplo
Los números de la tabla son ilustrativos: muestran de qué tipo de pregunta sale cada número, no un valor que debas copiar.
| Sistema | RTO | RPO | De qué pregunta de la operación sale el número |
|---|---|---|---|
| Inscripción de materias, en semana de inscripciones | 1 hora | 15 minutos | ¿Cuántos cupos se llenan por hora con quien sí pudo entrar? ¿Cuántas inscripciones puede rehacer a mano la oficina de registro? |
| Billetera digital de pagos | Minutos | Casi cero | ¿Cuánto tiempo aguanta un comercio sin poder cobrar? ¿Se puede perder un pago ya hecho sin que alguien pierda plata? |
| Agenda de citas de una EPS | 4 horas | 1 hora | ¿Cuántos pacientes llegan a una cita que el sistema ya no registra? ¿Cuántas citas puede reagendar por teléfono el centro de llamadas? |
| Intranet de un colegio | 3 días | 1 día | ¿Qué se deja de hacer si nadie consulta la intranet una semana? ¿Cuánto material puede volver a subir un profesor sin perder una clase? |
Fíjate en que ninguna de las preguntas de la última columna la puede responder el equipo técnico solo: todas las responde alguien que conoce la operación. Lo que el equipo técnico aporta es cuánto cuesta cumplir cada número.
Lectura disponible — Dos respuestas reales y un caso resuelto
MicroPréstamos resuelto
MicroPréstamos es un caso ficticio construido para esta clase.
La línea de tiempo. El registro completo de la aplicación, revisado después con calma, muestra que el atacante empezó a probar el formulario de /login a la 1:58. A las 2:03 escribió en el campo de usuario un texto que la base de datos interpretó como una orden, el mismo error de obedecer órdenes disfrazadas de datos que viste en la clase 05, y entró al panel de administración sin necesitar ninguna contraseña. Entre las 2:04 y las 2:05 usó dos botones de exportación: la lista de usuarios (nombre, cédula, celular, correo y el hash de la contraseña) y la de préstamos (monto, saldo pendiente e historial de pagos de cada beneficiaria). A las 2:06 cerró sesión. Las dos exportaciones de tablas completas saturaron el servidor pequeño de la ONG, que se fue poniendo cada vez más lento hasta dejar de responder. El servicio de monitoreo, que revisa cada cinco minutos si la aplicación responde, envió la alerta a las 2:47, cuando el servidor dejó de recuperarse solo. Entre el acceso y la alerta pasaron 44 minutos, y la alerta no la disparó el ataque sino su efecto secundario.
Lo que sabía cada rol en la ronda 1. El Líder técnico sabía que el registro de la aplicación es confiable porque se copia fuera del servidor y que el de la base de datos no lo es; que aislar el servidor sin apagarlo conserva la lista de conexiones abiertas, la única forma de saber si el atacante dejó algo corriendo; que las contraseñas guardadas como hash se pueden adivinar con tiempo si son débiles; que desde el servidor aislado se pueden invalidar todas las contraseñas y sesiones, pero nadie podrá crear una nueva hasta que el servicio vuelva; y que el único respaldo tenía seis días y estaba en el mismo servidor. Comunicaciones sabía que a las 3:05 una beneficiaria había preguntado en Facebook si les habían robado la plata, y que un periodista local sigue esa página. Dirección sabía que a las 8:00 empezaba el día mensual de desembolsos para 140 beneficiarias, que existía un formato en papel que las cajeras saben usar, y que el contrato con el donante exige avisarle en 24 horas. Cumplimiento legal sabía que los datos son personales y financieros, que la ONG es la responsable y el equipo el encargado, que la SIC pide el reporte en quince días hábiles y que todo lo que se diga en público queda como prueba.
Lo que hacía cada tarjeta. La tarjeta A, para quienes aislaron sin apagar, mostraba un programa que el atacante dejó en el servidor y que intentaba conectarse cada diez minutos a su dirección: solo se pudo encontrar porque el servidor seguía encendido. Es la recompensa de una contención a corto plazo que preserva lo que se necesita para entender el ataque. La tarjeta B, para quienes apagaron, dejaba al equipo sin forma de saber si había algo corriendo, y por eso cualquier recuperación que reutilizara ese servidor quedaba en duda. La tarjeta C, para quienes mantuvieron en línea, mostraba un segundo acceso a las 4:10 por el mismo formulario, esta vez con la tabla de pagos del mes: mantener el servicio sin cerrar la falla dejó la puerta abierta.
Lo que sabía cada rol en la ronda 2. El Líder técnico tenía tres opciones de recuperación: restaurar el respaldo de seis días en un servidor nuevo (unas 4 horas, perdiendo 61 pagos), limpiar el servidor actual (1 hora, sin garantía de haber encontrado todo), o montar un servidor nuevo, corregir el formulario, restaurar el respaldo y volver a digitar los 61 pagos desde los recibos en papel (unas 7 horas). Comunicaciones sabía que el periodista ya había llamado y que la publicación tenía 40 comentarios. Dirección sabía que el día de desembolsos se podía atender en papel, pero que un segundo día así impedía cruzar cobros con saldos y podía terminar en cobros dobles, y que las cajeras guardan los recibos durante 30 días. Cumplimiento legal sabía que el mensaje no podía afirmar que no se vieron afectados datos, y que las contraseñas robadas eran un riesgo para cualquier otro servicio donde la beneficiaria usara la misma.
El razonamiento de la recuperación. La primera opción parece la más rápida de las que usan un servidor limpio, pero restaura el mismo código con la misma falla en el formulario: se salta la erradicación, y el atacante puede volver a entrar exactamente igual que a las 2:03. La segunda es la más corta, pero depende de haber encontrado todo lo que el atacante dejó, y para quien recibió la tarjeta B esa garantía no existe. La tercera es la única que cierra la puerta y vuelve a un estado conocido, y además recupera los 61 pagos, porque los recibos en papel existen y duran 30 días: ese dato de Dirección es el que fija el RPO real de la base de préstamos. Mientras los recibos estén guardados, perder seis días de datos cuesta horas de digitación y no plata perdida. El RTO, en cambio, lo fija el riesgo del segundo día en papel: la aplicación tiene que estar de vuelta antes de que empiecen los cobros de la semana. Queda una pregunta que la tercera opción no resuelve sola: el respaldo estaba en el mismo servidor que el atacante alcanzó, así que antes de restaurarlo hay que comprobar que nadie lo modificó.
El mensaje a las beneficiarias. La conclusión más importante de la ronda 2 no está escrita en ninguna hoja. Con el servidor aislado y las contraseñas invalidadas, no se le puede pedir a una beneficiaria que cambie su contraseña en un enlace que no funciona. Lo que sí puede hacer esa mañana es cambiar esa misma contraseña en cualquier otro servicio donde la use, porque eso es lo que el Líder técnico y Cumplimiento legal sabían por separado. Un mensaje razonable dice que hubo un acceso no autorizado a la aplicación, que pueden estar afectados sus datos de contacto y de préstamo, que el desembolso de hoy se hace en papel con normalidad, que cambie la contraseña en otros servicios donde use la misma y que la ONG volverá a escribirle ese mismo día.
El post-mortem. La causa técnica es un formulario de /login que armaba la consulta a la base de datos pegando lo que el usuario escribía. Las causas del sistema son las que explican por qué eso llegó a producción y por qué costó tanto responder: nadie revisó la seguridad de ese formulario antes de publicarlo; ninguna alerta vigilaba un acceso de administrador fuera de horario, por lo que el ataque se descubrió 44 minutos después y por un síntoma secundario; el único respaldo tenía seis días y estaba en el mismo servidor, sin que nadie hubiera decidido nunca ese intervalo; y no existía un plan escrito que dijera quién decide qué. La lista de acciones del caso asigna cada una a un responsable con fecha: el Líder técnico revisa todas las consultas de la aplicación en dos semanas; el equipo agrega una alerta por accesos de administrador fuera de horario en una semana; la dirección de la ONG y el equipo fijan juntos un RTO y un RPO por escrito en un mes, y los respaldos pasan a una copia diaria fuera del servidor; y el equipo escribe el plan de respuesta, con los cuatro roles y sus contactos, antes del siguiente día de desembolsos.
Lo que la tarjeta B prohibió
Los grupos que recibieron la tarjeta B no pueden saber si el atacante dejó algo en el servidor. ¿Qué opción de recuperación les quedó prohibida por eso, y qué les costó en horas?
Tu propio mensaje
Lee el mensaje de cuatro líneas que escribió tu grupo en la ronda 2. ¿Qué le pide a la beneficiaria que ella no puede hacer esa mañana, o qué le promete que el equipo todavía no sabía?
El segundo acceso
La tarjeta C mostró un segundo acceso a las 4:10 por el mismo formulario. Escribe la línea exacta del post-mortem que explicaría por qué ese segundo acceso fue posible, distinguiéndola de la causa del primero.
Maersk y NotPetya, 2017
En junio de 2017, un programa llamado NotPetya, que se presentaba como ransomware pero en realidad destruía lo que tocaba sin forma de devolverlo, se propagó por empresas de todo el mundo. La naviera danesa Maersk perdió en pocas horas casi todos sus computadores y servidores, incluido el sistema que guardaba quién podía entrar a qué en toda la empresa. Sus equipos buscaron una copia sana de ese sistema en todas sus oficinas, y la única que encontraron estaba en Ghana: un corte de luz había dejado ese servidor desconectado justo antes del ataque. Mientras se reconstruía todo a partir de esa copia, los puertos siguieron funcionando con procedimientos a mano (Wired, “The Untold Story of NotPetya”). Fíjate en que nadie diseñó la copia de Ghana: existió por suerte, y el plan de continuidad de cualquier organización seria intenta que esa suerte no haga falta. Las dos piezas que salvaron a Maersk son las dos que viste en clase: una copia que el ataque no pudo alcanzar, que es lo que la regla 3-2-1 busca a propósito, y una forma de seguir operando a mano mientras el sistema no estaba, que es lo que un plan de continuidad escribe de antemano.
Equifax: la respuesta
Qué le pasó a Equifax ya lo viste en la clase 02: una falla con parche disponible desde marzo de 2017, explotada entre mayo y julio, con datos de cerca de 148 millones de personas expuestos. Lo que importa para esta clase es lo que vino después. La empresa descubrió la brecha internamente en julio y no la hizo pública sino hasta septiembre, casi dos meses después. En ese intervalo, un directivo de la compañía que sabía de la brecha vendió sus acciones antes del anuncio, y la comisión de valores de Estados Unidos lo acusó de uso de información privilegiada (SEC, comunicado 2018-40). Para las personas afectadas, esos dos meses fueron tiempo en el que sus datos estaban en manos de otros sin que nadie les dijera que tomaran precauciones. Para la empresa, la venta de acciones convirtió una falla técnica en una pregunta sobre la honestidad de quienes la dirigían, y eso es lo que un mensaje tardío produce: quien lo lee ya no se pregunta solo qué pasó, sino qué más le ocultaron. Puesto al lado de Maersk, el contraste está en la fase que falló: Maersk perdió casi toda su infraestructura y se recuperó porque tuvo una copia y una forma de operar a mano; Equifax conservó su infraestructura y agravó la pérdida de los datos con la comunicación.
Lectura disponible — Conceptos clave
| Término | Definición |
|---|---|
| Evento | Algo observable que quedó registrado en un sistema y que todavía no se ha confirmado como incidente |
| Incidente de seguridad | Evento que, confirmado por quien tiene autoridad para hacerlo, compromete o pone en peligro inmediato la confidencialidad, integridad o disponibilidad de un sistema |
| Severidad | Nivel de urgencia que una organización asigna a un incidente según la criticidad del sistema, los datos involucrados y el número de afectados; se revisa a medida que llega información |
| NIST SP 800-61 | Guía de respuesta a incidentes de NIST; su revisión 2 (2012) define el ciclo de cuatro fases y su revisión 3 (2025) lo integra al CSF 2.0 |
| Contención | Impedir que el daño siga creciendo: a corto plazo sin destruir lo que permite entender el ataque, a largo plazo mientras se prepara la limpieza |
| Erradicación | Quitar la causa del incidente y todo lo que el atacante dejó, antes de volver a operar |
| Recuperación | Volver a operar con normalidad, desde un respaldo, desde el sistema limpiado o desde uno nuevo |
| RTO | Tiempo máximo aceptable para restaurar un servicio después de una interrupción |
| RPO | Cantidad máxima aceptable de datos que se pueden perder en un incidente, medida en tiempo |
| Plan de respuesta | Documento que define procedimientos, roles y comunicaciones para gestionar incidentes |
| Plan de continuidad de negocio | Documento que define cómo sigue funcionando la organización mientras el sistema no está: qué se hace a mano, con qué formatos y hasta cuándo |
| Continuidad de negocio | Capacidad de mantener operaciones esenciales durante y después de un incidente |
| Comunicación de crisis | Comunicación planeada por momentos durante un incidente, que dice lo que se sabe, lo que no se sabe y qué debe hacer quien la recibe |
| Regla 3-2-1 | Tres copias de los datos, en dos tipos de almacenamiento, una fuera del lugar y desconectada de la red |
| Análisis post-mortem | Revisión estructurada después de un incidente para identificar causas sistémicas y lecciones aprendidas, sin buscar culpables |