Introducción

La auditoría de SQL Server es un tema amplio y complejo que implica muchas tecnologías y posibilidades. Intentaremos desmitificar todo lo posible sin excedernos. Esperamos guiarte hacia la solución correcta mientras tomas decisiones tecnológicas informadas.

Captura

La captura es la recopilación de datos en bruto. Toda auditoría comienza con la recopilación de información. Después, hay que procesar los datos, almacenarlos, elaborar informes, etc. Estos aspectos se tratarán más adelante en este artículo, en la sección Obtener valor.

Aunque obtener valor de la información es un reto, conseguir la información para empezar es aún más difícil y tiene implicaciones de gran alcance sobre lo que está disponible para procesar.

Desafíos

¿Por qué es difícil recopilar datos de auditoría? Parece que debería ser fácil.

El problema subyacente es que las bases de datos ejecutan una enorme cantidad de actividad a velocidades increíbles. Cualquier interferencia con esta máquina altamente afinada puede paralizar el rendimiento y ralentizar la base de datos hasta hacerla ir a rastras. Por tanto, el impacto en el rendimiento es el mayor reto en la captura.

Un segundo reto son las cuentas privilegiadas, incluidos los DBA y la cuenta «sa». Normalmente, necesitamos auditar estas cuentas, pero son estas cuentas privilegiadas las que controlan las tecnologías de captura integradas en la base de datos.

Otro reto es el uso habitual de procedimientos en SQL Server. Muchas aplicaciones en SQL Server no ejecutan SQL contra la base de datos, sino que ejecutan procedimientos. Estos procedimientos ejecutan SQL dentro del motor de la base de datos. Esto es importante porque algunas tecnologías de captura sólo pueden ver la actividad fuera de la base de datos, y para ver las SQL, tablas y columnas es necesario capturar dentro de la base de datos.

Discutiremos estas limitaciones a medida que revisemos cada tecnología.

Tecnologías Disponibles

Esta tabla resumen muestra qué tecnología de auditoría es relevante para qué captura de datos. Como puedes ver, casi nada es perfecto. Estas tecnologías también tienen limitaciones y desventajas, así que lee los detalles a continuación.

	Inicios de Sesión	SQLs			Antes y Después de Valores	Metadata Snapshot	Bloqueo
		DDL	DML	Consultas
Hágalo usted mismo (DIY)						✓
C2 Modo de auditoría	✓	✓	✓	✓
Auditoría SQL Server	✓	✓	✓	✓
Perfilador/Rastreo	✓	✓	✓	✓
Eventos Ampliados	✓	✓	✓	✓
Triggers	✓	✓			✓
Registros de logs					✓
Inspección de paquetes	✓	✓	✓	✓			✓
Full Capture	✓	✓	✓	✓	✓	✓	✓

Hágalo usted mismo (DIY)

El «hágalo usted mismo» (DIY) es una solución sencilla que se puede construir internamente sin tecnología especial ni procesamiento complejo. Por ejemplo, puedes tomar una instantánea diaria de los usuarios de la base de datos e identificar los cambios del día anterior. No es muy potente desde el punto de vista de la seguridad, pero puede ayudar a validar el control de cambios. Aparte de sus capacidades limitadas, el principal inconveniente es el tiempo que le llevará a su equipo de DBA implantarlo, mantenerlo y hacerlo funcionar.

Auditoría de SQL Server

Hay varias tecnologías diferentes asociadas con el concepto de Auditoría de SQL Server. Algunas están relacionadas entre sí y otras no. Puede ser confuso, así que las hemos enumerado todas.

SQL Server C2 Audit es un parámetro de configuración en SQL Server (sp_configure ‘c2 audit mode’) que registra automáticamente toda la actividad de la base de datos. Tiene una sobrecarga extremadamente alta y crea archivos masivos. No es una opción realista para auditar SQL Server.

Auditoría SQL Server utiliza Eventos Ampliados. Es una envoltura para la misma cosa con pros y contras similares.

SQL Server Profiler o Trace es una característica anterior de SQL Server que fue reemplazada por Extended Events. SQL Server trace tiene un mayor impacto en el rendimiento y está obsoleto (lo que significa que Microsoft dejará de darle soporte en algún momento). No hay razón para usarla hoy en día.

Extended Events o Eventos Ampliados es una capacidad de captura de SQL Server incorporada. Es la mejor opción de captura sin costes adicionales de licencia. Es adecuada para un proyecto DIY y común en soluciones de bajo coste (ver más adelante). Sin embargo, tiene limitaciones que incluyen:

