Comienza el ataque

El sonido de un nuevo correo electrónico parpadeó en la pantalla de Cora. Era otra alerta de Core Audit, y no era la primera del día. Pero tomó un vistazo rápido a las SQL y la adrenalina la despertó. Sintió como si le hubieran inyectado cafeína directamente en el cerebro. Esto no es un falso positivo, es un ataque. Alguien está ejecutando con éxito un ataque de inyección SQL a través de la aplicación y en la base de datos.

Cora Blue es un DBA en el equipo de seguridad y entendió exactamente lo que estaba pasando. Esa es la primera etapa del ataque, ya que el intruso está intentando determinar si la aplicación es vulnerable y reunir información sobre el tipo de base de datos y las tablas que contiene. Hasta ahora, es probable que sólo sea un script recopilando información, pero dependiendo de lo bueno que sea este atacante, pronto se convertirá en una brecha de datos. Podría llevar días, a veces horas, pero en el peor de los casos, pueden pasar unos minutos antes de que empiecen a filtrar datos: no hay tiempo que perder.

Deteniendo la brecha

Cora sabe lo que tiene que hacer. Aunque desconectar la aplicación probablemente sea suficiente en este caso, la política exige cerrar tanto la aplicación como la base de datos. Como miembro senior del equipo de seguridad, tiene los permisos necesarios para hacerlo. Más vale prevenir que curar, y unos minutos más tarde, todo está fuera de línea. Mientras los sistemas se desconectan, envía un mensaje al grupo de notificación. Eso llegará al equipo de respuesta y a todos los que necesiten saberlo.

Cuando se reunió el equipo, Cora pudo echar un vistazo a la información forense de la auditoría central. Parece que los hackers todavía estaban en la fase de descubrimiento, y no se llevaron nada. Encontró el servidor de aplicaciones del que procedía el ataque y la hora, y a partir de los SQL, incluso pudo adivinar el área comprometida de la aplicación: la primera parte del SQL es el código original con la tabla y las columnas de la consulta original.

Ahora que todo el equipo está en una reunión de Zoom hay dos objetivos inmediatos. Conseguir que la aplicación y la base de datos vuelvan a estar en línea de forma segura es importante, ya que el servicio de asistencia probablemente ya esté recibiendo llamadas (menos mal que formaban parte de la cadena de notificación). Pero lo más apremiante es cómo entraron en la red, si siguen dentro y qué más hay que hacer de inmediato para detener este ataque en seco.

El pequeño equipo de respuesta incluye a Cora Blue, que identificó el suceso y es también la experta en bases de datos del equipo. Brandon Reese, el administrador de sistemas sabelotodo. Randall Shield, que controla la red. Y Audrey Cortez, que representa a la alta dirección.

¿Qué fue lo que pasó?

Cora explica rápidamente lo sucedido: un ataque de inyección SQL afectó a la base de datos a través del servidor de aplicaciones CBR002 a partir de las 14:35, pero el servidor de aplicaciones y la base de datos se cerraron antes de que se tomara algo. Audrey la felicita por su diligencia y rápida respuesta. No es la primera vez que el equipo se reúne y todos saben que Audrey puede hablar un rato. Pero también saben que no le importa que la interrumpan, sobre todo cuando el tiempo es oro, y antes de que pueda continuar, Brandon la interrumpe de manera cortés compartiendo su pantalla en la que muestra un grep de los registros de Apache.

Los registros muestran claramente el rápido disparo de las peticiones HTTP que causaron la inyección SQL y la IP que las envió. Parece que el ataque provino del rango de IP de la VPN. Mientras Brandon continuaba en Core Audit para ver las pantallas forenses de auditoría de aplicaciones, Randall, el administrador de red, encontró la asignación de IP DHCP que mostraba que el ataque procedía del ordenador personal de Holly Ackerman, la asistente administrativa de uno de los vicepresidentes.

Unos segundos más tarde, Brandon también encontró el ataque en el análisis forense de Core Audit, confirmando que se trataba del inicio de sesión de Holly en la aplicación. Aunque nadie del equipo conoce bien a Holly, no parece tener muchos conocimientos informáticos y probablemente nunca haya oído el término SQL Injection. Alguien debió apoderarse de su ordenador personal y utilizarlo para lanzar el ataque.

Se neutraliza la amenaza

En cualquier caso, el equipo desactiva la cuenta de Holly y la desconecta de la VPN. El equipo de asistencia técnica la llamará para explicárselo, el equipo de seguridad empezará más tarde a investigar su ordenador y el equipo de Windows acabará ayudándola a reinstalarlo. Brandon envía un breve correo electrónico de actualización al grupo de notificación de infracciones que pondrá todo en marcha.

El equipo cree que en este punto el ataque está prácticamente contenido. Necesitan ver si el usuario de Holly se utilizó en algún otro lugar, poner la base de datos en línea, encontrar el problema en la aplicación y averiguar cómo ponerla en línea de forma segura. También tienen que investigar la PC de Holly para averiguar cómo entró alguien, aunque probablemente sólo hizo clic en el correo electrónico equivocado.

El día no ha terminado, pero parece que han evitado lo peor.

¿Cómo lo lograron?

Repasemos algunos de los puntos clave que hicieron de esta historia un éxito para el equipo de seguridad.

En primer lugar, a pesar de una brecha del perímetro que probablemente era inevitable, contaban con una solución IDS de base de datos que reconoció el acceso anómalo a los datos y envió una alerta. Sin esa alerta, esta historia habría sido muy diferente. Pasarían meses antes de que se enteraran del ataque, y probablemente sólo como resultado de una notificación de las fuerzas de seguridad. El equipo de respuesta estaría entonces analizando una violación de datos de meses de duración, tratando de determinar cuántos sistemas se vieron comprometidos y a quién debían notificar que sus datos habían sido robados.

En segundo lugar, Cora Blue, una DBA con conocimientos y formación en ciberseguridad, recibió la alerta. Sabía qué buscar y reconoció el ataque. También disponía de información forense sobre la actividad de la base de datos que le permitía actuar de inmediato. Sin una solución como Core Audit, no hay información forense sobre cada SQL ni forma de determinar lo que ocurrió en la base de datos.

También había políticas sencillas que indicaban a Cora cómo responder, y ella tenía los permisos necesarios para actuar y detener el ataque en seco.

El equipo se reunió rápidamente, era lo suficientemente pequeño como para operar con eficacia y contaba con personas bien informadas con acceso a todos los sistemas. El equipo se había reunido muchas veces y tenía una buena relación de trabajo. Tampoco era la primera vez que intentaban responder a un ataque, ya que todos sabían exactamente qué hacer.

Todo puede salir bien cuando se reciben las alertas, se dispone de información de apoyo y se cuenta con personas con talento y formación que saben lo que tienen que hacer.