Vivimos en una era de amenazas cibernéticas implacables. Los titulares hablan de ataques de ransomware, violaciones de datos y sofisticadas campañas de phishing. En respuesta, las organizaciones suelen apresurarse a reforzar sus defensas perimetrales, actualizar la seguridad de los puntos finales e implementar las últimas herramientas de supervisión de redes. Si bien estas medidas son sin duda importantes, se está gestando una crisis silenciosa en el corazón digital de muchas organizaciones: las bases de datos descuidadas.

Piénselo. ¿Dónde residen sus datos más críticos? La información de los clientes, los registros financieros, la propiedad intelectual, los datos sanitarios confidenciales… todo ello se canaliza a través de sus bases de datos. Esto las convierte en el objetivo definitivo de los actores maliciosos. Una violación a nivel de la base de datos puede tener consecuencias catastróficas, muy superiores al impacto de un punto final comprometido o una interrupción temporal de la red.

Sin embargo, ¿por qué la seguridad de las bases de datos suele quedar en un segundo plano? Hay varios factores que contribuyen a este peligroso descuido:

• La mentalidad de «ojos que no ven, corazón que no siente»: las bases de datos funcionan entre bastidores y, a menudo, son gestionadas por equipos especializados. Esto puede dar lugar a una falta de visibilidad y comprensión entre los responsables de seguridad en general con respecto a su verdadera vulnerabilidad.
• Visión estrecha impulsada por el cumplimiento normativo: aunque normativas como el RGPD, la HIPAA y la PCI DSS suelen abordar la protección de datos, su enfoque puede ser a veces más amplio, haciendo hincapié en los controles de acceso y la seguridad perimetral en lugar de en las medidas de seguridad granulares necesarias dentro de la propia base de datos.
• El factor «poco atractivo»: seamos realistas, la seguridad de las bases de datos no siempre acapara los titulares como un exploit de día cero o un ataque de un Estado-nación. Puede parecer compleja, técnica y menos impactante a primera vista que ver cómo un cortafuegos bloquea una conexión maliciosa.
• La ilusión del retorno de la inversión: calcular el retorno directo de la inversión en actualizaciones de seguridad de bases de datos puede resultar complicado. Es más fácil cuantificar el coste de un nuevo cortafuegos que el beneficio aparentemente intangible de prevenir una violación de datos.

Pero seamos sinceros: ¿puede su organización permitirse realmente no dar prioridad a la seguridad de las bases de datos?

Usted conoce las consecuencias de una violación de datos. Eso es lo que ocurre cuando alguien accede a su base de datos. Un coste que puede alcanzar millones de dólares en multas reglamentarias, honorarios legales, indemnizaciones a clientes, investigaciones forenses y mucho más. Además de los efectos duraderos del daño irreversible a la reputación cuando se pierde la confianza de los clientes y las partes interesadas.

Base de datos: tu prioridad desde el minuto cero

La realidad es que una seguridad sólida de las bases de datos no es solo otro elemento más de su lista de comprobación de seguridad, sino que es la base sobre la que se sustentan todas las demás medidas de seguridad. Es la prioridad cero. Sin ella, todos sus sofisticados cortafuegos y sistemas de detección de puntos finales pueden estar simplemente protegiendo una cámara acorazada vacía.

Piénselo de esta manera: no construiría una fortaleza con paredes endebles alrededor de una cámara del tesoro. Su base de datos es esa cámara del tesoro. Exige la protección más sólida y sofisticada que pueda permitirse.

Invertir en seguridad de bases de datos: una inversión a su futuro

El argumento de que la seguridad de las bases de datos es difícil de rentabilizar es erróneo. Piense en los posibles costes que se evitan al prevenir una filtración de datos. El ahorro en multas, litigios, pérdida de clientes y daños a la reputación supera con creces la inversión en seguridad de bases de datos.

Pero lo más importante es que pasarse a una solución moderna de seguridad de bases de datos le permitirá ahorrar dinero. Esto se debe a que las soluciones modernas pueden hacer más con menos:

• Menor impacto en la base de datos. Core Audit tiene un impacto insignificante en sus servidores de bases de datos, lo que le da más poder para gestionar su negocio.
• Menos hardware. Core Audit requiere menos recursos para funcionar. Ahorrará dinero en CPU, memoria y espacio en disco. Podrá hacer más con menos.
• Menos tiempo. Con informes y alertas más eficientes, análisis de anomalías y mucho más, dedicará menos tiempo a la seguridad de las bases de datos.
• Visibilidad completa. Con análisis forenses proactivos, obtendrá una visibilidad completa de todo lo que ha ocurrido en su base de datos. Sabrá lo que está pasando, por lo que podrá mejorar las prácticas de seguridad y diseñar controles adecuados.
• Mayor seguridad. Y lo más importante, obtendrá una mayor seguridad. Podrá defenderse de cualquier amenaza y garantizar que sus datos estén bien protegidos.