• No registra la dirección IP del cliente. Si las direcciones IP son un requisito, esta no es la solución.
• Los DBA y las cuentas con privilegios pueden desactivar esta captura, por lo que su eficacia para supervisarlos es limitada.
• La sobrecarga puede ser elevada y depende del perfil de actividad de la base de datos. Incluso utilizando únicamente el búfer en anillo (una captura en memoria de alto rendimiento), en el peor de los casos puede llegar a superar el 1.200%. Aunque una sobrecarga tan elevada es poco probable, una significativa es muy plausible. Sólo en bases de datos de baja actividad el impacto sería insignificante.
• El registro de la actividad puede requerir archivos de gran tamaño. Dependiendo del tipo de almacenamiento, esto puede aumentar aún más el impacto en el rendimiento.
• Considere la posibilidad de realizar una auditoría selectiva. Al auditar sólo determinadas actividades, puede reducir significativamente el tamaño de los archivos. Desde el punto de vista del rendimiento, esto podría reducir la sobrecarga a no más de la mitad, ya que la comprobación de las condiciones de filtrado también tiene un impacto. El inconveniente es que la configuración de los filtros selectivos es tediosa y requiere mucho tiempo.

La conclusión es que los Eventos Ampliados pueden ser una buena solución de captura para bases de datos de baja actividad. Esto es especialmente cierto cuando se utiliza la auditoría selectiva para registrar un puñado de SQLs para cumplir con los requisitos de cumplimiento de menor importancia (ver más adelante).

Triggers

Los Triggers son pequeños fragmentos de código que la base de datos puede ejecutar en respuesta a una actividad.

Hay disparadores de inicio de sesión que pueden dispararse cuando alguien inicia sesión y disparadores DDL que pueden dispararse cuando se ejecuta un DDL. Puede utilizarlos para auditar este tipo de actividad. Estos eventos también son poco frecuentes y es poco probable que causen una sobrecarga de rendimiento significativa. Aunque es posible, este no es un enfoque de auditoría común para sesiones y DDLs.

También hay disparadores DML que se activan cuando los datos cambian en la base de datos. Sin embargo, no pueden ver el SQL y sólo son capaces de registrar los valores antes y después.

El problema de los triggers es que se ejecutan como parte del SQL y, por tanto, aumentan el tiempo que tarda en finalizar. Como los triggers suelen registrar información en otra tabla, suelen tener una sobrecarga elevada. En otras palabras, los triggers DML en tablas altamente transaccionales crearán un impacto significativo en el rendimiento.

Más allá de la sobrecarga, el inconveniente de los triggers es que están controlados por los DBA y otras personas con los permisos adecuados y pueden ser desactivados por cualquiera que desee saltárselos.

También es importante señalar que no existen disparadores o triggers para las consultas. Los desencadenantes son irrelevantes cuando se trata del riesgo de robo de datos.

Registros de Logs

Los registros de logs forman parte del funcionamiento de SQL Server. Contienen todos los cambios en la base de datos y se utilizan para la recuperación de fallos. Al margen de su función principal en la recuperación de fallos, SQL Server puede procesar estos registros para extraer todos los valores anteriores y posteriores. Esto es útil para la seguridad, la replicación y otros fines.

Hay tres mecanismos en SQL Server que procesan los registros de traducción de forma relevante para la seguridad:

• El seguimiento de cambios es el mecanismo antiguo. Utiliza el CDC más reciente.
• La captura de datos de cambios (CDC) almacena información sobre valores anteriores y posteriores. Requiere cierta administración y un mantenimiento regular, y la salida no es trivial de entender. Sin embargo, es probablemente el mejor de los tres.
• Las tablas temporales son un método de seguimiento del contenido de las tablas a lo largo del tiempo. La idea es añadir una dimensión temporal a la tabla para poder realizar consultas referidas al cuándo. Por ejemplo, ¿cuál era el salario de Juan el 17 de enero, o qué aspecto tenía la tabla en un día y hora determinados? El inconveniente es que, dependiendo del tamaño de la tabla y de la frecuencia de los cambios, esto puede requerir mucho espacio y recursos.

Lo bueno de aprovechar los registros de transacciones es que su procesamiento no está «en línea» con la actividad de la base de datos. Aunque el procesamiento consume recursos de la máquina, se produce en paralelo y no ralentiza las transacciones de la base de datos.

Aunque todos estos mecanismos forman parte de SQL Server y no requieren licencias adicionales, están controlados por los administradores de bases de datos (DBA) y es probable que necesite la ayuda de éstos para acceder a ellos. La información de cualquiera de estos mecanismos requiere esfuerzo para consumirla y actualmente no está integrada en su aplicación ni en ninguna otra interfaz de usuario.

Inspección de Paquetes

La tecnología de inspección de paquetes descifra la comunicación que entra y sale de la base de datos para identificar los SQL. Hay dos implementaciones: como sniffer de red fuera de la máquina o con un agente del kernel dentro de ella.

