Echa un vistazo a este breve cómic sobre un ataque realista y lee las explicaciones a continuación en las que se describen los métodos, se ofrecen estadísticas y se comentan posibles técnicas de defensa.

Análisis y Explicación de los Ataques

Este artículo analiza los tipos de ataques utilizados en los cómics y ofrece estadísticas sobre su popularidad y posibles medidas de defensa. Esta brecha, como cualquier otra, requirió una combinación de varios pasos. Aunque puede que no sea posible detenerlos todos, deberías intentar detener varios y solo necesitas tener éxito en prevenir uno.

BEC y Ataques de Pretexto

Los ataques de pretexto son similares a los de phishing, pero mucho más eficaces. Los ataques de pretexto suelen suplantar la identidad de alguien para generar confianza y tienen un alto índice de éxito en la manipulación de las personas.

Según el DBIR de Verizon, en 2023, el pretexting fue el ataque de ingeniería social más frecuente y eficaz. El Business Email Compromise (BEC) aumenta aún más la eficacia de los ataques y va en aumento.

Credenciales Robadas

El 86% de los accesos iniciales en 2023 utilizaron credenciales robadas (Verizon DBIR). Es uno de los medios más comunes y altamente efectivos de obtener acceso a la organización y es cada vez más difícil de detener a causa de los empleados que trabajan de forma remota.

La MFA (Multi Factor Authentication o Autenticación Multifactor) es una forma de ayudar a combatir las credenciales robadas, pero tiene múltiples limitaciones, como demuestran las altas tasas de éxito de estos ataques.

Contraseñas

Todos los administradores tienen un archivo con las credenciales de los muchos sistemas que administran. Es la única manera de «recordar» docenas de contraseñas seguras.

Si un hacker encuentra la manera de llegar al escritorio de un administrador o a este archivo, puede llegar a cualquier parte que el administrador pueda.

Una bóveda de contraseñas tiene un éxito limitado en la protección de tales credenciales por varias razones, incluyendo porque el acceso al escritorio del administrador comprometerá cualquier sistema al que accedan.

Compromiso de la Base de Datos

Con una contraseña de administrador del servidor o de la base de datos, sólo hay una forma de detener este ataque: la seguridad de la base de datos. Las defensas centradas en los datos, especialmente las defensas de bases de datos, pueden ser muy eficaces.

Esta organización no tenía seguridad de base de datos, por lo que el personal de seguridad no estaba al tanto del ataque y no pudo detenerlo.

En este caso, el atacante robó los datos y los cifró. El ransomware garantizó que la organización descubriera la brecha. Si el atacante hubiera optado sólo por robar, la organización no habría sido consciente del ataque, y seguiría sin saberlo hasta que un tercero descubriera los datos y los cotejara para determinar su origen.

Reflexiones finales

Este ataque utiliza los medios más comunes y más eficaces para una brecha de datos. No utiliza vulnerabilidades de día cero, conocimientos únicos o talento excepcional. Es un escenario muy realista para un ataque con el que te puedes encontrar y probablemente pasará desapercibido.

Es posible que pueda mejorar aún más las defensas perimetrales, pero sigue siendo probable que ataques eficaces como éste tengan éxito. Por eso estos ataques son los más comunes y sobre todo funcionan.

Sin defensas eficaces centradas en los datos para protegerlos, este escenario será probablemente una brecha exitosa. El perímetro es fácil de penetrar, y sólo unas defensas internas eficaces en la aplicación y la base de datos pueden detener estos ataques tan comunes.

Si estás interesado, descarga la guía “Seguridad Perimetral Vs. Centrada en Datos” para obtener más información.

Una reciente campaña masiva de phishing puso al descubierto una vulnerabilidad crítica en Proofpoint, uno de los principales proveedores de seguridad de correo electrónico basada en la nube.

El incidente plantea importantes cuestiones sobre los ataques a la cadena de suministro, la eficacia de la seguridad del correo electrónico y la necesidad de una defensa en capas contra los ataques.

Lo que ocurrió

Los hackers encontraron un exploit en organizaciones que utilizan Office 365 y Proofpoint. El exploit permitió a los hackers enviar correos electrónicos autenticados con firmas digitales idénticas a los correos electrónicos enviados por esas organizaciones. La lista de organizaciones explotadas incluye Disney, Coca-Cola, IBM, Nike, Best Buy y muchas otras.

Utilizando este exploit, los hackers enviaron durante al menos siete meses una media estimada de 3 millones de correos electrónicos al día, con picos que alcanzaron los 14 millones de correos electrónicos diarios. Es decir, entre 500 y 1.000 millones de correos electrónicos de phishing perfectamente falsificados.

Desconocemos el número de tarjetas de crédito, credenciales, identidades y demás información robada por los hackers. Sin embargo, algunos ataques se aprovecharon de los servicios vendidos por las empresas que falsificaban, enviando a los clientes a páginas de compra con cargos recurrentes en sus tarjetas de crédito.

Importancia

Los correos electrónicos autenticados enviados a través de Office 365 y Proofpoint son idénticos a los correos electrónicos enviados por las empresas auténticas, y los clientes no pueden notar la diferencia. Sin embargo, los ataques de phishing suelen embaucar a los clientes sin recurrir a falsificaciones de alta calidad, por lo que el mayor problema es otro.

Estos correos electrónicos tienen tasas de entregabilidad y de envío muy elevadas. Todos los proveedores de correo electrónico y filtros de spam admiten millones de correos electrónicos por minuto de esas organizaciones, y no entran en la carpeta de spam. Esto, unido a su autenticidad, crea potentes ataques de phishing.

Además, muchas organizaciones etiquetan los correos electrónicos externos para alertar a los empleados de posibles intentos de phishing. Estos correos autenticados eludirán estas advertencias, ya que son idénticos a los enviados por la organización. Esto hace que sea muy probable que los empleados sean presa de un ataque de phishing dirigido.

Ataques a la cadena de suministro y servicios en la nube

Los ataques a la cadena de suministro son motivo de gran preocupación, ya que exponen a las organizaciones a amenazas que desconocen y a las que no pueden hacer frente. Los ataques a la cadena de suministro también tienen un potencial aterrador, ya que los piratas informáticos pueden explotar las vulnerabilidades de cualquier organización que recurra a ese proveedor.

El problema de la cadena de suministro aumenta exponencialmente en los servicios basados en la nube. Los piratas informáticos pueden explotar las vulnerabilidades de la cadena de suministro en la nube sin acceder a la red corporativa ni hacer saltar las alarmas. Como demostró este ataque, muchas grandes organizaciones fueron víctimas de un ataque a gran escala del que no tenían conocimiento.

Seguridad del correo electrónico

La seguridad del correo electrónico es casi un oxímoron, y este ataque es otra prueba de nuestra incapacidad para protegerlo. Autenticar y firmar los correos electrónicos con DKIM, SPF y DMARC es beneficioso y valioso, pero es un esfuerzo que no puede evitar ni siquiera los simples ataques de phishing. Mejora las cosas, pero dista mucho de ser perfecto.

Las organizaciones deben aceptar que el correo electrónico es inseguro, que muchos empleados y clientes son presa del phishing y, en consecuencia, que se producen ataques de phishing con éxito de forma regular.

Debemos hacer esfuerzos razonables para proteger el perímetro. Es significativo porque reduce el número de ataques. Sin embargo, no se puede evitar que los intrusos lo penetren y accedan a la red corporativa. Por lo tanto, el aumento de las inversiones en la protección del perímetro tiene rendimientos decrecientes, especialmente los ineficaces como la seguridad del correo electrónico.

Enfoque por capas con defensas centradas en los datos

Dada nuestra limitada capacidad para proteger la red corporativa, debemos aplicar un enfoque de seguridad por capas con defensas centradas en los datos que impidan una violación de los datos cuando un hacker inevitablemente penetre en el perímetro.

Comprendiendo cómo se produce una violación de datos y aplicando una estrategia de seguridad adecuada, las organizaciones pueden reducir significativamente el riesgo de ser víctimas de ataques.

Core Audit es un componente fundamental en la batalla contra las brechas de datos, ya que proporciona la visibilidad y el control necesarios para proteger a su organización contra los ataques y las amenazas emergentes. Póngase en contacto con nosotros para obtener más información, analizar el entorno único de su organización y comprender sus necesidades de seguridad. Permitinos ayudarte a tener éxito.

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.

Encuestas recientes a profesionales de la ciberseguridad muestran que la mayoría de los encuestados (82%) tienen visibilidad parcial o nula de sus bases de datos y la necesitan. Pocos dijeron que tienen buena visibilidad (7%) o que no la necesitan (11%).

Las encuestas se realizaron en diferentes grupos de LinkedIn tanto en inglés como en español y preguntaban “¿Tienes visibilidad de lo que ocurre dentro de tu base de datos?”. Casi todos los encuestados ingleses afirmaron tener una visibilidad parcial (40%) o no tener la visibilidad que necesitan (53%).

En la encuesta en español, hubo más personas que afirmaron tener buena visibilidad (10%) o no necesitarla (13%), pero aún así la mayoría dijo tener visibilidad parcial o no tenerla y necesitarla (47% y 30% respectivamente).

