La infraestructura empresarial de bases de datos está sometida a una cantidad abrumadora de riesgos. Este documento se destina a ayudar a las organizaciones a afrontar las más críticas de estas amenazas ofreciendo una lista de las diez principales, identificadas por el Application Defense Center de Imperva. Por cada punto vulnerable, este informe proporciona información a fondo, estrategias generales de mitigación de riesgos y la protección de bases de datos que ofrece la solución SecureSphere Database Security de Imperva.

1. White Paper
Las diez principales amenazas para las
bases de datos
Cómo mitigar las vulnerabilidades más significativas para las bases
de datos
La infraestructura empresarial de bases de datos está sometida a una cantidad
abrumadora de riesgos. Este documento se destina a ayudar a las organizaciones a
afrontar las más críticas de estas amenazas ofreciendo una lista de las diez principales,
identificadas por el Application Defense Center de Imperva. Por cada punto
vulnerable, este informe proporciona información a fondo, estrategias generales
de mitigación de riesgos y la protección de bases de datos que ofrece la solución
SecureSphere Database Security de Imperva.
Las diez principales amenazas para las bases de datos
1. Abuso de permisos excesivos
2. Abuso de permisos legítimos
3. Elevación de privilegios
4. Explotación de bases de datos vulnerables y mal configuradas
5. SQL Injection
6. Trazas de auditoría deficientes
7. Denegación de servicio
8. Vulnerabilidades de protocolo de comunicación de bases de datos
9. Copias no autorizadas de datos confidenciales
10. Exposición de datos de copia de seguridad
Al tomar medidas para afrontar estas diez principales amenazas, las organizaciones
satisfacen los requisitos internacionales de cumplimiento regulatorio y las mejores
prácticas de la industria relacionadas con la protección de datos y mitigación de
riesgos.

2. Las diez principales amenazas para las bases de datos
Amenaza 1: Abuso de permisos excesivos
DatabaseFileWeb
Cuando a los usuarios (o las aplicaciones) se les conceden permisos de acceso a la base de datos que superan los
requisitos de su función, es posible que exista abuso de estos permisos con fines malintencionados. Por ejemplo, un
administrador universitario cuya responsabilidad sólo necesita la capacidad de cambiar la información de contacto
de los estudiantes puede aprovecharse de la concesión de permisos excesivos de actualización de bases de datos
para cambiar las calificaciones de los estudiantes.
A un usuario dado de una base de datos se le pueden conceder permisos excesivos por el simple hecho de que los
administradores de bases de datos no tienen tiempo para definir y actualizar mecanismos granulares de control de
permisos de acceso para cada usuario. Como resultado, todos los usuarios o grupos grandes de usuarios reciben
privilegios de acceso genéricos predeterminados que superan de largo los requisitos de una tarea específica.
Prevención del abuso de permisos excesivos: eliminación de derechos excesivos y su aplicación a
través del control de acceso a nivel de consulta
La solución para la amenaza que representan los permisos excesivos es la eliminación de éstos. Para ello, es necesario
poder identificar los derechos excesivos, es decir, derechos que el usuario no necesita para llevar a cabo su trabajo.
Esto se logra mediante la extracción de permisos de las bases de datos, correlación de permisos con el usuario de la
organización y análisis de estos permisos. Se trata de un proceso largo y complicado, que si se hace manualmente
absorbe grandes cantidades de tiempo y recursos. Una solución automatizada puede reducir en gran medida el
tiempo y recursos necesarios y acortar el proceso de análisis.
Para aplicar mejor los permisos de acceso, también es necesario implementar controles granulares de acceso a nivel
de consulta. El control de acceso a nivel de consulta es un mecanismo que restringe los privilegios de base de datos
a las operaciones SQL (SELECT, UPDATE, etc.) y datos mínimos requeridos. La granularidad del control de acceso a
los datos debe ir más allá de la tabla: a filas y columnas específicas dentro de una tabla. Un mecanismo de control
de acceso a nivel de consulta lo suficientemente granular permitiría que el administrador universitario deshonesto
que se mencionó anteriormente actualice la información de contacto, pero emitiría una alerta si intenta cambiar las
calificaciones. El control de acceso a nivel de consulta no sólo es útil para detectar el abuso de permisos excesivos
por parte de empleados desleales, sino también para prevenir la mayor parte de las demás amenazas de la lista de las
diez principales que se describen aquí. La mayoría de las implementaciones de software de bases de datos integran
un cierto nivel de control de acceso a nivel de consulta (disparadores, seguridad a nivel de filas, etc), sin embargo,
la naturaleza manual de estas funciones "incorporadas" hace que sólo resulten prácticas para las implementaciones
más limitadas. El proceso de definición manual de una política de control de acceso a nivel de consulta para todos
los usuarios en diferentes filas, columnas y operaciones de bases de datos simplemente lleva demasiado tiempo. Para
complicar más las cosas, dado que las funciones de los usuarios cambian con el tiempo, ¡las políticas de consultas
deben actualizarse para reflejar estos cambios en las funciones! La mayoría de los administradores de bases de
datos tendrían bastante dificultad para definir una política de consulta que resulte útil para varios usuarios en un
determinado momento en el tiempo, y esa dificultad sería aún mayor si se trata de cientos de usuarios dentro de un
período de tiempo. Como resultado, la mayoría de las organizaciones ofrecen a los usuarios un conjunto genérico de
permisos de acceso excesivos que funcionan para un abanico grande de usuarios. Es necesario utilizar herramientas
automatizadas para hacer realidad el control de acceso a nivel de consulta.
Perfilado dinámico (Dynamic Profiling) de SecureSphere: gestión de los permisos de los usuarios y
control automatizado de acceso a nivel de consulta
SecureSphere User Rights Management for Databases (URMD) permite la consolidación y revisión automáticas de los
permisos de los usuarios, el análisis de los permisos para acceder a datos restringidos y la identificación de permisos
excesivos y usuarios durmientes sobre la base del contexto de la organización y el uso real.
El permiso de acceso a objetos restringidos debe concederse según la necesidad y normalmente se define según el
contexto de los usuarios en la organización. Al agregar detalles tales como la función y el departamento del usuario,
los responsables tienen visibilidad completa de la función laboral del usuario y el tipo de datos al que puede acceder.
Las vistas analíticas de URMD ofrecen a los responsables la capacidad de determinar si los permisos de acceso de un
usuario están definidos adecuadamente y de eliminar los que resulten excesivos que no son necesarios para que el
usuario haga su trabajo.
Imperva White Paper
< 2 >

