En la lección anterior, al analizar la brecha de la consultora y al responder a la del proveedor de correo, necesitaste dos veces algo que Nimbus todavía no tiene: un cuaderno de bitácora, un equipo con roles, una decisión sobre a quién se comunica y en qué plazo, y una secuencia acordada de antemano. Vuelve por un momento a la tabla de las primeras 72 horas de 02-06: día 20, 09:00, Marta convoca al equipo y nadie sabe qué hacer primero. ¿Desconectar? ¿Avisar a los clientes? ¿Llamar a quién? Ese vacío no lo llena ni el mejor registro de riesgos ni el catálogo de controles más completo. Lo llena un documento escrito antes, ensayado y accesible cuando todo lo demás está cifrado. Esta lección es ese documento: el equipo, la matriz de severidad, la preservación de evidencias, las disyuntivas reales de la contención, las plantillas de comunicación, los runbooks y el post mortem.

1. Por qué el plan se escribe antes: evento, incidente y crisis
2. El ciclo de respuesta del NIST SP 800-61
3. Preparación: el 80 % del resultado
4. Clasificación y severidad
5. Detección y análisis, y la preservación de evidencias
6. Contención: las disyuntivas reales
7. Erradicación y recuperación
8. Comunicación: la mitad del trabajo
9. El cuaderno de bitácora
10. Runbooks por escenario
11. El post mortem sin culpables
12. Ejercicios de mesa

A las tres de la mañana, con la agenda de 40 clínicas parada y un teléfono que no deja de sonar, nadie improvisa bien. La capacidad de razonar con calma se desploma justo cuando más falta hace, y las decisiones de esos primeros minutos —apagar un servidor, borrar un fichero sospechoso, contestar a un periodista— condicionan todo lo demás, incluida la posibilidad de saber después qué ocurrió. El plan no sirve para tener respuestas geniales: sirve para que las decisiones importantes ya estén tomadas cuando llegue el momento de ejecutarlas.

La diferencia entre incidente y crisis no es de tamaño técnico, es de quién tiene que estar en la sala. Un incidente lo gestiona el equipo técnico con un responsable; una crisis exige a la dirección, probablemente asesoría jurídica y comunicación, y decisiones que no son técnicas —notificar, pagar o no pagar, hablar o no hablar públicamente—. Escalar tarde de incidente a crisis es uno de los fallos más caros y más frecuentes.

Dos observaciones sobre el diagrama. La primera: la preparación es el 80 % del resultado. Todo lo que se puede hacer en frío —decidir quién manda, tener los teléfonos, saber dónde están los registros, haber probado una restauración— multiplica la eficacia de las otras tres fases; lo que no esté hecho antes, no se improvisará durante. La segunda: la flecha de vuelta de contención a detección no es decorativa. En un incidente real se descubren cosas nuevas constantemente —un segundo servidor comprometido, una cuenta más—, y cada hallazgo obliga a reevaluar el alcance. Un equipo que da por cerrado el análisis demasiado pronto contiene la mitad del problema y deja al atacante dentro.

Cuatro funciones, siempre con suplente, porque el incidente ocurrirá en agosto:

Tres reglas del equipo. Quien ejecuta no decide: Lucía no debe estar valorando si se avisa a los clientes mientras aísla un servidor; separar las dos funciones evita el error clásico de que la persona más ocupada tome las decisiones más importantes. Una sola voz hacia fuera: si tres personas responden a los clientes, habrá tres versiones y una de ellas será errónea. Y el documentador no hace nada más: parece un lujo en una empresa de 38 personas, pero sin él nadie recordará a las 48 horas qué se hizo a las 04:12.

El plan no puede vivir solo en el sistema que puede estar cifrado. En 02-06 el atacante alcanzó la cuenta cloud, los buckets y las copias; si el plan, los teléfonos y los runbooks hubieran estado únicamente en la suite ofimática corporativa, el equipo se habría quedado sin plan justo cuando lo necesitaba.

