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.

Introducción

Al considerar las prioridades para el 2024, deben identificarse las brechas críticas entre lo que ya se está realizando y dónde debería estar. Para ayudar a lograrlo rápidamente, creamos una lista de las principales prioridades a abordar.

Una reciente encuesta mostró que aproximadamente la mitad del personal de seguridad incluye entre sus prioridades la automatización y la inteligencia artificial, para que le ayuden a ahorrar tiempo y mejorar la eficiencia. Todas las recomendaciones en las principales prioridades de perímetro y centrado en datos involucran áreas donde la automatización es posible y permiten alcanzar, de manera realista, esas altas eficiencias.

1. Perímetro básico

• Cortafuegos:
  Cualquier cortafuegos básico servirá. El objetivo principal es garantizar que las conexiones entrantes estén bloqueadas, excepto IP y puertos específicos. Estos suelen estar aislados en una zona desmilitarizada para crear una segunda barrera de entrada.
• Antivirus:
  Cualquier antivirus básico servirá. El objetivo principal es reducir el riesgo de virus y diversos programas maliciosos. Ningún antivirus es perfecto y casi todos los antivirus, incluidos los integrados en los sistemas operativos, proporcionan una protección razonable.
• Antispam y DMARC:
  Cualquier sistema de filtro antispam básico funcionará, incluidos los gratuitos integrados en los clientes de correo electrónico. También debe validar las firmas DMARC en todo el correo entrante (tanto SPF como DKIM) y firmar todo el correo electrónico saliente con una política DMARC configurada para rechazar. Esto, por sí solo, reducirá significativamente la carga de spam y el riesgo de suplantaciones.

2. Centrado-en-datos: lineamientos básicos

Esto es algo de lo que carecen muchas organizaciones. Si actualmente no hace esto, debería ser su segunda prioridad. El objetivo centrado-en-datos es defenderse contra ataques que penetran el perímetro poroso antes de llegar a los datos.

• Seguridad de la base de datos:
  Hay muchos aspectos de la seguridad de la base de datos, desde la configuración de permisos hasta el control de cambios, pero dado que la mayoría de las infracciones utilizan cuentas válidas, la medida más eficaz son las alertas sobre actividades anómalas o sospechosas.
• Seguridad de las aplicaciones:
  Existen muchas medidas que incluyen revisiones de código, análisis de vulnerabilidades y más. Sin embargo, la cobertura más amplia en esta superficie de ataque extremadamente grande son las alertas de anomalías y los perfiles de actividad de aplicaciones y usuarios finales.
• Enmascaramiento de datos:
  Esta es la forma más sencilla y eficaz de proteger los datos fuera de producción. Si copia datos de producción a entornos inseguros, debe enmascararlos.

3. Personal

Esto es algo que la mayoría de las organizaciones hacen hasta cierto punto, pero que normalmente pueden mejorar. El objetivo es reducir el riesgo de la mayor vulnerabilidad: las personas. Las dos prioridades anteriores abordan este riesgo, pero es bueno abordarlo de frente.

• Capacitación:
  La capacitación en seguridad de los empleados puede ayudar a reducir el riesgo de un ataque de ingeniería social exitoso. Si bien es imposible reducir este riesgo a un solo dígito, un buen programa de capacitación con ejemplos e interacción del usuario puede ser una inversión que vale la pena. Los programas simples con presentaciones y videos tienen un impacto mínimo y es posible que no valga la pena la inversión.
• Gestión de identidad:
  Si bien los proyectos de IAM pueden ser grandes y costosos, al menos debería tener medidas simples para rastrear al personal, cerrar cuentas innecesarias y tener un control básico de quiénes son sus usuarios y a qué tienen acceso.
• Pentesting:
  Muchas empresas ofrecen escaneos e informes automatizados. Sin embargo, son inútiles cuando se trata de la verdadera vulnerabilidad: las personas. Un verdadero equipo rojo que intente violar la seguridad utilizando cualquier medio, incluida la ingeniería social, le dará una idea mucho mejor de su postura de seguridad. Evite informes sin sentido sobre vulnerabilidades teóricas que no pueden explotarse.

4. Respuestas de análisis forenses

Una vez que haya cubierto sus bases principales, debe pensar en lo que sucede cuando ocurre una infracción o un evento de seguridad.

• Plan:
  Cree un plan de respuesta para manejar varios eventos. Los planes comienzan con quién identificó el evento, cómo se determina la gravedad, cuál es la respuesta inmediata, a quién se debe notificar, cómo se manejan las investigaciones y más. Tenga en cuenta que los eventos pueden ser generados por personal de seguridad, personal de TI o por terceros, como las fuerzas del orden.
• Validar:
  Que el plan sea realista. Muchos planes se basan en información y datos forenses que no existen o que son difíciles de extraer y analizar. Algunos planes suponen que el personal tiene habilidades o que los sistemas de TI tienen capacidades que en la realidad faltan. Revise el plan con el personal adecuado para asegurarse de que cada paso sea realizable.
• Práctica:
  Incluso los mejores planes fracasan cuando las personas no los ejecutan correctamente. Cree eventos realistas y deje que el personal haga su trabajo. Durante el evento, desempeña el papel del atacante, considera sus próximos movimientos e identifica cuándo se da cuenta de que el personal está respondiendo a la intrusión.

