Posted on

Cómo Auditar una Base de Datos Oracle

La auditoría de Oracle es un tema amplio, complejo y confuso, con muchas opciones tecnológicas. Nuestro objetivo es desmitificarlas y ayudarle a tomar decisiones tecnológicas con conocimiento de causa, guiándole hacia una solución que funcione para usted. Desde la captura de datos hasta la obtención de valor a partir de ellos y desde el bricolaje hasta las soluciones de gama alta, vamos a explorar la auditoría de Oracle.

Captura

La captura es la recopilación de datos en bruto. La auditoría siempre empieza 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 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, con implicaciones de gran alcance sobre lo que está disponible para procesar.

Desafíos

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

El problema subyacente es que Oracle ejecuta enormes cantidades de actividad a velocidades increíbles. Cualquier interferencia con esta máquina altamente ajustada puede paralizar el rendimiento y ralentizar la base de datos hasta convertirla en un rastreo. Por tanto, el impacto en el rendimiento es el mayor reto para capturar la actividad.

Un segundo obstáculo es que normalmente debemos auditar a los DBA. Sin embargo, estas cuentas privilegiadas controlan las tecnologías de captura integradas en la base de datos, lo que las hace ineficaces para supervisar la actividad privilegiada.

La cuenta SYS en Oracle es especialmente problemática, ya que muchas instalaciones de auditoría no capturan su actividad. Esto se debe a que SYS es una cuenta integrada en la base de datos, y también se utiliza para la actividad interna de la base de datos.

Otra dificultad es la actividad interna de la base de datos. Oracle tiene muchas capacidades que ejecutan actividad internamente y no son visibles desde el exterior, como bloques anónimos PL/SQL a procedimientos, disparadores, programas Java internos y trabajos programados. Algunas tecnologías de captura (específicamente la inspección de paquetes) sólo pueden ver la actividad fuera de la base de datos y no verán las SQL, tablas y columnas de la actividad interna.

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

¿Qué datos podrías recopilar?

Cuando se audita una base de datos Oracle, existen diferentes tipos de información que puede necesitar recolectar.

El requerimiento más básico es capturar Logons y Logons Fallidos. Esto significa monitorizar las conexiones a la base de datos (o sesiones) y dónde se originan. Esto incluye datos como la hora de conexión, la hora de desconexión, el nombre de usuario, el programa, la dirección IP, etc.

Otro requisito común son las SQL. Los SQL son los comandos ejecutados en las sesiones. Se dividen en tres categorías: DDL, DML y Consultas (select). Este desglose es importante porque las consultas no son fáciles de capturar y limitan las tecnologías de captura que podemos utilizar. La captura de consultas es fundamental para detectar el robo de datos, la captura de DML sirve para identificar cambios no autorizados y los DDL están relacionados con el control de cambios. Si el robo de datos es un riesgo, hay que capturar consultas, y esa tecnología de captura permitirá capturar cualquier SQL.

La captura selectiva es una forma de reducir la sobrecarga al no capturar todos los SQL. También simplifica el procesamiento, ya que hay muchos menos datos. No es ideal porque se perderá mucha información, pero es la única forma con capacidades de auditoría de Oracle incorporadas. Incluso si captura todo, debe considerar qué hará con los datos capturados. La captura selectiva puede ser una buena opción si más tarde descarta la mayoría de los datos capturados y sólo graba unos pocos SQLs (ver más en la sección de obtención de valor más abajo).

La captura de valores antes y después no es un requisito frecuente, excepto en algunos sectores en los que es necesario para el cumplimiento de la normativa (especialmente la banca y las finanzas). Antes y después de los valores significa auditar los valores que cambian en la base de datos. Si alguien, por ejemplo, actualiza los salarios utilizando salario=salario*2, este tipo de captura registrará todos los salarios originales y los salarios posteriores al cambio. En este ejemplo, no hay valores en el SQL, lo que explica por qué la captura SQL, incluso con variables bind, no satisface esta necesidad.

Otra función que no es de auditoría pero que está relacionada con la tecnología de captura es el bloqueo. El bloqueo permite impedir la ejecución de determinadas sentencias SQL. Se trata de una potente capacidad preventiva que, en algunas soluciones, está integrada en el motor de captura. Por último, existe una forma simplificada de auditoría que aprovecha las instantáneas de metadatos. Por ejemplo, se pueden identificar los cambios entre la lista de usuarios de ayer y la de hoy. Es un tipo de supervisión del control de cambios y puede aplicarse a la configuración, los usuarios, los permisos y los objetos (por ejemplo, tablas, vistas, etc.).

Tecnologías Disponibles

Esta tabla resumen muestra qué tecnología de auditoría es relevante para qué captura de datos. Como puede ver, casi nada es perfecto. Estas tecnologías también tienen muchas limitaciones y desventajas, y varias están relacionadas. Así que lea los detalles a continuación.

Inicios de
Sesión		SQLsAntes y Después
de Valores		Metadata
Snapshot		Bloqueo
DDLDMLConsultas
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 puede crear internamente sin tecnología ni procesamiento complejos. Por ejemplo, puede tomar una instantánea diaria de los usuarios de la base de datos e identificar los cambios del día anterior. No es una seguridad sólida, pero ayudará a validar el control de cambios. Aparte de sus capacidades limitadas, el principal inconveniente de éste y de cualquier proyecto DIY es el tiempo y el esfuerzo que su equipo de DBA tendrá que invertir en la implementación, el mantenimiento y el funcionamiento.

Auditoría Tradicional

La Auditoría Tradicional (utilizando la sentencia AUDIT) ofrece una auditoría selectiva de Oracle. Puede elegir auditar tipos específicos de sentencias, acceso a tablas particulares, o actividad de usuarios específicos (y algunas combinaciones de estos). La opción de configuración audit_trail controla cómo se registran los datos con opciones de os, db, xml y extended añadidas a las dos últimas.

Este es el método principal para la auditoría nativa de Oracle. Oracle lo está eliminando gradualmente y reemplazando con la Auditoría Unificada más completa. Las principales limitaciones de la auditoría tradicional son:

  • Los registros de auditoría contienen principalmente la hora, la cuenta de la base de datos, la cuenta del sistema operativo, la máquina y el nombre de la tabla. Si se añade la opción ampliada, también se registrará el SQL. Sin embargo, no es la solución adecuada si necesita información adicional, como la dirección IP.
  • No captura la actividad del SYS. SYS puede incluso purgar los datos de auditoría sin ningún mensaje. Se trata de una limitación paralizante que requiere otra función de Oracle (SYS auditing) para compensarla. También es la principal ventaja de la nueva Auditoría Unificada.
  • Su capacidad para controlar a los DBA es limitada, ya que son ellos quienes la administran. El registro contiene acciones que manipulan la auditoría y purgan datos, pero éstas pueden excusarse fácilmente.
  • El impacto en el rendimiento es el mayor problema, con un impacto base de más del 1.000% para SQLs cortos (audit_trail=db). Cuando también se registra el texto SQL, el impacto es del 2.000% (audit_trail=db, extended). Cuando se escribe en el sistema operativo, la sobrecarga es superior al 800% (audit_trail=os). La opción XML es irrelevante, con una sobrecarga de más del 80.000%.
    Incluso activar audit_trail=db en lugar de audit_trail=none supone una sobrecarga del 20%. Y eso sin auditar nada. La razón es que una vez que el sistema de auditoría está activado, Oracle evalúa las reglas de auditoría, y ese proceso de evaluación crea una sobrecarga incluso cuando no hay reglas de auditoría.
  • Sólo se puede registrar un volumen limitado de actividad. Las sobrecargas superiores al 5% se consideran inaceptables en entornos Oracle, por no mencionar la huella de disco resultante. La elevada sobrecarga de la auditoría tradicional significa que sólo es práctica si se limita a un pequeño número de SQL.
  • La complejidad de la administración, como la creación de reglas de auditoría y la gestión de los datos de auditoría, también es significativa. Esto se traduce en el tiempo de DBA necesario para gestionar la auditoría nativa de Oracle.
  • Otras utilidades de Oracle, como RMAN, SQL Loader y Data Pump, también pueden acceder a los datos. […]

Auditoría de grano fino (FGA)

La auditoría de grano fino (FGA) es una función de auditoría de Oracle que pretende mejorar la funcionalidad de la auditoría tradicional siendo aún más selectiva. FGA puede limitar la auditoría al acceso a columnas específicas o sólo auditar el acceso a filas concretas (como departamento=5 o salario>1000). FGA pretende resolver los problemas de rendimiento cuando se auditan tablas con un alto volumen de actividad.

Sin embargo, limitar las filas y columnas es una solución pobre, y FGA se utiliza raramente. Los clientes que se encuentran con este tipo de problemas suelen optar por otros métodos de auditoría que no requieren ser tan selectivos. Por ejemplo, con Core Audit se pueden auditar 1.000 millones de SQL con menos del 3% de sobrecarga y utilizando 32 GB de espacio en disco.