3. Las diez principales amenazas para las bases de datos
Mediante URMD, las organizaciones pueden demostrar que cumplen con normas tales como SOX, PCI 7 y PCI 8.5, y
DatabaseFileWeb
reducen el riesgo de violación de los datos. URMD es un complemento opcional de los productos de protección de
bases de datos de Imperva.
La solución SecureSphere Database Security de Imperva también ofrece un mecanismo automatizado para definir y
aplicar políticas de control de acceso a nivel de consulta. La tecnología de perfilado dinámico (Dynamic Profiling) de
SecureSphere aplica algoritmos de aprendizaje automatizados para crear perfiles de uso a nivel de consulta para cada
usuario y aplicación que accede a la base de datos. Cada perfil va desde patrones de uso general hasta las consultas
y procedimientos almacenados de cada persona. Los algoritmos de aprendizaje de SecureSphere actualizan
continuamente el perfil a lo largo del tiempo para eliminar los ajustes manuales cuando se producen cambios en las
funciones de los usuarios. Si cualquier usuario inicia una acción que no corresponda a su perfil, SecureSphere registra
el evento, emite una alerta y, de forma opcional, puede bloquear la acción según su severidad. El administrador
universitario, del que hablamos antes, que cambia las calificaciones sería fácilmente detectado mediante el perfilado
dinámico. El perfil del administrador incluiría un conjunto de consultas que reflejan modificaciones normales a
información específica de contacto de los estudiantes y quizás acceso de lectura solamente a las calificaciones. Sin
embargo, un intento repentino de cambiar las calificaciones emitiría una alerta.
Imperva White Paper
< 3 >

4. Las diez principales amenazas para las bases de datos
Amenaza 2: Abuso de permisos legítimos
DatabaseFileWeb
Los usuarios también pueden cometer abuso de sus permisos legítimos con fines no autorizados. Por ejemplo,
veamos el caso de un hipotético empleado desleal de una organización de atención médica con permisos para ver
los registros de pacientes individuales mediante una aplicación web personalizada. La estructura de la aplicación web
normalmente limita el acceso de los usuarios a la visualización de la historia clínica de un paciente individual: no se
pueden ver varios registros al mismo tiempo y no se permite hacer copias electrónicas. Sin embargo, el empleado
desleal puede eludir estas limitaciones conectándose a la base de datos mediante un cliente alternativo, como
Microsoft Excel. Con Microsoft Excel y sus credenciales legítimas de inicio de sesión, el empleado puede recuperar y
guardar los registros de todos los pacientes. Es improbable que la copia personal de bases de datos de registros de
pacientes cumpla con las políticas de protección de los datos de los pacientes de cualquier organización de atención
médica. Hay dos riesgos a tener en cuenta. El primero es el empleado deshonesto dispuesto a vender los registros
de los pacientes por dinero. El segundo (y quizás el más común) es el empleado descuidado que recupera y guarda
grandes cantidades de información en su máquina cliente con fines laborales legítimos. Cuando estos datos existen
en una máquina terminal, se vuelven vulnerables a riesgos como troyanos, robo de equipos portátiles, etc.
Prevención del abuso de permisos legítimos: comprensión del contexto del acceso a bases de datos
La solución para el abuso de permisos legítimos es el control de acceso a las bases de datos que se aplica no sólo a
consultas específicas como las que se describen anteriormente, sino también al contexto que rodea al acceso a bases
de datos. Al aplicar políticas para aplicaciones cliente, horarios, lugares, etc., es posible identificar a los usuarios que
usan permisos legítimos de acceso a bases de datos de manera sospechosa.
Perfilado dinámico (Dynamic Profiling) de SecureSphere: control de acceso basado en contexto
Además de la información de consultas (ver "Permisos excesivos" más arriba) la tecnología de perfilado dinámico de
SecureSphere crea automáticamente un modelo del contexto que rodea las interacciones normales con bases de
datos. La información contextual específica almacenada en el perfil incluye el horario, dirección IP de origen, volumen
de datos recuperados, aplicación cliente, etc. Cualquier conexión cuyo contexto no coincida con la información
almacenada en el perfil del usuario dispara una alerta. Por ejemplo, el empleado desleal de la organización médica
que se describió anteriormente sería detectado por SecureSphere no sólo por su uso no estándar de un cliente de
Microsoft Excel, sino también por el volumen de datos recuperados en una misma sesión. En este caso específico, las
desviaciones en la estructura de la consulta no estándar de Microsoft Excel también alertarían sobre una violación a
nivel de consulta (ver "Abuso de permisos excesivos", más arriba).
Imperva White Paper
< 4 >

