Nosotros, como profesionales de la seguridad, operamos en un reino de lógica, evaluación de riesgos y defensa proactiva. Predicamos el modelo de seguridad por capas, el principio del mínimo privilegio y la importancia de la defensa en profundidad. Sin embargo, hay un trasfondo persistente, casi desconcertante, en nuestro campo: la creencia de que la seguridad a nivel de aplicación es el bastión definitivo, un escudo suficiente para salvaguardar nuestro bien más preciado: los datos que residen en la base de datos.

Seamos claros: esta creencia es una falacia peligrosa. Aunque la seguridad de las aplicaciones es innegablemente crucial, considerarla una estrategia completa de protección de datos es como fortificar la puerta principal de una casa dejando las ventanas traseras abiertas de par en par. Comprendemos las vulnerabilidades inherentes a las aplicaciones: el flujo interminable de errores, las complejidades de las diversas arquitecturas, la pura imposibilidad de lograr un código perfecto. Lo sabemos. Sin embargo, el enfoque, el presupuesto y la atención a menudo se inclinan desproporcionadamente hacia la seguridad de la capa de aplicación, dejando expuesto el corazón mismo de nuestros datos.

¿A qué se debe esta irracionalidad? Tal vez sea la complejidad percibida de la seguridad de las bases de datos, la sensación de que se trata de una caja negra. Tal vez sea el atractivo de las correcciones inmediatas a nivel de aplicación, la sensación tangible de parchear una vulnerabilidad conocida. Pero sea cual sea la razón, esta disonancia cognitiva debe terminar. Tenemos que ir más allá de la comprensión intelectual y cultivar una creencia profunda e inquebrantable en la necesidad absoluta de contar con defensas sólidas para las bases de datos.

Considere los vectores de ataque que hacen que la seguridad centrada en las aplicaciones sea incompleta:

• La amenaza interna: La seguridad de las aplicaciones, por muy estricta que sea, ofrece poca protección contra un administrador de bases de datos malintencionado o comprometido. Estos individuos poseen las llaves del reino, eludiendo por completo los controles de las aplicaciones.

• Robo de credenciales: Los atacantes son cada vez más expertos en obtener credenciales legítimas, ya sea mediante phishing, ingeniería social o malware. Armados con las credenciales de la base de datos, pueden acceder directamente a los datos confidenciales y filtrarlos, haciendo que las medidas de seguridad de la aplicación sean irrelevantes.

• Exploits del sistema operativo: Una brecha en el nivel del sistema operativo del servidor puede otorgar a los atacantes acceso directo a la base de datos, eludiendo todas las salvaguardas de la aplicación.

• La inevitable brecha en las aplicaciones: Admitámoslo, a pesar de nuestros mejores esfuerzos, las aplicaciones tendrán vulnerabilidades. La inyección SQL, a pesar de ser una amenaza bien conocida, persiste. Y aunque las defensas a nivel de aplicación son vitales, la propia base de datos puede y debe actuar como última línea de defensa, detectando y evitando las consultas maliciosas antes de que causen daños.

Además, demos la vuelta al guión. En lugar de considerar la seguridad de la base de datos como una tarea separada y desalentadora, considere su poder para mejorar la seguridad de las aplicaciones. Unos controles sólidos de la base de datos, como la identificación de actividades anómalas de la aplicación a nivel de base de datos, pueden neutralizar eficazmente clases enteras de ataques a nivel de aplicación, como la inyección SQL. La base de datos se convierte en un participante activo en la postura de seguridad, no sólo en un repositorio pasivo.

Y aquí hay una verdad que debería resonar en nuestras mentes pragmáticas: la seguridad moderna de las bases de datos es a menudo más manejable y eficiente que asegurar el extenso panorama de las aplicaciones. Las API de bases de datos están bien definidas. Los métodos de acceso son claros y auditables. Las medidas de seguridad, desde el cifrado de datos en reposo y en tránsito hasta la auditoría robusta, el análisis de anomalías y el bloqueo avanzado de SQL, están fácilmente disponibles. Compárese esto con la caótica diversidad de arquitecturas de aplicaciones, lenguajes, marcos de trabajo y la constante aparición de nuevas vulnerabilidades. Proteger la base de datos proporciona un retorno de la inversión más centrado e impactante. Hable con nosotros y le mostraremos cómo.