Auditoría SYS

La auditoría SYS se refiere al parámetro de configuración de Oracle AUDIT_SYS_OPERATIONS. Cuando se establece en true, registra toda la actividad del usuario SYS. Es vital porque SYS es una cuenta de base de datos incorporada a la que los DBAs siempre pueden acceder y no puede ser auditada por la auditoría tradicional. Los usuarios SYS también pueden borrar información de los datos de auditoría sin dejar rastro. SYS es un usuario complicado de auditar porque la base de datos lo utiliza internamente.

La auditoría SYS tiene importantes limitaciones:

  • No registra la actividad interna de la base de datos, sólo la externa. Esto significa que no es difícil de eludir.
  • No puede ser selectiva y registra automáticamente toda la actividad del SYS.
  • Si los DBA pueden acceder al sistema operativo, pueden borrar o manipular los datos de auditoría.
  • Tiene una sobrecarga superior al 1.200%. Cuando se mide con ida y vuelta de red (que es más apropiado para transacciones externas), la sobrecarga es superior al 90%.
  • Los datos de auditoría suelen contener mucho ruido procedente de diversas actividades y operaciones internas de la base de datos. Es casi imposible localizar información significativa en su interior si no se sabe lo que se está buscando.

Auditoría Unificada

La Auditoría Unificada (usando una POLÍTICA DE AUDITORÍA) es el nuevo mecanismo de auditoría incorporado en Oracle que combina características de la auditoría tradicional, FGA y SYS. Tiene mejor cobertura, pero la sobrecarga es mucho peor.

Por el lado bueno, la auditoría SYS es mucho más completa y similar a la de otros usuarios. Se registra la actividad interna del SYS y sólo lo que requiere la política (por tanto, menos ruido). Unified Auditing también puede registrar la actividad de otras herramientas de Oracle. Todo esto se combina para una cobertura mucho mejor.

Pero las limitaciones son:

  • Los registros de auditoría contienen principalmente la hora, la cuenta de la base de datos, la cuenta del sistema operativo, la máquina, la aplicación, el nombre de la tabla y el texto SQL. No es la solución adecuada si se necesita información adicional, como la dirección IP.
  • Los DBA lo administran, por lo que no puede controlarlos eficazmente. Aunque hay un registro de acciones que detienen la auditoría y purgan los datos, éstas pueden excusarse fácilmente.
  • El impacto en el rendimiento es el mayor problema, con una sobrecarga de alrededor del 4.000% para SQLs cortos.
  • Sólo se puede auditar un volumen limitado de actividad. Cualquier sobrecarga superior al 5% es inaceptable en entornos Oracle, por no mencionar la huella de disco aún mayor. La Auditoría Unificada no es práctica a menos que se limite a un pequeño número de SQLs.
  • La complejidad de la administración, como la creación de las reglas de auditoría y la gestión de los datos de auditoría, es significativa. Eso significa tiempo de DBA que se requiere para gestionar Oracle Unified Auditing.

La conclusión es que la Auditoría Unificada puede ser una buena opción para una captura de bajo volumen con el fin de cumplir requisitos de conformidad menores (véase más adelante). Capturar la actividad en mesas activas o pretender utilizar los datos para análisis, como perfiles de comportamiento y anomalías, no es realista.

Triggers

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

Existen tres tipos de disparadores. Los disparadores de inicio de sesión se activan cuando alguien inicia sesión. Puede utilizarlos para auditar la actividad de inicio de sesión. Aunque es posible, es un enfoque de auditoría poco común para las sesiones. También hay disparadores DDL y DML. Sin embargo, el texto SQL sólo es visible en un número limitado de casos.

Sin embargo, los disparadores DML pueden auditar los valores antes y después. Es un método realista para auditarlos.

El problema con los triggers es que se ejecutan como parte del SQL y aumentan el tiempo que tarda en finalizar. Dado que los desencadenadores de auditoría suelen registrar información en otras tablas, tienden a causar una sobrecarga elevada al añadir otro DML al DML actual. En otras palabras, los disparadores DML en tablas altamente transaccionales causan 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 para las consultas. Los triggers son irrelevantes cuando se trata del riesgo de robo de datos.

Registros de Logs

Logminer o Registro de Logs es una función de Oracle que puede extraer información de los redo logs de Oracle. Los redo logs forman parte del funcionamiento de Oracle. Contienen todos los cambios en la base de datos y se utilizan para la recuperación de fallos. Independientemente de su función principal en la recuperación de fallos, puede procesar los redo logs para extraer todos los valores anteriores y posteriores. Esto es útil para seguridad, replicación y otros propósitos.

El uso de los redo logs es beneficioso porque el procesamiento se realiza una vez finalizada la actividad de la base de datos. Aunque el procesamiento consume recursos de la máquina, ocurre en paralelo y no ralentiza las transacciones de la base de datos.

Aunque siempre puede procesar los redo logs con Logminer, puede extraer información de mejor calidad si solicita a Oracle que capture información adicional. Puede hacerlo con un SQL como «ALTER DATABASE ADD SUPPLEMENTAL LOG DATA». Tenga en cuenta que puede registrar distintos tipos de datos de registro suplementarios.

Los redo logs de Oracle también tienen un ciclo en el que los redo logs anteriores se copian a una ubicación separada y se denominan Archive logs. Las bases de datos de producción siempre tienen registros de archivo configurados, pero el tiempo de retención depende del entorno. Sin embargo, Logminer puede extraer tanto los registros de archivo como los registros de rehacer en línea. Sólo necesita tener los registros en algún lugar para minarlos.

Puede acceder al Registro de Logs con la ayuda de un DBA o utilizando una solución como Core Audit.

Inspección de Paquetes

La tecnología de Inspección de Paquetes o Packet Inspection 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. Esto suele ser inaceptable. La mayoría de las implantaciones utilizan el agente local. Esto permite a la solución capturar la comunicación local, pero genera una elevada sobrecarga de red.

Ambos métodos de despliegue plantean problemas con la codificación de la red, pero una de las limitaciones más importantes es la falta de visibilidad dentro de la base de datos. Esto significa que se puede intentar deducir lo que ocurre dentro de la base de datos basándose en el SQL, pero no siempre es posible. Esto se debe a que las bases de datos pueden ejecutar procedimientos, disparadores, programas Java y bloques anónimos. Todos ellos son fragmentos de código que pueden generar SQL dentro de la base de datos. SQLs que serían invisibles para una solución basada en la inspección de paquetes.

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 o Captura Total 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 la actividad de Oracle. La calidad de la información es superior a la de cualquier otro método, con una sobrecarga insignificante, y los DBA no pueden obviarla.

Full Capture hace 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.

También puede capturar los valores anteriores y posteriores mediante la integración con disparadores de baja sobrecarga y Logminer. Así que tiene ambas alternativas con diferentes pros y contras.

Por último, Full Capture tiene capacidades de bloqueo que pueden devolver errores o advertencias para SQLs ofensivos. A diferencia de la inspección de paquetes, Full Capture no tiene agujeros de temporización u otros agujeros de seguridad.

Conclusión sobre la Captura

La parte más difícil de la captura son las consultas. Normalmente, también es la más importante, ya que está relacionada con el robo de datos. Una vez que se tienen las consultas, se tiene la mayoría del resto de la información. Si además necesita valores de antes y después, puede conseguirlo en Oracle sin interfaz de usuario o como parte de una solución que lo soporte.

Esto significa que tiene cuatro opciones básicas:

  • Hágalo usted mismo (DIY) – Utilice Auditoría Unificada para capturar la actividad y procesarla usted mismo (ver más abajo). También puede añadir disparadores para registrar valores anteriores y posteriores o extraer la información de Logminer. No hay costes de licencia, pero lleva mucho tiempo construirlo y mantenerlo. No lo recomendamos porque suele ser un proyecto interminable con resultados poco satisfactorios.
  • Solución de bajo coste: – Soluciones que utilizan una de las funciones de auditoría nativas de Oracle, como la auditoría tradicional o unificada. Estas soluciones se encargan del almacenamiento y la generación de informes, pero dependen de la base de datos para realizar la captura. La auditoría DBA es ineficaz debido al método de captura. Además, estas soluciones no pueden escalarse para registrar un gran volumen de SQL. Esto puede ser aceptable para algunos requisitos de cumplimiento, pero nada más. No pueden proporcionar una seguridad de calidad sin una supervisión eficaz de los DBA, una grabación de mayor volumen para el acceso a datos sensibles y las anomalías necesarias para el control de las aplicaciones.
  • Solución de inspección de paquetes – Solución de auditoría de gama alta que examina los paquetes de la base de datos. Puede manejar mucho más volumen que las soluciones de bajo coste, pero proporciona informes en la misma línea. En cierto modo, son peores que las soluciones de bajo coste que se basan en Unified Auditing, ya que los inspectores de paquetes no pueden ver la actividad interna de la base de datos. Estas soluciones son razonables para el cumplimiento, pero ofrecen una seguridad limitada.
  • Core Audit – Es una solución de gama alta que puede capturar todo lo que necesita y proporcionar potentes informes, alertas y análisis. No tiene limitaciones ni agujeros de seguridad, y ofrece la seguridad más completa.