Todo esto se traduce en dinero. Dinero real en hardware y recursos humanos, por no hablar de evitar los costes de las catástrofes.

No persigas tendencias y protege lo que más importa

Es hora de ir más allá del atractivo de las soluciones de seguridad de moda y centrarse en la verdad fundamental: sus datos son su activo más valioso y su base de datos es su principal guardián. Una postura de seguridad de bases de datos sólida y bien mantenida no es solo una buena idea, es una necesidad empresarial.

En lugar de adoptar al azar la última moda en seguridad, dé un paso atrás y realice una evaluación exhaustiva del panorama de seguridad de su base de datos. ¿A qué amenazas se enfrenta y está preparado para hacerles frente? Invierta en soluciones que le proporcionen la protección que necesita.

No espere a que se produzca una violación de datos para convencerse. El coste de la inacción supera con creces la inversión en seguridad moderna para bases de datos. Haga de la seguridad de las bases de datos su prioridad número uno hoy mismo y garantice la seguridad y la resiliencia a largo plazo de su organización. Su futuro depende de ello.

El seguimiento de los cambios en los datos es una piedra angular del mantenimiento de registros y la integridad de los datos. En el mundo altamente regulado de la banca y las instituciones financieras, la capacidad de realizar un seguimiento preciso y reconstruir los cambios en los datos no es solo una buena práctica, sino un requisito normativo fundamental.

Las instituciones financieras manejan información de clientes y datos transaccionales en los que incluso una alteración menor y no documentada puede tener importantes implicaciones fiscales y legales. Este artículo explora el seguimiento de los cambios en los datos y examina su implementación práctica en las bases de datos Oracle y SQL Server.

¿Qué es el seguimiento de los cambios en los datos?

En lo que respecta a la auditoría, el mantenimiento de registros y la integridad de los datos, hay tres medidas que los clientes encuentran confusas:

• La auditoría de consultas tiene como objetivo registrar todas las solicitudes de acceso para ver los datos. Este tipo de auditoría tiene como objetivo combatir el robo de datos mediante la inspección y/o el control de quién accede a qué. Eso es algo en lo que podemos ayudarle, pero no entra dentro del alcance de este artículo.
• La auditoría de modificación de datos tiene como objetivo evitar cambios no autorizados mediante la inspección y/o el control de quién cambia los datos. Esto incluye insertar filas, eliminar datos o modificar registros. También podemos ayudarle con esto, pero no entra dentro del alcance de este artículo.
• El seguimiento de cambios en los datos tiene como objetivo rastrear el linaje de cada dato, lo que le permite deshacer los cambios. Ese es el tema de este artículo, y vamos a explicarlo un poco más.

Entonces, ¿en qué se diferencia el seguimiento de cambios en los datos de la auditoría de modificaciones?

Supongamos que tenemos una columna de saldo y alguien emite un SQL que lo cambia. Por ejemplo:

saldo = saldo + 1000

En la auditoría, registramos el SQL, quién lo ejecutó y cuándo. En el seguimiento de cambios en los datos, registramos los valores anteriores y nuevos del saldo (por ejemplo, 10 000 y 11 000). Esos valores no están en el SQL, ya que el SQL solo pidió añadir 1000 al valor anterior.

Si el SQL anterior modificó 10 filas, la auditoría registrará el SQL y el hecho de que modificó 10 filas. Sin embargo, la auditoría no enumerará qué filas cambiaron. El seguimiento de cambios en los datos registrará cada cambio, enumerando los 10 valores anteriores y los 10 nuevos.

Del mismo modo, si alguien eliminó varias filas, la auditoría registrará el SQL y el número de filas eliminadas. El seguimiento de cambios registrará los valores de cada fila eliminada.

El seguimiento de cambios en los datos es un requisito importante común en entornos altamente regulados, como bancos e instituciones financieras. Significa que conoceremos los valores antes y después de cada cambio. Esto es fundamental para llevar un registro detallado.

Las Regulaciones

El seguimiento de los cambios en los datos es la piedra angular de un buen mantenimiento de registros. Significa que conocemos el origen de cada dato y podemos revertirlo si alguien realiza un cambio no autorizado. Por lo tanto, es un requisito de todas las regulaciones de cumplimiento para bancos y otras instituciones financieras.

En los Estados Unidos, la FINRA (Autoridad Reguladora de la Industria Financiera) y el FFIEC (Consejo Federal de Examen de Instituciones Financieras) publican directrices para bancos e instituciones financieras.