Las estadísticas dibujan un panorama desolador. La mayoría de las violaciones de datos importantes se originan en el acceso directo a las bases de datos. Lo sabemos. Vemos los titulares. Comprendemos las implicaciones: ruina financiera, daños a la reputación, sanciones reglamentarias. Sin embargo, persiste la tendencia arraigada hacia la seguridad de las aplicaciones.

Las estadísticas dibujan un panorama desolador. La mayoría de las violaciones de datos importantes tienen su origen en el acceso directo a bases de datos. Lo sabemos. Vemos los titulares. Comprendemos las implicaciones: ruina financiera, daños a la reputación, sanciones reglamentarias. Sin embargo, persiste la tendencia arraigada hacia la seguridad de las aplicaciones.

Es hora de cambiar de mentalidad. La seguridad de las bases de datos no es un elemento más de la lista de comprobación, sino el cimiento de la protección de datos. Es el guardián silencioso que se mantiene firme incluso cuando se violan los muros de la aplicación. Es la capa crítica que puede transformar una catástrofe potencial en un incidente contenido.

No estamos tratando con usuarios finales ingenuos. Somos profesionales de la seguridad. Entendemos los principios. La desconexión no radica en el conocimiento, sino en la creencia, en interiorizar realmente la profunda importancia de la seguridad de las bases de datos.

Vayamos más allá de la reconfortante ilusión de la seguridad centrada en las aplicaciones. Defendamos la causa de una sólida protección de las bases de datos con el mismo fervor y dedicación que aplicamos a otros ámbitos críticos de la seguridad. Asignemos recursos, apliquemos las mejores prácticas y fomentemos una cultura en la que la seguridad de las bases de datos no sea una ocurrencia tardía, sino un pilar fundamental de nuestra estrategia de seguridad.

Los datos que se nos ha confiado proteger lo exigen. Lo exige nuestra integridad profesional. El panorama de la seguridad lo exige. Es hora no sólo de entender la lógica, sino de creer de verdad en el poder y la necesidad de proteger nuestras bases de datos. Las consecuencias de no hacerlo son demasiado graves como para ignorarlas.

Introducción

PCI-DSS es una norma de seguridad publicada por las empresas de tarjetas de crédito (PCI es Payment Card Industry, y DSS significa Data Security Standard). Es un requisito obligatorio para cualquiera que procese tarjetas de crédito.

La versión 4.0.1 de PCI-DSS es un documento de casi 400 páginas, por lo que este artículo no lo sustituye. Pero ayudamos a traducir PCI-DSS a pasos prácticos de implementación en bases de datos Oracle y SQL Server para ayudarle a entender lo que necesita hacer. Sugerimos las mejores prácticas, metodologías y soluciones para ayudarle a cumplir la normativa.

El alcance de este artículo: Este artículo aborda las tareas realizadas por el equipo de DBA y no para administradores de red, desarrolladores de aplicaciones, etc. Supone que la base de datos está configurada y se utiliza de forma habitual, no es accesible desde Internet e, idealmente, se encuentra en una red interna segura. Tampoco abordamos los requisitos de la aplicación relacionados con la base de datos, como qué datos almacenar o cuánto tiempo conservarlos.

Las Buenas Prácticas del final resumen todo lo que hay que hacer.

Los Requisitos

A diferencia de la mayoría de las normativas de cumplimiento, PCI-DSS tiene requisitos precisos. Sin embargo, estos requisitos abarcan todo el entorno informático, incluidas redes, servidores, bases de datos, aplicaciones, etc.

Dado que no todos los requisitos se aplican a las bases de datos, este artículo sólo aborda los que son pertinentes para las bases de datos Oracle o SQL Server. Se trata de los requisitos 2, 3, 6, 7, 8, 10 y 11.

Requisito 2: Configuraciones seguras

El requisito 2 consiste en cambiar las configuraciones por defecto que puedan ayudar a un atacante a comprometer el sistema. Esto es especialmente importante para las contraseñas por defecto:

“Las personas malintencionadas, tanto externas como internas a una entidad, suelen utilizar contraseñas predeterminadas y otras configuraciones predeterminadas del proveedor para comprometer los sistemas. Estas contraseñas y configuraciones son bien conocidas y se determinan fácilmente a través de información pública.