Obteniendo 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 no sirve para nada por sí solo. 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 es decidir qué registrar y cómo crear informes significativos a partir de los datos. Los informes eficaces se basan en tres principios básicos:

  1. El tema del informe debe ser realista en su entorno. Este tipo de informes 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 supone ningún reto técnico una vez que se dispone de los datos capturados. Sólo se necesita un repositorio, un motor de generació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 informes incorporados para empezar. Y lo que es más importante, dispone de un análisis forense proactivo que le ahorra tiempo al ayudarle a averiguar qué incluir en los informes.

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 hay nuevos usuarios activos 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, potenciales ataques de inyección SQL, y mucho más. Hay muchas formas de cortar, dividir, comparar y contrastar la actividad para encontrar comportamientos anómalos.

Análisis forense reactivo. La investigación forense reactiva consiste en obtener detalles adicionales sobre los eventos de seguridad. Estos eventos pueden ser una línea sospechosa en un informe, una violación potencial, una indicación de otra fuente, y más. Sea cual sea el suceso, siempre es necesario saber más sobre lo que ha ocurrido.

El reto es disponer de un repositorio con la información. En la mayoría de las soluciones, usted 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. No se pueden diseñar informes de cumplimiento eficaces ni alertas de anomalías sin una comprensión sólida de lo que ocurre en la base de datos. Ni siquiera puedes comprender las amenazas a las que te enfrentas.

No se puede asegurar lo que no se puede ver, y el análisis forense proactivo es un primer paso muy recomendable para proteger su base de datos Oracle. Pero también es fundamental para identificar las malas prácticas de seguridad, ataques y brechas, cambios en los patrones de comportamiento, las lagunas en los controles que ha desplegado, y mucho más.

Core Audit Proactive Forensics incluye herramientas de análisis gráfico para visualizar los perfiles de actividad desde varias dimensiones. Por ejemplo, dispone de pilas basadas en el tiempo, gráficos de árbol, gráficos Sunburst, un Sankey, gráficos de red, etc.

Soluciones Oracle

Además de las tecnologías de captura, Oracle ofrece dos soluciones de seguridad. Éstas no forman parte de la licencia de la base de datos e incurren en importantes costes adicionales, por no hablar de la configuración, administración, etc.

Audit Vault y Database Firewall (AVDF)

Oracle Audit Vault and Database Firewall es una solución de inspección de paquetes que puede complementar sus datos a partir de funciones de auditoría nativas de Oracle como Traditional Auditing, FGA, SYS auditing y Unified Auditing. A pesar de su confuso nombre, se trata de una única solución que contiene funciones de auditoría y prevención.

Esta malla de tecnologías (inspección de paquetes y auditoría nativa) pretende compensar las limitaciones de cada método de captura. Las soluciones de inspección de paquetes que sólo se basan en la red, como AVDF, no pueden ver la actividad local o interna de la base de datos. La actividad local de la máquina es crítica ya que contiene actividad privilegiada desde dentro de la máquina y, en algunos casos, actividad de la aplicación cuando la aplicación se ejecuta en el servidor de base de datos. Por lo que respecta a la auditoría nativa, cada función tiene sus propias limitaciones, pero todas se ven limitadas por el volumen de actividad que pueden gestionar.

La solución combinada puede capturar toda la actividad externa y parte de la local e interna, siempre que el volumen no sea elevado. Sin embargo, AVDF no puede fusionar las fuentes de datos, por lo que las almacena de forma independiente. Eso significa que hay un solapamiento significativo entre la actividad capturada por la auditoría nativa y la capturada por la inspección de paquetes.

Bóveda de Bases de Datos (DV)

Database Vault es una medida preventiva, no una solución de auditoría. Su objetivo es limitar el acceso de los DBA del sistema y evitar que accedan al esquema de datos.

DV redefine las funciones de administración de bases de datos de forma diferente y las aísla en varias categorías. Sin embargo, la administración del esquema de datos sigue siendo la misma y probablemente se asigne a uno o varios DBA. Por tanto, aunque tiene algunas ventajas, no resuelve el problema.

La DV es una solución increíblemente complicada e intrusiva que, en última instancia, no aporta mucha seguridad. Hay soluciones más fáciles y efectivas, como Core Audit, que son más efectivas y menos intrusivas para la organización.

Mejores Prácticas

A continuación se indican algunos pasos básicos de buenas prácticas que le ayudarán a empezar:

  1. Defina sus drivers. ¿Quiere cumplir una normativa concreta o proteger su base de datos contra algunas amenazas? ¿Por qué realiza este proyecto y qué pretende conseguir? Es difícil tener éxito sin objetivos.
  2. Identifique los recursos disponibles y defina el marco. ¿Hay un plazo de ejecución? ¿Existe un presupuesto? ¿Quién participará en el proyecto y está familiarizado con Oracle? Conocer sus recursos le permite definir objetivos realistas.
  3. ¿Cuáles son sus requisitos de captura? ¿Es el robo de datos un riesgo y necesita capturar las consultas? ¿Le preocupan los cambios no autorizados en los datos? ¿Necesita capturar valores anteriores y posteriores? ¿Le preocupa el abuso de privilegios? Esto se deriva de sus riesgos, necesidades de seguridad y requisitos de conformidad.
  4. ¿Qué valor espera obtener de los datos? ¿Necesita informes de conformidad o alertas de anomalías? ¿Le preocupa la inyección SQL? Depende del nivel de seguridad y de cumplimiento de la normativa que desee alcanzar.
  5. Elige un enfoque. Tus recursos y objetivos te orientarán rápidamente entre el bricolaje, un producto de bajo coste o una solución de gama alta. Póngase en contacto con algunos proveedores para obtener demostraciones y presupuestos que le permitan cuantificar los costes y calibrar el valor potencial. Póngase en contacto con nosotros y le proporcionaremos más información y asistencia de forma gratuita.
  6. Si se trata de un proyecto de DIY o si va a comprar una solución de bajo coste, tendrá que experimentar en producción. Así se asegurará de que el impacto en el rendimiento es aceptable y determinará los filtros que necesita para una huella de almacenamiento razonable. Cuando utilice Core Audit, comience con Proactive Forensics para comprender el perfil de actividad de su base de datos y diseñar sus controles.
  7. Audite el acceso local, los DBA y las cuentas privilegiadas. El acceso local es un vector de ataque popular en el robo de datos y ataques de ransomware. Las cuentas DBA también son un vector de alto riesgo para el robo de credenciales y el abuso de privilegios.
  8. Con Core Audit, controle la cuenta de aplicación. Las cuentas de aplicación son el objetivo de la inyección SQL y otras vulnerabilidades de las aplicaciones. Auditarlas requiere una captura y un análisis de anomalías de alto nivel.
  9. Examine otras cuentas que necesite controlar. Tenga en cuenta las cuentas nuevas, no aprobadas e inactivas.
  10. Mejore la eficacia del control. Realice un análisis de deficiencias para determinar la eficacia de sus controles. Eso incluye estimar los falsos negativos (eventos no detectados) y el potencial de ataques desconocidos (como los de día cero). Existen varios métodos para hacerlo.

Reflexiones finales

Existen múltiples tecnologías y soluciones para proteger una base de datos Oracle. Van desde el bricolaje hasta productos de bajo coste y 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 mejor enfoque para su caso particular.

Posted on

¿Cuál es la diferencia entre Auditoría y Monitoreo?

¿Cuál es la diferencia entre Auditoría y Monitoreo?

Auditoría y supervisión en IT no son lo mismo; aunque ambas implican vigilancia, tienen propósitos, herramientas y tecnologías distintas. Comprender sus diferencias es clave para el éxito operativo y la comunicación en los equipos.

¿Qué es Auditoría?

En IT, la auditoría es una función normalmente asociada a la seguridad y al cumplimiento de la normativa. También se conoce como supervisión de la actividad y se centra en el seguimiento de lo que hacen los usuarios y administradores dentro de los sistemas informáticos. Esto es especialmente importante en los sistemas que manejan información confidencial.

¿En qué consiste la Auditoría?

El objetivo de la auditoría es supervisar la actividad del sistema con fines de seguridad y cumplimiento. Entre los objetivos clave se incluyen:

  • Cumplir los requisitos normativos
  • Detectar accesos no autorizados o amenazas internas.
  • Alertar a los equipos de seguridad de actividades sospechosas
  • Identificar prácticas de seguridad deficientes
  • Realizar investigaciones forenses (tanto proactivas como reactivas).

Las auditorías se centran en los sistemas que manejan datos sensibles, como bases de datos y aplicaciones críticas.

Un Centro de Operaciones de Seguridad (SOC) lleno de grandes pantallas, cuadros de mando y luces parpadeantes es un ejemplo de cómo las organizaciones pueden identificar y responder a los eventos de seguridad. Los operadores del SOC revisan constantemente los sucesos relacionados con la seguridad para mantener protegida a la organización.

Los equipos SOC utilizan sistemas SIEM que reciben eventos relacionados con la seguridad a través del protocolo SYSLOG. La auditoría puede alimentar eventos a las operaciones de seguridad como el SOC enviando mensajes SYSLOG al SIEM.

Otro significado de Auditoría informática


La auditoría informática también puede referirse a una auditoría realizada por un auditor interno o externo. En una auditoría informática, un auditor examina los controles de seguridad utilizados para proteger los sistemas informáticos. Una auditoría inspeccionará el alcance, el plan y la aplicación de los controles de seguridad. Superar una auditoría de TI es un paso esencial en el cumplimiento de la normativa.

¿Qué es el Monitoreo?

En esencia, supervisar significa observar y comprobar el progreso o la calidad de algo. En TI, la supervisión suele referirse al trabajo realizado por los equipos de Operaciones. El objetivo es sencillo: garantizar el buen funcionamiento de todos los sistemas informáticos.

A diferencia de la auditoría informática, que sólo cubre los sistemas con información sensible, la supervisión abarca todos los componentes de la infraestructura, desde bases de datos y aplicaciones hasta conmutadores de red, enrutadores, cortafuegos y más.

¿En qué consiste el Monitoreo?

La supervisión hace un seguimiento de la salud y el rendimiento generales de la infraestructura informática. Esto incluye:

  • Detectar si los ordenadores, servidores o servicios no funcionan.
  • Garantizar la conectividad de la red
  • Identificar problemas de rendimiento, como aplicaciones lentas.
  • Supervisar el uso de recursos para detectar poco espacio en disco, falta de memoria, CPUs cargadas, etc.

Por lo general, los equipos de operaciones supervisan los sistemas 24 horas al día, 7 días a la semana, utilizando herramientas de supervisión de red basadas en SNMP. Si algo va mal, toman medidas correctivas o elevan el problema al responsable correspondiente o al experto de guardia.

Un Centro de Operaciones de Red (NOC) lleno de grandes pantallas, cuadros de mando y luces parpadeantes es un ejemplo de cómo pueden supervisar las organizaciones. Los operadores de NOC mantienen todo en perfecto funcionamiento supervisando constantemente la infraestructura para detectar fallos del sistema y problemas de rendimiento.

Otros significados de Monitoreo

El monitoreo de la actividad es otro término para referirse a la auditoría. Por ejemplo, la Auditoría de Bases de Datos también se conoce como Monitorización de Actividad de Bases de Datos (DAM).

La monitorización también puede referirse a la monitorización de eventos de seguridad. A veces se denomina Vigilancia de la Seguridad, SIM (Vigilancia de la Información de Seguridad) o SEM (Vigilancia de Eventos de Seguridad). Es el análisis realizado sobre varios eventos de seguridad, incluidos los originados por la auditoría. Es, esencialmente, el trabajo realizado por los equipos SOC que utilizan un SIEM (Security Information Event Management).

La vigilancia también puede referirse a la supervisión de la gestión, y el término Vigilancia del Cumplimiento se refiere a la supervisión de la gestión de las operaciones de seguridad y cumplimiento. El objetivo es evitar el incumplimiento mediante la evaluación continua del cumplimiento de la normativa.

Diferencias Clave

MonitoreoAuditoría o Monitoreo de ActividadesMonitoreo de Seguridad
(SIM, SEM, SIEM)
PropósitoGarantizar el funcionamiento de los sistemasSeguimiento de la actividad de los usuarios para garantizar la seguridad y el cumplimiento de la normativaAnalizar los eventos de seguridad para garantizar la seguridad y el cumplimiento
Qué Sistemas?Toda la infraestructura informática (redes, servidores, aplicaciones, etc.)Sistemas específicos que manejan información sensible (bases de datos, aplicaciones críticas)La mayor parte de la infraestructura informática (redes, servidores, bases de datos, etc.)
Tipo de DatoTiempo de actividad, información sobre rendimiento, utilización de recursosDatos de actividad de los usuarios (inicios de sesión, acceso a datos)Eventos de seguridad (errores, advertencias y accesos específicos)
Volumen del DatoBajo a moderado (miles a millones de métricas por hora en todos los sistemas)Alta (millones a decenas de millones de eventos por hora por sistema auditado)Bajo a moderado (miles a millones de métricas por hora en todos los sistemas)
ResponsabilidadEquipo de operaciones
(por ejemplo, NOC)		Equipo de seguridad(por ejemplo, SOC)Equipo de seguridad(por ejemplo, SOC)

¿Por qué hay tanta confusión?

El primer motivo de confusión es que tanto Auditoría como Supervisión pueden referirse a varias cosas diferentes. Normalmente hay que determinar el significado correcto en función del contexto.

También hay mucho solapamiento en la terminología, ya que algunos profesionales de la seguridad se refieren a la auditoría como Monitorización de Actividades. La auditoría también genera eventos de seguridad que posteriormente son analizados por la monitorización de seguridad y es, por tanto, un precursor de ésta.

Para hacer las cosas más confusas, los equipos de TI modernos pueden combinar funciones de operaciones y seguridad en SecOps, DevSecOps y OpSec, difuminando las líneas entre supervisión y auditoría.

Otro punto de confusión es la similitud entre un Centro de Operaciones de Red (NOC) y un Centro de Operaciones de Seguridad (SOC). Aunque ambos funcionan las veinticuatro horas del día y supervisan los sistemas, el NOC se centra en la disponibilidad, mientras que el SOC lo hace en la seguridad.

Conclusión

Si usted es un profesional de operaciones de TI, su objetivo principal es la supervisión, es decir, asegurarse de que todo funciona correctamente. Si se dedica a la seguridad, le preocupa más la auditoría, es decir, el seguimiento de la actividad para evitar infracciones y mantener la conformidad.

Ambos son fundamentales para el buen funcionamiento de un entorno informático, pero desempeñan funciones distintas. Una diferenciación adecuada puede ayudar a las empresas a aplicar las estrategias correctas para garantizar la seguridad y el tiempo de actividad.

Haz una Pregunta

Si tienes una pregunta o coentario, por favor hazlo saber. Estaremos felices de escuchar de ti.

Posted on

Análisis Forense Reactivo y Auditoría: Sigue a Sherlock Holmes

Análisis Forense Reactivo y Auditoría: Sigue a Sherlock Holmes

Una Investigación Forense Reactiva (también conocida como investigación forense «muerta») es el equivalente informático de un detective que analiza la escena de un crimen. Al igual que Sherlock Holmes reconstruía los hechos de un crimen mediante pistas, rastros y métodos deductivos, la investigación forense reactiva trata de responder a preguntas esenciales como ¿quién lo hizo, cuándo, cómo, etc.? Básicamente: ¿qué ocurrió?

Sherlock Holmes y la recogida de pruebas

En sus historias, Holmes analiza cada detalle de la escena del crimen para formular una hipótesis. Eso es exactamente lo que hace la forense reactiva, sólo que en el mundo digital: examinar archivos, registros de actividad y cualquier otro rastro digital. Sin embargo, como advertiría el propio Holmes, la calidad de la investigación depende de la disponibilidad y conservación de las pruebas. Sin pruebas, encontrar respuestas es mucho más complejo y costoso, si se puede.

Tipos de Evidencias

Las investigaciones forenses reactivas aprovechan cualquier prueba disponible. Pero, ¿cuáles pueden ser esas pruebas?

  • Los archivos y discos duros son como la escena del crimen en la que entró Sherlock. La aguda observación de Sherlock habría sido capaz de advertir el más pequeño de los indicios, y un buen investigador forense no es diferente. Pero muchas veces es casi imposible reconstruir lo ocurrido basándose únicamente en la escena del crimen. Es como entrar en la cocina y encontrar huevos en el techo y ketchup en el suelo. Puede que sea imposible saber exactamente cómo llegaron allí.
  • Los registros de sucesos de seguridad son como preguntar a los vecinos si han oído algo. No todos los delitos registrarán un suceso de seguridad, y los sucesos de seguridad pueden tener muchas causas posibles. Pero es una pista más. Si los vecinos oyeron a los niños reír y gritar, el desorden en la cocina podría haber sido el resultado de un juego y no de un delito.
  • Los registros de auditoría son como tener una grabación de una cámara de seguridad. Estas no estaban disponibles en la época de Sherlock, pero son ideales hoy en día. Si hubiera una cámara de seguridad en la cocina cuando los huevos acabaron en el techo, no habría dudas sobre lo ocurrido.

Una prueba de alta calidad podría significar que no necesitas a Sherlock Holmes en absoluto. Aquí es donde la preparación ahorrará tiempo y dinero.

Análisis Forense Reactivo y Auditoría


La auditoría, también conocida como supervisión de la actividad, es el acto de conservar pruebas de lo ocurrido en los sistemas de información. Es fundamental en muchos aspectos de la seguridad, incluida la investigación forense reactiva. Con una pista de auditoría suficiente, las investigaciones forenses son breves y precisas: no hay dudas sobre lo que ha ocurrido.

El reto en IT es que los sistemas de información procesan un inmenso volumen de actividad. Eso significa que hay mucha actividad que capturar y almacenar.

Capturar la actividad puede afectar al rendimiento, por lo que existen tres paradigmas de captura: capturar sólo la información de inicio de sesión, capturar la actividad de forma selectiva o capturar todo lo ocurrido. La captura del inicio de sesión sólo le informará de quién se ha conectado y desde dónde, no de qué ha hecho ni cuándo. La captura selectiva de actividad capturará un subconjunto de la actividad, como la actividad privilegiada. La captura completa capturará todo, pero requiere una tecnología que pueda hacerlo sin afectar al rendimiento.

También existen dos paradigmas de almacenamiento: el almacenamiento selectivo de la actividad basado en reglas definidas por el usuario, o el registro completo de todo lo ocurrido. La grabación completa requiere una tecnología de repositorio que pueda grabar esas pruebas con una huella de almacenamiento pequeña.

Core Audit viene con Full Capture, que ofrece una visibilidad del 100% con menos del 3% de sobrecarga, y dos repositorios: un repositorio de cumplimiento que graba basándose en reglas y un repositorio de seguridad que graba todo lo ocurrido.

Cuando se produce un incidente de seguridad, entra en juego el análisis forense reactivo para analizar lo ocurrido. Sin una pista de auditoría, a menudo se llega a la conclusión de que es imposible saber qué ocurrió y hay que asumir lo peor: que todo se vio comprometido.

Plan de Reacción

Hay muchas formas de reaccionar ante un incidente de seguridad, y pensar en ello de antemano ahorrará tiempo valioso. He aquí algunos aspectos clave a tener en cuenta:

  • ¿Hubo un ataque? Al igual que Sherlock a veces suponía que no se había cometido ningún delito, no todos los sucesos de seguridad son un ataque con éxito. Los eventos de seguridad son indicios sospechosos que pueden no ser nada, ser un ataque fallido o una brecha. Llegar a conclusiones rápidas sobre la naturaleza de un suceso de seguridad es vital y puede depender de las pruebas inmediatas de que disponga.
  • Reaccionar al ataque Una de las acciones más urgentes es reaccionar al ataque. La reacción tiene como objetivo evitar que se produzcan más pérdidas de datos y reinfecciones, y también puede tener como objetivo saber más sobre el atacante. Hay muchas reacciones posibles, como la desconexión de los sistemas infectados, los honey pots, entre otras. Es aconsejable planificar de antemano el tipo de acción o acciones que se pretenden llevar a cabo y asegurarse de que se tiene todo preparado para cuando llegue el momento. Tenga en cuenta que la reacción también puede afectar a las pruebas disponibles más adelante para la investigación forense.
  • Determinar el alcance La inspección holística del entorno suele ir más allá de la habitación o del escenario oficial del crimen. Pueden encontrarse huellas y pistas críticas en los lugares más inverosímiles. Una investigación forense examina qué sistemas estuvieron implicados, reconstruyendo la ruta y la cronología del ataque.
  • Asegurar las pruebas Al igual que los detectives aseguran la escena del crimen para evitar la contaminación de las pruebas, los analistas de seguridad deben preservar los sistemas afectados para conservar las pruebas. Estas pueden incluir archivos, registros de eventos y de actividad, o discos duros enteros.
  • Cerrar los agujeros de seguridad Sherlock descubrió cómo entró y salió el criminal de la escena, y en la medicina forense reactiva nuestro objetivo es identificar las vulnerabilidades explotadas en el ataque. Cuanto antes lo hagamos, antes podremos cerrar los agujeros de seguridad y evitar otros ataques similares.
  • Vuelta a la normalidad Una vez resuelto el caso, Holmes restablece el orden. También debemos restaurar los datos, volver a poner en línea los sistemas y devolver las operaciones a la normalidad. El tiempo de inactividad afecta a la empresa, pero para volver a la normalidad puede ser necesario concluir la investigación o, como mínimo, asegurarse de que se han identificado y cerrado todos los agujeros de seguridad.

Como puede ver, hay muchas acciones sensibles al tiempo e importantes decisiones empresariales y de seguridad que deben deliberarse con antelación. Y, como siempre, el conocimiento es poder, y saber rápidamente lo ocurrido lo hace todo más fácil.

Reflexión Final

La investigación forense reactiva es inevitable porque, tarde o temprano, se producirá un incidente de seguridad que requerirá una investigación. La preparación es clave y es la diferencia entre una resolución rápida y fácil y un resultado prolongado y costoso.

No espere a que se produzca una brecha para encontrarse con que no sabe qué hacer, no tener datos ni forma de averiguar qué ha ocurrido. Asegúrese de que dispone de información suficiente y de que puede reaccionar rápidamente cuando llegue el momento. Core Audit le permitirá hacerlo, así que póngase en contacto con nosotros hoy mismo para obtener más información.

Haz una Pregunta

Si tienes una pregunta o coentario, por favor hazlo saber. Estaremos felices de escuchar de ti.

Posted on

¿Cómo auditar una base de datos SQL Server?

¿Cómo auditar una base de datos SQL Server?

Conoce las diferentes opciones tecnológicas para auditar SQL Server y cómo obtener valor de los datos que recopila.

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.

¿Qué datos podrías recopilar?

Hay varios tipos de información que puede recopilar al auditar una base de datos SQL Server.

El requisito más sencillo es capturar los inicios de sesión y los inicios de sesión fallidos. Eso es monitorizar las conexiones a la base de datos (o sesiones) y dónde se originan. La información incluye la hora de inicio de sesión, la hora de cierre de sesión, el nombre de usuario, el programa, la dirección IP, etc.

Otro requisito habitual son los SQL. Los SQL son los comandos ejecutados en las sesiones de inicio de sesión. Se dividen en tres categorías: DDL, DML y Consultas (select). Este desglose es importante porque las consultas son difíciles de capturar y limitan las tecnologías de captura que podemos utilizar. La captura de consultas es fundamental para detectar el robo de datos, la captura de DML sirve para identificar cambios no autorizados y los DDL están relacionados con el control de cambios. Si el robo de datos es un riesgo, hay que capturar las consultas y eso permitiría capturar todo lo demás.

La Captura Selectiva es una solución para reducir el impacto en el rendimiento al no capturar todas las SQL. También simplifica el procesamiento porque hay muchos menos datos con los que tratar. No es ni mucho menos lo ideal, porque se pierde mucha información, pero con algunas tecnologías de auditoría es la única solución. También debes considerar qué harás con los datos capturados, ya que si pretendes descartar la mayor parte y sólo registrar algunas SQL, la captura selectiva podría ser una buena opción.

La captura de valores antes y después no es un requisito común, excepto en algunos sectores (especialmente banca y finanzas), donde es importante para el cumplimiento de la normativa. Antes y después de los valores significa auditar los valores que cambian en la base de datos. Por ejemplo, si alguien actualiza «salario = salario * 2», esta captura registrará todos los salarios originales y los salarios después del cambio. Como se ve en este ejemplo, el SQL puede no contener ninguno de estos valores, por lo que la captura SQL no responde a esta necesidad.

Otra función que no es de auditoría pero que está relacionada con la tecnología de captura es el bloqueo. El bloqueo permite impedir la ejecución de determinadas sentencias SQL. Es una potente medida preventiva que existe en algunas soluciones y está integrada en el motor de captura.

Por último, existe un tipo simplificado de auditoría que utiliza Metadata Snapshots (capturas de metadatos). Por ejemplo, se pueden identificar los cambios entre la lista de usuarios de ayer y la de hoy. Es un tipo de seguimiento del control de cambios y puede implementarse para la configuración, los usuarios, los permisos y los objetos (por ejemplo, tablas, vistas, etc.).

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		SQLsAntes y Después
de Valores		Metadata
Snapshot		Bloqueo
DDLDMLConsultas
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.

Conclusión sobre la Captura

La parte más difícil de la captura son las consultas, y a menudo es la parte más importante en lo que se refiere al robo de datos. Una vez que se dispone de las consultas, se tiene la mayor parte del resto de la información. Si además necesita los valores antes y después, puede obtenerlos en SQL Server sin interfaz de usuario o como parte de una solución.

Esto significa que tenes cuatro opciones básicas:

  • Hágalo usted mismo (DIY) – Utilice Eventos Extendidos para capturar los datos y procesarlos usted mismo (ver más abajo). También puede añadir disparadores o CDC para valores anteriores y posteriores. No hay costes de licencia, pero lleva mucho tiempo construirlo y mantenerlo. No lo recomendamos porque suele ser un proyecto interminable con resultados insatisfactorios.
  • Solución de bajo coste – Una solución que utiliza Extended Events o el Profiler. Estas soluciones se encargan del almacenamiento y la generación de informes, pero dependen de la base de datos para realizar la captura. La auditoría DBA es ineficaz debido al método de captura y no pueden escalar para registrar un gran número de SQLs. Esto puede ser aceptable para algunos requisitos de cumplimiento, pero nada más. Si no se supervisan los DBA, la aplicación, el acceso a datos confidenciales, etc., no pueden proporcionar una seguridad de alta calidad.
  • Solución de inspección de paquetes – Una solución de auditoría de gama alta que examina los paquetes de la base de datos. Puede manejar mucho más volumen que las soluciones de bajo coste, pero proporciona informes en la misma línea. En cierto modo son peores que las soluciones de bajo coste, ya que éstas también pueden ver el interior del motor de la base de datos, mientras que los inspectores de paquetes no pueden. Estas soluciones son buenas para el cumplimiento, pero ofrecen una seguridad limitada.
  • Core Audit – una solución de gama alta que puede capturar cualquier cosa que pueda necesitar y proporcionar potentes informes, alertas y análisis. No hay limitaciones ni agujeros y es la seguridad más completa.

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.

Prácticas Recomendadas

A continuación te dejamos algunos pasos básicos de buenas prácticas que te ayudarán a empezar:

  1. Defina sus objetivos. ¿Quiere cumplir determinadas normativas o proteger su base de datos frente a ciertas amenazas? ¿Por qué está realizando este proyecto y qué pretende conseguir? Es difícil tener éxito sin unos objetivos claros.
  2. Identifique los recursos disponibles y defina el marco. ¿Hay un plazo de ejecución? ¿Existe un presupuesto? ¿Quién formará parte del proyecto y está familiarizado con SQL Server? Conocer sus recursos le permite definir objetivos realistas.
  3. ¿Cuáles son sus requisitos de captura? ¿Es el robo de datos un riesgo y necesita capturar consultas? ¿Le preocupan los cambios no autorizados en los datos? ¿Necesita capturar valores anteriores y posteriores? ¿Le preocupa el abuso de privilegios? Esto se deriva de sus riesgos, necesidades de seguridad y requisitos de conformidad.
  4. ¿Qué valor espera obtener de los datos? ¿Necesita informes de conformidad o alertas de anomalías? ¿Le preocupa la inyección SQL? Todo depende del nivel de seguridad y conformidad que quiera alcanzar.
  5. Elija un enfoque. Sus recursos y objetivos le orientarán rápidamente entre un producto de bricolaje y bajo coste o una solución de gama alta. Póngase en contacto con algunos proveedores para obtener demostraciones y presupuestos que le permitan cuantificar los costes y calibrar el valor potencial. Póngase en contacto con nosotros y le proporcionaremos más información y asistencia de forma gratuita.
  6. Si se trata de un proyecto de bricolaje o si va a adquirir una solución de bajo coste, tendrá que experimentar en producción para asegurarse de que el impacto en el rendimiento es aceptable y para definir los filtros que necesita para una huella de almacenamiento razonable.
  7. Cuando utilice Core Audit, comience con Proactive Forensics para comprender el perfil de actividad de su base de datos y diseñar sus controles.
  8. Audite el acceso local, los DBA y las cuentas privilegiadas. El acceso local es un vector de ataque popular en el robo de datos y ataques de ransomware. Las cuentas DBA también son un vector de alto riesgo para el robo de credenciales y el abuso de privilegios.
  9. Con Core Audit, controle la cuenta de aplicación. Las cuentas de aplicación son el objetivo de la inyección SQL y otras vulnerabilidades de las aplicaciones. Auditarlas requiere una captura y un análisis de anomalías de alto nivel.
  10. Examine otras cuentas que necesite controlar. Tenga en cuenta las cuentas nuevas, no aprobadas e inactivas.
  11. Mejore la eficacia del control. Realice un análisis de deficiencias para determinar la eficacia de sus controles. Eso incluye estimar los falsos negativos (eventos no detectados) y el potencial de ataques desconocidos (como los de día cero). Existen varios métodos para hacerlo.

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.

Haz una Pregunta

Si tienes una pregunta o coentario, por favor hazlo saber. Estaremos felices de escuchar de ti.

Posted on

Cómo elegir la solución de enmascaramiento de datos más adecuada para ti

Cómo elegir la solución de enmascaramiento de datos más adecuada para usted

Obten información sobre el enmascaramiento de datos y qué tener en cuenta al comprar una solución.

Introducción

En el mundo actual, impulsado por los datos, la privacidad y la seguridad son más cruciales que nunca. Las soluciones de enmascaramiento de datos ayudan a proteger la información personal, financiera y crítica para la empresa. Seleccionar la solución adecuada es esencial para el éxito de un proyecto de enmascaramiento y la protección eficaz de su información confidencial.

Terminología Errónea

Muchos proveedores utilizan términos como anonimización, seudonimización, tokenización, hashing, cifrado, reducción y otros. El problema es que cada uno tiene una definición diferente de lo que significan.

Estos términos suenan bien porque están relacionados con la privacidad o la seguridad y parecen características deseables. Sin embargo, no son descriptivos en términos de funcionalidad y pueden significar cualquier cosa. A menudo se utilizan como palabras de moda para atraer a posibles compradores.

Cuando alguien te venda una función como Anonimización, deberías preguntar para obtener detalles sobre lo que hace.

El Problema

¿Por qué necesitamos el enmascaramiento de datos? El problema subyacente es que muchas organizaciones copian datos fuera del entorno de producción seguro, y es difícil, si no imposible, proteger los datos una vez que están fuera de producción. Hay muchas razones posibles para copiar datos fuera, pero la más común es para probar y desarrollar aplicaciones. Otras razones son el análisis, la formación, el suministro a terceros, etc.

Los datos de producción son valiosos y útiles para muchos propósitos. Sin embargo, fuera de producción, los datos residen en sistemas inseguros, a los que pueden acceder personas no autorizadas, y crean una exposición innecesaria con un mayor riesgo para la seguridad.

La Solución y Objetivos

La solución consiste en eliminar los datos sensibles de las copias de no producción. Es lo que se llama enmascaramiento estático de datos. Y una vez enmascarados los datos, se pueden utilizar en muchos entornos menos seguros.

Sin embargo, no basta con eliminar los datos sensibles. Los datos enmascarados también deben ser de alta calidad para seguir siendo valiosos. Tanto si los necesita para pruebas como para otros fines, deben seguir arrojando resultados similares a los datos originales. Si los datos enmascarados no proporcionan resultados equivalentes, los equipos que los utilicen exigirán acceso a la información sensible original. Esa es una de las formas en que un proyecto de enmascaramiento puede fracasar.

Otros objetivos son que los datos conserven su validez y la integridad de la aplicación. Estos objetivos son importantes para que la aplicación funcione correctamente.

El problema es que la eliminación de datos sensibles y la conservación de la calidad de las pruebas pueden entrar en conflicto directo. Cuanto mejor se elimine la información sensible, menos queda para el equipo de pruebas. Aunque el enmascaramiento de datos no es una tarea trivial, tampoco es demasiado difícil. Se necesita la solución adecuada y tomarse el tiempo necesario para hacerlo bien.

También existe el enmascaramiento dinámico de datos, pero hablaremos de él más adelante, ya que es una solución diferente para un problema diferente. Otra parte de la confusa terminología.

Aspectos Críticos

Es fundamental evaluar estas funciones de enmascaramiento de datos, ya que pueden hacer fracasar su proyecto. Estas características son la base de lo que necesitas del enmascaramiento de datos, así que asegúrate de comprobarlas.

1. Soporte de plataformas

El primer requisito de una solución es que sea compatible con las bases de datos que necesita enmascarar. Ya sean bases de datos Oracle, bases de datos SQL Server, archivos CSV, etc., la solución de enmascaramiento de datos debe poder conectarse al sistema pertinente y enmascarar los datos que contiene.

La dificultad de este requisito tan obvio radica en que es posible que no conozca todos los sistemas que necesita soportar ahora y en el futuro. Además, es probable que con el tiempo los proveedores introduzcan compatibilidad con bases de datos adicionales. Esto crea una situación fluida.

Práctica recomendada: Evalúe las soluciones en función de sus necesidades actuales y discuta con el proveedor sus posibles necesidades futuras y cómo encajan en su hoja de ruta.

2. Algoritmos y técnicas

Los algoritmos y técnicas disponibles en una solución son fundamentales para la calidad de los datos enmascarados. Determinarán la calidad del enmascaramiento desde el punto de vista de la seguridad y su realismo a la hora de proporcionar pruebas de calidad. También es fundamental para la validez de los datos y la integridad de la aplicación.

En otras palabras, los algoritmos de la solución de enmascaramiento son la característica principal que afecta a todos los objetivos.