5.  Análisis de brechas

Finalmente, debe asegurarse de que todo esté bien implementado, identificar las debilidades y reforzar estratégicamente la seguridad.

• Exploración de vulnerabilidades:
  Las herramientas automatizadas que exploran en busca de vulnerabilidades pueden identificar rápidamente posibles brechas de seguridad. Ya sean sistemas sin parches, configuraciones incorrectas, contraseñas predeterminadas o muchos otros problemas.
• Análisis centrado en datos:
  Como principal y última línea de defensa, las medidas centradas en datos deben ser lo más herméticas posible. El análisis de posibles rutas de ataque puede resaltar los puntos débiles donde la seguridad merece una atención adicional.
• Análisis de sistemas individuales:
  El análisis de la actividad de diferentes sistemas en cada silo es vital para obtener visibilidad del comportamiento en el mundo real. Saber lo que sucede puede ayudar a diseñar e implementar una seguridad más estricta, identificar prácticas de seguridad deficientes y más.

Pensamientos finales

Una estrategia de seguridad equilibrada y bien pensada puede ayudarle a maximizar su postura de seguridad y optimizar su presupuesto. Los puntos anteriores son esenciales para cualquier estrategia, pero cada entorno es diferente y se beneficiará de una asignación de inversión ligeramente diferente. Contáctanos para tener una consulta sin cargo sobre tu estrategia y ver cómo podemos ayudarte a maximizar tu presupuesto.

OpEx Vs. CapEx

Una encuesta reciente mostró que más del 50% de las empresas tienen un presupuesto que es principalmente OpEx (el resto se dividió entre CapEx, Mix y Otros). En LATAM, casi el 80% de las empresas tienen un presupuesto que es mayoritariamente OpEx.

En OpEx las empresas alquilan soluciones y servicios, por lo que cada año pagan por todo. En CapEx, las organizaciones compran productos, por lo que cada año seleccionan proyectos específicos en los que centrarse e invertir. La línea es un poco borrosa ya que incluso en CapEx hay que pagar por el soporte, e incluso en OpEx, las nuevas inversiones toman tiempo para implementarse. Entonces, ¿por qué es importante la distinción?

La flexibilidad de OpEx permite, en teoría, crear una distribución óptima de recursos cada año. Es más caro y puede requerir mucho tiempo, pero puedes redistribuir los recursos más libremente. Eso es parte del atractivo que lo hace tan popular. Por lo tanto, debería aprovechar parte de esa libertad en sus objetivos y planificación presupuestaria. No tienes que hacer el año que viene lo que hiciste el año pasado. Esto plantea la pregunta no trivial de cuál es la distribución óptima de recursos en su organización.

El CapEx también debería comenzar buscando la distribución óptima, pero luego requiere una pregunta adicional sobre cómo llegar allí. El camino puede durar varios años, entonces, ¿cuáles son los mejores proyectos a realizar este año que mejorarán la seguridad más rápidamente?

Primero, debemos considerar OpEx o CapEx: en OpEx alquilamos soluciones y servicios, por lo que cada año pagamos por todo. En CapEx, compramos productos, por lo que cada año tenemos proyectos en los que elegimos centrarnos e invertir. Pero incluso en CapEx tenemos que pagar por el soporte, e incluso en OpEx, tenemos que invertir tiempo en nuevas implementaciones. Entonces, ¿por qué la distinción?

La flexibilidad de OpEx permite, en teoría, crear la distribución óptima de recursos cada año. Es más caro y puede requerir mucho tiempo, pero podemos redistribuir nuestros recursos con mayor libertad. Eso significa que debemos ejercer esta libertad en nuestra planificación y objetivos. Entonces la pregunta importante es: ¿cuál es la distribución óptima de recursos en nuestra organización?

CapEx también debería comenzar preguntando cuál es la distribución óptima, pero luego agregar otra pregunta sobre cuál es el mejor camino para llegar allí. ¿Qué proyectos mejorarán la seguridad más rápidamente para que mejoremos nuestra postura lo más rápido posible?

80/20

Para entender la distribución óptima debemos recordar la regla 80/20. Dice que podemos lograr el 80% de los resultados con el 20% del costo/esfuerzo/tiempo y se necesita el resto del 80% de los recursos para lograr el último 20% de los resultados. 80/20 es una buena regla general en muchas áreas y en algunos casos resulta tener una proporción más extrema como 90/10.

Es decir, siempre debemos empezar por hacer ese 10%-20% de la inversión para conseguir el 80%-90% de los resultados. No necesitamos comprar el mejor firewall porque incluso un firewall simple o gratuito nos permitirá alcanzar el 80%-90% del camino. No necesitamos comprar el mejor antivirus porque incluso un antivirus simple o gratuito nos permitirá alcanzar entre el 80% y el 90% del camino. Y para ser honesto, ningún antivirus o firewall nos solucionará el 100% del camino porque ningún producto de seguridad ofrece una protección del 100%.

Lo mismo ocurre con la formación del personal, los filtros de spam y cualquier otro producto/servicio de seguridad: incluso los productos simples ofrecen una buena protección y ninguna solución es 100% efectiva.

Defensas en series