Como sniffer de red, esta tecnología no afecta al rendimiento de la base de datos, pero no puede ver la comunicación local. Eso suele ser inaceptable. El despliegue común utiliza el agente local, y de esta forma se puede ver la comunicación local, pero genera una elevada sobrecarga de red.

Ambos métodos de despliegue tienen retos con el cifrado de red, pero una de las mayores limitaciones es la falta de visibilidad dentro de la base de datos. El uso común de procedimientos almacenados en SQL Server significa que a menudo es imposible conocer el SQL, la tabla o la columna.

La falta de visibilidad interna también es un reto porque SQL Server recibe lotes, no SQLs. Un lote es un bloque TSQL con múltiples SQLs o un pequeño programa. Desglosar los lotes e inferir lo que hacen dentro de la base de datos va de difícil a imposible.

Algunas soluciones basadas en la inspección de paquetes también pueden bloquear la actividad no deseada. Sin embargo, suele haber un problema de sincronización que permite que las peticiones ofensivas pasen.

Full Capture

Core Audit Full Capture es una tecnología de auditoría de nueva generación que se conecta directamente al motor SQL. Se diseñó desde cero para abordar los retos exclusivos de la seguridad y la auditoría de SQL Server. La calidad de la información es similar a la de Extended Events, pero sin la sobrecarga y los DBA no pueden desactivarla.

Full Capture hace exactamente lo que se espera de una tecnología de captura: ver todo sin afectar a la base de datos. Esto le proporciona una visibilidad del 100% con menos del 3% de sobrecarga.

Full Capture también puede proporcionarle valores anteriores y posteriores mediante la integración con disparadores de baja sobrecarga o con la replicación de SQL Server (utilizando registros de transacciones). Así que tiene ambas alternativas con diferentes pros y contras.

Por último, la captura completa tiene capacidades de bloqueo que pueden devolver errores o advertencias a los SQL ofensivos. A diferencia de la inspección de paquetes, en esta medida preventiva no existen lagunas de tiempo ni de otro tipo.

Obteneniendo valor

Captar datos de auditoría es sólo la primera mitad del problema. Una vez que se tienen los datos, hay que convertirlos en información significativa. Un repositorio con miles de millones de SQL es inútil por sí mismo. Esta sección analiza brevemente lo que se puede hacer para obtener valor de todos estos datos.

Informes de cumplimiento. Una expectativa básica de la auditoría de bases de datos es lograr la conformidad. Para ello, se necesitan informes sobre inicios de sesión, inicios de sesión fallidos, actividad privilegiada, acceso a datos confidenciales y mucho más. El reto consiste en decidir qué registrar y cómo crear informes significativos a partir de ello. Los informes eficaces se basan en tres principios básicos:

1. El tema del informe debe ser realista en su entorno. Este tipo de informe funciona para subconjuntos de actividad de alto riesgo y bajo volumen. Como DDLs, DBAs ejecutando DMLs, etc.
2. Encuentre la forma correcta de informar sobre ello. Muchas veces de forma agregada, como contar el número de inicios de sesión de cada usuario en lugar de enumerarlos.
3. Afinar los informes sin perder valor de seguridad. Por ejemplo, excluir la actividad de un script de monitorización, pero asegurarse de que lo que se excluye no puede suponer un riesgo para la seguridad.

La elaboración de informes de cumplimiento no es difícil, sólo requiere un repositorio, un motor de elaboración de informes y un poco de tiempo. En Core Audit dispone de un repositorio altamente escalable, un motor de generación de informes fácil de usar y asistentes con políticas e informes incorporados para empezar.

Análisis de anomalías. La mayor parte de la actividad de las bases de datos no se presta a la elaboración de informes de cumplimiento y requiere algo que pueda escalar a volúmenes masivos. Eso requiere un tipo especial de repositorio y automatización que pueda localizar actividad inusual en él. Esto sólo existe en las soluciones de gama alta.

Core Audit puede alertar cuando nuevos usuarios están activos en la base de datos cuando se conectan desde diferentes aplicaciones o IPs o están activos en momentos inusuales, cuando SQLs inusuales acceden a información sensible, de volúmenes SQL inusuales, de potenciales ataques de inyección SQL, y mucho más. Hay muchas formas de trocear, comparar y contrastar la actividad para encontrar comportamientos anómalos.

Análisis forense reactivo. El análisis forense reactivo consiste en obtener detalles adicionales sobre los eventos de seguridad. Estos eventos pueden ser una línea sospechosa en un informe, una infracción potencial, una indicación de otra fuente, y más. Sea cual sea el suceso, siempre se necesita saber más sobre lo ocurrido.