5. Las diez principales amenazas para las bases de datos
Amenaza 3: Elevación de privilegios
DatabaseFileWeb
Es posible que personas malintencionadas puedan aprovechar vulnerabilidades en el software de la plataforma
de una base de datos para convertir privilegios de acceso de un usuario común en privilegios de administrador. Se
pueden encontrar vulnerabilidades en procedimientos almacenados, funciones incorporadas, implementaciones
de protocolo e incluso, en sentencias SQL. Por ejemplo, un desarrollador de software en una institución financiera
puede aprovechar una función vulnerable para acceder al privilegio de administrador de una base de datos. Con el
privilegio de administrador, el desarrollador deshonesto puede desactivar mecanismos de auditoría, crear cuentas
falsas, transferir fondos, etc.
Prevención de la elevación de privilegios: IPS y control de acceso a nivel de consulta
La elevación de privilegios se puede prevenir mediante una combinación de sistemas tradicionales de prevención
contra intrusos (IPS) y control de acceso a nivel de consulta (ver "Permisos excesivos" más arriba). El IPS inspecciona
el tráfico de la base de datos para identificar patrones que corresponden a vulnerabilidades conocidas. Por ejemplo,
si se sabe que una función determinada es vulnerable, un IPS puede bloquear todo el acceso al procedimiento
vulnerable, o (de ser posible) bloquear sólo los procedimientos con ataques incorporados. Desafortunadamente, la
localización precisa únicamente de las solicitudes de bases de datos que contienen ataques puede ser difícil si se
utiliza sólo un IPS. Muchas funciones vulnerables de bases de datos se usan normalmente con fines legítimos. Por
lo tanto, bloquear todos los casos de estas funciones no es una opción válida. El IPS debe separar correctamente las
funciones legítimas de las que contienen ataques. En varios casos, las infinitas variaciones en los ataques hacen que
esto resulte imposible. En estos casos, los sistemas IPS se pueden usar únicamente en modo de alerta (sin bloqueos),
dado que es posible que se produzcan falsos positivos. Para mejorar la exactitud, los IPS se pueden combinar con
indicadores alternativos de ataques, como el control de acceso de consulta. El IPS se puede usar para verificar si
una solicitud de acceso a una base de datos accede o no una función vulnerable, mientras que el control de acceso
de consulta detecta si la solicitud corresponde o no al comportamiento normal del usuario. Si una misma solicitud
indica acceso a una función vulnerable y comportamiento inusual, entonces es casi seguro que se está produciendo
un ataque.
Elevación de privilegios de SecureSphere: integración del IPS y el perfilado dinámico
SecureSphere integra sistemas IPS avanzados y perfiles dinámicos para el control de acceso de consulta (ver
"Permisos excesivos" más arriba). Juntas, estas tecnologías ofrecen una protección sumamente precisa contra la
elevación de privilegios. El IPS de SecureSphere ofrece protección contra ataques detectando vulnerabilidades
conocidas con diccionarios de firmas compatibles con Snort® para todos los protocolos. Además, la organización
internacional de investigación sobre seguridad de Imperva, Application Defense Center, ofrece protecciones
exclusivas específicas para SQL, que garantizan que SecureSphere represente la mejor protección IPS para bases de
datos del mundo. El servicio de actualización de seguridad de SecureSphere actualiza automáticamente todos los
diccionarios de firmas para garantizar que las protecciones más actualizadas se estén aplicando continuamente. El IPS
de SecureSphere bloquea ciertos ataques fácilmente identificables en línea sin exigir ninguna confirmación adicional
del ataque. Sin embargo, si una solicitud determinada se puede clasificar como sólo sospechosa, SecureSphere
correlaciona la solicitud con infracciones relacionadas de perfiles dinámicos para validar un ataque. Para ilustrar
cómo SecureSphere integra IPS y perfiles dinámicos, volvamos al caso del desarrollador de software desleal de la
empresa de servicios financieros del que hablamos antes. Imagínese que el desarrollador intenta aprovechar un
desbordamiento conocido de la memoria intermedia en una función de base de datos para insertar un código
malintencionado para elevar sus privilegios a los de administrador de la base de datos. En este caso, SecureSphere
identifica dos violaciones simultáneas. En primer lugar, cualquier consulta que intenta acceder a una función
vulnerable conocida dispara una violación de IPS. En segundo lugar, la consulta inusual dispara una violación de
perfil. Al correlacionar las dos violaciones en una misma solicitud de base de datos del mismo usuario, se valida un
ataque con suma precisión, y se puede emitir una alerta de alta prioridad para bloquear la acción.
Imperva White Paper
< 5 >

6. Las diez principales amenazas para las bases de datos
Amenaza 4: Explotación de bases de datos vulnerables y mal configuradas
DatabaseFileWeb
Es común encontrar bases de datos vulnerables a las que no se han aplicado parches, o bases de datos que todavía
tienen las cuentas y los parámetros de configuración predeterminados. Un atacante que busque aprovecharse de
los puntos débiles de la base de datos por lo general probará los sistemas para detectar estas vulnerabilidades, lo
que puede comprometer la seguridad. Mientras los proveedores no lanzan un parche para proteger a los sistemas
contra una cierta vulnerabilidad, la base de datos de la organización queda desprotegida. Cuando se lanza un parche,
no se dispone de él de inmediato. Hay diferentes aspectos a tener en cuenta al instalar un parche en una base de
datos. En primer lugar, la organización debe valorar, previamente al proceso de instalación del parche, cómo éste
puede afectar al sistema. A veces, un parche puede entrar en conflicto con un código ya existente, o puede abrir un
camino para eludir una protección. En segundo lugar, el sistema sufre tiempo de inactividad cuando el servidor de
la base de datos no puede proporcionar servicio a los usuarios mientras se instala el parche. Finalmente, las grandes
empresas con decenas e incluso cientos de bases de datos deben incluir un cronograma de instalación de parches,
estableciendo un orden de prioridad para instalar los parches en las bases de datos. Así, no resulta sorprendente que
para muchas organizaciones, el proceso de instalación de parches dure unos cuantos meses, por lo general entre 6
y 9 meses (según investigaciones realizadas por Independent Oracle User Group – IOUG*). Los administradores de
bases de datos, administradores de sistemas y de TI, los desarrolladores...todos ellos juegan un papel en el proceso
de instalación de parches. Si se tiene en cuenta que los recursos y el tiempo son limitados, los servidores quedan
vulnerables durante meses después del lanzamiento de un parche.
Las cuentas y los parámetros de configuración predeterminados que quedan en una base de datos de producción
pueden ser aprovechados por un atacante, que puede intentar obtener acceso a la base de datos usando una cuenta
predeterminada. Un parámetro de auditoría deficiente puede permitir que un atacante eluda controles de auditoría
o elimine los rastros de sus actividades. Los esquemas de autenticación deficientes permiten que los atacantes
asuman la identidad de usuarios legítimos de la base de datos mediante el robo o la obtención de otra manera de
credenciales de inicio de sesión.
Prevención: evaluación y parcheo de vulnerabilidades
Para mitigar la amenaza sobre las bases de datos vulnerables y sin parches, en primer lugar, es necesario evaluar la
situación de seguridad de las bases de datos y cerrar todas las vulnerabilidades y brechas de seguridad conocidas.
Las organizaciones deben examinar periódicamente las bases de datos para detectar vulnerabilidades y parches
no aplicados. Las evaluaciones de configuración deben proporcionar una imagen clara del estado actual de la
configuración de los sistemas de datos. Estas evaluaciones también deben identificar las bases de datos que no
cumplan con las políticas de configuración definidas. Cualquier parche de seguridad no aplicado debe instalarse
lo antes posible. Si se descubre una vulnerabilidad y el parche aún no está disponible, ya sea porque el proveedor
no lo ha proporcionado o porque todavía no se ha instalado, se debe implementar una solución de parche virtual.
Este tipo de solución bloquea cualquier intento de explotar estas vulnerabilidades. Por lo tanto, al minimizar el
plazo de exposición con parches virtuales se protege a la base de datos contra los intentos de explotación de sus
vulnerabilidades hasta que se instala un parche.
Evaluaciones de vulnerabilidad y parches virtuales de SecureSphere
SecureSphere incluye una solución completa de evaluación de vulnerabilidades y configuraciones que permite que
los usuarios programen exploraciones periódicas para detectar vulnerabilidades conocidas, parches no aplicados
y configuraciones erróneas. La solución se actualiza de modo rutinario mediante el mecanismo de actualizaciones
automatizado de ADC con las políticas de evaluación y pruebas para detectar las más recientes vulnerabilidades
sobre la base de investigaciones desarrolladas por el centro de investigación de Imperva: Application Defense Center
(ADC). SecureSphere también permite que los usuarios usen parches virtuales para bloquear cualquier intento de
explotar vulnerabilidades hasta que se instala el parche. Según una investigación del Independent Oracle User Group
(IOUG)*, las organizaciones tienen una demora típica de 6 a 9 meses en la instalación de parches. SecureSphere
puede minimizar el riesgo de exposición durante el plazo que se necesita para instalar el parche.
* http://ioug.itconvergence.com/pls/apex/f?p=201:1:4201959220925808
Imperva White Paper
< 6 >