Nimbus no tiene capacidad forense propia y no debe fingir que la tiene. Lo que sí puede tener, y cuesta poco, es un acuerdo de retención firmado antes con un proveedor forense: negociar precio y condiciones el día del incidente es lento y caro. Lo mismo con la asesoría jurídica y con el contacto de la aseguradora, cuyo teléfono debe estar en la tarjeta impresa porque, como viste en 04-01, muchas pólizas obligan a notificar en un plazo corto y a usar sus propios peritos. En cuanto a preparación técnica, lo mínimo viable: registros centralizados fuera de las máquinas que registran, con retención de 90 días en caliente y un año en frío; un usuario de solo lectura para investigar sin modificar; una máquina limpia de análisis; y las credenciales break-glass probadas al menos una vez al año. Y la formación mínima: que todo el equipo sepa dos cosas —cómo se declara un incidente y a quién se llama— y que Lucía e Iván hayan ejecutado al menos un runbook en un ejercicio de mesa.

Tres reglas de clasificación que evitan discusiones inútiles. Ante la duda, se escala: bajar la severidad después cuesta un correo, subirla tarde cuesta días de permanencia del atacante, y nadie será reprendido por haber declarado un S2 que resultó ser un S3. La severidad se revisa continuamente: el incidente de 02-06 empezó como «una incidencia de rendimiento» que Rubén atendía como S4, y la severidad de entrada casi nunca es la definitiva. Y la incertidumbre sobre el alcance sube la severidad, no la baja: «no sabemos si salieron datos» se trata como S1 hasta demostrar lo contrario, precisamente porque no poder determinar el alcance fue el problema central del día 22 en 02-06.

Cinco fuentes, ordenadas de mejor a peor. La alerta propia es la ideal y la que Nimbus casi no tiene (04-03). Un empleado avisa a menudo, y con qué rapidez depende por completo de que reportar no se castigue (POL-04 5.3.1). Un cliente, que fue la vía de detección en 02-06, veinte días tarde. Un aviso externo de un investigador, del CERT nacional o de un proveedor. Y el propio atacante, con la nota de rescate o el correo de extorsión: la peor forma posible de enterarse.

La disciplina más valiosa de las primeras horas es separar hechos de hipótesis en el cuaderno de bitácora, explícitamente, porque en un incidente real las suposiciones se convierten en hechos por repetición: alguien dice «parece que entraron por la VPN», media hora después es «entraron por la VPN» y dos horas después se está reconstruyendo la VPN mientras el atacante sigue dentro por otro sitio.

Toda acción de contención destruye información: apagar una máquina borra la memoria, reiniciar un contenedor elimina el sistema de ficheros efímero y rotar una credencial impide ver qué más hacía. De ahí la regla —capturar primero, actuar después— siguiendo el orden de volatilidad, en el que lo que antes desaparece se recoge antes.

Cuatro decisiones del script que son de método, no de programación. No apaga la máquina, porque apagarla destruye la evidencia más valiosa y, con algunos ransomware, puede empeorar el estado del cifrado. Recoge en un volumen externo, no en el disco comprometido, para no sobrescribir espacio no asignado. Calcula hashes, porque una evidencia sin integridad verificable es discutible ante un seguro o un tribunal. Y documenta la cadena de custodia: quién la recogió, cuándo, con qué método y dónde está. Cuándo parar y llamar a un forense: Detén cualquier manipulación adicional y llama al retenedor si: hay indicios de exfiltración de datos personales; el atacante ha tenido acceso administrativo; hay ransomware; el incidente puede acabar en reclamación judicial, denuncia o parte al seguro; o simplemente no sabes qué estás mirando. El instinto de «voy a investigar un poco más» es comprensible y es exactamente lo que destruye las evidencias que después hacen falta para determinar el alcance —y sin alcance no se puede notificar con precisión, que fue el atolladero del día 22 en 02-06—.

La contención busca detener el daño sin destruir la información que hace falta para entender el alcance, y se divide en dos: la contención a corto plazo, con medidas inmediatas para parar la hemorragia —aislar la máquina de la red manteniéndola encendida, bloquear una IP, deshabilitar una cuenta, cortar una integración—, y la contención a largo plazo, que permite seguir operando mientras se erradica: levantar un entorno limpio en paralelo, añadir reglas de filtrado, restringir funcionalidad no esencial. Las tres disyuntivas que hay que haber pensado en frío:

Y el catálogo de decisiones típicas de contención en Nimbus, con lo que hay que saber de cada una:

Erradicar es eliminar la presencia del atacante y la causa que le permitió entrar: cerrar la vulnerabilidad, eliminar la persistencia detectada en el paso 4 del script, retirar las cuentas y claves que creó y corregir la configuración que lo hizo posible. Aquí aplica la regla más importante del apartado: ante la duda, reconstruir en vez de limpiar. Si un servidor ha tenido a un atacante con privilegios administrativos, no puedes demostrar que lo has limpiado del todo; solo puedes demostrar que has creado uno nuevo. En Nimbus esto es especialmente barato porque la infraestructura es contenedores y despliegue automatizado: reconstruir desde la imagen y el código verificados es más rápido que auditar un sistema sospechoso, y termina con certeza en lugar de con esperanza. Naturalmente, reconstruir solo sirve si no reintroduces la vulnerabilidad: primero se erradica la causa, después se reconstruye. Y para volver a producción hacen falta cinco condiciones, escritas para que la presión comercial no las acorte: causa raíz identificada y corregida; sin indicios de persistencia; credenciales potencialmente expuestas rotadas; datos restaurados verificados (04-06); y monitorización reforzada durante al menos dos semanas, porque los atacantes vuelven, y vuelven por el mismo sitio si nadie lo cerró.

Nota de validación. El plazo de 72 horas para notificar una brecha de datos personales a la autoridad de control, la obligación de comunicar a los afectados, la denuncia ante las fuerzas de seguridad y las implicaciones de pagar un rescate —que puede tener consecuencias legales según la jurisdicción, la identidad del atacante y la normativa de sanciones internacionales— son cuestiones jurídicas. Nimbus no las decide en la sala de crisis: las consulta con asesoría jurídica y con el responsable de cumplimiento desde la primera hora. El detalle de las obligaciones se trata en 06-03.

Cinco reglas de redacción que esta plantilla aplica: no prometer lo que no se sabe —«sus datos están seguros» sin haberlo verificado es la frase que después destruye la credibilidad—; decir explícitamente qué no se sabe todavía, porque la incertidumbre comunicada genera más confianza que la certeza falsa; dar acciones concretas al cliente, lo que reduce llamadas y le devuelve algo de control; comprometer una fecha para la siguiente comunicación y cumplirla aunque no haya novedades; y un único canal de contacto, para que el soporte no colapse ni aparezcan versiones distintas.

Un registro cronológico, escrito en el momento y no reconstruido después, de todo lo que se observa y se decide. Importa por tres razones: permite el análisis posterior con datos reales en vez de recuerdos; sostiene la defensa jurídica y la reclamación al seguro, que preguntarán cuándo se supo y cuándo se actuó; y evita trabajo duplicado cuando entra gente nueva al incidente a las doce horas.

La última regla no es cortesía: la bitácora puede acabar leída por un abogado, un perito o un cliente, y una frase como «esto pasó porque Lucía nunca revisa nada» convierte un documento técnico en un problema añadido.

Un runbook es el procedimiento paso a paso para un escenario concreto, escrito para que lo ejecute alguien con estrés y sin tiempo de pensar. Estructura mínima: escenario, indicadores de activación, severidad inicial, roles, pasos numerados por fase, criterios de cierre y errores conocidos.

El escenario más probable en Nimbus, porque no requiere ninguna vulnerabilidad técnica.

El post mortem sin culpables (blameless) es la reunión de análisis posterior cuyo objetivo explícito es entender el sistema, no evaluar a las personas. Su premisa: si un error humano ha podido causar un incidente grave, el problema no es la persona, es el sistema que permitió que un error individual tuviera esa consecuencia. Cómo se dirige, en cuatro reglas: se convoca entre 3 y 7 días después, ni antes —falta información— ni mucho después —se pierde el detalle—; la persona más involucrada en el fallo cuenta la historia, sin interrupciones ni juicios; se prohíben las frases con «debería haber» y se sustituyen por «qué información faltaba para tomar otra decisión»; y no asiste nadie con capacidad disciplinaria sobre los participantes, o no habrá honestidad.

(1) ¿Por qué se cifraron los datos y las copias? Porque un atacante obtuvo control administrativo de la cuenta cloud (A-05). (2) ¿Por qué obtuvo ese control? Porque encontró una credencial de A-05 en un fichero .env del servidor de aplicaciones. (3) ¿Por qué llegó a ese servidor? Porque entró con la cuenta compartida de la consultora, sin MFA y con acceso permanente. (4) ¿Por qué existía ese acceso permanente sin MFA? Porque se concedió en 2023 como excepción operativa y nadie volvió a revisarlo: no había caducidad, ni revisión periódica, ni requisito contractual. (5) ¿Por qué no había revisión ni requisito? Porque no existía ningún proceso de gestión de riesgo de terceros: ni evaluación previa, ni cláusulas, ni revisión de accesos.