El reto es disponer de un repositorio con la información. En la mayoría de las soluciones, está limitado a los eventos que decide registrar. En Core Audit, aparte del repositorio de cumplimiento, también tiene el repositorio de seguridad que almacena automáticamente información sobre cada SQL en su base de datos. Aunque el repositorio de seguridad es menos detallado, garantiza que siempre podrá saber lo que ha ocurrido.

Análisis forense proactivo. Este tipo de análisis forense le ofrece visibilidad de toda la actividad de la base de datos. Tiene múltiples objetivos, pero el más importante es desarrollar controles. Sin una comprensión sólida de lo que ocurre en la base de datos, es imposible diseñar informes de cumplimiento, alertas de anomalías o incluso comprender las amenazas a las que se enfrenta.

No se puede proteger lo que no se puede ver, y el análisis forense proactivo es un primer paso muy recomendable para proteger la base de datos de SQL Server. Pero también es importante identificar las malas prácticas de seguridad, los ataques y las infracciones, los cambios en los patrones de comportamiento, las lagunas en los controles desplegados y mucho más.

Core Audit Forense Proactivo incluye herramientas de análisis gráfico para visualizar los perfiles de actividad desde varias dimensiones e incluye pilas basadas en el tiempo, gráficos de árbol, gráficos Sunburst, un Sankey, gráficos de red y mucho más.

Reflexión Final

Existen múltiples tecnologías y soluciones para proteger una base de datos SQL Server. Van desde el bricolaje a los productos de bajo coste, pasando por las soluciones de gama alta. Todo depende de sus necesidades y de los recursos disponibles. Póngase en contacto con nosotros y le ayudaremos a encontrar el enfoque que mejor se adapte a su situación particular.

Introducción

Las empresas modernas funcionan con datos. Desde los datos de los clientes hasta la información financiera, las bases de datos almacenan gran cantidad de información confidencial. Estos datos facilitan las operaciones de la empresa e impulsan la toma de decisiones. Sin embargo, esta dependencia de los datos expone a las organizaciones a riesgos significativos. Los ciberataques y las filtraciones de datos pueden poner en peligro la información confidencial, provocando pérdidas económicas, sanciones normativas, demandas judiciales y daños irreparables a la reputación de la marca. Para mitigar estos riesgos, las organizaciones deben tomar medidas para proteger sus datos. Esto significa proteger el acceso a las bases de datos que los almacenan.

Que es la auditoría de bases de datos

La auditoría de bases de datos, o Database Activity Monitoring (DAM), es un sistema de detección de intrusiones en bases de datos (IDS). Supervisa las conexiones a las bases de datos y los SQL ejecutados en esas conexiones. Aunque pueda parecer un ejercicio sin sentido, cuando se hace bien, es la defensa de bases de datos más crítica y una de las medidas de seguridad más importantes para proteger tus datos.

El reto de la auditoría de bases de datos es el volumen de actividad. Hay miles de millones de SQL al mes, y nadie puede revisarlo todo manualmente. En realidad, el reto empieza antes de procesar los datos, ya que capturar esta cantidad de actividad es difícil sin crear una sobrecarga de rendimiento y ralentizar la base de datos.

Para que la auditoría de bases de datos esté a la altura de su potencial y proporcione una defensa sólida, requiere un potente mecanismo de captura que pueda verlo todo sin sobrecarga y potentes capacidades de procesamiento que le permitan obtener valor de todos estos datos. Eso es mucha tecnología y saber cómo utilizarla, y de eso trata este artículo.

Auditoría de bases de datos: Un viejo término equivocado

La auditoría de bases de datos suele traer a la mente métodos tradicionales y declarativos para supervisar la actividad de las bases de datos. Normalmente, se trata de activar funciones de auditoría en la base de datos, registrar la actividad y elaborar informes. Aunque estos métodos tienen su lugar, no abordan los retos de seguridad de los entornos de bases de datos modernos. Hoy en día, la atención se centra en sistemas de detección de intrusiones en bases de datos (IDS) más completos, el componente principal de una solución de seguridad de bases de datos moderna y avanzada. Con una visibilidad y un control superiores sobre la actividad de las bases de datos, permiten a las organizaciones detectar y responder a las amenazas actuales.

Aspectos de la seguridad de las bases de datos

Las soluciones de seguridad de bases de datos, las capacidades integradas de bases de datos, la auditoría de bases de datos, IDS, IPS y otras capacidades necesarias están todas interrelacionadas. Así pues, echemos un vistazo a la seguridad de las bases de datos para comprender qué es importante, qué necesitamos y cómo protegemos una base de datos.

Seguridad Básica