Ahora debes preguntarte cómo cubrimos ese último 10%-20%. ¿Qué compensa esas soluciones más simples y cómo esto nos lleva a una mayor seguridad?

Aquí es donde necesitamos introducir otro concepto de defensas paralelas y en serie. Las defensas paralelas son lo que conocemos como el eslabón más débil. Un pirata informático puede atravesar el firewall, el correo electrónico no deseado, la seguridad física, es posible que ya esté empleado en la empresa, etc. Cualquier brecha en el perímetro permitirá que el pirata informático ingrese a la red corporativa.

Por el contrario, las defensas seriales se refuerzan entre sí. Con las defensas en serie, un atacante tiene que romper múltiples capas de defensa para tener éxito. Entonces, ¿qué defensa debe traspasar un atacante después de traspasar el perímetro? Estas son las defensas internas alrededor de la base de datos y la aplicación que tendemos a llamar centradas en datos. No habrá una violación de datos si no se accede a la base de datos y/o a la aplicación de alguna manera.

Un cálculo probabilístico simple muestra que si logramos un 80% de protección en el perímetro y un 80% de protección alrededor de los datos, tendremos una protección combinada del 96%. Si el perímetro y el centrado en datos están ambos al 90%, la protección combinada será del 99%. Se trata de niveles de protección que son imposibles de alcanzar con defensas paralelas, independientemente de la inversión.

En otras palabras, lograr niveles de protección similares en el perímetro y centrado en los datos logrará una postura de seguridad óptima.

Presupuesto

¿Cuáles son entonces las mejores asignaciones presupuestarias?

Es difícil dar una cifra exacta porque cada entorno es diferente y tiene un perfil de riesgo único. ¿Cuántos puntos finales, cuántas bases de datos y aplicaciones, qué tan capacitados están los empleados, etc.?

Sin embargo, como referencia, considere una asignación general de:

• 40% para Perímetro

Esto incluye seguridad de red, puntos finales, seguridad del correo electrónico, capacitación de empleados y más.

• 40% para Centrado en Datos

Esto incluye seguridad de bases de datos, seguridad de aplicaciones, enmascaramiento de datos, gestión de identidades, autenticación, cifrado, cadena de suministro y más.

• 20% para Otros esfuerzos

Esto incluye respuesta a incidentes, inteligencia sobre amenazas, SIEM, etc.

Dentro de cada categoría, las asignaciones deben hacerse de manera diferente:

• En el perímetro, el objetivo es conseguir un nivel de protección similar en todas las categorías. Dado que es casi imposible lograr más del 90% en la capacitación de los empleados, el 90% es un objetivo bueno y razonable para todos los proyectos: bloquear 9 de cada 10 intentos.

• En el ámbito centrado en datos, el objetivo es centrarse más en categorías que tienen más probabilidades de ofrecer protecciones internas contra ese 1 de cada 10 que traspasó el perímetro. La aplicación y la base de datos tienden a clasificarse como las más importantes.

• En otros esfuerzos, la atención suele centrarse en proyectos específicos que se ajustan al enfoque de seguridad de la organización, y las organizaciones rara vez invierten en todos los ámbitos.

• Su organización puede ser diferente y requerir asignaciones diferentes. Por ejemplo, las empresas más pequeñas con presupuestos más reducidos podrían reducir o eliminar por completo la categoría “otros” y centrar sus esfuerzos en el perímetro y centrados en los datos.

Pensamientos finales

Con una buena planificación y asignación, es posible alcanzar niveles extremadamente altos de protección con una inversión modesta. Si bien todos queremos un presupuesto mayor, se puede lograr mucho con mucho menos de lo que gastamos actualmente. Se trata simplemente de recordar que ningún esfuerzo por sí solo puede llevarnos al 100% y siempre debemos compensar con defensas superpuestas o en serie.

Contáctenos para obtener más información sobre cómo podemos ayudarlo a proteger su aplicación y sus datos.

Muchas organizaciones diseñan sus estrategias de ciberseguridad y deciden qué soluciones comprar en función de las tendencias y mejores prácticas de la industria. El resultado suele ser desequilibrado e inapropiado para el perfil de riesgo y las necesidades de seguridad de la organización.

Las implementaciones de mejores prácticas suelen ser de talla única y no se adaptan al entorno específico. Al ser predecibles, generalmente existen herramientas y guías en Internet que pueden vencerlos. Un enfoque genérico de esta naturaleza tampoco logra aprovechar las ventajas fácilmente disponibles cuando se examinan los aspectos específicos del entorno.

Muchas soluciones vienen con seguridad lista para usar. Contienen políticas integradas y firmas diseñadas para una baja tasa de falsos positivos en cualquier entorno. Estos tienen dificultades para identificar variaciones de ataque y nunca pueden identificar otros vectores, lo que resulta en una defensa más débil.

Este documento trata sobre cómo hacer la seguridad de manera diferente.

Perímetro vs. Centrado en datos

La mayoría de las soluciones de seguridad se clasifican en una de dos categorías: seguridad perimetral o seguridad centrada en los datos.

La seguridad perimetral tiene como objetivo evitar que los atacantes ingresen a la red y accedan a los sistemas internos. Un escritorio comprometido no es una violación de datos, pero una vez que los atacantes tienen este acceso, pueden dar el siguiente paso e intentar obtener acceso a la aplicación o la base de datos. Una violación de datos solo ocurriría si los atacantes pueden navegar desde ese escritorio comprometido hasta los datos.