7. Las diez principales amenazas para las bases de datos
Amenaza 5: SQL Injection
DatabaseFileWeb
En un ataque de SQL Injection, el atacante por lo general inserta (o "inyecta") sentencias no autorizadas de base de
datos en un canal de datos SQL vulnerable. Los canales de datos generalmente atacados incluyen los procedimientos
almacenados y los parámetros de entrada de aplicaciones web. Estas sentencias inyectadas se pasan a la base de
datos, donde se ejecutan. Mediante SQL Injection, los atacantes pueden obtener acceso sin restricciones a toda una
base de datos.
Prevención de SQL Injection
Se pueden combinar tres técnicas para combatir eficazmente SQL Injection: prevención contra intrusos (IPS),
control de acceso a nivel de consulta (ver "Abuso de permisos excesivos") y correlación de eventos. El IPS puede
identificar procedimientos almacenados vulnerables o cadenas SQL Injection. Sin embargo, el IPS por sí solo no es
confiable, dado que las cadenas de SQL Injection tienen tendencia a presentar falsos positivos. Los administradores
de seguridad que confían sólo en un IPS se verían bombardeados por alertas de "posibles" inyecciones SQL. Sin
embargo, al correlacionar una firma de SQL Injection con otra violación, como una violación de control de acceso a
nivel de consulta, se puede identificar un ataque verdadero con suma precisión. Es improbable que una firma de SQL
Injection y otra violación aparezcan en la misma solicitud durante una operación comercial normal.
Protección contra SQL Injection de SecureSphere
SecureSphere integra las tecnologías de perfilado dinámico, IPS y validación correlacionada de los ataques para
identificar SQL Injection con precisión sin igual.
» Los perfiles dinámicos ofrecen control de acceso a nivel de consulta creando automáticamente perfiles de cada
usuario y patrones de consulta normales de las aplicaciones. Cualquier consulta (como una consulta de ataque
de SQL Injection) que no coincida con los patrones de la aplicación o el usuario previamente establecidos se
identifica de inmediato.
» IPS de SecureSphere incluye diccionarios únicos de firmas de bases de datos diseñados específicamente para
identificar procedimientos almacenados vulnerables y cadenas SQL Injection.
» La validación correlacionada de los ataques correlaciona las violaciones de seguridad provenientes de
diferentes capas de detección de SecureSphere. Al correlacionar varias violaciones de un mismo usuario,
SecureSphere puede detectar SQL Injection con un grado de precisión que no sería posible con el uso de una
sola capa de detección. Veamos el ataque SQL Injection a un procedimiento almacenado que se describe a
continuación.
exec ctxsys.driload.validate_stmt (‘grant dba to scott’)
En este ataque, el atacante (scott) intenta otorgarse privilegios de administrador de base de datos incrustando
una operación de "grant" (conceder) en un procedimiento almacenado vulnerable. SecureSphere maneja
este ataque mediante uno de dos procesos, según si el procedimiento almacenado forma parte o no de una
función comercial necesaria.
Procedimiento almacenado vulnerable no necesario
Lo ideal es que los usuarios o aplicaciones no usen procedimientos almacenados vulnerables. Si éste es el caso,
IPS de SecureSphere basta para identificar correctamente y, de forma opcional, bloquear todas las instancias
de este ataque. Las actividades comerciales normales no incluirían una cadena de caracteres tan compleja (…
ctxsys.driload…).
Procedimiento almacenado vulnerable necesario
En algunos casos, un procedimiento almacenado vulnerable forma parte de una función comercial necesaria.
Por ejemplo, puede ser parte de una aplicación heredada que no se puede cambiar. En este caso, SecureSphere
primero alerta a los gerentes de seguridad sobre el uso de esta función. Entonces, se puede aplicar la validación
correlacionada de los ataques de manera opcional para correlacionar casos de esta firma con una lista de
usuarios y aplicaciones que están autorizados para usar el procedimiento. Si cualquier usuario no autorizado
intenta usar el procedimiento, SecureSphere puede emitir una alerta o, de manera opcional, bloquear la
solicitud.
Imperva White Paper
< 7 >

8. Las diez principales amenazas para las bases de datos
Amenaza 6: Trazas de auditoría deficientes
DatabaseFileWeb
El registro automatizado de todas las transacciones restringidas y/o inusuales de las bases de datos debe formar
parte de los cimientos de cualquier base de datos instalada. Una política deficiente de auditoría de bases de datos
representa un serio riesgo para la organización a varios niveles.
» Riesgo regulatorio: Las organizaciones con mecanismos de auditoría deficientes (o a veces inexistentes)
encontrarán con cada vez mayor frecuencia que no cumplen los requisitos regulatorios de los gobiernos. En
Estados Unidos, la ley Sarbanes-Oxley (SOX) en el ámbito de la información financiera y la Ley de Portabilidad y
Responsabilidad de la Información de Seguros Médicos (HIPAA) en el sector de salud son apenas dos ejemplos
de normas gubernamentales que tienen requisitos claros de auditoría de las bases de datos.
» Disuasión: Tal como ocurre con las cámaras de video que filman a las personas que entran a un banco, los
mecanismos de auditoría de bases de datos sirven como elemento disuasivo para los atacantes que saben que
una traza de auditoría de las bases de datos ofrece a los investigadores una vinculación forense de los intrusos
con un delito.
» Detección y recuperación: Los mecanismos de auditoría representan la última línea de defensa de las bases
de datos. Si un atacante se las arregla para eludir otras defensas, los datos de auditoría pueden identificar la
existencia de una violación una vez cometido el acto. Los datos de auditoría pueden usarse entonces para
vincular una violación con un usuario específico y/o reparar el sistema.
Las plataformas de software de las bases de datos por lo general integran capacidades básicas de auditoría,
pero éstas presentan varias debilidades que limitan o impiden la implementación.
» Falta de trazabilidad de los usuarios: Cuando los usuarios acceden a la base de datos a través de aplicaciones
web (como SAP, Oracle E-Business Suite o PeopleSoft), los mecanismos nativos de auditoría no tienen
conocimiento de las identidades de los usuarios específicos. En este caso, toda la actividad del usuario se asocia
con el nombre de la cuenta de la aplicación web. Por lo tanto, cuando los registros de la auditoría nativos
revelan transacciones fraudulentas de la base de datos, no hay vínculo con el usuario responsable.
» Degradación del rendimiento: Los mecanismos nativos de auditoría de bases de datos son notorios por su
consumo de recursos de CPU y de disco. El deterioro del rendimiento que se experimenta cuando las funciones
de auditoría se activan, obliga a muchas organizaciones a reducir los mecanismos de auditoría o eliminarlos por
completo.
» Separación de funciones: Los usuarios con acceso administrativo (ya sea legítimo u obtenido de manera ilícita,
ver "Elevación de privilegios") al servidor de la base de datos simplemente pueden desactivar los mecanismos
de auditoría para ocultar las actividades fraudulentas. Lo ideal es que los deberes de auditoría estén separados
de los administradores de bases de datos y la plataforma del servidor de la base de datos.
» Granularidad limitada: Muchos mecanismos de auditoría nativos no registran detalles necesarios para la
detección de ataques, actividad forense y recuperación. Por ejemplo, la aplicación cliente de base de datos,
direcciones IP de origen, atributos de respuesta a consultas y consultas con error (un importante indicador de
reconocimiento de un ataque) no son registrados por varios mecanismos nativos.
» Mecanismos propios: Los mecanismos de auditoría son exclusivos de cada plataforma del servidor de la base
de datos: los registros de Oracle son diferentes de los de MS-SQL, los de MS-SQL son diferentes de los de
Sybase, etc. Para las organizaciones con entornos mixtos de bases de datos, esto prácticamente elimina la
implementación de procesos de auditoría uniformes y escalables en toda la empresa.
Imperva White Paper
< 8 >