La seguridad básica de las bases de datos está integrada en ellas e incluye la autenticación (usuarios, contraseñas, etc.) y la autorización (privilegios, permisos, etc.). También puede incluir el cifrado de la red (datos en tránsito) y el cifrado de archivos o discos (datos en reposo). Además, puede haber parámetros de configuración relacionados con la seguridad que deban controlarse.

Todos estos elementos requieren una configuración adecuada y una revisión periódica. Un proceso de control de cambios es crucial para mantener el control sobre las configuraciones básicas de seguridad, y una solución de seguridad de bases de datos debe permitirte supervisarlas.

Control de Cambios

El control de cambios se basa en el principio de que el control de los cambios en la base de datos (incluida la seguridad básica) garantiza un entorno seguro permanente. El control de cambios de la base de datos tiene por objeto controlar la configuración, los objetos, los usuarios, los privilegios y los permisos.

El control se ejerce mediante dos mecanismos: un proceso de aprobación de las solicitudes de cambio antes de realizar los cambios y un proceso de auditoría que identifica todos los cambios para verificar su aprobación. Puedes implementar el proceso de auditoría a través de instantáneas de metadatos o utilizando el control de actividades. Éstos deben formar parte de una solución de seguridad de bases de datos.

Vulnerabilidades y Parches

Las vulnerabilidades desempeñan un papel menor en la seguridad de las bases de datos. La mayoría de las bases de datos son sistemas maduros con pocas vulnerabilidades por descubrir. Aunque los proveedores publican parches con regularidad, éstos suelen abordar vulnerabilidades difíciles de explotar y que rara vez son remotas. Casi todas las violaciones se producen por medios distintos a las vulnerabilidades no parcheadas o de día cero.

La exploración de vulnerabilidades no suele formar parte de las soluciones de seguridad de bases de datos, sino de soluciones que buscan vulnerabilidades en muchos tipos de sistemas, no sólo en bases de datos.

Cumplimiento de la Normativa

El cumplimiento se refiere a la adhesión a leyes y normativas diseñadas para proteger datos específicos, como información personal, tarjetas de crédito, datos financieros, información sanitaria y médica, etc. Para evitar la divulgación o manipulación no autorizadas, la ley (y los reglamentos derivados) exige a las empresas que protejan este tipo de información.

En última instancia, las normas de cumplimiento exigen aplicar una estrategia de seguridad. Más allá de centrarse en tipos específicos de información, los requisitos de cumplimiento difieren de la seguridad habitual en que exigen una estructura formal con documentación. La documentación sirve como prueba de las medidas adoptadas por la organización para proteger los datos, y los auditores pueden revisarla. La conformidad suele abarcar todos los demás tipos de seguridad, pero hace hincapié en el cumplimiento de un proceso y el mantenimiento de registros.

Dado que la conformidad es, esencialmente, seguridad, es algo que proporcionan la mayoría de las soluciones de seguridad para bases de datos. El cumplimiento no es una característica de una solución de seguridad, pero ciertas características son importantes para el cumplimiento. Por ejemplo, la elaboración de informes, el seguimiento de los cambios en las políticas y los informes, un repositorio a prueba de manipulaciones (un repositorio en el que los registros no se pueden actualizar ni eliminar), un largo periodo de conservación con una huella de almacenamiento mínima, etc.

Control de actividad y auditoría de bases de datos

El control de la actividad de la base de datos consiste principalmente en la auditoría (supervisión), pero también puede incluir la prevención avanzada (IPS). El control de actividad y la auditoría son cruciales para la seguridad de las bases de datos porque la mayoría de los ataques utilizan cuentas legítimas. Como control principal de las cuentas reales, el control de actividad es la defensa principal contra la mayoría de las violaciones de datos. Por ejemplo, el abuso de privilegios, el robo de credenciales y la inyección SQL son ejemplos de ataques que sólo el control de actividad puede abordar.

El control de la actividad incluye cuatro medidas principales:

• Visibilidad – Comprender el perfil de actividad de la base de datos utilizando análisis forenses proactivos y reactivos. Se trata de un control importante en sí mismo, pero también es esencial para diseñar el resto de los controles.
• Auditoría tradicional – Establecer políticas, reglas e informes sobre subconjuntos de la actividad de la base de datos que son de alto riesgo y bajo volumen. También se conoce como auditoría declarativa, y es un control central en el cumplimiento normativo.
• Análisis de anomalías – Identificar cambios en los perfiles de comportamiento de usuarios, aplicaciones, etc. Se trata de un control crítico para subconjuntos de gran volumen de la actividad, así como para reducir su inversión de tiempo.
• Preventivo (IPS) – Aplicar restricciones bloqueando la actividad de SQL. Por ejemplo, impedir que usuarios con privilegios accedan a datos confidenciales, aplicar la separación de funciones, etc.