La seguridad perimetral tiene dos limitaciones estratégicas:

• Amenazas internas: cuando una amenaza ya está dentro de la red y detrás del perímetro, no puede protegerse con este tipo de defensas. Lo mismo se aplica a las amenazas fuera de la red con acceso VPN (por ejemplo, socios, consultores y más).
• Defensa estadística: las protecciones perimetrales casi siempre tienen como objetivo reducir el número de penetraciones, pero no evitarlas por completo. Independientemente de lo buenos que sean nuestros filtros de spam, seguimos recibiendo correos electrónicos no deseados. No importa cuán buena sea la capacitación de nuestro personal, la gente aún hace click en esos correos electrónicos de phishing.

Data-centric es una metodología que gira en torno a los datos. Comienza con el lugar donde se almacenan los datos: la base de datos y se expande hacia las aplicaciones que procesan esos datos.

La seguridad centrada en datos incluye seguridad de bases de datos, seguridad de aplicaciones, IAM y más. Una sólida postura centrada en los datos puede evitar una filtración de datos independientemente de cuántos atacantes hayan penetrado en el perímetro. Por ejemplo, las aplicaciones basadas en la nube se basan principalmente en medidas centradas en datos.

La seguridad perimetral es una defensa paralela donde los atacantes solo necesitan violar una de las medidas para ingresar. Los atacantes que no logran penetrar el firewall pueden probar el sistema de correo, la ingeniería social, etc. La seguridad perimetral es tan fuerte como su eslabón más débil.

La seguridad centrada en datos es una seguridad en capas que da como resultado una defensa en serie donde los atacantes deben penetrar todas las capas. Una violación exitosa de la aplicación que no puede ejecutar un ataque contra la base de datos es un ataque fallido. La seguridad centrada en los datos es la última línea de defensa y pretende ser lo más hermética posible.

Las defensas perimetrales y centradas en datos no se excluyen mutuamente, y las estrategias bien equilibradas incluirán ambas.

Consideraciones generales

Al construir una estrategia de seguridad, debemos considerar las amenazas que percibimos como relevantes. Por ejemplo, ¿nos preocupan las amenazas externas, las amenazas internas, o ambas? Si las amenazas internas son una preocupación importante, la seguridad del perímetro no será eficaz contra ellas y debemos reforzar los componentes centrados en los datos.

También debemos considerar la efectividad de diferentes medidas en el panorama actual. Por ejemplo, a medida que más y más personas trabajan de forma remota, la seguridad de la red y la seguridad de los terminales son menos efectivas. Una vez que las personas trabajan desde casa, están fuera del firewall corporativo y usan las computadoras de su hogar. Con un control mínimo sobre todas estas minioficinas remotas con conexiones VPN, nuestra defensa perimetral se vuelve más débil de lo esperado.

BYOD (Bring-Your-Own-Device) plantea un desafío similar en el que muchos teléfonos y tabletas descontrolados e inseguros deambulan por la red corporativa dentro de nuestro perímetro.

A medida que cambia el panorama moderno y disminuye la efectividad de los controles perimetrales, hay un cambio creciente hacia las defensas internas. Parte de este cambio incluye una redefinición de la línea perimetral: proteger la red del centro de datos es más importante que la red corporativa.

Consideraciones de activos

Hay varias consideraciones a la hora de elegir en qué sistemas centrar nuestras defensas y cómo asignar los recursos:

• Riesgo: algunos sistemas presentan un mayor riesgo que otros. Por ejemplo, es necesario un firewall porque, sin él, tendremos infinidad de atacantes dentro de nuestra red. Necesitamos defender la aplicación porque todas las personas que la usan, o tienen acceso a la red, forman una gran superficie. También debemos proteger nuestra base de datos porque almacena todos los datos y una violación sería catastrófica.
• Efectividad: algunos sistemas son más fáciles de asegurar con mejores resultados, mientras que otros pueden ser costosos de proteger o tener beneficios de seguridad limitados. Por ejemplo, los firewalls son una medida efectiva y son baratos y fáciles de implementar; esa es una opción fácil. La seguridad de la aplicación o la base de datos (según la solución utilizada) puede ser difícil o costosa de implementar, pero con buenos resultados. IAM puede ser costoso de implementar pero con un valor limitado.
• Caminos de ataque: algunos sistemas se encuentran en una ruta crítica entre los atacantes y los datos. Otros están en caminos que los atacantes podrían eludir. Por ejemplo, un atacante debe comunicarse con la base de datos para extraer los datos. Es poco probable que un ataque tenga éxito sin él. Sin embargo, si una aplicación está en esa ruta depende del entorno. A veces, la ruta principal a los datos es a través de una sola aplicación. En otros casos, varias aplicaciones o conexiones directas a bases de datos ofrecen rutas alternativas.

Equilibrar las rutas de riesgo, eficacia y ataque es una consideración central en la estrategia de ciberseguridad, y existen múltiples métodos de equilibrio. Sin embargo, es importante recordar que hay muchas variables. Por ejemplo, la efectividad de la seguridad depende de la solución y la tecnología que esté evaluando, ya que las diferentes soluciones diferirán en costo y efectividad.