Por ejemplo, la norma 4511 de la FINRA y la norma 17a-4 de la SEC en la que se basa tratan sobre el mantenimiento de registros electrónicos y exigen que el registro de auditoría incluya «todas las modificaciones y eliminaciones del registro o de cualquier parte del mismo» (17a-4(f)(2)(i)(A)(1)).

Existen directrices similares del BCE (Banco Central Europeo), la BaFin (Bundesanstalt für Finanzdienstleistungsaufsicht) en Alemania, la ACPR (Autorité de contrôle prudentiel et de résolution) en Francia y la CNMV (Comisión Nacional del Mercado de Valores) en España.

En América Latina, los reguladores también tienen requisitos estrictos de la CNBV (Comisión Nacional Bancaria y de Valores) en México, la SFC (Superintendencia Financiera de Colombia) en Colombia, la SBS (Superintendencia de Banca, Seguros y Administradoras Privadas de Fondos de Pensiones) en Perú y muchos más.

BCBS 239 (Comité de Supervisión Bancaria de Basilea – Principios para la agregación eficaz de datos de riesgo y la presentación de informes de riesgo) es una guía bancaria global que influye en la mayoría de los reguladores de todo el mundo. La mayoría de las interpretaciones tienden a coincidir en que también exige este tipo de registro detallado.

Implementaciones

El seguimiento de los cambios en la base de datos es posible a través de diferentes mecanismos. Aunque cada base de datos es ligeramente diferente y se revisa a continuación, los principios generales y las ventajas e inconvenientes son similares.

Los desencadenadores son fragmentos de código que se ejecutan cuando se producen cambios en los datos. Uno de los métodos más sencillos para realizar un seguimiento de los cambios en una base de datos es utilizar un desencadenador que registre los cambios en una tabla de auditoría. Esto es algo que cualquier administrador de bases de datos puede implementar en cualquier base de datos.

Sin embargo, los disparadores tienen un gran inconveniente: un alto impacto en el rendimiento. El registro adicional en la tabla de auditoría forma parte de la transacción y la ralentiza considerablemente. El impacto típico es de al menos un 100 %, lo que hace que todo tarde el doble de tiempo.

Los desencadenantes ligeros son una variante de la implementación clásica de los desencadenantes. En lugar de una inserción, ejecutan un SQL ficticio que incluye los datos que han cambiado. El uso de un SQL ficticio reduce significativamente la sobrecarga de rendimiento. Core Audit Full Capture puede ver estos SQL internos en los desencadenantes, extraer los datos y registrarlos en el servidor Core Audit.

Una de las ventajas de los desencadenantes ligeros es que permiten correlacionar los cambios en los datos con el resto de los datos de auditoría, incluida la sesión exacta en la que se produjeron.

Los desencadenantes ligeros funcionarán en cualquier base de datos siempre que se disponga de la tecnología Core Audit Full Capture para recopilar los datos. Por ejemplo, la información de los desencadenantes ligeros de SQL Server almacenada en Core Audit puede tener este aspecto:

Time	2025/05/16 15:38:19
Session	714000000000002308 (link to Core Audit session)
Username	sa
Session Info	OSQL-32 local
Owner	test
Table	emp
Operation	UPDATE
New Values	id=1 first=’John’ last=’Doe’ salary=11000
Old Values	id=1 first=’James’ last=’Doe’ salary=10000

Los registros de rehacer o registros de transacciones son nombres diferentes para lo mismo. Se trata de registros que existen en todas las bases de datos y que registran cada cambio en los datos. Son una parte fundamental de la base de datos, ya que permiten la recuperación tras un fallo y la recuperación en un momento determinado, lo que garantiza la integridad de los datos.

Dado que estos registros siempre existen y registran cada cambio, se pueden extraer para obtener los cambios que se desean rastrear. La principal ventaja de extraer estos registros es que no forma parte del SQL y no ralentiza las transacciones de la base de datos.

La desventaja es que la extracción de estos registros aumenta el consumo de recursos en el servidor y, lo que es más importante, se limita a la información almacenada en los registros. Por ejemplo, algunas bases de datos registran la información de la sesión, mientras que otras solo registran el cambio en sí, sin ninguna referencia a quién lo ha realizado. A continuación se ofrece información específica para cada tipo de base de datos, incluidas las desventajas que dependen de la base de datos.

Registros de rehacer de Oracle

Puede controlar la información de los registros de rehacer de Oracle a través de la configuración de registro suplementario de Oracle. Si su objetivo es extraer cambios de los registros, debe, como mínimo, ejecutar este SQL:

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Sin ello, «update» a veces aparece como «delete» e «insert». Puede habilitar el registro adicional para registrar más información sobre claves primarias, otras columnas y mucho más.

Oracle Logminer le permite consultar los registros de rehacer en línea y archivados para extraer información de los registros de rehacer de Oracle.