Auditoría de cambios en los datos

Algunas normativas obligan a llevar un registro de todos los cambios realizados en determinados tipos de datos sensibles. Esto va más allá del seguimiento de quién hizo el cambio, cuándo y cómo… y se extiende al registro de los valores exactos que cambiaron. A veces se denomina imágenes antes y después. Por ejemplo, cuando una sentencia SQL cambia un salario de 1.000 a 2.000, la auditoría de cambio de datos registra tanto el valor original o la «imagen antes» (1.000) como el nuevo valor o la «imagen después» (2.000).

Este tipo de auditoría puede requerir un almacenamiento significativo en función de los datos que necesite auditar, la frecuencia con la que cambian y el periodo de retención. Hay diferentes maneras de implementar este requisito, incluidos los cambios en el código de la aplicación, los disparadores de la base de datos, los registros de rehacer y las tecnologías de auditoría avanzadas. Cada método conlleva un coste, una complejidad y una sobrecarga de rendimiento diferentes que debe tener en cuenta.

Aunque auditar los cambios en los datos es algo que se puede hacer utilizando el código de la aplicación o las funciones de la base de datos, utilizar las capacidades incluidas en una solución de seguridad de la base de datos es más fácil, más completo y tiene una menor sobrecarga.

Buenas prácticas de auditoría de bases de datos e IDS

Estas mejores prácticas para IDS de bases de datos y soluciones de auditoría le ayudarán a lograr una postura de seguridad fuerte. Es importante tener en cuenta que, si bien Core Audit puede cumplir fácilmente todas estas recomendaciones, otras soluciones podrían carecer de algunas de las capacidades.

1. Clasificar los riesgos por tipo de cuenta: Las bases de datos tienen diferentes tipos de cuentas como DBAs, cuentas de aplicaciones, cuentas de analistas, cuentas para herramientas y más. Cada tipo de cuenta tiene un perfil de actividad diferente y está sujeta a vectores de ataque distintos. Eso significa que para conseguir una seguridad eficaz, cada tipo de cuenta requerirá informes, anomalías, medidas preventivas, etc. diferentes.
2. Comience con Forense Proactiva: Antes de diseñar controles, utilice Proactive Forensics para comprender el perfil de actividad de su base de datos y el perfil de actividad de cada tipo de cuenta.
3. Implemente controles superpuestos y compensatorios: Siempre que sea posible, utilice varios controles de distintos tipos para aprovechar sus puntos fuertes y mitigar sus puntos débiles. Por ejemplo, los informes de cumplimiento proporcionan un tipo de seguridad diferente del análisis de anomalías, que difiere de las revisiones forenses ocasionales. Utilizar los tres tipos contra una amenaza dará como resultado una mejor protección.
4. Proteger las cuentas DBA y de usuarios con privilegios: Estas cuentas presentan una amenaza significativa debido a su poder ilimitado. Están sujetas a amenazas internas (abuso de privilegios) y externas (credenciales robadas). Implemente controles de sesión para detectar cuentas comprometidas y controles de actividad para supervisar los DDL, los DML, el acceso a datos confidenciales y la hora del día de actividad. Considerar medidas preventivas (IPS) para limitar el acceso de los DBA al esquema de datos y aplicar la separación de funciones.
5. Cuentas de aplicación seguras: Las cuentas de aplicaciones tienen acceso a todos los datos y son difíciles de supervisar debido al alto volumen de actividad. Utilice controles de sesión para detectar el uso no autorizado y controles de actividad como el análisis de anomalías para identificar la actividad sospechosa. Considere la supervisión del control de cambios para validar la aprobación de cambios y medidas preventivas para limitar las fuentes de actividad.
6. Abordar los riesgos de acceso local: Mitigar los riesgos asociados al acceso local al servidor de base de datos. Se trata de un vector de ataque popular en el robo de datos y los ataques de ransomware. Implemente controles de sesión para supervisar las conexiones locales y controles de actividad para identificar actividades sospechosas.
7. Controle otras cuentas: Identifique y evalúe los riesgos que plantean las cuentas utilizadas por analistas, gestores, etc. Implemente controles de sesión, controles de actividad y otros en función de los permisos de la cuenta y el perfil de actividad.
8. Mitigar las cuentas nuevas, no aprobadas e inactivas: Detecte y controle la creación y el uso de cuentas nuevas, los cambios de privilegios y, en general, la actividad de cuentas que antes no se veían (como las cuentas inactivas). El control tiene dos vertientes: En primer lugar, utilizando controles de sesión para supervisar las conexiones desde cuentas poco frecuentes y cualquier actividad que realicen. En segundo lugar, informando sobre los DDL relacionados con cuentas y privilegios.
9. Copias y extracciones de datos seguras: Es difícil, si no imposible, asegurar los datos una vez que salen de la base de datos. Gestione los riesgos asociados a los datos sensibles copiados fuera de la base de datos. Las operaciones de producción, como las réplicas y las copias de seguridad, requieren defensas equivalentes a las de todas las bases de datos sensibles. Las copias que no son de producción, como los datos para pruebas y desarrollo, requieren enmascaramiento de datos. Sin embargo, la extracción de datos para análisis externos en Excel y otras herramientas es motivo de preocupación. Si es posible, intente evitarlos. Si no, los datos deben enmascararse o protegerse de otra forma. Implemente controles de actividad para identificar los accesos a datos de gran volumen y una revisión forense ocasional para identificar las prácticas de riesgo.
10. Mejorar la eficacia de los controles: Realice un análisis de las deficiencias en la eficacia de los controles. Eso incluye estimar los falsos negativos (eventos no detectados) y el potencial de ataque desconocido (como el día cero). Hay tres métodos para el análisis de brechas: (a) basarse en los eventos marcados por una medida de seguridad y no por otra (ver controles compensatorios). (b) utilizar el análisis del perfil de actividad en la medicina forense proactiva para identificar posibles puntos débiles de los controles. (c) con un equipo rojo (o equipo DBA) que intente penetrar las defensas.