Los algoritmos de enmascaramiento son un tema extenso, y tenemos muchos artículos sólo sobre este punto. Sin embargo, en términos generales, los algoritmos se dividen en tres categorías principales. Los algoritmos de Generación de Datos crean datos sintéticos no relacionados con los datos originales. Los algoritmos de manipulación de valores modifican de algún modo los valores originales y conservan algunas de sus propiedades. Los algoritmos de creación de perfiles son un punto intermedio, ya que generan datos, pero la generación utiliza un perfil de los datos originales. También existen perfiles personalizados y otras variaciones que pueden llevar las cosas aún más lejos.

También hay que tener en cuenta el tipo de datos que se van a enmascarar, ya que las distintas clases de algoritmos tienen distinta compatibilidad con los distintos tipos de datos. Por ejemplo, no se puede manipular el valor de una columna Sexo, ya que sólo hay un número limitado de valores válidos. Lo mejor es enmascarar Género utilizando un perfil de los datos originales.

Práctica recomendada: Experimente durante un POC. Defina algunos casos de prueba realistas y solicite al proveedor varias alternativas de enmascaramiento. Por ejemplo, una opción para mejorar la seguridad, otra para mejorar la calidad de las pruebas y otra para equilibrar la calidad de los datos.

3. Rendimiento y escalabilidad

El rendimiento ocupa el tercer lugar en la lista de características críticas porque es una de las principales razones del fracaso de los proyectos de enmascaramiento.

El rendimiento del enmascaramiento de datos implica múltiples elementos, desde la tecnología utilizada por la solución hasta el ajuste de la base de datos para la actividad de escritura intensiva (a diferencia del ajuste habitual optimizado para la lectura).

Sin embargo, el mayor problema en el enmascaramiento de datos son los disparadores. Los disparadores son pequeños fragmentos de código que se ejecutan en la base de datos cuando se actualizan las tablas. Sólo tienen una pequeña sobrecarga en cada actualización. Sin embargo, el enmascaramiento de datos ejecuta millones de actualizaciones, y estos pequeños gastos generales se acumulan hasta provocar una ralentización masiva. Pueden hacer que un proceso de enmascaramiento dure días o más, haciéndolo inviable. La solución tampoco es sencilla, ya que los disparadores suelen ser críticos para la integridad de los datos y no deberían desactivarse sin una forma de compensar su funcionalidad.

Práctica recomendada: Consulte a su equipo de DBA si las bases de datos que pretende enmascarar tienen triggers en tablas con datos sensibles. Además, durante el POC, debería insistir en enmascarar una de sus tablas grandes de principio a fin. Si el rendimiento del enmascaramiento parece inaceptable por cualquier motivo (desencadenantes u otros), asegúrese de que se resuelva durante el POC o, si la resolución es compleja (en el caso de los desencadenantes), que el proveedor le ayude a resolverlo como parte de la implantación.

4. Apoyo del proveedor

El apoyo de los proveedores puede ser fundamental en los proyectos de enmascaramiento de datos. Ya sea para superar problemas de rendimiento o para ayudar a personalizar una política de enmascaramiento que proporcione datos de calidad sin exponer información confidencial. Los proveedores pueden marcar la diferencia entre el fracaso y el éxito de un proyecto.

Práctica recomendada: Durante el POC, pida al proveedor que ofrezca algo más que soluciones enlatadas. Solicite varias alternativas de enmascaramiento para los datos que está probando. Enmascare grandes volúmenes de datos y espere que el rendimiento sea razonable. No siga el camino del proveedor para un POC, sino trace el suyo propio de forma que se sienta seguro de que está equipado y dispuesto a ayudarle cuando lo necesite.

5. Facilidad de aplicación y uso

Normalmente, no utilizará una solución de enmascaramiento de datos todos los días. Además, estas soluciones son utilizadas por personal que tiene muchas otras tareas y que procede de distintos ámbitos (DBA, QA, personal de seguridad, etc.). En otras palabras, una solución que requiera conocimientos específicos, que tenga una curva de aprendizaje pronunciada o que tenga una interfaz poco intuitiva será difícil de asimilar y es menos probable que se utilice.

Práctica recomendada: Durante el POC, asegúrese de que es su personal el que dirige, no el proveedor. Tras una reunión inicial con el proveedor para que le enseñe el sistema, pida a su personal que pase unos días intentando realizar algunas tareas de enmascaramiento sin ayuda.

6. Evaluación del enmascaramiento

Uno de los retos es saber si las políticas de enmascaramiento están haciendo su trabajo. Sobre todo, querrá saber si todos los datos están bien enmascarados. No es una cuestión trivial. Depende tanto de los datos que se enmascaran como de la política que los enmascara. Core Masking dispone de una función que le ayudará a responder a esta pregunta crítica.

Por ejemplo, la sustitución de dígitos por otros dígitos sólo es eficaz si todos los valores contienen dígitos y un número suficiente de ellos. Otro ejemplo: en muchos productos de enmascaramiento, fijar la semilla o garantizar la coherencia tiene el coste no documentado de no enmascarar algunos de los valores. Estos son sólo algunos ejemplos, pero ¿cómo saber si se han enmascarado todos los datos sensibles?

Práctica recomendada: Durante un POC, la seguridad se comprueba a menudo tomando muestras de algunos valores y comparándolos antes y después. Esto no es una buena prueba. Busque una forma de asegurarse de que todos los valores están bien enmascarados. Esto puede ser difícil debido a las diferencias estadísticas entre ejecuciones de enmascaramiento consecutivas. De nuevo, si la solución puede resolverle este problema, será mucho más fácil.

Elementos de Distracción

Las siguientes capacidades pueden ser valiosas en algunos casos, pero suelen utilizarse para distraer a los clientes de lo que importa. Explicaremos cada una de ellas y por qué le distraen de sus objetivos.

7. Enmascaramiento Dinámico

El enmascaramiento dinámico no modifica los datos de la base de datos y devuelve datos enmascarados no para todas las consultas a la base de datos, sino para algunas de ellas. El caso de uso es bastante limitado. Es para cuando algunas aplicaciones que se conectan a la base de datos de producción necesitan acceder a columnas con datos sensibles pero sólo a una versión enmascarada de esas columnas. El enmascaramiento suele ser sólo para una aplicación completa, no para usuarios finales concretos.

El enmascaramiento dinámico sólo es relevante para las bases de datos de producción. Debe seguir protegiendo la base de datos, ya que los datos confidenciales siguen estando dentro de ella.

Además, como el enmascaramiento dinámico es una operación en tiempo real, ofrece un pequeño número de algoritmos con capacidades limitadas. Por ejemplo, la sustitución de caracteres por estrellas. Estos algoritmos no pueden crear datos falsos realistas.

El enmascaramiento dinámico es una solución complicada y cara que no está relacionada con las bases de datos de no producción, y no elimina la necesidad de proteger la base de datos.

8. Descubrimiento

El descubrimiento suele girar en torno a la búsqueda de datos sensibles en la base de datos. Es una buena función que incluyen la mayoría de los productos. Sin embargo, su capacidad para identificar correctamente todos los datos es bastante limitada.

Un método utilizado por el descubrimiento es escanear los datos en la base de datos y buscar datos que se parezcan a patrones específicos. Esto tiene dos limitaciones. En primer lugar, la información sensible debe seguir patrones específicos. Los salarios, por ejemplo, son sólo números que no pueden identificarse de esta manera. En segundo lugar, tiene un elevado número de falsos positivos.

Otro método utilizado consiste en examinar los nombres de las columnas. Este método tiene muchas probabilidades de omitir datos sensibles y también puede dar lugar a muchos falsos positivos.

Aunque la detección es una buena función, no es crítica y no puede confiar en ella para localizar sus datos.

9. Aprovisionamiento y Despliegue

Algunas soluciones permiten copiar datos de producción a no producción o entre sistemas no productivos.

Aunque parece una característica valiosa, todo DBA sabe cómo desplegar una copia de una base de datos de producción. Los administradores de bases de datos tienen métodos más rápidos y probados, como restaurar una copia de seguridad o utilizar funciones específicas de la base de datos. Según nuestra experiencia, los DBA no confían en las funciones de enmascaramiento de datos para realizar copias de bases de datos.

Otra razón por la que esta función distrae la atención es que existen soluciones especializadas en una canalización de datos, el aprovisionamiento del sistema u otros tipos de gestión de datos. No se trata de herramientas de seguridad con un alcance y una finalidad distintos del enmascaramiento de datos.

En otras palabras, la copia de datos está relacionada con las operaciones, no con la seguridad, y por lo tanto, distrae de los requisitos críticos relacionados con el enmascaramiento.

10. Cumplimiento

La conformidad parece la característica perfecta. ¿No sería maravilloso que la solución de enmascaramiento fuera compatible con su requisito de cumplimiento específico? La realidad es que todas las soluciones de enmascaramiento de datos son igualmente adecuadas para el cumplimiento de normativas y las soluciones que afirman ser compatibles con un requisito u otro no hacen nada diferente. Es más, ningún requisito de conformidad, salvo la PCI, especifica cómo enmascarar los datos. Incluso en el caso de la PCI, la buena práctica consiste en enmascarar de forma más agresiva que el requisito mínimo de enmascaramiento establecido en la normativa.