Core Audit puede utilizar Logminer para consultar los registros de rehacer y almacenar la información en el servidor Core Audit. Por ejemplo, la información de Logminer almacenada en Core Audit puede tener este aspecto:

Time	2025/05/15 12:22:55
Session	68
Serial#	3787
Username	HRAPP
Session Info	login_username=HRAPP client_info= OS_username=bluecore Machine_name=WORKGROUP\BLUECORE2 OS_terminal=BLUECORE2 OS_process_id=5976:5220 OS_program_name=sqlplus.exe
Owner	HRAPP
Table	SALARIES
Operation	UPDATE
Redo SQL	update “HRAPP”.”SALARIES” set “SALARY” = ‘11000’ where “SALARY” = ‘10000’ and ROWID = ‘AABnEEAAEAAAAJUAAE’;
Undo SQL	update “HRAPP”.”SALARIES” set “SALARY” = ‘10000’ where “SALARY” = ‘11000’ and ROWID = ‘AABnEEAAEAAAAJUAAE’;
New Values	Salary=11000
Old Values	Salary=10000
Field

Registros de transacciones de SQL Server

Los registros de transacciones de SQL Server no contienen información de sesión, por lo que es imposible vincular los cambios a los usuarios que los realizaron.

Core Audit puede aprovechar el motor de replicación de SQL Server para extraer información de los registros de transacciones. Se trata de una extracción de alto rendimiento casi en tiempo real, pero ocupa el motor de replicación, por lo que no se puede utilizar la replicación de SQL Server junto con la extracción de registros de transacciones de Core Audit.

Por ejemplo, la información de los registros de transacciones de SQL Server almacenada en Core Audit puede tener este aspecto:

Time	2025/05/16 13:42:33
Owner	test
Table	emp
Operation	update
Redo SQL	update [dbo].[emp] set [salary] = 11000 where [id] = 1

SQL Server también cuenta con mecanismos integrados para extraer información de los registros de transacciones. Estos mecanismos también se limitan a la misma información disponible en los registros. El seguimiento de cambios es el mecanismo antiguo, y la captura de datos modificados (CDC) es el más reciente. CDC es mejor, pero aún así requiere cierta administración y mantenimiento regular, y los resultados no son fáciles de entender.

Resumen

El seguimiento de los cambios en los datos es vital para un buen mantenimiento de los registros y esencial en los sistemas bancarios y financieros.

Este requisito tiene múltiples opciones de implementación, y Core Audit las admite todas. Aunque la mejor opción puede depender de su entorno, muchos clientes consideran que las limitadas desventajas de los desencadenantes ligeros y la alta calidad de la información son convincentes.

Como profesionales de la seguridad, estamos programados para mirar hacia afuera. Las luces rojas intermitentes, los escaneos de puertos siniestros, los rumores de sofisticadas APT: estas son las narrativas que captan nuestra atención. Construimos fortalezas digitales, fosos de cortafuegos y torres de vigilancia de sistemas de detección de intrusiones, todo ello apuntando hacia un adversario externo sin rostro.

¿Y por qué no íbamos a hacerlo? A los medios de comunicación les encantan las buenas historias sobre hackers. Los titulares gritan sobre ataques de estados-nación y bandas de ransomware que secuestran empresas. Es un drama apasionante, lleno de destreza técnica y figuras oscuras.

Pero, ¿y si la verdadera amenaza no acecha en la oscuridad exterior, sino que se encuentra cómodamente dentro de tus propias paredes? ¿Y si las llaves de tu reino ya están en manos de alguien en quien confías, o crees confiar?

Dejemos de lado las estadísticas abstractas por un momento y pintemos un cuadro.

Imagina a Jennifer, una administradora de bases de datos que lleva cinco años en la empresa. Conoce los sistemas al dedillo, tiene acceso privilegiado a tus datos más sensibles y, en general, se la considera una empleada fiable. Pero Jenny está ahogada en deudas personales y una figura oscura en Internet le ha ofrecido mucho dinero a cambio de una copia de los registros de los clientes. Es algo puntual, se dice a sí misma. Nadie lo sabrá nunca.

O pensemos en Mark, un gerente de ventas descontento que se siente ignorado para un ascenso. Todavía tiene acceso a datos críticos de ventas y decide sabotear sutilmente los registros, sesgando los informes y socavando a sus antiguos superiores. Es su forma de vengarse, un acto silencioso de venganza digital.

Luego está David, un becario bienintencionado pero despistado, que trabaja desde casa y deja su ordenador desatendido. Un amigo malintencionado de su compañero de piso se aprovecha del acceso interno legítimo de David. Navega con facilidad por su red supuestamente segura y accede directamente a sus bases de datos.

No se trata de villanos de Hollywood con sudaderas con capucha. Son personas normales que se enfrentan a presiones cotidianas y que, de forma intencionada o no, pueden convertirse en conductos o en la fuente directa de devastadoras violaciones de datos.

