Madrid, junio de 2009 Seguridad en bases de datos: SQL Server 2005 y Oracle 10g

Auditoría

Introducción a la seguridad de la información Configuración de la plataforma Confidencialidad Integridad Disponibilidad Autenticación Autorización Auditoría Integración de bases de datos con otras aplicaciones Hacking de base de datos Índice del curso

Índice del capítulo Plan de auditoría Áreas a auditar Almacenamiento de los rastros de auditoría Información en los rastros de auditoría Auditoría de grano fino Examen de los rastros de auditoría

Objetivos de la auditoría Registrar las acciones de los usuarios en el sistema Saber qué pasa en la organización: Qué Quién Cuándo Cómo Desde dónde Con qué

Motivación de la auditoría Detección de intrusiones: El análisis continuo de los registros de auditoría permite detectar actividad sospechosa o anormal Análisis forense: En caso de intrusión, los rastros de auditoría podrían presentar evidencia de quién fue el atacante y exactamente qué información obtuvo Monitorización de recursos: Los rastros pueden ayudar a identificar las causas del mal funcionamiento de una aplicación Depuración de errores: Ayudan a detectar errores Cumplimiento de la legislación vigente

La LOPD obliga a mantener registros de acceso a los datos de nivel de seguridad alto De cada acceso se guardarán, como mínimo la identificación del usuario, la fecha y hora en que se realizó, el fichero accedido, el tipo de acceso y si ha sido autorizado o denegado En el caso de que el acceso haya sido autorizado, será preciso guardar la información que permita identificar el registro accedido El responsable de seguridad competente se encargará de revisar periódicamente la información de control registrada y elaborará un informe de las revisiones realizadas y los problemas detectados al menos una vez al mes

Plan de auditoría Qué acciones es necesario auditar: estrechar el campo posible Qué impacto tiene la auditoría en el sistema: auditar lo mínimo necesario Cómo se revisan los rastros generados Cómo se protegen Debe formar parte de la política de seguridad de la organización

Áreas a auditar Inicios de sesión y fines de sesión Las fuentes de conexión Uso de bbdd fuera de horas normales Actividad DDL Errores de bbdd Cambios a las fuentes de procedimientos, funciones, triggers Cambios a atributos de seguridad: privilegios, usuarios, etc. Cambios a datos sensibles Sentencias SELECT sobre datos privados Cambios a la definición de las reglas de auditoría

Inicios de sesión y fines de sesión Registre dos eventos para esta categoría: Un evento para el inicio de sesión Un evento para el fin de sesión Guardar como mínimo: Nombre y hora Información adicional: Dirección IP del cliente utilizado Programa utilizado para la conexión Registrar todos los intentos fallidos Más importante incluso que los exitosos Permiten alertar en caso de ataques de fuerza bruta

Las fuentes de conexión Qué nodo de red se ha conectado a la bbdd IP o nombre de host Especialmente si identifica al usuario Qué aplicación se ha utilizado para conectarse a la bbdd Debe decidirse cómo presentar estos datos: En crudo Listos para ser consumidos

Uso de bbdd fuera de horas normales Toda actividad fuera de las horas habituales de trabajo resulta sospechosa: indicio de acceso no autorizado No deben incluirse actividades administrativas programadas a horas de menor actividad

Actividad DDL Se trata de auditar los cambios al esquema Importante desde varios puntos de vista Seguridad Los comandos DDL son potencialmente los más peligrosos Cumplimiento de leyes Algunas regulaciones exigen auditar cambios a la estructura Gestión de configuración y procesos Evitar errores y descubrir problemas rápidamente

Errores de bbdd Seguridad Uno de los primeros rastros que deben activarse Los ataques suelen generar muchos errores antes de tener éxito Calidad Ayuda a identificar aplicaciones en producción que están experimentando errores y a determinar por qué se producen estos errores

Cambios a las fuentes de procedimientos, funciones, triggers Los cambios al código fuente puede deberse a actividad maliciosa por parte de usuarios o troyanos Diferentes formas de auditar cambios al código: Comparar periódicamente el código de la bbdd con código previamente almacenado, p.e. con diff Utilizar un sistema externo de auditoría y monitorización Utilizar características internas de la bbdd