IDS e IPS

Los sistemas de detección de intrusiones (IDS) y los sistemas de prevención de intrusiones (IPS) son metodologías fundamentalmente diferentes en seguridad.

IPS tiene como objetivo prevenir ataques e infracciones. Estos son sistemas de seguridad clásicos como firewalls, usuarios y contraseñas, etc. Los IPS son componentes críticos en cualquier estrategia de seguridad.

Por el contrario, IDS busca detectar ataques y alertar o informar sobre ellos. Estos incluyen medidas como auditoría, SIEM, etc. Los IDS también son un componente crítico en cualquier estrategia de seguridad, ya que informan al personal de seguridad, les permiten iniciar una respuesta y brindan información forense.

Es importante comprender las diferencias fundamentales entre IPS e IDS:

• Tolerancia a los falsos positivos.
  Los falsos positivos en IPS significan que el sistema impide que los usuarios realicen actividades legítimas. Por lo tanto, IPS no puede tolerar falsos positivos.
  Los falsos positivos en IDS significan que los informes o alertas requieren que el personal de seguridad los investigue mientras los usuarios continúan haciendo su trabajo. Si bien no queremos demasiados falsos positivos, la mayoría de los IDS están diseñados y calibrados para tener un cierto nivel de falsos positivos.
• Tiempo de respuesta.
  IPS debe determinar si las actividades son válidas antes de dejarlas pasar. Un IPS lento significa que los sistemas de TI tienen tiempos de respuesta más largos y los usuarios se quejan. Por lo tanto, un IPS siempre está diseñado para usar algoritmos en tiempo real capaces de tomar decisiones en una fracción de segundo.
  IDS, por otro lado, puede tomarse su tiempo para informar o alertar. Los IDS suelen utilizar algoritmos más complejos y pueden analizar grandes volúmenes de datos para identificar intrusiones. Pueden hacer referencia a información histórica o esperar a que ocurran eventos futuros.
• Burla.
  Cuando un sistema IPS previene un ataque, el atacante es inevitablemente consciente del intento fallido y puede volver a intentarlo. Por lo tanto, los atacantes desafían constantemente los sistemas IPS hasta que encuentran la manera de penetrarlos.
  Los IDS informan al personal de seguridad del ataque permitiéndoles responder de varias maneras. Las respuestas pueden incluir desconectar los sistemas, desviar los ataques a los honeypots, rastrear el ataque hasta su fuente y más. En todos los casos, los atacantes no tienen una segunda oportunidad de volver a intentarlo contra una defensa idéntica. Los sistemas IDS son, por lo tanto, mucho más difíciles de eludir.

En consecuencia, mientras que IPS podría prevenir una intrusión, es más probable que IDS la detecte y es menos probable que se eluda. Siempre se recomienda, cuando sea posible, implementar ambos tipos de sistemas. Implemente un IPS para bloquear la mayoría de los ataques e implemente un IDS para detectar los que pasaron.

Seguridad a medida

Cada entorno es diferente. Las diferencias incluyen la arquitectura de la aplicación, la pila de tecnología, la cantidad de usuarios, el acceso del administrador y más. Otros parámetros incluyen los roles de usuario, los programas en uso, los segmentos de red, los tipos de datos, los perfiles de actividad, etc.

Aprovechar dichos parámetros mientras se implementan medidas preventivas y de detección produce resultados más efectivos. Tal seguridad personalizada no puede estar lista para usar, ya que requiere evaluación, consideración y planificación. Sin embargo, es vital para lograr una alta efectividad en la detección de ataques y una baja tasa de falsos positivos.

Personalizar la seguridad de esta manera requiere tiempo y esfuerzo, y no existe una varita mágica. Pero es mucho más probable que los resultados resistan un ataque y prevengan una violación de datos.

DCSA

La evaluación de seguridad centrada en datos es un servicio que ofrece Blue Core Research para ayudar a los departamentos de seguridad a cuantificar el riesgo de cada uno de sus sistemas y evaluar la eficacia de diferentes controles y estrategias.

DCSA es una evaluación basada en entrevistas que utiliza su opinión sobre sus sistemas. Combinará múltiples parámetros sobre cada sistema en su entorno y producirá su nivel de riesgo.

DCSA tiene como objetivo ayudarlo a elegir las soluciones y estrategias con el mayor impacto en su seguridad para minimizar el riesgo.

Pensamientos finales

La calidad y la solidez de su estrategia de seguridad dependen del tiempo y el esfuerzo que se dediquen a ella. Tendrá una buena postura de seguridad si tiene un buen equilibrio entre su perímetro y su centro de datos, creó seguridad en capas, combinó IPS e IDS en cada sistema con una estrategia de respuesta adecuada, adaptó sus soluciones a cada entorno, y distribuye sus recursos de acuerdo con el riesgo, la eficacia y las rutas de ataque que es probable que sigan los atacantes.

Suena a mucho, pero no es tan difícil. Sin embargo, significa no seguir las tendencias y comprar soluciones solo porque están de moda. Significa poner esfuerzos en las implementaciones y no solo buscar seguir las mejores prácticas. Eso requiere esfuerzo y una reflexión cuidadosa, pero es la mejor manera de reducir el riesgo de una filtración de datos.

Recibí un alerta dos días antes de año nuevo. Fue poco antes de la media noche el 30 de diciembre de 2021. Era una alerta de una anomalía diaria relacionada al backend de la base de datos de un viejo sitio web, pero claramente un ataque.

Como se vio luego, este fue el primero de muchos intentos de ataques. Hubo tres más en enero de 2022, dos más en febrero, y uno más en agosto, octubre, y noviembre. Considerándolo todo, nueve ataques similares en el curso de un año.

Antecedentes

Usamos WordPress (un sistema de gestión de contenidos de código abierto) en muchos de nuestros sitios webs y siempre con un backend MySQL (la configuración más popular). El sitio web en questión era viejo, y debido a problemas de compatibilidad, no habíamos actualizado algunos de los componentes de software en un tiempo. Entonces cuando vi esta alerta, pareció altamente plausible que había una vulnerabilidad que derivó en un ataque exitoso.

Como luego resultó, esto era un falso positivo. La razón de este falso positivo fue que adicional a una vieja versión de WordPress y plugins, este sitio web también usaba una vieja versión de Core Audit. Pero más de esto luego.

Ninguno de nuestros sitios web contiene información confidencial, pero como mostrará este documento, proteger la base de datos de cualquier aplicación con Core Audit es un medio muy eficaz para detectar ataques y proteguer la aplicación.

La Anomalía

El alerta de anomalía tiene 168 líneas, y la primera línea fue esta:

SELECT * FROM wp_users WHERE user_login = 
'') UNION ALL SELECT NULL-- HupP'

Mientras cada línea fue diferente, cada línea empezó con uno de estos:

SELECT * FROM wp_users WHERE user_login =''

SELECT * FROM wp_users
 INNER JOIN wp_usermeta ON user_id = ID WHERE meta_key = '' AND user_login = ''

Lo que hizo claro que se trataba de un ataque fueron las muchas variaciones de SQLs que lucen como esto:

;SELECT SLEEP(9)#' LIMIT 9

) AND SLEEP(9) AND (\\\''=\\\''

WAITFOR DELAY \\\'' AND \\\''=\\\'' LIMIT 9

;SELECT SLEEP(9)#'

);SELECT PG_SLEEP(9)--'

;SELECT PG_SLEEP(9)--' LIMIT 9

);WAITFOR DELAY \\\''--'

;WAITFOR DELAY \\\''--' LIMIT 9

) AND 9=(SELECT 9 FROM PG_SLEEP(9))

UNION ALL SELECT NULL-- HupP'

) UNION ALL SELECT NULL-- HupP' LIMIT 9

UNION ALL SELECT NULL,NULL,NULL-- iIWs'

UNION ALL SELECT NULL,NULL,NULL,NULL-- ynbe'

Tener en cuenta que las cuerdas vacías ('') y los 9s no son parte del SQL original. Ellos se relacionan en cómo la seguridad del repositorio de Core Audit opera. Este repositorio automáticamente colecciona todos los SQLs en la base de datos, entonces para reducir espacio y eliminar anomalías de literales embebidos, automaticamente elimina todos los números y cuerdas.

Los SQLs vistos anteriormente son el resultado de un atacante que intentó escanear la aplicación en búsqueda de una vulnerabilidad de inyección de SQL. Intentaban detectar si la inyección SQL era posible en esta aplicación y encontrar información adicional que facilitara el ataque:

• Cada instrucción SLEEP/DELAY solo funcionaría en un tipo de base de datos. Así que un retraso en la respuesta le dice al atacante que la inyección fue exitosa y el tipo de base de datos utilizada.
• Las diversas permutaciones UNION y NULL estaban tratando de determinar el número de campos en la query y si podrían agregar datos de otras tablas.

Adicional a muchas más variaciones de SLEEP y UNION, hubo expresiones llenas de color como:

) AND (SELECT 9 FROM(SELECT COUNT(*),CONCAT(0x7178707671,(SELECT (ELT(9=9,9))),0x7171767171,FLOOR(RAND(9)*9))x FROM INFORMATION_SCHEMA.CHARAC

) AND 9=CAST((CHR(9)||CHR(9)||CHR(9)||CHR(9)||CHR(9))||(SELECT (CASE WHEN (9=9) THEN 9 ELSE 9 END))::text||(CHR(9)||CHR(9)||CHR(9)||CHR(9)||C

) AND 9=CAST((CHR(9)||CHR(9)||CHR(9)||CHR(9)||CHR(9))||(SELECT (CASE WHEN (9=9) THEN 9 ELSE 9 END))::text||(CHR(9)||CHR(9)||CHR(9 )||CHR(9)||CHR(9)) AS NUMERIC) AND (\\\''= \\\''

;SELECT DBMS_PIPE.RECEIVE_MESSAGE(CHR(9)||CHR(9)||CHR(9)||CHR(9),9) FROM DUAL--'

AND 9=CONVERT(INT,(SELECT CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9)+(SELECT (CASE WHEN (9=9) THEN CHAR(9) ELSE CHAR(9) END))+CHA R(9)+CHAR(9)+C

) AND (SELECT 9 FROM(SELECT COUNT(*),CONCAT(0x7178707671,(SELECT (ELT(9=9,9))),0x7171767171,FLOOR(RAND(9)*9))x FROM INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a) AND (\\\''=\\\''

) AND 9=CONVERT(INT,(SELECT CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9)+(SELECT (CASE WHEN (9=9) THEN CHAR(9) ELSE CHAR(9) END))+CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9))) AND (\\\''=\\\''

Estos SQLs eran claramente inusuales y parecen intentar eludir un sistema de protección de inyección de SQL como un WAF.

Forences

Experimentamos un ataque. El alerta no deja ninguna duda sobre esto. Las dos preguntas remanentes fueron:

• ¿Fue exitoso el ataque?
• ¿Qué parte de la aplicación fue objetivo?

Base de datos forences

La primera pregunta fue fácil de responder. Empecé por localizar las queries en la vista forense de SQL reducida. El repositorio reducido de SQL tiene una resolución de 5 minutos, y todos estos SQLs fueron ejecutados en la ventana de 8:20 am a 8:25 am.

Una vez que localicé las queries, también vi las buenas noticias – todos fueron exitosos (sin errores), y los números de las filas recuperadas fueron cero para todas.

¿Por qué son buenas noticias las ejecuciones exitosas? Porque este ataque estaba tratando de testar si la aplicación era vulnerable a una inyección de SQL. En este escaneo, se supone que muchas de estas queries fallen, y pocas exitosas indicando el método para explotar una vulnerabilidad. Por ejemplo, los SQLs con PG_SLEEP() nunca pueden ser exitosos en nuestra base de datos MySQL desde que esta función solo existe en base de datos PostgreSQL. Por lo tanto, ejecuciones exitosas significan el intento de inyección fallido de modificar la SQL.

Adicionalmente, estas SQLs no recuperan datos, entonces allí no hubo filtración. Mientras la mayoría de estos SQLs no estaban intentando extraer nada, es confortante saber que nada fue recuperado.

En otras palabras – este ataque no logró romper el límite literal. Volveremos a este asunto después y también responder la pregunta más interesante de porqué recibimos el alerta de anomalía en primer lugar.

Aplicaciones Forences

Ahora que tenemos más información, es fácil buscar los logs de Apache para más detalles en el ataque y a qué dirigió.

El ataque fue entre las 8:20 am y 8:25 am, y accedió a la tabla wp_users. Mirando al log de Apache, podemos ver que este ataque empezó exactamente a las 8:20 am:

[29/Dec/2021:08:20:00] "GET /wp-login.php?log=1&pwd=-9696%20UNION%20ALL%20SELECT%2024%2C24--%20ptzf"

Este ataque fue una pregunta GET al script wp-login.php. Esta es la página de logueo de WordPress. El ataque entregó su intento de inyección a través del campo de contraseña que, en este primer intento, incluyó:

-9696 UNION ALL SELECT 24,24-- ptzf

El último intento de ataque fue usando este requerimiento POST a las 8:21:51 am:

[29/Dec/2021:08:21:51] "POST /wp-login.php?Phws%3D5963%20AND%201%3D1%20UNION%20ALL%20SELECT%201%2CNULL%2C%27%3Cscript%3Ealert%28%22XSS%22%29%3C%2Fscript%3E%27%2Ctable_name%20FROM%20information_schema.tables%20WHERE%202%3E1--%2F%2A%2A%2F%3B%20EXEC%20xp_cmdshell%28%27cat%20..%2F..%2F..%2Fetc%2Fpasswd%27%29%23"

Los logs de Apache no graban los parámetros POST, pero podemos ver esta carga en el requerimiento:

Phws=5963 AND 1=1 UNION ALL SELECT 1,NULL,'<script>alert("XSS")</script>',table_name FROM information_schema.tables WHERE 2>1--/**/; EXEC xp_cmdshell('cat ../../../etc/passwd')#

Esta carga útil es un poco graciosa dado que contiene una inyección de SQL con un escaneo de secuencias de comandos entre sitios (alert(“XSS”)) y un intento de que SQL Server ejecute un comando de shell (EXEC xp_cmdshell) con un comando Unix/Linux imprimiendo el contenido de un archivo de contraseña Unix/Linux (cat …/passwd).

Este es una mezcla de ataques fragmentados que podrían nunca funcionar juntos. Y hay muchas otras cosas mal con el último requerimiento.

Esto indica que la persona corriendo el ataque tiene poco entendimiento de lo que está haciendo. Combinada con el hecho de que todo el escaneo duró menos de 2 minutos, sugiere esto fue un script o, más probable, muchos scripts ellos descargaron fuera de Internet y ejecutaron contra varios sitios.

Falso Positivo

Entonces, ¿por qué falló el ataque?, ¿y por qué recibimos una alerta de anomalía de cualquier forma?

Un ataque de inyección de SQL intenta modificar la estructura SQL al quebrar a través de los límites literales. En otras palabras, cuando un SQL contiene un literal como este:

SELECT * FROM wp_users WHERE user_login = 'JOHN'

Un ataque de inyección de SQL intenta mandar una cadena otra que “JOHN” entonces la estructura SQL cambia. Por ejemplo, la cadena “X' or 'Y'='Y” resultará in este SQL:

SELECT * FROM wp_users WHERE user_login ='X' or 'Y'='Y'

Al cambiar el SQL estructura y agrega “or 'Y'='Y'“, la base de datos correrá algo no intencionado por el desarrollador que escribió este código. Colocando una etiqueta (') en el aporte rompió a través de límites literales y permitió al atacante alterar la estructura SQL. Escapar los literales antes de incrustarlos en un SQL previene esta vulnerabilidad.

En el SQL estandard, puedes escapar etiquetas (') al usar etiquetas dobles (''). Cuando se escapa, el ejemplo de más arriba producirá:

SELECT * FROM wp_users WHERE user_login = 'X'' or ''Y''=''Y'

En este caso, la base de datos comparará el campo user_login a la cadena entera, con la palabra OR es solo parte de un nombre de usuario, no parte de una estructura SQL.

WordPress debe haber escapado de la entrada correctamente en nuestro ataque, y la estructura SQL no fue modificada. Es por esto que los SQLs se ejecutaron sin error, y el ataque falló.

Pero, ¿por qué recibimos un alerta de anomalía si el ataque no quebró los límites literales?

A diferencia de otras bases de datos, en MySQL, hay 2 formas de escapar de las etiquetas en las cadenas. La primera es con etiquetas dobles ('') de acuerdo con el SQL estándard. Pero hay un segundo método de preceder la etiqueta con un backslash (\'). WordPress usa el segundo método.

Acá es donde la vieja versión de Core Audit entra a jugar. Aquella vieja versión fue liberada cortamente luego de la liberación del soporte de MySQL, y la eliminación literal en el repositorio de SQL reducido no admitía el método de escape de barra invertida para bases de datos MySQL.

Una vez que descubrimos el consecuente no intencionado de detectar falsamante estos ataques de inyección de SQL, nosotros mantenemos a propósito la vieja versión de Core Audit en ese sitio web. Queríamos ver cómo muchos más ataques fallido experimentaríamos. Como comentamos antes, este viejo sitio web experimentó nueve intentos a lo largo del siguiente año. Una vez que actualizamos la versión de Core Audit, paramos de recibir estas alertas de falso positivo.

Area de superficie de ataque de la aplicación

Tal vez te preguntes por qué alguien intentó un ataque de inyección de SQL que no funcionó contra WordPress. Los atacantes, como cualquier otro, tenían acceso a WordPress. Entonces, ¿por qué no sabían que este ataque fallaría?

Esta es una pregunta interesante que resalta los complejidad de la cadena de suministro en algunas aplicaciones de terceros, como WordPress.

El primer pensamiento que viene a mi mente es que quizás algunas versiones de WordPress son susceptibles de ataque. Como sea, la inyección de SQL es una amenaza bien conocida, y el equipo de desarrollo de WordPress es estricto sobre escapando entradas antes de literales incrustados en SQLs. Mientras usar variables incrustadas sería más seguro, desarrolladores web tienen una inclinación por literales embebidos.

Como sea, es mundialmente conocido que múltiples versiones y parches significativamente aumentan el área de la superficie de ataque. La razón es que muchas organizaciones actualizan y emparchan aplicaciones de tanto en tanto y nunca pueden estar seguras qué vulnerabilidades eliminaron o introdujeron y en qué punto.

Pero desde que es poco probable que ninguna versión de WordPress fue susceptible a una inyección de SQL en la pantalla de login, que lleva otra interesante característica de WordPress – Plugins.

Una gran parte del poder y flexibilidad de WordPress son más de decenas de miles de plugins que pueden extenderlo. Estos plugins son código que puede adjuntarse a varios lugares en WordPress y modificar su comportamiento en casi cualquier manera inimaginable.

Plugins ofrece poder y flexibilidad a los usuarios, pero también muestran un riesgo de seguridad. WordPress plugins introducen proveedores adicionales, códigos estándar, cambios al modelo de la base de datos, nuevos caminos en la ejecución de la aplicación, y, por lo tanto, nuevas vulnerabilidades.

El riesgo en plugins no es solo vulnerabilidades en software de terceros pero también el riesgo de ataques en la cadena de suministro. Estos ataques pueden ser iniciados por el autor del plugin o por un hacker que alteró el código fuente.

Es poco probable que WordPress fuera susceptible de este ataque, pero es altamente plausible que algunos de los plugins lo sean. El atacante estaba apuntando a un plugin que no fue instalado en nuestro WordPress.

Ideas finales

Las inyecciones de SQL son notoriamente difíciles de detectar y, aún más, de prevenir. Como sea, el análisis de anomalías de Core Audit fue capaz de alertar sobre estos ataques.

No solo fue un análisis de anomalías capaz de detectar un ataque, pero se hizo sin ninguna firma de ataque o soporte para PHP o WordPress. Y, realmente, sin siquiera buscar un ataque de inyección de SQL.

Y esta es la razón por la que el análisis de anomalías es tan efectivo contra la inyección de SQL – no es buscando especialmente por esto. Es buscando por SQLs que son nuevos a la aplicación, por lo tanto, sospechosos. La inyección de SQL puede mascarar en muchas formas pero, por definición, no es parte del vocabulario SQL de la aplicación. Por lo tanto, el análisis de anomalías siempre detectará el ataque.