En otras palabras, el cumplimiento es un argumento de marketing, no una característica real.

Prácticas Recomendadas

Hemos enumerado las mejores prácticas de evaluación para cada característica crítica, pero lo fundamental es realizar un POC adecuado. Realice las pruebas usted mismo y evite las reseñas o clasificaciones de Internet. Su POC debe validar que la solución hace lo que usted necesita de principio a fin sin escatimar esfuerzos. Desconfíe de los proveedores que intenten convencerle de lo contrario, independientemente de su reputación.

Tendrá que enmascarar casos de prueba complicados que impliquen, por ejemplo, la coherencia entre columnas o la conservación de la distribución estadística de valores como el sexo o el estado. Tendrá que validar que todos los valores están enmascarados, comprobar el rendimiento y mucho más. Y lo que es más importante, asegúrese de que puede utilizar los datos enmascarados y de que el cliente final está satisfecho con la calidad de los datos.

Reflexión final

Elegir la solución de enmascaramiento de datos adecuada es crucial para el éxito de un proyecto de enmascaramiento. Una que pueda utilizar con regularidad y que mantenga la seguridad y privacidad de su información sensible. El enmascaramiento de datos le permitirá hacer mucho más con los datos que ya tiene sin aumentar el riesgo.

Haz una Pregunta

Si tienes una pregunta o coentario, por favor hazlo saber. Estaremos felices de escuchar de ti.

Posted on

Auditoría de bases de datos e IDS: Una guía completa para la protección de datos

Auditoría de Bases de Datos e IDS: Una guía completa para la protección de datos

Aprenda por qué es importante la auditoría de bases de datos y los IDS, cómo combatir los ataques y las infracciones, herramientas y tecnologías, buenas prácticas y mucho más.

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.

El poder de IDS de bases de datos

Aunque los sistemas de prevención de intrusiones (IPS) pueden desempeñar un papel en la seguridad de las bases de datos, los IDS son más eficaces debido a la naturaleza única del acceso a las bases de datos y a la forma en que se realizan los ataques a las mismas.

Las bases de datos suelen tener un número limitado de cuentas. Conectarse a una base de datos sin credenciales válidas o un método de acceso aprobado (como una conexión local) es casi imposible. El reto es, por tanto, controlar la actividad que llega a través de estos canales aprobados. El problema es el enorme volumen de actividad. Con miles de millones de SQL válidos al mes, resulta extremadamente difícil identificar el puñado de SQL maliciosos que podrían constituir un ataque.

Los sistemas preventivos deben tener un bajo índice de falsos positivos. Cuanto menor sea la tasa de falsos positivos, mayor será la tasa de falsos negativos. En las bases de datos, bloquear un SQL válido a mitad de una transacción puede tener consecuencias catastróficas, por lo que los IPS de bases de datos tienen una tolerancia especialmente baja a los falsos positivos (y, por tanto, a muchos eventos no prevenidos). El otro problema en las bases de datos es distinguir la actividad buena de la maliciosa. Así que, cuando se combina con las limitaciones inherentes de IPS, la prevención sólo es eficaz para un pequeño número de vectores de ataque.

Por el contrario, los sistemas detectives tienen una mayor tolerancia a los falsos positivos. Una solución IDS de bases de datos moderna puede ayudar a las organizaciones a obtener visibilidad de la actividad de sus bases de datos e identificar la mayoría de los ataques con un número razonable de falsos positivos.

Visibilidad: Una condición previa

Tanto si pretende desplegar un IPS como un IDS, primero debe obtener visibilidad de la actividad de su base de datos. No se puede proteger lo que no se ve. Es imposible diseñar políticas, reglas o informes eficaces sin un conocimiento sólido de la actividad que se intenta controlar.

By gaining visibility into your database activity, you could:

  • Controles de diseño: Comprender el perfil de la actividad te ayudará a determinar cómo controlarla. Debes identificar, por ejemplo, las cosas que ocurren, y debes estar atento a ellas. Otras cosas ocurren raramente, y deberías alertarlas o bloquearlas. Establecer la seguridad basándose en una suposición teórica de la actividad es ineficaz. Es imposible asegurar lo que no se puede ver.
  • Identificar prácticas riesgosas: En muchos entornos, los usuarios y administradores han adoptado prácticas que son inseguras. Cosas como compartir cuentas, utilizar cuentas de administrador por la aplicación, exportar datos sensibles fuera de la base de datos, etc.
  • Identificar actividades sospechosas: Una revisión humana ocasional de la actividad de la base de datos puede detectar actividades sospechosas que han pasado desapercibidas por otros medios.
  • Identificar brechas: Identifique actividades o posibles actividades no controladas por sus medidas actuales y con potencial para comprometer los datos.

La visibilidad es una característica clave de una solución de seguridad de bases de datos. En Core Audit, la llamamos análisis forense proactivo. Pero independientemente del nombre, debería permitirle responder a preguntas como quién se conecta a la base de datos, utilizando qué programas, desde qué máquinas/IPs, y qué están haciendo dentro. Deberías tener respuestas a preguntas como quién accede a tu información sensible, cuándo, desde qué programas y utilizando qué SQLs. Pero esto son sólo ejemplos. Las preguntas dependen del perfil de actividad de la base de datos, y eso es lo que hay que entender para poder controlar.

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.

Tecnologías

  • Capacidades de la base de datos: Todas las bases de datos contienen algún tipo de funcionalidad de auditoría. La ventaja es que es gratuita. Los inconvenientes son la falta de informes, la retención a largo plazo, los elevados gastos generales y las limitadas capacidades de captura. En sí misma, es una función de apoyo, no una solución.
  • Herramientas que utilizan la auditoría nativa: Existen soluciones baratas basadas en las capacidades integradas de las bases de datos. Su único valor es ofrecer la funcionalidad de elaboración de informes y retención que falta en las capacidades integradas de la base de datos. Sin embargo, adolecen de la misma sobrecarga y limitaciones de captura. Pueden ser aceptables para simples necesidades de cumplimiento, pero no ofrecen casi ninguna seguridad o protección contra amenazas realistas.
  • Soluciones basadas en la red: Estas herramientas de gama alta infieren la actividad de la base de datos a partir de la captura del tráfico de red. Suelen utilizar controladores locales del kernel para capturar la actividad local, pero su captura es incompleta, por lo que siguen siendo fáciles de eludir. La captura local también crea una alta carga de red al transmitir el tráfico local a su servidor. Su objetivo principal suele ser el cumplimiento, por lo que tienden a tener una visibilidad y unas capacidades de análisis limitadas. En otras palabras, tienen capacidades limitadas contra amenazas realistas (abuso de privilegios, inyección SQL, etc.).
  • Soluciones basadas en agentes: Las soluciones de gama alta como Core Audit se conectan directamente al motor de la base de datos y ven todo lo que ocurre en la base de datos con poca sobrecarga (conexiones cifradas, actividad local y actividad interna de la base de datos). Core Audit también incluye una visibilidad en profundidad, potentes repositorios y sólidas capacidades de análisis, lo que se traduce en una seguridad superior frente a cualquier amenaza.
  • Rendimiento, APM y otras soluciones: Se trata de soluciones pensadas para el rendimiento y otros fines que, en ocasiones, se reutilizan para la seguridad. Son inadecuadas porque están diseñadas para centrarse en actividades que generan carga en la base de datos en lugar de en actividades que suponen un riesgo para la seguridad. Los SQL maliciosos no suelen generar casi ninguna carga en la base de datos, rara vez son captados por la tecnología subyacente y, aunque se capten, es probable que las soluciones los ignoren.

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.

Haz una Pregunta

Si tenes alguna pregunta o comentario, no dudes en hacérnoslo saber. Estaremos encantados de escucharte.

Posted on

Tienes control sobre tus datos

¿Tienes control sobre tus datos?

Muchas organizaciones se quedan cortas en lo que a control y visibilidad se refiere. ¿Tienes control sobre tus datos?

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.





Posted on

Presupuestos para un futuro seguro: Optimiza el tuyo para 2025

Presupuestos para un futuro seguro
Optimiza el tuyo para 2025

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.

Posted on

Defensas Centradas en Datos

Más Allá del Perímetro: La Necesidad de Defensas Centradas en los Datos

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.

Descargar Guía Completa

Si querés obtener la guía "Endpoints: Seguridad y Riesgos Potenciales", por favor completa el siguiente formulario para poder descargar el archivo.

Posted on

Descargar Guía Completa

Descargar Guía Completa

Descargar Guía Completa

Si querés obtener la guía “Endpoints: Seguridad y Riesgos Potenciales”, por favor completa el siguiente formulario para poder descargar el archivo.

DESCARGAR AQUÍ

Nombre
Apellido
Correo electrónico corporativo
Número telefónico
Empresa donde trabaja
País
CAPTCHA