La semana pasada me dejé pendiente hablar de respuesta ante incidentes en #ciberseguridad. Vamos a contar algunas cosas :). Lo primero las fases: preparación, detección, análisis, contención, erradicación, recuperación y lecciones aprendidas. Dentro hilo 1/n
La preparación se hace de forma previa a cualquier incidente, y lo ideal es conseguir que tu infraestructura sea capaz de recoger toda la info posible para que luego podamos resolver el incidente. Parece fácil de decir, pero en la realidad poca gente lo tiene 100% 2/n
... y en muchos casos te encuentras con un "logs qué?". Logs del proxy, firewall, IDS/IPS, correo, EventLog, etc ... son fundamentales para los detectives puedan investigar y localizar el problema con rapidez y exactitud.
Consejo: Mete Sysmon en todos tus endpoints, con la config de github.com/SwiftOnSecurit…, y guarda logs de navegación de usuarios (ya sea en el proxy o en el fw). Solo con eso ya tienes el 80% del curro hecho
La detección nos la regalan nuestros compañeros del #SOC (hola majos), pero lo que tenemos que hacer es el análisis inicial: ¿es un incidente de verdad? ¿a qué afecta? ¿cómo de gordo es el marrón? Estas preguntas son claves por si hay q sacar a gente de la cama a las 0400AM...
Luego pasamos a la contención: vuestra org está sangrando, y hay que cortar la hemorragia. Aquí el problema es ajustar: medidas muy duras pueden hacer más daño q bien, medidas muy laxas pueden no ser suficientes
Cuando el "enfermo" ya no se nos muere en el sitio, hay que seguir analizando el problema de #seguridad hasta que lo encontramos, lo comprendemos y le podemos dar una solución. Es lo que llamamos erradicación (tb conocido como "echa a esos cabrones a patadas")
Mucho ojo con la erradicación: el análisis tiene q ser niquelado, pq pasa como con los antibiótico: si no liquidas TODO el problema te resurgirá y más rebotado (los malos andarán sobre aviso y serán más cuidadosos). El cierre tiene que ser preciso y contundente.
Una vez el problema de seguridad está resuelto, toca la recuperación: backups, snapshots, reinstalación de equipos ... todo lo necesario para volver a la normalidad. Consejo: equipo tocado por los atacantes == fuego purificador
Y ... !ojo! Un incidente de #seguridad q se cierra sin saber la causa raíz (el cómo y pq se produjo) ... es un incidente que volverá en un futuro a morderte el culo. Haz todo lo posible por encontrar y tapar esa vía de agua (spoiler: no siempre lo conseguirás y es una putada)
Y nos queda la fase que menos cariño recibe, y posiblemente la más importante: las lecciones aprendidas. Vale, nos hemos llevado un palo, pero ¿hemos aprendido algo? En IR el objetivo es "esta vez me has crujido, pero la próxima vez trae otro truco pq este no te va a funcionar"
Y para eso es fundamental hacer un post-mortem del incidente, repasando lo que se ha hecho mal (y lo que se ha hecho bien tb ojo), la causa raíz y todo lo que se puede hacer para mejorar tanto la #seguridad como la respuesta ante incidentes
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Tú no lo sabes, pero tienes dentro a un grupo de #ransomware que no puede progresar pq has bastionado bien. Están jodidos, pero no son tontos, y en lugar de hacer ruido se han quedado hibernando hasta que salga esa PoC que les permita elevar privilegios y liártela parda 1/n.
El bastionado tan solo te da TIEMPO y OPORTUNIDAD. Un atacante determinado al final encontrará "ese" sistema sin parchear, "ese" fichero con las pass en un .txt... El objetivo del bastionado es denegar/degradar la capacidad del atacante, forzándole a salir de su "zona de comfort"
... y de esa forma obligándoles a hacer cosas q no están acostumbrados. Y ahí entra la pareja del bastionado: La DETECCIÓN. Cuanto más ruido hagan los atacantes, más oportunidades tendremos de detectarlos, pero hay que tener una estrategia de detección con cobertura y profundidad