La aplicación de configuraciones seguras a los componentes del sistema reduce los medios de que dispone un atacante para comprometer el sistema. Cambiar las contraseñas por defecto, eliminar el software, las funciones y las cuentas innecesarias, y desactivar o eliminar los servicios innecesarios ayudan a reducir la superficie potencial de ataque.“

Oracle y SQL Server son bastante seguros desde el principio. Además, obligan a establecer contraseñas de administrador personalizadas durante la instalación. La única mejora necesaria es activar el cifrado de la red. O más exactamente, hacer del cifrado un requisito del lado del servidor, ya que los clientes siempre pueden elegir cifrar las conexiones.

Es un buen punto de partida, pero tu base de datos no es nueva nada más sacarla de la caja. Eso significa que necesitarás asegurarte de que no has cambiado la configuración por defecto para que sea menos segura.

Por ejemplo, tras la instalación, las bases de datos Oracle contienen muchas cuentas en estado «EXPIRADO Y BLOQUEADO». Estos son usuarios como Scott/tiger, hr/hr, y más. Estas cuentas tienen una contraseña por defecto y pueden ser desbloqueadas, creando una vulnerabilidad de seguridad. Debes revisar la lista de cuentas, identificar las que no están en uso activo y desactivarlas. Puedes obtener la lista de cuentas y su estado usando un SQL como:

select username, account_status from dba_users;

Core Audit es una potente solución que le ayudará a identificar todas las cuentas configuradas en su base de datos y qué cuentas están activas.

SQL Server presenta retos diferentes debido a las numerosas funciones opcionales adicionales que se pueden instalar. Aunque no siempre es realista, debería intentar eliminar las funciones que no utilice. Además, si es posible, desactive xp_cmdshell.

Otro escollo en todas las bases de datos son las aplicaciones instaladas que requieren una cuenta. Debes asegurarte de que no utilizan una contraseña por defecto. Eso incluye aplicaciones de monitorización, software de ajuste, software empresarial y más.

Requisito 3: Almacenamiento de datos de titulares de tarjetas

El requisito 3 se refiere a la protección del almacenamiento de la información de los titulares de tarjetas:

“Los métodos de protección como el cifrado, el truncamiento, el enmascaramiento y el hashing son componentes críticos de la protección de datos de cuentas. Si un intruso elude otros controles de seguridad y consigue acceder a los datos cifrados de la cuenta, los datos son ilegibles sin las claves criptográficas adecuadas y son inutilizables para ese intruso… Por ejemplo, los métodos para minimizar el riesgo incluyen no almacenar los datos de la cuenta a menos que sea necesario, truncar los datos del titular de la tarjeta si no se necesita el PAN completo.“

El cifrado es una función incorporada tanto en SQL Server como en las bases de datos Oracle. Se denomina TDE (Cifrado Transparente de Datos) y debe configurarlo en cualquier base de datos que contenga datos de titulares de tarjetas.

Si tiene datos de titulares de tarjetas fuera de producción, debe utilizar el Enmascaramiento Estático de Datos para eliminarlos. El reto del enmascaramiento es que los datos enmascarados no sólo deben ocultar los datos de los titulares de tarjetas (como exige PCI-DSS), sino también ofrecer los resultados esperados. Por ejemplo, en el caso de los sistemas de control de calidad y desarrollo, las pruebas con los datos enmascarados deben ofrecer resultados similares a las pruebas con los datos originales. Conseguir un enmascaramiento eficaz no es trivial y recomendamos utilizar Core Masking de Blue Core Research.

Requisito 6: software seguro

El requisito 6 se refiere a la instalación de parches:

“Los actores con malas intenciones pueden utilizar las vulnerabilidades de seguridad para obtener acceso privilegiado a los sistemas. Muchas de estas vulnerabilidades se solucionan mediante parches de seguridad proporcionados por el proveedor, que deben ser instalados por las entidades que gestionan los sistemas. Todos los componentes del sistema deben tener todos los parches de software apropiados para protegerse contra la explotación y el compromiso de los datos de las cuentas por parte de individuos malintencionados y software malicioso.“