Piénsalo:

• Tienen las llaves: los empleados internos poseen credenciales y permisos legítimos que los atacantes externos solo pueden soñar con obtener. Ni siquiera necesitan eludir tus defensas perimetrales cuidadosamente construidas.
• Conocen el terreno: están familiarizados con tus protocolos de seguridad, comprenden las estructuras de tus bases de datos, pueden localizar dónde se encuentran los datos y saben cómo modificarlos. Utilizan estos datos a diario y los conocen al dedillo. Por eso los ataques internos son mucho más peligrosos y difíciles de detectar.
• El daño puede ser catastrófico: un empleado malintencionado con el acceso adecuado puede extraer grandes cantidades de datos y modificar información crítica sin que nadie se dé cuenta. Pueden causar un daño irreparable a la reputación y a los resultados de su organización.

Dedicamos mucho tiempo y energía a construir muros, pero ¿qué pasa con las puertas y ventanas que dejamos abiertas a sabiendas para los que están dentro? Supervisamos meticulosamente el tráfico de red en busca de anomalías, pero ¿aplicamos el mismo nivel de escrutinio a la actividad interna?

La cifra del 20 % no es solo una estadística; representa empresas reales, personas reales y consecuencias reales. Aparece cada año en el DBIR (Informe de investigación sobre violaciones de datos) de Verizon, y es una parte significativa del panorama de las violaciones que no podemos permitirnos ignorar.

La seguridad centrada en los datos no es solo una «mejor» defensa contra las amenazas externas; es la única defensa verdadera contra el enemigo interno. Al centrarse en proteger los datos en sí, se deja sin poder al atacante, ya sea externo o interno, incluso si logra penetrar en su perímetro o aprovechar credenciales legítimas.

Recuerde que el hombre del saco en el borde de la red no suele ser un hacker experto, sino un script kiddy que busca una vulnerabilidad oportunista. El verdadero hombre del saco es el que toca sus datos todos los días y puede causar un daño inimaginable con solo pulsar unas teclas.

Tenga en cuenta estas prácticas recomendadas de seguridad de bases de datos.

Imagine que Jennifer intenta extraer registros de clientes, pero es detectada por una alerta de anomalía de Core Audit o se le deniega el acceso por una política de bloqueo SQL de Core Audit. Imagine que los intentos de Mark de sabotear los datos se marcan inmediatamente como un cambio en su perfil de actividad. Imagine que el amigo que utiliza el ordenador de David no consigue extraer los datos porque está accediendo a una cantidad inusual de información confidencial.

No se trata de desconfiar de todos los miembros de su organización. Se trata de reconocer que la naturaleza humana es compleja, que las circunstancias cambian y que incluso las personas bienintencionadas pueden ser explotadas. Se trata de implementar una estrategia de seguridad que asuma que se producirá un ataque a la base de datos, independientemente de su origen.

Así que, la próxima vez que revise su postura de seguridad, tómese un momento para mirar hacia dentro. Más allá de las deslumbrantes luces del panorama de amenazas externas, existe una realidad más silenciosa, quizás menos dramática, pero igualmente peligrosa dentro de sus propias paredes digitales. No permita que el enfoque en el exterior le impida ver las vulnerabilidades internas. Sus datos, y el futuro de su organización, dependen de ello. Es hora de sentir el peso de la amenaza interna, no solo de reconocer su existencia.

¿Por qué es tan importante la seguridad de las bases de datos?

Una brecha de datos grave significa que alguien ha accedido a su base de datos y ha robado datos. Las bases de datos son las guardianas de sus datos, y cualquiera que quiera obtenerlos debe hacerlo a través de la base de datos.

Aunque debe proteger todos los componentes de la infraestructura, ninguno es más importante que la base de datos. Independientemente de cómo se inicien, todas las brechas terminan en la base de datos.

Muchas organizaciones no prestan suficiente atención a la seguridad de las bases de datos por diversas razones. Algunas no creen que sea posible protegerlas, otras piensan que no disponen de los recursos necesarios, les preocupan los costes, etc. Pero la verdad es que la tecnología adecuada y los conocimientos técnicos de los socios le permitirán proteger sus bases de datos a un precio asequible. Y esa protección es el paso más importante en la seguridad informática.

Amenazas a las bases de datos

Por extraño que parezca, Internet está lleno de tonterías sobre las amenazas a las bases de datos. Incluso blogs y artículos de fuentes acreditadas repiten estas afirmaciones sin fundamento. La siguiente lista pretende aclarar estos hechos:

Amenazas Internas