9. Las diez principales amenazas para las bases de datos
Prevención de auditorías deficientes
DatabaseFileWeb
Los appliances de auditoría de calidad basados en red resuelven la mayor parte de las debilidades asociadas con las
herramientas de auditoría nativas.
» Alto rendimiento: Los appliances de auditoría basados en red pueden operar a velocidad de línea con cero
impacto sobre el rendimiento de la base de datos. En realidad, al derivar los procesos de auditoría a los
appliances de red, las organizaciones pueden esperar ver una mejora en el rendimiento de la base de datos.
» Separación de funciones: Los appliances de auditoría basados en red pueden operar independientemente
de los administradores de bases de datos, lo que permite separar las funciones de auditoría de las funciones
administrativas según corresponda. Además, dado que los dispositivos de red son independientes del servidor
en sí, también son invulnerables ante los ataques de elevación de privilegios ejecutados por personas que no
son administradores.
» Auditoría entre plataformas: Los appliances de auditoría de red por lo general admiten todas las principales
plataformas de bases de datos, lo que permite que haya normas uniformes y operaciones de auditoría
centralizadas en entornos grandes y heterogéneos de bases de datos. Juntos, estos atributos reducen los costes
del servidor de base de datos, los requisitos de equilibrio de la carga y los costes administrativos. También
ofrecen mayor seguridad.
Capacidades de auditoría de SecureSphere
Además de las ventajas generales asociadas con los appliances de auditoría basados en red que se describen
anteriormente, SecureSphere ofrece una serie de capacidades de auditoría únicas que la diferencian para enfoques
alternativos.
» La trazabilidad universal de usuarios (Universal User Tracking) hace que los usuarios individuales puedan ser
responsabilizados por sus acciones, incluso cuando tienen acceso a la base de datos mediante aplicaciones
web comerciales (Oracle, SAP, PeopleSoft, etc) o personalizadas. Para identificar los nombres de usuarios
de las aplicaciones web, una interfaz dedicada de SecureSphere capta la información de inicio de sesión
de la aplicación, hace un seguimiento de las sesiones web de usuario subsiguientes y las correlaciona con
las transacciones de base de datos. Los registros de auditoría resultantes incluyen nombres de usuario de
aplicaciones web únicos.
» La trazabilidad granular de transacciones admite la detección avanzada de fraude, las actividades forenses y la
recuperación. Los detalles de registro incluyen detalles tales como nombre de aplicación de origen, texto de
consulta completo, atributos de respuesta de consultas, SO de origen, nombre de host de origen y mucho más.
» La arquitectura de auditoría distribuida permite la trazabilidad granular de transacciones (ver anterior)
facilitando la escalabilidad necesaria para grandes centros de datos. La arquitectura distribuye los recursos
necesarios de almacenamiento y proceso entre appliances distribuidos de SecureSphere. La consola de gestión
de SecureSphere presenta al personal de auditoría una vista unificada del centro de datos. La consola de
gestión activa eficazmente varios portales que se gestionan como si fueran un solo portal desde el punto de
vista del personal de auditoría. Los enfoques alternativos recomiendan ya sea un registro de las transacciones
restringido o forzar a los administradores a gestionar varios dispositivos distribuidos independientemente.
» Las capacidades de archivo de datos externos automatizan los procesos de archivo de datos a largo
plazo. SecureSphere se puede configurar para archivar datos periódicamente en sistemas externos de
almacenamiento masivo. De manera opcional, los datos pueden comprimirse, cifrarse o firmarse antes del
archivo.
» Los informes gráficos integrados ofrecen a los administradores un mecanismo flexible y fácil de entender
para analizar las trazas de auditoría. Incluye informes preconfigurados que responden preguntas comunes de
auditoría, mientras que al mismo tiempo permiten la creación de informes personalizados para cumplir los
requisitos específicos de la empresa. Como alternativa, se puede usar cualquier paquete de informes externo
compatible con ODBC para analizar datos de auditoría de SecureSphere.
» Se ofrece auditoría de actividad local en el propio servidor a través del agente de base de datos de
SecureSphere. El agente de base de datos de SecureSphere es un agente de host ligero instalado en el servidor
de la base de datos para supervisar la actividad del administrador local de la base de datos. Juntos, el agente
de base de datos de SecureSphere y los portales de SecureSphere ofrecen una auditoría completa con escaso
impacto sobre el rendimiento, o en algunos casos, hasta mejorándolo.
Imperva White Paper
< 9 >