Cambios a atributos de seguridad: privilegios, usuarios, etc. Deben auditarse los cambios al modelo de seguridad Adición/Eliminación de usuarios Cambios a las asociaciones entre inicios de sesión y usuarios/roles Cambios a los privilegios (por usuario o por rol) Cambios de contraseñas Cambios a atributos de seguridad a nivel de servidor, bbdd, sentencia y objeto

Cambios a datos sensibles Auditoría de la actividad DML Deben realizarse selectivamente, ya que la cantidad de datos generadas puede ser enorme Tres métodos: Capacidades internas de la bbdd Sistema externo de auditoría Disparadores

Sentencias SELECT sobre datos privados Para asegurar la confidencialidad de los datos Registrar: De dónde procede la consulta (dirección IP, aplicación) Quién seleccionó los datos (nombre de usuario) Qué datos fueron seleccionados Resulta impráctico para toda la bbdd: hay que centrarse en los datos sensibles Creación de conjuntos de privacidad

Cambios a la definición de las reglas de auditoría Auditar cambios a la definición de los rastros de auditoría y cualquier modificación a los propios rastros En caso contrario, un atacante podría cambiar las definiciones de lo que está siendo auditado Implementación Capacidades internas de auditoría Sistema externo de auditoría de bbdd

Rastros de auditoría externos Son más valiosos que los generados desde la propia bbdd Filosóficamente, está alineado con la estrategia de defensa en profundidad Técnicamente: Resulta más difícil de comprometer No sufre los mismos fallos y vulnerabilidades que la bbdd Soporta mejor la segregación de tareas Puede usarse en tándem con la auditoría interna de la bbdd

Arquitecturas para sistemas externos de auditoría Inspección de las estructuras de datos internas de la bbdd Inspección de todas las comunicaciones con la bbdd Inspección de elementos creados por la bbdd en el curso normal de operación

Archivo de la información de auditoría Los registros de auditoría generan montañas de información Las estrategia de auditoría debe contemplar el archivo y recuperación de estos registros En el caso peor, una mala gestión del archivado puede llevar a la caída de la bbdd Resulta más conveniente no archivar los archivos de auditoría en la propia bbdd Muchas regulaciones exigen conservar la información de auditoría un cierto número de años, lo que exige diseñar una estrategia de archivado y recuperación

Tiempo de conservación de los datos de auditoría Si se quiere cumplir con los requisitos de la LOPD para datos de nivel de seguridad alto, entonces el período mínimo de conservación de los datos registrados será de dos años

Archivo de la información de auditoría Permitir reglas sencillas que definan qué archivar, cuándo y dónde Programar el archivado de manera que los datos en línea resulten adecuados para generación de informes Archivar los informes y entregables generados, no sólo los datos en crudo, ya que serán más solicitados que los datos en sí Archivar de forma tal que facilite la recuperación en caso de ser requerido para una investigación Utilizar soluciones de almacenamiento como una SAN (Storage Area Network, o una NAS (Network Attached Storage)

Protección de la información de auditoría Una vez que la información ha sido archivada, hay que protegerla para evitar su manipulación (integridad) y su obtención (confidencialidad), ya que podría contener información sensible La seguridad de la solución de auditoría debe contemplar los cuatro lugares donde la información de auditoría podría residir 1. El repositorio principal donde reside la información de auditoría mientras está siendo recolectada 2. Archivos dentro del servidor de auditoría 3. Archivos en tránsito 4. Archivos en la ubicación de almacenamiento

Almacenamiento de los rastros de auditoría El sistema de auditoría normalmente almacena la información recolectada en una bbdd Debe asegurarse frente a accesos externos: accesible solamente desde el sistema de auditoría Debe bastionarse Debe ser de un único usuario: el proceso de auditoría El archivado de los rastros de auditoría es un proceso en dos pasos: 1. Los datos se vuelcan a un archivo y se borran de la bbdd 2. Estos datos se cifran y firman para probar que fueron generados por el sistema de auditoría, cuándo y para qué bbdd

Auditoría del sistema de auditoría Debe mantenerse a su vez un rastro de auditoría de cualquier acceso y cambio realizado a la información de auditoría Incluye tanto los datos como las definiciones de auditoría

Examen de los rastros de auditoría Tan malo es no activar registros de auditoría como tenerlos y no revisarlos Productos comerciales para revisión de registros y detección de intrusiones: DB Audit: Apex SQL Audit: OmniAudit: Audit DB: