Un buen plan de respuesta a incidentes implica roles clave, planes y guías específicos, y acciones bien ensayadas con una comunicación clara y precisa. Los mejores planes de respuesta a incidentes son aquellos escritos a lápiz, bien revisados ​​y profundamente familiares para quienes necesitan estar en primera línea de respuesta. Hay algunos aspectos cruciales en cualquier plan de respuesta a incidentes; el primero es la evaluación. Haga un inventario de lo que ha sucedido. Es esto un falso positivo? ¿Se ha visto comprometido el sistema o es sólo un intento? Es necesario comprender lo que ha sucedido y lo que está sucediendo para saber qué hacer al respecto. A nivel técnico, esto a menudo se reduce a los registros: asegurarse de contar con registros sólidos en todos los sistemas es un «hallazgo» muy común de las empresas que han sufrido recientemente un ciberataque mientras revisan el incidente en retrospectiva. Podrías pensar que haces un buen registro. Ponlo a prueba. El siguiente elemento de un plan de respuesta a incidentes es la contención. Al igual que responder a una emergencia de salud pública, es necesario comprender el origen y aislar la infección. Si un atacante ha violado sus sistemas, identifique esos puntos de acceso y elimínelos de Internet. Bloquear la comunicación con sus servidores de comando y control. A menudo es más fácil decirlo que hacerlo, pero este paso del proceso separará a las organizaciones maduras de las poco preparadas. Los errores ocurren y, como hemos visto en los últimos años, las tácticas de phishing y de ingeniería social siguen siendo muy efectivas, incluso en organizaciones seguras como los principales proveedores de identidad. La clave es la rapidez con la que se pueda detener la marea de daños. El tercer elemento de un buen plan de respuesta a incidentes es formar el equipo que se encargará de la respuesta. A veces se trata de personal específicamente dedicado con RI como su única responsabilidad, y otras veces se trata de personal autorizado para desempeñar una función de RI cuando se produzcan incidentes. Ambos están bien, siempre y cuando el equipo esté preparado y tenga buena práctica en sus funciones. Una parte fundamental de esto es la identificación de un líder de respuesta a incidentes, un gerente único que es el único que toma las decisiones para el incidente y está facultado por el liderazgo técnico para actuar rápidamente. Esto ayuda a garantizar que no haya dudas en términos de autoridad para tomar decisiones difíciles, ya que a menudo es necesario tomarlas en situaciones en las que el tiempo es muy crítico y las líneas jerárquicas normales no funcionan. Una vez que tenga su equipo, con un líder de gestión de incidentes dedicado, haya evaluado la situación y haya contenido el brote, lo siguiente será la recuperación ante desastres. Para las organizaciones con las que trabajo, recomiendo ejecutar tantos procesos de copia de seguridad/recuperación automatizados como sea posible; por ejemplo, cada semana tenga una tarea automatizada que tome una aplicación web, cree una nueva versión a partir del código fuente, ponga en marcha la infraestructura asociada, copie el base de datos desde una copia de seguridad y luego se inicia, con el tráfico apuntado al nuevo sistema. Desde una perspectiva de desarrollo de software, aquí es donde entra en juego la infraestructura como código. Desea poder tener estos planes escritos en gran medida en código y poder ejecutarlos de forma regular con informes de ejecución y (con suerte) métricas de éxito para compartir con el liderazgo técnico superior. Una de las partes de un plan de respuesta a incidentes que más a menudo se pasa por alto es su práctica. Con demasiada frecuencia, las organizaciones elaboran planes, pero lo hacen con equipos que solo se ocupan de la recuperación ante desastres o la gestión de riesgos. Luego, esos planes se mantienen en un silo lejos de los equipos que realmente necesitan implementar el plan cuando surge un incidente. Y seamos realistas, con la creciente frecuencia de ataques y casos de compromiso, necesitamos cambiar nuestra mentalidad de «si ocurre un compromiso» a «cuando ocurra un compromiso». Reconocer que se producirá un compromiso es el primer paso hacia una postura de seguridad más sólida y una organización más resiliente. El siguiente paso es elaborar un plan que puedas practicar, y es necesario que lo practiques. Comience con un pequeño plan que cubra lo básico: ¿Cómo maneja las copias de seguridad? ¿Se mantienen en un sistema separado de sus entornos generales de producción y TI? ¿Qué tan rápido puedes restaurar desde estas copias de seguridad cuando surja la necesidad? ¿Has probado eso? Cuando se trata de medir la madurez de una organización a la hora de afrontar incidentes, existe una lección realmente útil que podemos extraer de la disciplina de la ingeniería de confiabilidad del sitio. Existe un concepto llamado «ingeniería del caos», que consiste efectivamente en realizar pruebas deliberadas de fallas en los sistemas para comprender sus puntos de ruptura y reconstruirlos mejor. Los ingenieros probarán la resistencia de grupos de máquinas virtuales o servicios en contenedores derribando intencionalmente algunos de ellos mediante una carga no intencionada o, a veces, un error de seguridad, y verán qué tan bien la red general de sistemas es capaz de reequilibrarse y repararse a sí misma. Podemos aplicar este mismo principio a la respuesta a incidentes. Utilizando este modelo, intente que un equipo diferente al responsable de la recuperación ante desastres proponga algunos fragmentos medidos de “caos” para inyectarlos en su tecnología y ver qué tan bien funciona su plan en la práctica. Estos son más informativos cuando se tiene un enfoque de “sin previo aviso”, lo que significa que los equipos que responden al incidente no saben que se trata de un simulacro hasta que han terminado el trabajo. Esto puede parecer estresante, pero si ya ha realizado prácticas exitosas, este es el siguiente paso lógico que mejorará en gran medida la capacidad de su organización para responder a lo desconocido. Involucrar al liderazgo en las sesiones de práctica de respuesta a desastres puede marcar la diferencia cuando se trata de apoyo de la alta dirección. Es importante involucrar a líderes no técnicos en la planificación de desastres y el trabajo de respuesta a incidentes mediante la realización de ejercicios prácticos o pruebas de planes de respuesta reales. Esta participación directa de la junta les permite comprender la gravedad de la situación, respaldar el plan de acción y asegurarse de que el programa obtenga el apoyo institucional y la financiación que necesita para tener éxito cuando surjan incidentes cibernéticos. Elliott Wilkes es director de tecnología de Advanced Cyber ​​Defense Systems

Source link