Cuando algo ya ha salido mal

Todo lo anterior se trato de prevenir. Esta leccion trata de la otra mitad, que es lo que separa un pasatiempo de seguridad de un trabajo de seguridad: lo que ocurre entre el momento en que algo sale mal y el momento en que termina. Es una leccion de proceso mas que tecnica, y el proceso es la parte que falla con mas frecuencia bajo presion, porque la accion correcta suele ser la que se siente menos decisiva. Un post-mortem es la parte del proceso que abarata el siguiente incidente, y solo funciona si las personas dicen la verdad. La culpa y la verdad compiten directamente: la primera pregunta de una investigacion que busca un culpable es si alguien va a aportar informacion despues. El sustituto de la culpa no es la vaguedad, es una pregunta distinta. En lugar de preguntar quien ejecuto el comando equivocado, pregunta que hizo que el comando equivocado pareciera correcto, y que habria hecho imposible el resultado equivocado en vez de solo desaconsejarlo. Una accion de seguimiento que dice ten mas cuidado no es una accion de seguimiento. Una que dice que el script de despliegue ahora se niega a ejecutarse contra produccion sin una bandera de confirmacion explicita si lo es, porque no depende de que alguien recuerde nada. El mismo incidente redactado dos veces. Solo la segunda version produce acciones de seguimiento que sobreviven al contacto con una semana ocupada. El resumen honesto es que la prevencion y la respuesta fallan de maneras distintas. La prevencion falla porque un control en el que creias no resistio, y suele fallar en silencio. La respuesta falla por las cosas que hacen los humanos bajo presion, y falla ruidosamente: reiniciar la maquina que contenia la evidencia, borrar el host porque los sintomas cesaron, restaurar un backup tomado despues de que empezo la intrusion, o escribir un informe que garantiza que nadie reporte el siguiente. La conclusion incomoda es que el resultado de un incidente lo decide menos la sofisticacion del atacante que el hecho de que la organizacion hubiera escrito y practicado lo que haria.

La primera etapa, y la mas dificil, es darse cuenta. Un evento es cualquier cosa observable; una alerta es un evento que alguien decidio que merecia atencion; un incidente es una alerta que alguien decidio que era real. Cada una de esas conversiones puede fallar. Los registros que nunca se revisan son decoracion. Las alertas que se disparan cuatro mil veces al dia entrenan a todos para ignorarlas, lo que es peor que no tener ninguna alerta, porque ademas elimina la suposicion de que alguien esta mirando. La leccion practica es que la capacidad de deteccion no es la cantidad de herramientas sino la cantidad de senales que un humano realmente va a mirar. Todo lo que sigue en esta leccion no esta disponible para una organizacion que no resolvio esta etapa, porque no puedes contener lo que no notaste. Panorama aproximado de la industria sobre cuanto tiempo pasan las brechas sin ser detectadas. La variacion entre organizaciones es mucho mayor que la variacion entre anos. Una alerta necesita tres cosas para ser util: una descripcion de lo observado, contexto suficiente para juzgarlo y una accion definida. Una alerta que solo dice que ocurrio algo anomalo es peor que el silencio, porque consume atencion y no devuelve nada. La linea base es lo que hace posible el contexto. No puedes afirmar que un inicio de sesion a las 03:14 es inusual si no sabes como se ve una hora normal en esa cuenta, lo que significa que el trabajo util empieza mucho antes del incidente, cuando alguien decide que registrar.

$ sudo dd if=/dev/sda1 of=/mnt/evidence/disk.img bs=4M conv=noerror,sync
$ sha256sum /mnt/evidence/disk.img | tee /mnt/evidence/disk.img.sha256

$ date -u +"%Y-%m-%dT%H:%M:%SZ" | tee -a /mnt/evidence/chain-of-custody.txt

# every later look works on a copy, never on the original
$ cp /mnt/evidence/disk.img /tmp/work.imgCapturar una imagen de disco e iniciar una cadena de custodia. El hash es el punto central: es lo que te permite afirmar despues que la copia no fue alterada.

Un incidente es un evento que amenaza o viola la politica, la confidencialidad, la integridad o la disponibilidad. Una brecha es un tipo especifico de incidente: aquel en el que alguien que no debia tener los datos efectivamente los accedio o los tomo. La distincion no es pedanteria, cambia lo que haces. Una campana de phishing en la que nadie hizo clic es un incidente sin brecha, y la respuesta es bloquear al remitente y avisar a las personas. Un bucket mal configurado que estuvo publico una semana es potencialmente una brecha aunque nada tecnico se rompiera, y la respuesta implica averiguar si alguien lo leyo. Confundir ambos casos hace que las organizaciones reaccionen de mas ante el ruido o de menos ante una exposicion real.

La contencion detiene el dano. La erradicacion elimina la causa. La restauracion devuelve el servicio. Son tres objetivos distintos y con frecuencia se ejecutan como uno solo, y ahi empieza el problema. El instinto bajo presion es reiniciar, reinstalar y restaurar, porque asi los sintomas desaparecen. Una reconstruccion que empieza antes de que entiendas como entro el atacante produce una maquina limpia y un misterio permanente, y si la via de entrada no se cerro, la siguiente compilacion queda comprometida de la misma manera. El orden importa, y tambien importa la disposicion a mantener una maquina comprometida aislada y en funcionamiento un tiempo en lugar de borrarla de inmediato. Las tres etapas y la accion que cada una tiene permitido tomar. Observa que la preservacion ocurre dentro de la contencion, antes de que la erradicacion borre la maquina. Restaurar desde un backup es una respuesta excelente a una falla de hardware y una respuesta peligrosa a una intrusion. La pregunta que lo decide no es que tan bueno es el backup, sino cuando llego el atacante respecto de cuando se tomo el backup. Si el backup se hizo despues de que empezo la intrusion, cualquier mecanismo de persistencia instalado puede seguir dentro, y restauraras el compromiso junto con los datos. Esta es la razon por la que la contencion va antes de la restauracion: necesitas entender lo suficiente de la linea de tiempo para elegir un punto de restauracion anterior a la primera senal de entrada, y necesitas haber cerrado la via de entrada antes de volver a poner algo en linea. La evidencia tiene una vida util, y se agota en el orden opuesto al que la mayoria espera. Todo lo que esta en memoria, en un proceso en ejecucion, en una conexion de red o en un archivo temporal desaparece en el momento en que la maquina pierde energia o se reinicia. Todo lo que esta en disco sobrevive a un reinicio pero no a una reinstalacion. Todo lo que esta en un almacen central de log sobrevive a ambos, si ya se habia enviado alli, que es la razon por la que el log centralizado es un control forense y no solo una comodidad operativa. Las primeras acciones de una respuesta son por lo tanto casi mecanicas: anotar la hora actual, capturar lo volatil antes de que desaparezca y solo entonces empezar a decidir que hacer con la maquina. La regla que se sigue de esto es corta y es la que la gente rompe mas a menudo en los primeros cinco minutos: no reinicies. Un reinicio limpia la memoria, corta las conexiones de red, detiene los procesos en ejecucion y sobrescribe parte del estado que necesitabas, y el atacante puede haber dejado una entrada de arranque que el reinicio activa. Si la maquina debe aislarse, desconecta la red en lugar de la alimentacion. Esto es poco intuitivo precisamente porque apagar y encender es la respuesta correcta a casi cualquier otro problema informatico.