Causa raíz: ausencia de un proceso de gestión de accesos de terceros con revisión y caducidad. Fíjate en dos cosas. Primera: la causa raíz no es «el atacante» ni «Lucía dejó un .env»; es un proceso que no existía, que es justo lo que se puede arreglar. Segunda: los cinco porqués producen una cadena, pero un incidente real tiene varias. Aquí hay al menos dos más que merecen su propio análisis: por qué se tardó 20 días en detectar y por qué las copias eran destruibles. El método se aplica una vez por cada cadena, no una vez por incidente.

El apartado de acciones correctivas es el único que importa dentro de seis meses, y por eso cada acción lleva propietario y fecha, y se sigue hasta el cierre en la revisión mensual de riesgos de 04-01. Un post mortem cuyas acciones no se cierran es un ejercicio de escritura: el incidente volverá con otro nombre.

Un ejercicio de mesa (tabletop) es una simulación conversada: se reúne al equipo dos horas, se plantea un escenario y se pregunta «¿y ahora qué haces?», sin tocar ningún sistema. Es la forma más barata de probar el plan, y encuentra siempre los mismos huecos: nadie sabe quién decide, el teléfono del forense no está, el runbook menciona un sistema que ya no existe, o todo el mundo asume que otro estaba avisando a los clientes.

Tres formatos con distinto coste y valor: el repaso del plan en reunión (30 min, coste nulo, trimestral), el ejercicio de mesa propiamente dicho (2 h, coste muy bajo, semestral) y el simulacro técnico de un runbook —restaurar de verdad—, que ocupa media jornada, tiene coste bajo-medio y se hace una vez al año (04-06).

Guion mínimo para uno de dos horas: se presenta el escenario en tres inyectos sucesivos —el aviso inicial, un giro a los 30 minutos («un cliente ha publicado el incidente en redes») y una complicación a los 60 («la persona que decide está en un avión»)—; se documenta cada decisión en una bitácora real; y se termina con la lista de huecos encontrados, cada uno con propietario y fecha, igual que un post mortem. Si el ejercicio no genera acciones, no se hizo bien.

• No tener plan, o guardarlo solo donde puede estar cifrado. El día 20 a las 09:00 nadie sabía qué hacer primero. Consejo: un plan de una página con roles y teléfonos vale más que un manual de 60 que nadie ha leído, y debe existir en papel y en el móvil de dos personas, con un canal de emergencia distinto del corporativo.
• Apagar la máquina por instinto, o cambiar la contraseña antes de exportar los registros. Lo primero destruye la memoria y puede empeorar el cifrado; lo segundo pierde el rastro y deja viva la sesión robada. Consejo: aislar de red manteniendo encendido, capturar antes de contener y revocar siempre las sesiones.
• Comunicar de más o de menos. Prometer que los datos están seguros sin saberlo destruye la credibilidad; el silencio la destruye igual. Consejo: comunica lo que sabes, di lo que no sabes y compromete la próxima actualización.
• No escalar por miedo a exagerar, o investigar «un poco más» antes de llamar al forense. Consejo: escribe que escalar de más nunca se reprocha, define por escrito los cinco criterios de parada del apartado 5.3 y respétalos.
• Post mortem con culpables. Garantiza que el próximo incidente se oculte. Consejo: sin nadie con capacidad disciplinaria en la sala y con acciones sobre el sistema, no sobre personas.

Clasifica cada situación en S1-S4, justifica el nivel e indica las tres primeras acciones en orden:

1. Sara informa de que introdujo sus credenciales corporativas en una página que imitaba el portal de nóminas. Ocurrió hace 20 minutos.
2. El escaneo externo mensual detecta que el puerto 5432 vuelve a estar abierto a Internet tras la migración de la semana pasada. No hay evidencia de acceso.
3. Una clínica avisa de que, al abrir la ficha de un paciente suyo, ve el nombre de un paciente de otro centro.
4. Rubén reenvía un correo de phishing genérico que fue bloqueado por el filtro y que ningún usuario abrió.