Instalar parches de bases de datos suele ser todo un reto. Esto se debe a que no siempre son compatibles con el software. También requieren pruebas en no producción y tiempo de inactividad en producción para instalarlos.

La buena noticia es que, aunque Oracle publica innumerables parches, este requisito sólo se refiere a los parches de seguridad. SQL Server tiene más parches relacionados con la seguridad, que deben instalarse.

Además, recuerde que también debe parchear todo el software utilizado en la base de datos, incluida la administración, el ajuste, la supervisión y todas las demás aplicaciones y herramientas.

Requisito 7: Restringir el acceso a los datos del titular de la tarjeta

El requisito 7 trata sobre la minimización de privilegios:

“Personas no autorizadas pueden acceder a datos o sistemas críticos debido a la ineficacia de las normas y definiciones de control de acceso. Para garantizar que solo el personal autorizado pueda acceder a los datos críticos, deben existir sistemas y procesos que limiten el acceso en función de la necesidad de conocer y de acuerdo con las responsabilidades del puesto.“

Se trata de un reto similar tanto en Oracle como en SQL Server. Debes reducir los permisos y privilegios en la medida de lo posible. Preste especial atención a los usuarios con el rol de DBA, privilegios sensibles (como ALTER USER o los privilegios «ANY» en Oracle) y permisos relacionados con tablas y columnas con datos de titulares de tarjetas.

El uso de Core Audit Level 1 puede ayudar a identificar estos tipos de privilegios y permisos para ayudarle a cumplir la normativa.

Requisito 8: Cuentas individuales

El requisito 8 consiste en tener cuentas individuales (no cuentas compartidas):

“Dos principios fundamentales de la identificación y autenticación de usuarios son 1) establecer la identidad de un individuo o proceso en un sistema informático, y 2) probar o verificar que el usuario asociado a la identidad es quien el usuario dice ser.“

La identificación de un individuo o proceso … se lleva a cabo asociando una identidad con … un identificador … (también denominado «cuentas») … asignando una identificación única … para distinguir a un usuario o proceso de otro. … garantiza que se rindan cuentas de las acciones realizadas por esa identidad. Cuando existe tal responsabilidad, las acciones realizadas pueden ser rastreadas hasta usuarios y procesos conocidos y autorizados.

El elemento utilizado … para verificar la identidad se conoce como factor de autenticación. Los factores de autenticación son 1) … una contraseña …, 2) … un dispositivo token o tarjeta inteligente, o 3) … un elemento biométrico».

Las bases de datos suelen tener cuentas individuales. Las excepciones son algunas cuentas de administración (SYS y SYSTEM en Oracle y, posiblemente, SA en SQL Server) y la cuenta de aplicación. Debe asegurarse de que así sea.

Este requisito también incluye instrucciones sobre políticas de contraseñas, como contraseñas seguras (12 caracteres con números y letras), no reutilización de contraseñas, bloqueo de cuentas, etc.

Requisito 10: Registrar y supervisar todos los accesos

El requisito 10 se refiere a la auditoría de actividades:

“Los mecanismos de registro y la capacidad de rastrear las actividades de los usuarios son fundamentales para prevenir, detectar o minimizar el impacto de un compromiso de datos. La presencia de registros… permite un seguimiento, alerta y análisis exhaustivos cuando algo va mal. Determinar la causa de un compromiso es difícil, si no imposible, sin registros de actividad del sistema.“

La auditoría de bases de datos es un reto tanto en SQL Server como en Oracle. El problema es que el uso de las funciones integradas de auditoría de bases de datos genera una importante sobrecarga de rendimiento y no cumple algunos aspectos del requisito 10 (como la seguridad de los datos de registro).

Tenemos artículos completos que revisan las opciones de auditoría de Oracle y SQL Server. La conclusión es que recomendamos utilizar Core Audit, ya que puede capturar toda la actividad con una sobrecarga insignificante, asegurar el registro de auditoría, generar los informes y alertas necesarios, y mucho más.

En términos de qué auditar, probablemente necesitará auditar al menos toda la actividad del DBA y todos los accesos a tablas que contengan datos de titulares de tarjetas.

Requisito 11: Comprobar periódicamente la seguridad de los sistemas

El requisito 11 se refiere a la exploración de vulnerabilidades y las pruebas de penetración:

“Las vulnerabilidades son descubiertas continuamente por individuos malintencionados e investigadores, así como introducidas por nuevo software. Los componentes del sistema, los procesos y el software a medida y personalizado deben probarse con frecuencia para garantizar que los controles de seguridad siguen reflejando un entorno cambiante.“

Hay muchas soluciones que buscan vulnerabilidades y rara vez encuentran algo significativo en la mayoría de las bases de datos. La razón es que es poco probable penetrar en una base de datos moderna sin credenciales. Del mismo modo, es poco probable que un pentest interno o externo revele nada nuevo.

Sin embargo, es necesario seguir estos pasos, y tiene sentido hacerlo dada la naturaleza de la seguridad: siempre hay un agujero esperando a ser encontrado.

Buenas Prácticas

1. Alcance. El primer paso para cumplir la normativa PCI-DSS es reducir el alcance de las bases de datos, servidores y redes que contienen datos de titulares de tarjetas. Si una instancia de SQL Server contiene varias bases de datos y una de ellas contiene datos de titulares de tarjetas, toda la instancia está sujeta a PCI-DSS. La base de datos tampoco debe estar conectada directamente a Internet, lo ideal es que se encuentre en una red interna segura. Aislar los datos de los titulares de tarjetas en bases de datos, servidores y redes que contengan poco más reducirá significativamente el esfuerzo de cumplimiento.
2. Cuentas. Hay varios pasos para asegurar las cuentas, y deben rehacerse al menos cada seis meses.
   • Inventario de cuentas. Haga una lista de todas las cuentas de la base de datos, identifique a las personas o aplicaciones asociadas a esas cuentas y determine cuáles siguen activas. Recomendamos utilizar Core Audit.
   • Cuentas inactivas. Cierre o desactive todas las cuentas inactivas.
   • Cuentas individuales. Asegúrese de que todas las cuentas son cuentas individuales (excepto las cuentas administrativas integradas compartidas y las cuentas de aplicaciones).
   • Mínimos privilegios. Asegúrese de que todas las cuentas tienen los permisos mínimos necesarios para que las personas realicen sus tareas. En particular, debe haber restricciones de acceso significativas a los datos de los titulares de las tarjetas (lo ideal sería que sólo la aplicación y los DBA).
3. Contraseñas.
   • Contraseñas por defecto. Asegúrese de que ninguna de las cuentas tiene una contraseña por defecto. En caso de duda, cambie la contraseña.
   • Política de contraseñas. Contraseñas fuertes (12 caracteres con números y letras), no reutilizar contraseñas (al menos 4), bloqueo de cuentas (no más de 10 intentos y bloqueo durante al menos 30 minutos).
4. Cifrado. Activa el cifrado de red y el cifrado de disco (TDE – Transparent Data Encryption).
5. Enmascaramiento. Utilice la Máscara Estática de Datos para enmascarar los datos de los titulares de tarjetas fuera de producción. Recomendamos utilizar Core Masking. En general, debe asegurarse de que todas las copias de datos de titulares de tarjetas fuera de la base de datos de producción (como copias de seguridad, exportaciones, etc.) estén enmascaradas o cifradas.
6. Parches. Instale todos los parches de seguridad para la base de datos y todo el software asociado. Se trata de una actividad continua.
7. Auditoría. Audite los inicios de sesión fallidos, la actividad del DBA, el acceso a las tablas que contienen datos de titulares de tarjetas y los DCL (DDL relacionados con cuentas). Recomendamos utilizar Core Audit.
8. Escaneos de vulnerabilidad y Pentesting. Realice escaneos de vulnerabilidades internas y externas (hay soluciones que lo hacen), y realice pruebas de penetración (hay empresas externas certificadas que debe contratar para ello).

Resumen

PCI-DSS sigue prácticas de seguridad estándar, especialmente cuando se trata de bases de datos. Aunque siempre se puede hacer más, estos pasos son esenciales para mantener los datos seguros y deben seguirse en cualquier entorno que contenga datos sensibles.

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?

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

Hágalo Usted Mismo (DIY)

El «hágalo usted mismo» (DIY) es una solución sencilla que 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.

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.

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.

¿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.

¿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.

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.

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.

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.

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.

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.