Mes de la Ciberseguridad (4/4): ¿y si ya ha pasado?

Último lunes de octubre y última entrega. Hemos visto lo que tienes, cómo te van a engañar y por dónde va a entrar.

Hoy la pregunta que nadie quiere formular en una reunión: ¿y si ya ha pasado?

La serie

1. El inventario
2. El factor humano
3. La cadena de suministro
4. El día después ← estás aquí

Un simulacro: fuego de verdad, emergencia de mentira, y el ensayo hecho el día que no pasaba nada. Foto: Armada de EE. UU., dominio público, vía Wikimedia Commons.

Los primeros veinte minutos

Las peores decisiones de un incidente se toman en los primeros veinte minutos. Siempre.

Porque en esos veinte minutos hay tres o cuatro personas nerviosas, nadie sabe todavía qué está pasando, alguien de dirección está preguntando cada dos minutos si ya está arreglado, y la reacción instintiva de cualquier técnico es la peor posible: apagar y reiniciar.

Vamos con los tres errores clásicos, por orden de frecuencia:

Apagar la máquina. Se pierde toda la memoria RAM, que es donde vive la mayor parte de la evidencia útil: procesos, conexiones abiertas, a veces las propias claves de cifrado del ransomware. Aislar de la red no es lo mismo que apagar. Desconecta el cable; no toques el botón.

Restaurar el backup inmediatamente. Encima del sistema comprometido, sin saber cuándo entraron. Si llevaban tres semanas dentro, acabas de restaurar una copia que ya estaba comprometida, y además has borrado las huellas de cómo entraron. Ahora tienes el mismo problema y menos información.

Cambiar todas las contraseñas a lo loco. Antes de saber si el atacante sigue dentro. Si sigue, le acabas de avisar de que le has visto, y lo que hacen cuando se sienten descubiertos es acelerar: cifrar, borrar, exfiltrar lo que puedan.

La regla de esos veinte minutos es una sola: aislar y documentar antes que reparar. Y la única forma de cumplirla con gente nerviosa es tenerlo escrito de antes.

El folio

No hace falta un plan de respuesta de cuarenta páginas que nadie va a leer. Hace falta un folio, impreso, que esté accesible sin acceso a los sistemas. Y sí, impreso: si el incidente te tumba el correo y la intranet, un plan que vive en la intranet no existe.

El folio contesta cinco preguntas:

1. ¿Quién manda? Un nombre y un suplente. Durante un incidente hay una sola persona que decide, y no es la que más grita. Sin esto, cuatro personas hacen cuatro cosas contradictorias a la vez.
2. ¿A quién se llama? Teléfonos móviles: responsable técnico, dirección, asesoría legal, proveedor de hosting, seguro de ciberriesgo si lo hay, e INCIBE (017). Móviles, no extensiones internas.
3. ¿Qué se apaga y en qué orden? Decidido en frío. Qué se puede desconectar sin cargarse otra cosa.
4. ¿Dónde están los backups y quién sabe restaurarlos? Con nombres. Si esa persona está de vacaciones en agosto, ¿quién más sabe?
5. ¿Quién habla? Con clientes, con empleados y con prensa si toca. Una sola voz.

Se escribe en dos horas. Se revisa una vez al año. Es lo más rentable que vas a hacer en tu vida en materia de seguridad.

El reloj legal: 72 horas

Y ahora la parte que convierte esto de problema técnico en problema del consejo de administración.

Si hay datos personales de por medio —y los hay: tienes clientes, tienes empleados—, el RGPD obliga a notificar la brecha a la Agencia Española de Protección de Datos en un plazo máximo de 72 horas desde que se tiene conocimiento, salvo que sea improbable que suponga un riesgo para los derechos de las personas afectadas.

Tres matices que se pasan por alto constantemente:

• El reloj arranca cuando te enteras, no cuando lo resuelves. No hay que esperar a tenerlo todo claro: se puede notificar de forma escalonada, con la información disponible.
• Si el riesgo para los afectados es alto, también hay que avisar a las personas, no solo al regulador.
• Si tu proveedor sufre la brecha, la obligación de notificar sigue siendo tuya. Por eso decía la semana pasada que en el contrato tiene que estar escrito en cuántas horas te avisa él a ti. Si tu proveedor tarda cinco días, tú ya has incumplido.

Que quede claro el orden de magnitud: la sanción por no notificar puede ser mayor que el daño del incidente. Y la posición «no lo notificamos, a ver si no se entera nadie» tiene un historial de éxito francamente pobre.

La copia de seguridad que no has restaurado nunca

Esto lo dije en el post del Día del Sysadmin y lo voy a repetir aquí porque es el punto donde más empresas descubren, en el peor momento, que no tenían lo que creían tener:

Un backup que no has restaurado no es un backup. Es una hipótesis.

Los tres fallos que aparecen justo el día del incidente:

• La copia estaba en la misma red, montada como unidad accesible, y el ransomware la cifró también. Hace falta al menos una copia fuera de línea o inmutable.
• La copia se hacía, pero de la carpeta equivocada. Nadie lo comprobó nunca porque el proceso terminaba en verde.
• La copia era correcta pero nadie había medido cuánto tarda en restaurarse. Y resulta que son 40 horas. Cuarenta horas de empresa parada no es un plan de recuperación: es un plan de cierre.

La regla clásica sigue siendo la buena: 3-2-1. Tres copias, en dos soportes distintos, una de ellas fuera. Y le añado el número que falta, que es el importante: restaurada al menos una vez, con cronómetro.

Lo que de verdad se mide

Al final, la madurez en seguridad de una empresa no se mide por si le pasan cosas. A todo el mundo le pasan cosas.

Se mide por tres números:

Los tres se mejoran con lo mismo: preparación previa. Ninguno se mejora comprando un producto en mitad del incendio.

Cierre del mes

Cuatro lunes y un resumen que cabe en cuatro frases:

1. Sabe qué tienes. El inventario es la base de todo lo demás.
2. No pongas a las personas de última defensa. Pon procedimientos.
3. Vigila lo que enchufas. Tu seguridad es la del más flojo de tu lista.
4. Prepárate para el día que falle. Porque va a fallar.

Ninguna de las cuatro requiere comprar nada. Todas requieren dedicarles un rato en frío, que es exactamente el rato que nunca hay.

Por eso existe un mes al año para recordarlo.

Y por eso, el 30 de noviembre, cuando llegue el Día de la Seguridad Informática, volveremos a hablar del tema. Nos vemos allí.