10. Las diez principales amenazas para las bases de datos
Amenaza 7: Denegación de servicio
DatabaseFileWeb
La denegación de servicio (DOS) es una categoría general de ataques en el que se deniega el acceso a las
aplicaciones de red o datos a los usuarios. Las condiciones de denegación de servicio (DOS) pueden producirse
mediante varias técnicas, muchas de las cuales se relacionan con vulnerabilidades anteriormente mencionadas. Por
ejemplo, se puede lograr la DOS aprovechando una vulnerabilidad de plataforma de base de datos para provocar
un fallo en un servidor. Otras técnicas comunes de DOS incluyen daño de datos, inundación de la red y sobrecarga
de recursos del servidor (memoria, CPU, etc.). La sobrecarga de recursos es particularmente común en los entornos
de base de datos. Las motivaciones por detrás de la DOS son también diversas. Los ataques con DOS a menudo se
relacionan con mecanismos de extorsión, donde un atacante puede provocar a distancia fallos reiterados en los
servidores, hasta que la víctima deposita fondos en una cuenta bancaria internacional. Como alternativa, la DOS
puede ser causada por una infección con un "gusano". Independientemente de su origen, la DOS representa una
seria amenaza para muchas organizaciones.
Prevención de la denegación de servicio
La prevención de la DOS exige protecciones a varios niveles. Las protecciones a nivel de red, aplicaciones y base de
datos son todas necesarias. Este documento se concentra en las protecciones específicas de la base de datos. En este
contexto específico de la base de datos, se recomienda implementación de control de velocidad de conexión, IPS,
control de acceso de consultas y control de tiempo de respuesta.
Protecciones de SecureSphere contra la DOS
» Los controles de conexión impiden la sobrecarga de recursos del servidor limitando las velocidades de
conexión, velocidades de consulta y otras variables para cada usuario de base de datos.
» El IPS y la validación de protocolos impiden que los atacantes exploten vulnerabilidades conocidas del software
para provocar DOS. El desbordamiento de la memoria intermedia, por ejemplo, es una vulnerabilidad de
plataforma común que puede aprovecharse para provocar fallos en los servidores de bases de datos. Consulte
las secciones sobre elevación de privilegios y vulnerabilidades de protocolo de comunicación de bases de
datos de este documento para obtener descripciones más completas de las tecnologías de IPS y de validación
de protocolo de comunicación de bases de datos
» Los perfiles dinámicos automáticamente proporcionan control de acceso de consultas para detectar las
consultas no autorizadas que puedan provocar DOS. Los ataques de DOS que apuntan a vulnerabilidades de
la plataforma, por ejemplo, pueden provocar violaciones de IPS y de perfiles dinámicos. Al correlacionar estas
violaciones, SecureSphere puede lograr precisión sin igual. Consulte la sección sobre abuso de los permisos
excesivos de este informe para obtener una descripción más completa de los perfiles dinámicos.
» Tiempo de respuesta: Los ataques de DOS contra bases de datos diseñados para sobrecargar los recursos del
servidor producen demoras en las respuestas de las bases de datos. La función de tiempo de respuesta de
SecureSphere detecta demoras en las respuestas a consultas individuales y el sistema en general.
Imperva White Paper
< 10 >

11. Las diez principales amenazas para las bases de datos
Amenaza 8: Vulnerabilidades de protocolo de comunicación de bases
DatabaseFileWeb
de datos
Se está identificando una cantidad creciente de vulnerabilidades en los protocolos de comunicaciones de bases
de datos de todos los proveedores de bases de datos. Cuatro de siete soluciones de seguridad en los dos IBM DB2
FixPacks más recientes corrigen vulnerabilidades de protocolo. Asimismo, 11 de 23 vulnerabilidades de base de datos
corregidas con el parche trimestral más reciente de Oracle se relacionan con protocolos. La actividad fraudulenta que
explota estas vulnerabilidades puede ir desde acceso no autorizado a los datos hasta daño de los datos o denegación
de servicio. El gusano SQL Slammer2, por ejemplo, aprovechó una falla en el protocolo de Microsoft SQL Server para
forzar la denegación de servicio. Para empeorar las cosas, no hay registro de estos vectores fraudulentos en la traza de
auditoría nativa, dado que las operaciones de protocolo no están cubiertas por los mecanismos nativos de auditoría
de base de datos.
Prevención de los ataques de protocolo de comunicación de base de datos
Los ataques de protocolo de comunicación de base de datos se pueden combatir con tecnología denominada de
"validación de protocolo". La tecnología de validación de protocolo esencialmente examina (desarma) el tráfico de la
base de datos y lo compara con los valores esperados. En caso de que el tráfico activo no cumpla las expectativas, se
pueden tomar medidas de alerta o bloqueo.
Validación de protocolo de comunicación de base de datos de SecureSphere
La validación de protocolo de comunicación de base de datos de SecureSphere audita y protege contra las amenazas
de protocolo comparando los protocolos activos de comunicaciones de bases de datos con las estructuras de
protocolo esperadas. Ninguna otra solución de seguridad o auditoría de bases de datos ofrece esta capacidad.
Se deriva de la investigación permanente de Application Defense Center (ADC) de Imperva de los protocolos y
vulnerabilidades de comunicación de las bases de datos propiedad de otros proveedores. Entre estos proveedores
de bases de datos y aplicaciones se incluyen Oracle, Microsoft y IBM, que han dado su reconocimiento a ADC por la
detección de vulnerabilidades serias y el descubrimiento de técnicas de mitigación que han mejorado la seguridad
de sus productos. Sobre la base de esta investigación, Imperva puede incorporar un conocimiento de protocolos sin
igual a SecureSphere.
Imperva White Paper
< 11 >