El reto de la visibilidad de la base de datos

Las bases de datos de las que somos responsables, almacenan muchos datos de terceros y de empresas que son muy sensibles, como datos financieros, información personal y mucho más. Es vital que estos datos no se vean comprometidos, filtrados o manipulados, pero no tenemos visibilidad sobre quién accede a ellos, cuándo o cómo.

Sabemos que necesitamos visibilidad. Sin ella, no podemos diseñar controles eficaces y está generalmente aceptada como un paso fundamental en la seguridad: no vueles a ciegas. No se puede controlar lo que no se ve. Entonces, ¿cómo es que es algo de lo que carecen la mayoría de las organizaciones?

Las bases de datos son un reto por el volumen de actividad y los requisitos de rendimiento. ¿Cómo se puede obtener visibilidad de miles de millones de SQL? ¿Cómo puede incluso recopilar la información sin afectar al rendimiento, por no hablar de procesarla y consumirla? ¿Cómo se puede obtener el control y saber cuándo alguien está haciendo algo malicioso cuando hay tanto ruido? Incluso limitando el alcance a los accesos a tablas confidenciales, hay demasiada actividad que comprender.

Y sin visibilidad, ¿cómo puede establecer controles, informes o alertas? ¿Qué hay que tener en cuenta? ¿Cómo sabrá si se ha producido una violación de datos? O si la ha habido, ¿qué ha ocurrido?

Cómo obtener y mejorar la visibilidad

Como ya se ha mencionado, la visibilidad de las bases de datos es un reto debido a su gran actividad y a sus requisitos de alto rendimiento. También es poco probable que pueda conseguirla por sí mismo sin la solución y la tecnología subyacentes adecuadas.

Las herramientas sencillas que se basan en funcionalidades integradas en las bases de datos suelen tener un impacto en el rendimiento y es poco probable que le proporcionen la visibilidad que necesita. Incluso las herramientas caras suelen basarse en tecnologías antiguas que no pueden ofrecer la visibilidad y el valor que usted necesita.

En los últimos años, Core Audit ha introducido importantes avances e innovaciones en este espacio del mercado, incluidas múltiples tecnologías de captura, procesamiento y análisis. Hable con nosotros para obtener más información sobre cómo podemos ayudarle a proteger sus datos.

Conclusión

Hoy en día, necesitamos proteger más datos, más sistemas y enfrentarnos a mayores riesgos como nunca antes. Estos retos son importantes y necesitamos la visibilidad y el control que ofrecen las últimas tecnologías.

Estas encuestas recientes muestran que la mayoría de los profesionales de la ciberseguridad son conscientes de lo importante que es la visibilidad. Sin embargo, la mayoría de las organizaciones siguen estando a la deriva, con una visibilidad limitada o nula de sus bases de datos.

Póngase en contacto con nosotros hoy mismo en marketing@bluecoreresearch.com para obtener más información sobre cómo podemos ayudarle a mejorar la visibilidad de sus bases de datos y proteger su información confidencial.

El motor de análisis de anomalías crea dinámicamente perfiles de comportamiento basados en el repositorio de seguridad para comparar el presente con el pasado. Al contrastar la actividad actual con la histórica, es fácil destacar los cambios de comportamiento que son indicativos de problemas de seguridad.

Esto le permite romper la idea preconcebida de que no puede controlar grandes volúmenes de actividad como la aplicación. El análisis de anomalías le permite detectar la aguja en el pajar para encontrar un único SQL ofensivo entre miles de millones.

¿Cómo funciona?

Como todos los sistemas informáticos, la actividad de las bases de datos es repetitiva, ya que aunque los valores cambian, los patrones persisten. El motor de análisis de anomalías es capaz de mucho más, pero los análisis suelen centrarse en cinco aspectos:

1. Actividad nueva – Algo visto hoy pero no en el pasado. Como un nuevo usuario, programa, SQL, entre otros.
2. Alto volumen de actividad – Actividad que existe ahora y en el pasado pero que ahora ocurre aún más.
3. Hora del día – Actividad que en la actualidad ocurre a una hora diferente al pasado.
4. Dimensiones combinadas – En lugar de un cambio en una sola dimensión (como un nuevo usuario) ocurre un cambio en múltiples dimensiones (como la combinación de un usuario y una IP). Tanto el usuario como la IP podrían ser conocidos, pero ese usuario podría no haber utilizado nunca esa IP.
5. Filtros – Reduzca la búsqueda de anomalías a las áreas de interés, como las tablas sensibles, la aplicación, usuarios concretos, etc. Es probable que diversos subconjuntos de la actividad muestren comportamientos diferentes y se beneficien de otros tipos de anomalías.