Sí, la amenaza interna es un gran problema. Para cuantificarla con mayor precisión, alrededor del 20 % de las brechas de datos involucran a un actor interno malintencionado. El informe DBIR de Verizon es una buena fuente de información, ya que cada año presenta cifras similares. Algunos países, como Alemania, informan que la amenaza interna alcanza hasta un 26 %. Independientemente de si se trata de 1 de cada 4 o 1 de cada 5 brechas, se trata de una amenaza significativa que no debemos ignorar.

Esta amenaza es otra razón más por la que las organizaciones deben invertir en la seguridad de las bases de datos. Las defensas centradas en los datos, en general, y la seguridad de las bases de datos, en particular, son las únicas defensas contra los actores internos.

Amenazas externas

La mayoría de los ataques provienen de agentes externos. Sin embargo, es fundamental comprender cómo estos agentes penetran en la base de datos. Dado que las bases de datos no deben estar conectadas directamente a Internet, todos estos ataques deben realizarse a través de un intermediario.

Desde el punto de vista de la seguridad de las bases de datos, es irrelevante si el atacante ha entrado en la organización mediante un ataque de phishing, algún otro tipo de ataque de ingeniería social, un error de configuración o cualquier otra cosa. Lo importante es que ha entrado y ahora va a por tus datos. El resto de esta lista desglosa cómo ocurre esto.

Acceso al servidor local

Aunque es difícil cuantificar la amenaza que supone el acceso al servidor de la base de datos local, es posible establecer un límite mínimo. Ten en cuenta que más del 40 % de las brechas de datos implican ransomware y que, por definición, casi todos los ataques de ransomware deben comprometer el servidor de la base de datos. Simplemente no hay otra forma de cifrar los archivos de datos.

Por lo tanto, independientemente de si la amenaza del acceso al servidor local es del 40 % o superior, se trata de una amenaza significativa que no podemos ignorar.

Cuentas válidas

Las amenazas a través de cuentas válidas incluyen el robo de credenciales, la suplantación de identidad y ataques similares. Pero todo lo demás en esta lista de amenazas, como las amenazas internas, las inyecciones SQL y otras, también se manifiesta a través de una cuenta válida. Aunque no podemos estimar el nivel exacto de amenaza de las cuentas válidas, estas son el método principal para penetrar en una base de datos.

Pero, ¿por qué agrupar el robo de credenciales con, por ejemplo, el abuso de privilegios por parte de actores internos? Se debe a la forma en que abordamos estas amenazas. Si no podemos confiar en la actividad de las conexiones autenticadas, debemos identificar la actividad maliciosa dentro de esas conexiones. No importa si alguien robó las credenciales o si el usuario abusó de sus privilegios. Más adelante se profundizará en este tema.

Inyección SQL

Puede resultar sorprendente, pero no hay cifras fiables sobre el nivel de amenaza de la inyección SQL. Aunque se estima que es alto, especialmente para las aplicaciones conectadas a Internet, diferentes fuentes publican cifras muy dispares.

Aunque la inyección SQL es solo un tipo de vulnerabilidad de las aplicaciones, es sin duda la más común. Las soluciones de seguridad para aplicaciones web, como WAF, no logran abordarla de manera consistente, mientras que las soluciones modernas de seguridad de bases de datos, como Core Audit, ofrecen una defensa eficaz. Las defensas modernas de bases de datos abordan más que la inyección SQL y, hoy en día, son la solución preferida. La situación actual contrasta fuertemente con la de hace dos décadas, cuando surgió la tecnología WAF.

Errores humanos

Los errores humanos pueden crear vulnerabilidades en las bases de datos. Por ejemplo, al otorgar demasiados privilegios, descuidar el cierre de cuentas, utilizar contraseñas sencillas, etc. Sin embargo, las pruebas sugieren que esto no es una causa significativa de brechas de la seguridad de las bases de datos. Si bien los errores humanos son una razón fundamental para la penetración del perímetro, no son una causa para la penetración de las bases de datos.

No obstante, identificar y corregir dichos errores es una buena práctica. Establecer procesos de control de cambios (véase más abajo) es un paso esencial en esa dirección.

Riesgos menores

Algunas amenazas teóricas suponen amenazas minúsculas para las bases de datos. Las mencionamos porque existen afirmaciones de este tipo en diversos blogs y artículos. Sin embargo, son absurdas.

Las bases de datos modernas no tienen vulnerabilidades significativas, desbordamientos de búfer ni debilidades similares. Al menos, no las que son responsables de una brecha, ya que esta falta de vulnerabilidades es particularmente cierta en el caso de las vulnerabilidades relacionadas con la autenticación que permiten a los atacantes conectarse sin contraseña. No existe ningún paquete mágico ni puerta trasera secreta no documentada que permita a alguien acceder a su base de datos. Si bien es esencial aplicar parches de seguridad, es raro que se aproveche una vulnerabilidad de la base de datos sin un nombre de usuario y una contraseña válidos.