A las 03:40, Lucía detecta un proceso desconocido consumiendo CPU en el servidor de aplicaciones. Actúa así:

Identifica todos los errores, indica qué información se ha perdido irreversiblemente y reescribe la secuencia correcta con horas plausibles.

Aplica los cinco porqués a esta cadena del incidente de 02-06 que no se analizó en el apartado 11.1: «El día 20, cuando se intentó restaurar, no había ninguna copia utilizable». Identifica la causa raíz y redacta tres acciones correctivas con el formato del apartado 8 de la plantilla, indicando para cada una el riesgo del registro de 04-01 con el que enlaza.

Ejercicio 1

1. Phishing con credenciales entregadas: S3, que sube a S2 según el alcance de la cuenta de Sara. Sara gestiona administración y RRHH, así que tiene acceso a nóminas y datos de empleados (A-16) y probablemente a facturación: eso lo empuja a S2. Primeras acciones: (a) abrir bitácora y exportar los inicios de sesión de su cuenta antes de tocar nada; (b) revocar todas las sesiones activas, restablecer la contraseña y forzar nuevo segundo factor; (c) revisar reglas de reenvío, delegaciones y aplicaciones OAuth de su buzón. Es literalmente RB-01. Y una cuarta acción no técnica pero obligatoria: agradecerle el aviso, porque avisó en 20 minutos y eso es lo que convierte un desastre en un incidente menor.

2. PostgreSQL reexpuesto: S3. No hay evidencia de acceso, pero es un servicio crítico expuesto a escaneo automatizado permanente, así que no puede esperar al día siguiente. Acciones: (a) cerrar el grupo de seguridad de inmediato —la contención es trivial y no destruye evidencia—; (b) revisar los registros de conexión de PostgreSQL en la ventana de exposición para descartar accesos, y si los hubiera, escalar a S1; (c) abrir la causa raíz: por qué la migración reintrodujo la regla, que es un caso de deriva de controles de 04-03 y debe corregirse en el proceso de despliegue, no solo en el grupo de seguridad.

3. Un cliente ve datos de otro: S1. Es un fallo de aislamiento entre tenants, es decir, una brecha de confidencialidad de datos que revelan salud, y aunque el origen sea un error de programación y no un ataque, el impacto es el mismo. Acciones: (a) preservar evidencia: capturar la petición exacta, el usuario, la hora y el registro de auditoría asociado; (b) determinar el alcance —¿es un caso aislado o llevan meses viendo datos ajenos?—, lo que se hace consultando la tabla de auditoría de C-07; (c) contener, desactivando la funcionalidad afectada si el alcance no está acotado en la primera hora, y activar en paralelo la consulta con asesoría por el reloj de las 72 h. El error típico aquí es tratarlo como un bug de la cola de trabajo en vez de como un incidente de seguridad.

4. Phishing bloqueado: S4. No hubo impacto: se registra, se comprueba si otros usuarios lo recibieron y se usa como insumo para la formación (06-05), sin consumir al equipo de respuesta.

Ejercicio 2

Errores, y lo que cada uno destruyó:

Secuencia correcta:

Ejercicio 3

Cinco porqués. (1) ¿Por qué no había copia utilizable? Porque las copias fueron borradas por el atacante el día 20 a las 02:10 y la única alternativa era un disco externo de hacía cinco semanas. (2) ¿Por qué pudo borrarlas? Porque residían en la misma cuenta cloud que producción y eran accesibles con las mismas credenciales administrativas. (3) ¿Por qué estaban ahí? Porque se configuraron buscando comodidad operativa y coste, sin modelar el escenario de un atacante con credenciales de administración. (4) ¿Por qué no se detectó esa debilidad antes? Porque no existía evaluación de riesgos ni catálogo de controles que preguntara «¿qué pasa si el atacante tiene las credenciales de administración?». (5) ¿Por qué nadie supo que la copia de cinco semanas tampoco servía? Porque nunca se había probado una restauración: no se conocía ni su integridad ni el tiempo que llevaría.

Causa raíz: la estrategia de copias se diseñó contra el fallo técnico —un disco que se rompe— y no contra el adversario, y su eficacia nunca se verificó.

