El primer paso en respuesta a incidentes es pensar ante cada circunstancia indeseable, cuál es el plan a ejecutar en cada caso.
Por ejemplo, al encontrar un hallazgo de Amazon GuardDuty que nos reporta minería de bitcoins, o conexiones hacia IPs maliciosas de control remoto (Command & Control) desde instancias de Amazon EC2, como acción de respuesta definimos cambiar los security groups de las instancias agregándole un security group que no permite conexiones salientes, y solo permite conexiones entrantes de acceso remoto (SSH/RDP) desde la IP que tiene la estación de trabajo del equipo de investigación forense.
Se recomienda establecer los escenarios sobre los que deberían tomar acción, definirlo, documentarlo (runbooks: procedimientos / playbooks: procesos de investigación), y probarlo a través de ejercicios (table-top) para probar si el equipo (blue team) sabe responder acorde a los lineamientos corporativos.
Tener documentado el plan ayuda a que cuando el recurso más calificado en respuesta a incidentes no se encuentra disponible (por ejemplo si está de vacaciones), el personal mas junior pueda responder de un modo similar, siguiendo las instrucciones del recurso más calificado.
Un plan de respuesta no ejercitado, es igual a un backup que nunca tuvo una prueba de restauración… uno no sabe si realmente funcionara adecuadamente hasta no probarlo.
A continuación comparto algunos recursos, complementarios para ayudar con ideas sobre hallazgos y sus runbooks.
https://d1.awsstatic.com/whitepapers/aws_security_incident_response.pdf
https://github.com/aws-samples/aws-customer-playbook-framework