Además, no se debe conectar una base de datos directamente a Internet. Las bases de datos deben residir únicamente en redes internas seguras. Por lo tanto, las bases de datos no son vulnerables a los ataques de denegación de servicio (DoS). Y eso se aplica doblemente a los ataques de denegación de servicio distribuido (DDoS). Cualquier intento de proteger una base de datos contra tales ataques es inútil.

Resumen de amenazas

En resumen, una brecha de la base de datos aprovecha un usuario y una contraseña válidos para conectarse a la base de datos. Estas son las vías principales:

• Amenaza interna del administrador de bases de datos (DBA). Se trata de un abuso de privilegios por parte de un administrador de bases de datos.
• Compromiso de la cuenta del DBA. Se trata de un agente externo que ha penetrado el escritorio del DBA, ha robado la contraseña del DBA o la contraseña de una cuenta con privilegios compartidos (como SYS o SA).
• Acceso local. La mayoría de las bases de datos permiten conexiones no autenticadas desde cuentas específicas del sistema operativo en el servidor de la base de datos. Una brecha de este tipo suele ser obra de un agente externo, pero también puede ser un abuso de privilegios.
• Compromiso de la cuenta de la aplicación. Se trata de un agente externo que ha obtenido acceso a la contraseña de la aplicación, o de un agente interno que abusa de su acceso.
• Compromiso de la aplicación. Se trata de un exploit de una vulnerabilidad de la aplicación, como una inyección SQL.
• Otro abuso o compromiso de cuentas. Al igual que la cuenta DBA, otras cuentas de la base de datos pueden ser objeto de abuso por parte de sus legítimos propietarios o comprometidas por un agente externo.

Prácticas básicas

Las prácticas básicas de seguridad tienen como objetivo reforzar una base de datos, pero no abordan las amenazas comunes. Se trata de pasos esenciales, pero no impedirán una brecha de la seguridad.

1. Cifrado. Active el cifrado de red y de disco. Aunque ninguna amenaza común se dirige a los paquetes de red o a los archivos, es una buena práctica y fácil de implementar.
2. Seguridad de las cuentas:

• Inventario de cuentas. Haga una lista de todas las cuentas de la base de datos e identifique a las personas o aplicaciones asociadas a ellas.
• Cuentas inactivas. Cierre las cuentas inactivas.
• Cuentas individuales. Asegúrese de que todas las cuentas sean cuentas individuales, excepto las cuentas de aplicaciones y las cuentas de administración compartidas integradas (como SYS o SA).
• Contraseña. Asegúrese de que ninguna contraseña sea la contraseña predeterminada o una contraseña codificada.
• Política de contraseñas. Active las políticas de contraseñas que requieran una longitud mínima de contraseña, complejidad de contraseña, bloqueo de cuentas, etc.
• Privilegios mínimos. Asegúrese de que todas las cuentas tengan los privilegios mínimos que las personas necesitan para realizar sus tareas.

3. Parches. Instale todos los parches de seguridad para la base de datos y todo el software y las herramientas asociados. Esto incluye el software de aplicación, las herramientas de generación de informes, las herramientas de administración de bases de datos, las herramientas de gestión del rendimiento, etc.

4. Control de cambios. Implemente un proceso de control de cambios y valide de forma independiente que todos los cambios estén aprobados. Esto incluye cambios en la configuración, los usuarios, los permisos, los objetos de la base de datos, etc.

Buenas prácticas

Como se mencionó anteriormente, las medidas de seguridad básicas son esenciales, pero no pueden hacer frente a las principales amenazas. Para hacer frente a estas amenazas se utiliza el control de actividad, el método principal para la seguridad de las bases de datos.

Casi todas las amenazas provienen de conexiones válidas que utilizan privilegios adecuados. Por lo tanto, la única forma de hacerles frente es inspeccionando cada SQL en cada conexión y aplicando los controles detectivos o preventivos adecuados.

Dado que los controles de actividad tienen como objetivo garantizar que las conexiones solo realicen actividades «buenas», independientemente de si la amenaza es interna o externa, lo que importa es el perfil de actividad de la cuenta y cómo evitar que realice acciones maliciosas.