Hay muchas formas de seleccionar el tipo de anomalías a utilizar. Podrían ser comportamientos que usted espera, patrones vistos en análisis forenses proactivos, los asistentes de Core Audit, la guía de control de Core Audit, o simplemente prueba y error. Pero una de las características cruciales del motor de anomalías es que puede probar inmediatamente una anomalía y encontrar los resultados. Eso hace que elegir y ajustar estas irregularidades sea un proceso relativamente sencillo.

Ventajas

Inicialmente creamos el motor de anomalías para responder a una petición habitual de los clientes. Al considerar la auditoría declarativa tradicional, algunos clientes solían decir: “No quiero decirle a Core Audit sobre qué informar, quiero que Core Audit me diga qué mirar”.

A medida que la tecnología evolucionaba, ayudaba a proteger subconjuntos de la actividad que antes se consideraban imposibles de controlar. Por ejemplo, para proteger la aplicación con sus miles de millones de SQL.

Las anomalías también han demostrado su eficacia para detectar la inyección SQL e incluso los intentos de inyección. La inyección SQL, inevitablemente, hace que la aplicación haga algo que se supone que no debe hacer, creando así una nueva construcción SQL fácil de identificar.

Hoy en día, las anomalías son una poderosa herramienta para reducir el volumen de informes, asegurando grandes subconjuntos de la actividad con un ratio de falsos positivos relativamente bajo.

Conclusión

El análisis de anomalías es vital para la seguridad moderna, ya que permite hacer más controles con menos recursos, como por ejemplo controlar mayores volúmenes procedentes de más fuentes con menos personal, menos tiempo y un conjunto de habilidades más reducido.

En lugar de revisar informes interminables, las anomalías hacen gran parte del trabajo pesado, indicando rápidamente los problemas potenciales. Aunque no son una solución mágica que lo resuelva todo, las anomalías pueden y deben ser un elemento clave en cualquier estrategia de seguridad.

Hable con nosotros para obtener más información y experimentar la diferencia de Core Audit.

Uno de los mitos populares sobre la seguridad es que se puede obtener de una caja. Basta con instalar algo y ¡voilá! Estás mágicamente protegido. Pero en realidad eso nunca funciona así.

Independientemente de lo que intentes proteger, tu primer paso debe ser siempre comprender la actividad. Debes saber cómo se utiliza el sistema, quién lo utiliza, cómo, etc. Obtener este tipo de visibilidad en un sistema de producción en vivo es fundamental para averiguar cómo protegerlo.

Visibilidad

No se puede proteger lo que no se ve.

Aunque es importante, obtener visibilidad de los sistemas informáticos no es sencillo, y  resulta cada vez más difícil para los sistemas que procesan grandes volúmenes de actividad. Las bases de datos pueden procesar miles de SQL cada segundo, por lo que toda esta actividad es imposible de entender sin las herramientas adecuadas.

Core Audit es una solución de seguridad integral que incluye, entre sus muchas capacidades, la posibilidad de realizar investigaciones forenses proactivas. Éstas le darán una idea de lo que está ocurriendo en su base de datos. Es el primer paso que recomendamos a la hora de configurar su seguridad.

Una vez que sepa lo que ocurre, podrá diseñar informes eficaces, configurar alertas que tengan sentido, definir análisis prácticos de anomalías, etc.

Beneficios Adicionales

El análisis forense proactivo no se limita a configurar la seguridad, sino que es esencial para identificar las lagunas en las medidas de seguridad. A medida que la actividad evoluciona, debemos ajustar los controles para adaptarlos a los nuevos patrones de actividad, y es imposible hacerlo sin visibilidad. De lo contrario, tus controles quedarán gradualmente desfasados y, con el tiempo, obsoletos.

El análisis forense proactivo también permite identificar malas prácticas de seguridad. Personas que comparten cuentas, que se conectan desde ubicaciones inseguras, que descargan tablas de la base de datos, etcétera. Aunque no se trate de una violación, estas prácticas populares aumentan su exposición y hacen más probable una filtración de datos.

Conclusión

Hay muchas razones para revisar regularmente la actividad de la base de datos, pero la razón subyacente puede ser que necesitamos incluir a las personas en el proceso de seguridad. Independientemente de los informes, alertas o automatizaciones que creemos, una revisión humana periódica puede detectar fácilmente comportamientos y necesidades de seguridad que una máquina nunca detectaría.

Hable con nosotros para obtener más información y pruebe Core Audit para comprobar la diferencia.