Durante la noche, se retiró dinero de la cuenta de la empresa. Por la mañana, entró en pánico, lo que provocó más problemas. Por ejemplo, los departamentos de TI reinstalan sistemas comprometidos, comenzando desde cero o restaurando desde copias de seguridad. En el primer caso, se borraron los rastros del intruso, dejando al equipo de investigación de incidentes visitante con poco más que un pequeño esfuerzo y una larga búsqueda de artefactos en otros sistemas. En el segundo caso, existe el riesgo de restaurar una imagen dañada. En esta publicación, discutiremos las principales trampas que dificultan una respuesta competente y rápida a los piratas informáticos.
Error #1 - Falta de un plan de afrontamiento
El dinero de una empresa fue robado. Sólo tiene software antivirus. La gerencia no nos permitía cerrar servidores y cuentas porque no sabían qué impacto tendría en el negocio. Pasamos días tratando de averiguar quién era el dueño de las computadoras que fueron pirateadas y cuál era su papel en la empresa, mientras que los piratas informáticos podrían estar vaciando cajeros automáticos, retirando dinero o robando datos. Además de responder a los incidentes, hay una serie de cuestiones organizativas. Es diferente si una empresa tiene registro, gestión básica de activos y comprensión de los procesos comerciales. Esto permite a los empleados de la empresa detectar a los piratas informáticos en la red en medio de un ataque y, para nosotros, si ocurre un incidente, el problema se puede abordar de inmediato sin perder un tiempo valioso. Este enfoque mejora en gran medida la eficacia de las investigaciones de incidentes y potencialmente evita repercusiones graves.
El propósito del plan de respuesta es eliminar los factores inesperados cuando ocurre un evento y considerar tomar medidas para minimizar la pérdida. Es importante evaluar la idoneidad de los medios técnicos para recopilar y almacenar los datos necesarios para la investigación de accidentes. También es necesario comprender la experiencia de los equipos internos en la investigación de incidentes. Si no se dispone de experiencia en investigación, se debe buscar experiencia externa.
El plan de respuesta también especifica los roles de los responsables dentro de la empresa en caso de un incidente. El departamento de TI recopila datos relacionados con el incidente. La gerencia, el departamento legal o de relaciones públicas (o todos juntos) son responsables de tratar con el mundo exterior. Necesitan saber en qué evento (datos de clientes robados, dinero, etc.) y a quién deben notificar (cliente, regulador, autoridad).
En ciertos sectores (banca, infraestructura crítica), los incidentes de seguridad de la información deben ser informados a los reguladores. Otras compañías deben comunicarse con las compañías de seguros, lo que también debe decirse, las demoras pueden costarles a las víctimas la oportunidad de presentar un reclamo de seguro. Todos estos deben discutirse con un abogado y un investigador de incidentes de antemano.
Para evitar facturar a la empresa la mitad por cada virus detectado, se deben segmentar los incidentes por nivel de amenaza e importancia de los nodos afectados. Por ejemplo, si se encuentra software espía en la computadora de un contador, esa es la alarma número uno. La lista de verificación debe incluir todas las actividades potenciales que un usuario malicioso podría realizar en él: malversación de fondos, falsificación de credenciales, autorización en banca remota, instalación de herramientas ocultas para la administración remota de computadoras, copia de claves de firma electrónica del usuario, etc. Lo que sigue es una investigación completa y una comprensión de hasta dónde ha llegado el hacker. Esto indicará qué contramedidas son posibles y en qué etapa. En el caso de un contador, esto podría ser: cambiar la clave de un sistema bancario remoto, bloquear las transacciones de la cuenta, reemplazar la computadora del contador con una computadora limpia conocida o bloquear el acceso a la red. El mismo plan debe implementarse para las estaciones de trabajo de los directores ejecutivos, gerentes senior, empleados de base y otras clases de activos.
Los investigadores que detectan sistemas con actividad sospechosa a menudo pasan días o semanas averiguando dónde está realmente la computadora, quién es su propietario, cuál es su función en el proceso empresarial y qué tiene de malo desactivarla o recopilar datos. Es el trabajo de los equipos de TI e IS aclarar esto desde el principio. Hay momentos en que un sistema está en el departamento de contabilidad y simplemente no descartan una estación de trabajo porque se está pagando y deja de funcionar. Para los sistemas críticos, sin los cuales la empresa no puede funcionar, el departamento de TI debe tener computadoras de repuesto listas. Pero a menudo estos no están disponibles, lo que retrasa la investigación. Durante este tiempo, los atacantes pueden retirar fondos o robar datos de la empresa.
Las dependencias planificadas deben verificarse regularmente a través de pruebas de penetración. El infiltrado se infiltró en la computadora del contador y analizamos las amenazas que podría llevar a cabo. Los anotamos en el plan y luego, cuando ocurre un evento real, verificamos si el intruso llevó a cabo esas amenazas. También puede elegir un escenario de ataque virtual para el entrenamiento realizando un ejercicio de simulación. Especifique un escenario posible: una computadora es pirateada, ocurre un incidente de virus con un criptógrafo o se roba dinero. El siguiente paso es probar la funcionalidad del plan de respuesta: haber localizado a todos los propietarios del sistema, haber descubierto la posible secuencia de acciones relacionadas con el activo y tener a todos los actores involucrados en el proceso. Es como en la vida real, pero este enfoque evita consecuencias graves y detecta las debilidades que deben abordarse temprano.
Las instrucciones paso a paso pueden ser para incidentes conocidos, como ataques de phishing o infecciones de criptoransomware. Sin embargo, si no es posible una clasificación específica de actividad sospechosa, generalmente es necesario saber
a) en qué parte de la red se ve afectado el activo,
b) ¿Qué se puede hacer con estos activos?
c) quién es responsable de ellos,
d) planes de comunicación dentro de la empresa y con el mundo exterior,
e) Cómo aislar la amenaza.
No se puede exagerar la importancia de la planificación, ya que los eventos siempre ponen a prueba la fortaleza de una empresa y aquellos que no están preparados pagarán un alto precio, incluida la pérdida de negocios. La realidad es que ningún negocio hoy en día es completamente defendible, por lo que los eventos le sucederán a todos tarde o temprano, y es mejor que esté preparado para ello. Después de todo, un plan bien pensado convierte el caos y la crisis en un algoritmo de acción claro y preciso.
Error n.º 2: incidentes de seguridad de la información que no se investigan.
Una empresa reinstaló el sistema operativo en una computadora infectada, marcó la casilla "incidente cerrado" y perdió una gran suma de dinero de la cuenta una semana después. Esto sucede con bastante frecuencia: no podemos limitarnos a medias tintas. Debe comprender cómo los atacantes se infiltraron en la red, reconstruir la línea de tiempo de los eventos y determinar las medidas para contener y neutralizar la amenaza. De lo contrario, aún puede haber nodos infectados a través de los cuales procederá el ataque.
Error n.º 3: falta de infraestructura de recopilación de eventos
La infiltración de las redes corporativas puede haber ocurrido hace mucho tiempo sin dejar rastros. Como cualquier sistema operativo, Windows recopila eventos, pero almacena los datos localmente y por un tiempo limitado, a menudo solo hasta que se reinicia el sistema operativo. La situación es aún peor con los dispositivos conectados, que suelen tener una capacidad de memoria pequeña para almacenar eventos. Esto hace que sea imposible saber si una computadora en particular se conectó a un servidor malicioso hace tres meses.
En nuestra encuesta, solo una o dos de cada diez empresas tenían infraestructura de recopilación de eventos, y SIEM a menudo era una chuchería. Nadie dentro de estas empresas verifica que el SIEM recopila los datos en el formato correcto. Como los integradores lo implementaron, lo dejaron ahí. Los datos pueden almacenarse durante un día o una semana y no utilizarse para nada.
Los equipos de TI utilizan sistemas de monitoreo y recopilación de registros como parte de sus trabajos. Dicho sistema también es eficaz y puede utilizarse en las investigaciones.
Los requisitos mínimos para la recopilación de eventos incluyen la recopilación de datos de los sistemas operativos y dispositivos de red (cortafuegos) y el almacenamiento de esta información durante al menos un año. Esto le permitirá comprender qué nodos están conectados y dónde.
Almacenar esta información también es útil para detectar eventos basados en nueva información. Luego, al usar herramientas de análisis retrospectivo, puede descubrir si la empresa ha sido atacada en el pasado. Esto permitirá que se tomen medidas ahora, en lugar de dentro de un año cuando la información confidencial aparezca repentinamente en la web oscura en el momento más inoportuno, como antes de que una empresa se haga pública.
Es imposible obtener datos del pasado sin una infraestructura para la captura de eventos. Además, ahorra tiempo: no tiene que analizar docenas, cientos y, a veces, miles de computadoras. Sin embargo, por supuesto, es mejor utilizar una solución IS dedicada y configurada correctamente. Cuando las herramientas de recopilación de incidentes están disponibles, como un sistema SIEM configurado correctamente, pueden ayudar a identificar incidentes, reconstruir cronogramas y encontrar puntos de entrada para los atacantes. Con un sistema de este tipo, los eventos microscópicos individuales pueden ensamblarse en un mosaico.
Error #4 - Falta de información de activos
En el mejor de los casos, encontramos descripciones de qué componentes componen el sistema empresarial, quién es responsable de él y qué tareas resuelve. Más a menudo, es peor. En la mayoría de las empresas, la gestión de activos no existe en absoluto o la información sobre los activos es irrelevante. Observa documentos de hace tres años y describen una configuración de red única cuando, de hecho, la red se ha duplicado en tamaño. En tales casos, no es posible una respuesta rápida y eficaz a los incidentes.
En un nivel básico, la gestión de activos no requiere una gran inversión. Después de todo, los atacantes a menudo conocen la infraestructura de una empresa mejor que TI y no utilizarán sistemas engorrosos. Dedican tiempo a estudiarlo, averiguando qué funciona, cómo funciona, qué procesos se ejecutan, quién está conectado a quién y cómo monitorear.
Hay algunas soluciones técnicas para facilitar las cosas, pero en general se trata de procesos. Una empresa necesita comprender sus procesos comerciales, y cómo rastrear todas sus computadoras, en Excel o automáticamente con un SIEM, es una cuestión de elección.
Error #5 - Falta de Documentación
La documentación en este caso es un escenario para el curso normal de la interacción entre departamentos, determinando si, por ejemplo, un contador debe iniciar sesión en la computadora del departamento de TI y el resto debe transferir archivos a través de correo electrónico personal. La documentación técnica que describe cómo interactúa el sistema también es importante. Por ejemplo: la documentación describe un componente para que solo funcione con un módulo, pero en realidad funciona con tres módulos. De lo contrario, especialmente si la persona de TI que lo sabía todo renunció hace mucho tiempo, los investigadores buscarán pistas y eventos sospechosos que no tienen nada que ver con el incidente. Y estas interacciones, históricamente formadas o evolucionadas, se han descifrado en conversaciones con los empleados; por ejemplo, los empleados no tienen otras herramientas para compartir archivos. Esto consume mucho tiempo. Es cierto que sería aún peor si no hubiera personal para ayudar a dar sentido a estas relaciones establecidas.
Error #6 - Manipulación de pruebas
Es un error común intentar investigar un incidente sin la experiencia necesaria. A veces, cuando se intenta crear una imagen de un disco, se hace por error y se borra el disco de pruebas. A veces encontramos puntos críticos en la evolución de un ataque donde el propietario ha reinstalado el sistema, eliminando artefactos críticos para la investigación. En algunos casos, la computadora no se puede apagar mientras se realiza un volcado de memoria, o la información se dañará. Al mismo tiempo, un SIEM no siempre tiene todos los datos que necesita. Además, a menudo no es posible rotar más la cadena sin una copia del historial. Por lo tanto, es imperativo contar con un plan riguroso para tratar adecuadamente con hosts comprometidos, el más importante de los cuales es coordinar todos estos cambios con expertos dedicados al comienzo de la investigación. PT Expert Security Center, en situaciones tan urgentes, trata de intervenir rápidamente en la investigación, a menudo incluso antes de que se llegue a un acuerdo formal.
Error #7 - Burlarse de los intrusos
Los empleados sin la experiencia necesaria pueden intentar bloquear todo sin mirar, o amenazar a los piratas informáticos en sus comunicaciones, sin darse cuenta de la gravedad de la situación. En este caso, es posible que los piratas informáticos comiencen a "quemar puentes", no solo cubriendo sus huellas, sino también comprometiendo a la empresa, por ejemplo, instalando un virus de cifrado en toda la infraestructura por diversión, o "cerrando" un crítico servicio. Debe anticipar lo que harán los atacantes si son descubiertos y estar preparado.
Error 8 - Lección no aprendida
Algunas empresas no aprendieron ninguna lección del incidente. De vez en cuando, hay situaciones en las que investigamos un ataque, establecemos un cronograma, hacemos recomendaciones y el cliente trabaja con nosotros y no hace nada: no se configura un programa de monitoreo, no se aborda una vulnerabilidad. Durante el verano, ayudamos a eliminar las consecuencias del ataque, eliminamos el malware, restablecimos las contraseñas y limpiamos la red. Y en otoño, la situación se repitió. Y los hackers vuelven a la red como si estuvieran en casa. La última vez, una organización gubernamental fue pirateada dos veces. La mayoría de las empresas implementan protecciones después de un incidente, si no inmediatamente. Si una red está constantemente bajo ataque, los departamentos de seguridad no tienen otro mes para corregir la primera vulnerabilidad crítica que se está explotando. Los eventos recurrentes ocurren más rápido.
Error #9 - Alertar al atacante
Si el sistema de correo electrónico está comprometido, el servicio de seguridad de la información maneja las cartas en el correo y el pirata informático puede monitorear todas las contramedidas. O se ocultará, eliminará los rastros y dificultará la investigación, o realizará acciones destructivas (ver error #7) y la compañía ya no tendrá tiempo para investigar. Esto es exactamente lo que sucedió una vez, durante una investigación, un administrador se comunicó con la computadora de nuestro trabajo a través de la versión de escritorio de Telegram. Los piratas informáticos pudieron monitorear los chats y atacar de manera proactiva, lo que complicó una investigación que ya era difícil hasta que la computadora del administrador se vio comprometida y cambiamos el canal de comunicación.
En caso de accidente, es necesario contar con canales de comunicación de respaldo que no estén conectados a la infraestructura de la empresa, usando el mismo Telegram o WhatsApp, pero solo desde dispositivos confiables. Solo sea claro: si toda su red está comprometida, ya no tiene el control y debe pensar en cada paso de su investigación.
Error #10 - Eventos Zombie
Después de la investigación y corrección, es posible que el problema no se cierre. Una imagen comprometida de seis meses de antigüedad se restauró a partir de una copia de seguridad y los atacantes tuvieron el regalo inesperado de restaurar el acceso a la red interna. Esto es raro, pero afecta duramente a las empresas. Por lo tanto, no solo debe prestar atención a su infraestructura actual, sino también a sus sistemas de archivo y respaldo. Durante un período de tiempo, incluso después de que se haya investigado el incidente, es una buena idea estar atento a las señales de daño. Los incidentes zombis ocurren no solo con los sistemas de respaldo, sino también con la llegada de activos que estaban ausentes en el momento de la investigación. Por ejemplo, una persona se va de vacaciones y su computadora no está revisada. O la computadora está en reparación. Se activa una puerta trasera en una computadora y nadie la limpia. En tales casos, una respuesta oportuna solo es posible si se implementa un sistema de monitoreo sólido y se implementan todas las recomendaciones una vez que concluye la investigación.
La tarea principal de investigar un incidente parece simple: llegar al fondo, reconstruir la cronología de los eventos, encontrar la fuente y detener la amenaza. Pero si una empresa no cuenta con la infraestructura mínima para identificar y tratar incidentes, o comienza a responder sin la experiencia adecuada, no necesariamente podrá ayudar. Por lo tanto, es mejor estar preparado con anticipación para enfrentar a los ciberdelincuentes.