12. Las diez principales amenazas para las bases de datos
Amenaza 9: Copias no autorizadas de datos confidenciales
DatabaseFileWeb
Muchas empresas tienen dificultades para ubicar y mantener correctamente un inventario de todas sus bases de
datos. Se pueden crear nuevas bases de datos sin que el equipo de seguridad las conozca, y los datos confidenciales
copiados en esas bases de datos pueden quedar expuestos si no se implementan los controles necesarios. Estas
bases de datos “ocultas” pueden contener información potencialmente restringida como detalles sobre transacciones,
clientes y empleados, pero si la gente a cargo no conoce el contenido de las bases de datos es muy difícil garantizar
que se implementen los controles adecuados. Ya sea intencionalmente o no, es un hecho que hoy en día empleados
o hackers tengan acceso ilegal a los datos confidenciales. Otro ejemplo son las bases de datos olvidadas que quedan
fuera del alcance de la evaluación. Si nadie administra estas bases de datos, los datos quedan sin supervisión, a
disposición de personas no autorizadas.
Prevención: copias no autorizadas de datos confidenciales
Para mantener un inventario exacto de las bases de datos y la ubicación de datos restringidos las organizaciones
deben identificar todas las bases de datos de la red que contengan datos confidenciales. El paso siguiente es
descubrir qué tipos de datos confidenciales/restringidos se encuentran dentro de los objetos de la base de datos.
Dos dificultades clave para clasificar los datos son, en primer lugar, encontrar la información confidencial dentro de
la gran cantidad de tablas de todos los tamaños. En segundo lugar, encontrar combinaciones de datos que en sí
mismos se consideren inocuos, pero en combinación con otros datos componen información considerada como
confidencial. Para detectar correctamente la información confidencial, cuando se obtiene un inventario correcto de
bases de datos y ubicación de datos confidenciales, se deben implementar los controles correctos de acuerdo con las
políticas de acceso a los datos de la organización.
Detección y clasificación de SecureSphere
SecureSphere permite que los usuarios programen exámenes automatizados de la red, que ofrecen un inventario
completo de todas las bases de datos. También identifica bases de datos nuevas o modificadas, por lo que es útil
para detectar bases de datos “ilícitas”. Los usuarios entonces pueden solicitar explorar el contenido de las bases
de datos para identificar objetos que contengan datos confidenciales. SecureSphere reconoce tipos de datos de
uso genérico, como números de tarjetas de crédito y de la Seguridad Social (los usuarios pueden agregar tipos de
datos personalizados). Para reducir los falsos positivos SecureSphere usa algoritmos de validación. También destaca
cualquier nuevo caso de datos confidenciales/restringidos.
Imperva White Paper
< 12 >

13. White Paper
Amenaza 10: Exposición de datos de copia de seguridad
Los medios de almacenamiento de las copias de seguridad de las bases de datos quedan a menudo sin protección
contra los ataques. Como resultado, varias violaciones de seguridad de alto perfil han involucrado el robo de cintas y
discos con copias de seguridad de bases de datos.
Prevención de la exposición de datos de copia de seguridad
Todas las copias de seguridad de las bases de datos deberían ser cifradas. En realidad, varios proveedores han
sugerido que los futuros productos de sistemas de gestión de bases de datos no admitan la creación de copias de
seguridad sin cifrar. A menudo se ha sugerido el cifrado de la información de bases de datos de producción en línea,
pero los problemas de rendimiento y de gestión de las claves criptográficas a menudo hacen que esto no resulte
práctico y por lo general se considera como un sustituto deficiente para los controles granulares de privilegios que se
describen anteriormente.
Resumen
Aunque la información de las bases de datos es vulnerable ante una serie de ataques, es posible reducir
drásticamente el riesgo concentrándose en las amenazas más críticas. Al ofrecer soluciones a las 10 principales
amenazas que se describen anteriormente, las organizaciones satisfarán los requisitos de cumplimiento y mitigación
de riesgos de las industrias más reguladas del mundo.
Acerca de Imperva
Imperva es el líder global en seguridad de datos. Entre nuestros clientes se incluyen empresas líderes, organizaciones
gubernamentales y proveedores de servicios gestionados, quienes confían en Imperva para prevenir el robo de
información sensible por parte de hackers y personal interno. El galardonado Imperva SecureSphere es la única
solución que proporciona una monitorización completa de la actividad de las bases de datos, aplicaciones web y
sistemas de ficheros.
Para saber más sobre las soluciones de Imperva, visite http://www.imperva.com.
Imperva Spain
Edificio Torre Europa
Paseo de la Castellana, 95 – planta 15 A
28046 Madrid
Tel: +34 91 418 69 02
www.imperva.com
© Copyright 2011, Imperva
Reservados todos los derechos. Imperva, SecureSphere y Protecting the Data That Drives Business son marcas comerciales registradas de Imperva.
Todas las demás marcas y nombres de productos son marcas comerciales o marcas comerciales registradas de sus respectivos propietarios.
#WP-TOP10-DATABASE-THREATS-ES-1110rev1