Estas prácticas garantizarán una postura de seguridad sólida. Pero tenga en cuenta que las organizaciones suelen seguir un camino de madurez, y adoptar un enfoque gradual suele ser más realista. Si desea más información, póngase en contacto con nosotros para obtener la Guía de Controles completa. La guía incluye muchos más detalles y recomendaciones.

El control de los datos es la base de la seguridad de los datos. Es la esencia de todos los requisitos de cumplimiento y establecer el control es el núcleo de lo que hacemos.

Mientras navegamos por el final de este año y nos preparamos para el siguiente, examinemos este requisito básico. Nuestra experiencia nos dice que muchas organizaciones tienen dificultades con los fundamentos, pero siga leyendo y vea cuál es su situación.

¿Qué es el control?

Controlar los datos significa controlar el acceso a ellos. En otras palabras, controlar la actividad. Pero, ¿qué significa en la práctica y cómo lo hacemos?

Lo que todo el mundo sabe es que gestionar el acceso a los datos implica dos actividades:

• Usuarios y permisos – ¿Quiénes son los usuarios y qué acceso necesitan?
• Supervisión – ¿Qué está ocurriendo en la realidad?

Todo el mundo tiende a centrarse en la primera e ignorar la segunda. Pero la aplicación correcta tiene que ser diferente, porque es imposible asegurar los datos sin saber lo que está ocurriendo con ellos. No se puede proteger lo que no se ve.

Establecer controles sobre los usuarios y el acceso sin saber lo que ocurre en realidad carece de sentido. No sólo carece de visibilidad sobre si los controles están funcionando según lo previsto, sino que ni siquiera sabe qué cosas están sucediendo que necesita detener. Usted está asumiendo que sus usuarios y permisos se comportan como imaginaba, pero esa suposición suele ser errónea.

El conocimiento es poder

Saber lo que ocurre es la base de cualquier seguridad. Un guardia de seguridad ciego y sordo deambulando por los pasillos no podrá detener a los delincuentes. La visibilidad es la clave del éxito.

¿Tienes el control?

Por desgracia, muchas organizaciones se quedan cortas en lo que a visibilidad se refiere. Carecen de las herramientas necesarias para responder a preguntas básicas como:

• ¿Quién accedió a mis datos la semana pasada?
• ¿Qué programas se utilizaron para acceder a los datos?
• ¿A cuántos datos se accedió?

Sin respuestas a estas y otras preguntas similares, es imposible establecer controles eficaces. ¿Cómo puede determinar sobre qué debe informar o alertar? ¿Qué hay que evitar?

Cuando preguntamos a los clientes por qué configuran determinadas alertas, solemos obtener respuestas vagas como “me lo recomendaron”, “es una buena práctica”, “me parece una buena idea”, etcétera.

Por tanto, no es sorprendente que estos controles rara vez produzcan incidentes de seguridad. La falta de falsas alertas positivas es indicativa de una seguridad ineficaz, porque significa que hay muchos falsos negativos (sucesos no detectados).

Visualiza tu actividad como nunca antes

La seguridad ha cambiado mucho en los últimos 20 años y las tecnologías y soluciones nacidas a principios de la década de 2000 se consideran hoy en día obsoletas. Las soluciones modernas como Core Audit pueden dar una visibilidad sin precedentes de la actividad utilizando Proactive Forensics y ese es el primer paso recomendado en las implementaciones.

Con Core Audit Proactive Forensics, usted puede:

• Visualizar fuentes de actividad para entender quién ejecuta actividad, cuánta, desde dónde y cuándo.
• Investigar los patrones de actividad para comprender quién accede, a qué datos, cuándo y cuánto.
• Profundizar en los subconjuntos de actividad y visualizar cada uno para determinar la mejor manera de controlarlo.

El análisis forense proactivo es una de las muchas funciones de Core Audit, como el análisis de anomalías, las auditorías declarativas, los controles preventivos y muchas más. Sin embargo, Proactive Forensics es el primer paso en las implementaciones que le ayuda a entender el perfil de actividad y determinar qué otros controles debe implementar.

No te conformes con menos

Si cree que comprende bien lo que ocurre dentro de sus bases de datos y aplicaciones, ¡enhorabuena! Pero si no es así, es hora de considerar una alternativa. Programe una demostración para ver lo que Core Audit puede ofrecerle y, a continuación, pruébelo en sus propios sistemas para experimentar una visibilidad real.

Póngase en contacto con nosotros hoy mismo y adopte el futuro de la seguridad de las bases de datos.

A medida que nos adentramos en 2025, el panorama digital sigue evolucionando, trayendo consigo inmensas oportunidades e importantes riesgos. Las ciberamenazas son cada vez más sofisticadas y se dirigen a empresas de todos los tamaños. Para que las organizaciones prosperen, una estrategia de ciberseguridad sólida ya no es un lujo; es una necesidad básica.

Escasa inversión en ciberseguridad

En relación a su PIB, Latinoamérica invierte entre 4 y 5 veces menos en Ciberseguridad que Norteamérica. El crecimiento previsto de los presupuestos de Ciberseguridad en Latam también es inferior al de NA.

Al mismo tiempo, las brechas de datos en Latinoamérica están en su punto más alto. Diferentes estudios muestran cifras diferentes en cuanto a los países más atacados, y los primeros de la lista suelen ser México, Brasil, Colombia y Perú. Sin embargo, toda Latinoamérica está bajo ataque, con muchas brechas de datos exitosas.

Con mayores riesgos y menor inversión, América Latina debe invertir de forma MÁS INTELIGENTE. Es la única manera de luchar contra las olas de ataques si se tiene recursos limitados.

Una inversión más inteligente

Lo ideal sería poder comprar y utilizar muchas soluciones que aborden todos los riesgos posibles, pero eso no es realista. Nadie tiene presupuesto ni personal suficientes para hacer realidad esa fantasía.

La solución consiste en identificar unos pocos elementos críticos que impidan una filtración de datos y crear una inversión equilibrada en todos ellos. Hable con nosotros para obtener más información sobre cómo equilibrar el perímetro frente a los datos, los IPS frente a los IDS y mucho más. Permítanos ayudarle a crear en conjunto una defensa ganadora.

Ciberseguridad con un presupuesto optimizado

En Blue Core Research comprendemos la importancia de equilibrar las necesidades de seguridad con las limitaciones presupuestarias. Nuestro equipo de expertos trabaja en estrecha colaboración con los clientes para crear enfoques personalizados que se ajusten a su presupuesto y, al mismo tiempo, maximicen la protección de sus datos.

Cómo podemos ayudarle a optimizar su presupuesto de ciberseguridad

Comienza con una conversación para entender tus necesidades: Queremos entenderte a vos y tu situación particular. Tus motores, necesidades, expectativas, entorno, etc. Cuanto más sepamos sobre vos y tu organización, mejor podremos elaborar un plan que responda a tus necesidades y se ajuste a tu presupuesto.

Crear un enfoque personalizado: Nuestras soluciones pueden utilizarse de muchas maneras en función de los recursos disponibles. Sugeriremos un enfoque diferente para la implantación en función del número de sistemas, el personal disponible, el nivel de seguridad previsto, etc. Encontraremos la forma de sacar el máximo partido a sus recursos.

Precios agresivos: Queremos cuidar de tu negocio y vamos a trabajar en conjunto con vos para encontrar la manera. Podemos sugerirte diferentes niveles de seguridad y encontrar la forma de cubrir todo lo que necesites. Tenemos precios agresivos para ayudarle a cumplir sus objetivos presupuestarios.

Invertí en tranquilidad

Trabaja con nosotros para asegurarte de que tu presupuesto para 2025 incluya las soluciones de primera categoría que necesitas para luchar contra los ciberataques, las filtraciones de datos y mucho más.

Recordá que un plan presupuestario sólido no es un gasto, sino que es una inversión en el futuro de tu empresa.

Ponte en contacto con nosotros hoy mismo para hablar de tus necesidades específicas y saber cómo podemos ayudarte a protegerte de las inminentes amenazas.

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.