1. Cuentas DBA y conexiones locales. Por lo general, los administradores de bases de datos (DBA) no deben acceder a datos confidenciales. Muchas veces, tampoco ejecutan DML. Eso significa que alertar o bloquear estas actividades en las cuentas administrativas es una forma excelente de prevenir una brecha. Los controles internos de la base de datos no pueden hacer eso, pero el control avanzado de actividades sí. Estos controles mitigan cualquier amenaza que se manifieste a través de una cuenta privilegiada, incluido el abuso por parte de un DBA, el robo de credenciales y las conexiones locales.
2. Cuenta de aplicación. Las aplicaciones tienden a repetir las mismas construcciones SQL una y otra vez. Aunque puede haber varios cientos de miles de construcciones, en última instancia, todas se repiten. Un análisis de anomalías de la actividad de la aplicación es una forma excelente de identificar cambios en el perfil de actividad de la aplicación. Esto funciona para detectar inyecciones SQL, así como la mayoría de los tipos de comportamiento indebido de las aplicaciones.
   Aunque esto también detecta el abuso de la cuenta de la aplicación o el robo de credenciales, también se pueden detectar mediante controles de sesión (que se describen a continuación).
3. Actividad DDL. Ciertos tipos de actividad, como DDL y DCL, merecen precauciones adicionales. Los DDL permiten administrar la base de datos, y los DCL son un subtipo relacionado con la autorización (usuarios y concesiones). La práctica habitual es informar sobre estos SQL para garantizar que los cambios sean aprobados.
4. Tablas confidenciales. Controlar el acceso a los datos confidenciales es fundamental, y el análisis de anomalías es una medida eficaz para identificar cambios en el comportamiento relacionado con estas tablas. Esto permitirá detectar accesos inusuales por parte de los administradores de bases de datos u otras cuentas, cambios peligrosos en el comportamiento de la aplicación y mucho más.
5. Programas sensibles. Algunos programas no tienen restricciones integradas sobre lo que pueden hacer sus usuarios y les permiten ejecutar cualquier SQL. Los administradores suelen utilizar estos programas para gestionar la base de datos, y los analistas a veces escriben SQL para aprovechar al máximo las capacidades de la base de datos. La ausencia de restricciones merece una supervisión adicional que depende de cómo utilicen estas personas los programas. Puede implicar la supervisión del acceso a tablas sensibles, DML, anomalías, etc.
6. Sesiones y origen de la actividad. El control de sesiones es el tipo de control más sencillo y fácil de entender. Implica supervisar quién se conecta, desde dónde y cuándo. Los informes pueden referirse a un subconjunto de cuentas, como los administradores de bases de datos o la aplicación, para garantizar que todas las conexiones proceden de las fuentes esperadas. Las anomalías son alertas cruciales que destacan un cambio en el origen de la actividad (por ejemplo, una IP diferente), una hora inusual del día, un mayor volumen de actividad y mucho más.

Ponte a Prueba

Las siguientes preguntas evalúan su nivel de control sobre sus bases de datos. Si no está seguro, considere algunas de las mejores prácticas recomendadas anteriormente.

1. ¿Recibe alertas falsas positivas de su solución de seguridad de bases de datos?
   Ningún sistema de seguridad es perfecto. Todas las soluciones equilibran los falsos positivos y los falsos negativos (eventos de seguridad no detectados). No recibir falsos positivos significa que su seguridad es demasiado laxa o inexistente. Significa que no recibirá ninguna alerta aunque se produzca una brecha de seguridad.
2. ¿Sabe quién ha accedido a sus datos confidenciales durante la última semana?
   Saber quién accede a los datos confidenciales de su base de datos es un indicador clave de concienciación. Si no sabe la respuesta, es poco probable que sepa cuándo se produce un acceso malicioso. También es poco probable que pueda llevar a cabo una investigación forense satisfactoria de una brecha de seguridad.
3. ¿Sabe qué usuarios, programas e IP han accedido a su base de datos durante la última semana?
   Esa es una pregunta fundamental sobre el control de sesiones. Conocer las fuentes de actividad de su base de datos es un control esencial. Si no lo sabe, no sabrá si se ha producido un robo de credenciales y no podrá llevar a cabo una investigación forense.
4. ¿Cree que sabría si un intruso ha aprovechado el acceso local o una cuenta de DBA?
   Esa es una pregunta más compleja, ya que un intruso podría utilizar la misma fuente de actividad que el usuario real. Sin embargo, es una prueba crítica, ya que se trata de vectores de ataque muy populares.
5. ¿Cree que sabría si se ha producido un intento de inyección SQL?
   La inyección SQL se considera una amenaza importante y el principal vector de ataque a las aplicaciones. También es muy difícil de detectar, y el análisis de anomalías es el único método eficaz.

Una postura de seguridad adecuada debería permitirle responder a estas preguntas. Al fin y al cabo, cubren las vías más populares para la brecha de datos.

Reflexiones Finales

La seguridad de las bases de datos es fundamental para proteger tus datos. En este artículo se explican las principales amenazas, cómo abordarlas y cómo ponerse a prueba. Si no controla sus bases de datos, es mucho más probable que sufra una brecha de datos y es poco probable que se entere.

Toma el control de tus bases de datos. ¡Ponte en contacto con nosotros hoy mismo!

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.