Observa que las tres acciones son una preventiva, una de verificación y una detectiva, aplicando la regla de 04-03 de cubrir varias funciones. Y observa también que la número 2 no añade ninguna protección nueva: solo comprueba que la número 1 funciona. Sin ella, dentro de un año Nimbus volvería a tener copias en las que cree.

Has escrito el plan antes del incidente, que es la única forma de que sirva, porque a las tres de la mañana nadie improvisa bien y las decisiones importantes deben estar tomadas de antemano. Distingues evento, alerta, incidente y crisis, sabiendo que la diferencia entre incidente y crisis no es de tamaño técnico sino de quién tiene que estar en la sala, y que escalar tarde es uno de los fallos más caros. Conoces el ciclo del NIST SP 800-61 con sus dos lecciones: la preparación es el 80 % del resultado y el análisis se reabre cada vez que aparece un hallazgo nuevo, porque cerrar el alcance demasiado pronto deja al atacante dentro. Tienes el equipo de respuesta de Nimbus con titulares y suplentes y sus tres reglas —quien ejecuta no decide, una sola voz hacia fuera, y el documentador no hace nada más—, los contactos fuera de banda en papel y en un canal distinto porque el plan no puede vivir solo en el sistema que puede estar cifrado, el retenedor forense y el contacto legal firmados en frío, y la matriz de severidad de cuatro niveles con la regla de que ante la duda se escala y de que la incertidumbre sobre el alcance sube la severidad. Sabes hacer triaje separando hechos de suposiciones por escrito, para que una hipótesis no se convierta en certeza por repetición. Y dominas lo que más incidentes arruina: preservar evidencias antes de tocar nada, con el orden de volatilidad, un script de recolección que no apaga la máquina, escribe en volumen externo, calcula hashes y documenta la cadena de custodia, y los cinco criterios para parar y llamar a un forense. Conoces las disyuntivas reales de la contención —aislar ya frente a observar, que cortar avisa al atacante y puede acelerar la destrucción como el día 20, y por qué no se apaga—, y en la erradicación, la regla de reconstruir en vez de limpiar cuando hubo privilegios administrativos, con las cinco condiciones para volver a producción con monitorización reforzada.

Te llevas las plantillas: el comunicado a clientes con sus cinco reglas de redacción —no prometer lo que no se sabe, decir qué no se sabe, dar acciones concretas, comprometer la siguiente comunicación y un único canal—, la nota interna, el cuaderno de bitácora con sus reglas de escritura, el runbook completo de compromiso de credenciales con sus errores conocidos y el esquema de otros tres, y el informe post mortem cuyo apartado de acciones correctivas es el único que importa dentro de seis meses. Y te llevas el método del post mortem sin culpables aplicado a 02-06, con la causa raíz que no es «el atacante» ni una persona, sino la ausencia de un proceso de gestión de accesos de terceros con revisión y caducidad, más el recordatorio de que un incidente tiene varias cadenas causales y cada una merece su análisis. Cierran la lección los ejercicios de mesa, la forma más barata que existe de descubrir que el teléfono del forense no está y que todos asumían que otro avisaba a los clientes. Pero repasa el ejercicio 3 y verás lo que falta. Las tres acciones correctivas de la causa raíz de las copias —inmutabilidad en cuenta separada, prueba de restauración trimestral, alerta de borrado— no son respuesta a incidentes: son otra disciplina. El plan de respuesta te dice cómo actuar cuando la agenda de 40 clínicas está parada, pero no cuánto tiempo puede estar parada antes de que el negocio no lo resista, ni cuántos datos se puede permitir perder, ni cómo siguen atendiendo Rubén y las clínicas mientras el sistema no vuelve, ni cuánto tarda realmente una restauración que nadie ha cronometrado.

En la última lección del módulo, Recuperación ante Desastres y Continuidad de Negocio (04-06), responderás a eso: la diferencia entre BCP y DRP, el análisis de impacto en el negocio, RTO y RPO fijados desde el BIA y no desde el deseo, las estrategias de copia con la regla 3-2-1-1-0 desarrollada dígito a dígito, la prueba de restauración como corazón de la lección —porque una copia no verificada no es una copia—, el escenario ransomware que rompe los planes clásicos, la alta disponibilidad que no es copia de seguridad, el orden de arranque por dependencias y los procedimientos manuales de emergencia.