Machine Translated by Google

CAPÍTULO 18 AUDITORÍA DE SEGURIDAD

18.1 Arquitectura de auditoría de seguridad
Modelo de alarmas y auditoría de seguridad

Funciones de auditoría de seguridad

Requisitos

Directrices de implementación

18.2 Registro de auditoría de

seguridad Qué recopilar

Protección de datos de seguimiento de auditoría

18.3 Implementación de la función de registro Registro

a nivel del sistema

Registro a nivel de aplicación

Bibliotecas interponibles

Reescritura binaria dinámica

18.4 Preparación del análisis de

seguimiento de auditoría

Momento

Revisión de auditoría

Enfoques para el análisis de datos

18.5 Información de seguridad y gestión de eventos

Sistemas SIEM

18.6 Términos clave, preguntas de revisión y problemas

OBJETIVOS DE APRENDIZAJE

Después de estudiar este capítulo, debería poder:

Analice los elementos que componen una arquitectura de auditoría de seguridad.

Machine Translated by Google

Evalúe las ventajas relativas de varios tipos de pistas de auditoría de seguridad.

Comprenda las consideraciones clave al implementar la función de registro para la auditoría de seguridad.
Describir el proceso de análisis de pistas de auditoría.

La auditoría de seguridad es una forma de auditoría que se centra en la seguridad de los activos
de tecnología de la información (TI) de una organización. Esta función es un elemento clave en la seguridad
informática. La auditoría de seguridad puede:

Proporcionar un nivel de seguridad sobre el correcto funcionamiento del ordenador con

respecto a la seguridad.
Genere datos que puedan utilizarse en el análisis posterior de un ataque, ya sea exitoso o no.

Proporcionar un medio para evaluar las deficiencias del servicio de seguridad.

Proporcionar datos que puedan utilizarse para definir comportamientos anómalos.
Mantener un registro útil en informática forense.

1 definidas
Dos conceptos clave son las auditorías de seguridad y las pistas de auditoría de seguridad,
en la Tabla 18.1.

1NIST SP 800­12 (Introducción a la seguridad informática: manual del NIST, octubre

1995) señala que algunos expertos en seguridad hacen una distinción entre una pista de auditoría y

un registro de auditoría de la siguiente manera: Un registro es un registro de eventos realizados por un software en particular

paquete, y una pista de auditoría es un historial completo de un evento, posiblemente utilizando varios registros.

Sin embargo, el uso común dentro de la comunidad de seguridad no hace uso de este
definición. No hacemos ninguna distinción en este libro.

Tabla 18.1 Terminología de auditoría de seguridad (RFC 4949)

Auditoría de seguridad Una revisión y examen independiente de los registros y

actividades para determinar la idoneidad de los controles del sistema, garantizar el cumplimiento de

políticas y procedimientos de seguridad establecidos, detectar violaciones en los servicios de seguridad y

Recomendar cualquier cambio que se indique como contramedida.

El objetivo básico de la auditoría es establecer la responsabilidad de las entidades del sistema que inician

o participar en eventos y acciones relevantes para la seguridad. Por lo tanto, se necesitan medios para

generar y registrar una pista de auditoría de seguridad y revisar y analizar la pista de auditoría para

descubrir e investigar ataques y compromisos de seguridad.

Machine Translated by Google

Registro de auditoría de seguridad Un registro cronológico de las actividades del sistema que es suficiente

para permitir la reconstrucción y el examen de la secuencia de entornos y

actividades que rodean o conducen a una operación, procedimiento o evento en una transacción

relevante para la seguridad desde el inicio hasta los resultados finales.

El proceso de generación de información de auditoría arroja datos que pueden ser útiles en tiempo
real para la detección de intrusiones; Este aspecto se analiza en el Capítulo 8. En el presente
capítulo, nos ocupamos de la recopilación, el almacenamiento y el análisis de datos relacionados
con la seguridad de TI. Comenzamos con una mirada general a la arquitectura de auditoría de seguridad
y cómo se relaciona con la actividad complementaria de detección de intrusiones. A
continuación, analizamos los diversos aspectos de los registros de auditoría, también conocidos
como registros de auditoría. Luego discutimos el análisis de los datos de auditoría.
Machine Translated by Google

18.1 AUDITORÍA DE SEGURIDAD

ARQUITECTURA
Comenzamos nuestra discusión sobre la auditoría de seguridad observando los elementos que componen una arquitectura
de auditoría de seguridad. Primero, examinamos un modelo que muestra la auditoría de seguridad en su contexto más amplio.
Luego, analizamos un desglose funcional de la auditoría de seguridad.

Modelo de Auditoría de Seguridad y Alarmas

2
La Recomendación UIT­T X.816 desarrolla un modelo que muestra los elementos de la función de auditoría de
seguridad y su relación con las alarmas de seguridad. La figura 18.1 muestra el modelo. Los elementos clave son los siguientes:

2Sector de Normalización de las Telecomunicaciones de la Unión Internacional de Telecomunicaciones. Consulte el Apéndice C

para una discusión sobre esta y otras organizaciones que elaboran estándares.
Machine Translated by Google

Figura 18.1 Modelo de alarmas y auditoría de seguridad (X.816)

Discriminador de eventos: esta es una lógica integrada en el software del sistema que monitorea la actividad del sistema
y detecta eventos relacionados con la seguridad para los que ha sido configurado.
Registrador de auditoría: Para cada evento detectado, el discriminador de eventos transmite la información a un registrador

de auditoría. El modelo representa esta transmisión en forma de mensaje. La auditoría también podría realizarse registrando
el evento en un área de memoria compartida.
Procesador de alarmas: algunos de los eventos detectados por el discriminador de eventos se definen como eventos de
alarma. Para tales eventos, se emite una alarma a un procesador de alarmas. El procesador de alarmas realiza alguna acción
en función de la alarma. Esta acción es en sí misma un evento auditable, al igual que lo es
transmitido al registrador de auditoría.

Pista de auditoría de seguridad: el registrador de auditoría crea un registro formateado de cada evento y lo almacena en el
registro de auditoría de seguridad.
Analizador de auditoría: el rastro de auditoría de seguridad está disponible para el analizador de auditoría, que, según un
patrón de actividad, puede definir un nuevo evento auditable que se envía al registrador de auditoría y puede generar una
alarma.
Archivador de auditoría: este es un módulo de software que extrae periódicamente registros del seguimiento de auditoría
para crear un archivo permanente de eventos auditables.
Archivos: Los archivos de auditoría son un almacén permanente de eventos relacionados con la seguridad en este sistema.
Proveedor de auditoría: El proveedor de auditoría es una aplicación y/o interfaz de usuario para la pista de auditoría.
Machine Translated by Google
Examinador de seguimiento de auditoría: El examinador de seguimiento de auditoría es una aplicación o usuario que examina

el seguimiento de auditoría y los archivos de auditoría en busca de tendencias históricas, con fines informáticos forenses y para

otros análisis.

Informes de seguridad: el examinador de seguimiento de auditoría prepara informes de seguridad legibles por humanos.

Este modelo ilustra la relación entre las funciones de auditoría y las funciones de alarma. La función de auditoría crea un registro

de eventos que el administrador de seguridad define como relacionados con la seguridad. De hecho, algunos de estos eventos pueden

ser violaciones de seguridad o sospechas de violaciones de seguridad.

Estos eventos se alimentan de una función de detección de intrusiones o de cortafuegos mediante alarmas.

Como fue el caso con la detección de intrusiones, una función de auditoría distribuida en la que se crea un repositorio centralizado

puede resultar útil para los sistemas distribuidos. Se necesitan dos componentes lógicos adicionales para un servicio de auditoría

distribuida (ver Figura 18.2):

Figura 18.2 Modelo de seguimiento de auditoría distribuido (X.816)

Recopilador de pistas de auditoría: módulo en un sistema centralizado que recopila registros de pistas de auditoría de otros

sistemas y crea una pista de auditoría combinada.

Despachador de auditoría: módulo que transmite los registros de seguimiento de auditoría desde su sistema local al recopilador
de seguimiento de auditoría centralizado.

Funciones de auditoría de seguridad

Es útil observar otro desglose de la función de auditoría de seguridad, desarrollada como parte de la especificación de Criterios Comunes

[CCPS12a]. La Figura 18.3 muestra un desglose de la auditoría de seguridad en seis áreas principales, cada una de las cuales tiene

una o más funciones específicas:

Machine Translated by Google

Figura 18.3 Descomposición de clases de auditoría de seguridad de criterios comunes

Generación de datos: identifica el nivel de auditoría, enumera los tipos de eventos auditables e identifica el conjunto
mínimo de información relacionada con la auditoría proporcionada. Esta función también debe abordar el conflicto entre
seguridad y privacidad y especificar para qué eventos se incluye la identidad del usuario asociado a una acción en los datos
generados como resultado de un evento.
Selección de eventos: Inclusión o exclusión de eventos del conjunto auditable. Esto permite que el

El sistema debe configurarse en diferentes niveles de granularidad para evitar la creación de un registro de auditoría difícil
de manejar.

Almacenamiento de eventos: Creación y mantenimiento de la pista de auditoría segura. La función de almacenamiento

Machine Translated by Google

incluye medidas para proporcionar disponibilidad y evitar la pérdida de datos de la pista de auditoría.

Respuesta automática: define las reacciones tomadas después de la detección de eventos que son indicativos de una posible violación

de seguridad.

Análisis de auditoría: Proporcionado a través de mecanismos automatizados para analizar la actividad del sistema y auditar datos

en busca de violaciones de seguridad. Este componente identifica el conjunto de eventos auditables cuya ocurrencia o ocurrencia

acumulada indica una posible violación de seguridad. Para tales eventos, se realiza un análisis para determinar si ha ocurrido una

violación de seguridad; Este análisis utiliza heurísticas de detección de anomalías y ataques.

Revisión de auditoría: Disponible para usuarios autorizados para ayudar en la revisión de datos de auditoría. La revisión de auditoría

El componente puede incluir una función de revisión seleccionable que brinda la capacidad de realizar búsquedas basadas

en un único criterio o en múltiples criterios con relaciones lógicas (es decir, y/o), ordenar datos de auditoría y filtrar datos de auditoría

antes de revisarlos. La revisión de auditoría puede estar restringida a usuarios autorizados.

Requisitos
Al revisar la funcionalidad sugerida por las Figuras 18.1 y 18.3, podemos desarrollar un conjunto de requisitos para la auditoría

de seguridad. El primer requisito es la definición del evento. El administrador de seguridad debe definir el conjunto de eventos

que están sujetos a auditoría. Entraremos en más detalles en la siguiente sección, pero incluimos aquí una lista sugerida en [CCPS12a]:

Introducción de objetos dentro de la parte del software relacionada con la seguridad en el espacio de direcciones de un sujeto

Eliminación de objetos

Distribución o revocación de derechos o capacidades de acceso.

Cambios en los atributos de seguridad del sujeto u objeto.

Verificaciones de políticas realizadas por el software de seguridad como resultado de una solicitud de un sujeto

El uso de derechos de acceso para eludir una verificación de políticas

Uso de funciones de identificación y autenticación.

Acciones relacionadas con la seguridad tomadas por un operador y/o usuario autorizado (por ejemplo, supresión de un mecanismo

de protección)

Importación/exportación de datos desde/hacia medios extraíbles (por ejemplo, resultados impresos, discos magnéticos u ópticos,

dispositivos de almacenamiento USB portátiles)

Un segundo requisito es que los ganchos apropiados deben estar disponibles en la aplicación y el software del sistema para permitir

la detección de eventos. Es necesario agregar software de monitoreo al sistema y a los lugares apropiados para capturar la

actividad relevante. A continuación se necesita una función de grabación de eventos , que incluya la necesidad de proporcionar un

almacenamiento seguro resistente a la manipulación o la eliminación. Se pueden utilizar interfaces, herramientas y software de

análisis de seguimiento de eventos y auditoría para analizar los datos recopilados, así como para investigar tendencias y

anomalías en los datos.

Existe un requisito adicional para la seguridad de la función de auditoría. No sólo la auditoría

Machine Translated by Google

rastro, pero todo el software de auditoría y el almacenamiento intermedio deben protegerse contra derivaciones o
manipulaciones. Finalmente, el sistema de auditoría debería tener un efecto mínimo sobre la funcionalidad.

Directrices de implementación
3
ISO 27002 (Código de prácticas para la gestión de la seguridad de la información, octubre de 2013) proporciona un
conjunto útil de directrices para las consideraciones de auditoría de sistemas de información:

3Organización Internacional de Normalización. Consulte el Apéndice C para obtener una discusión sobre este y otros estándares.
organizaciones fabricantes y la Lista de documentos NIST e ISO.

1. Los requisitos de auditoría para el acceso a sistemas y datos deben acordarse con las autoridades apropiadas.
gestión.
2. Debe acordarse y controlarse el alcance de las pruebas de auditoría técnica.
3. Las pruebas de auditoría deben limitarse al acceso de sólo lectura al software y a los datos.
4. Sólo se debe permitir un acceso distinto del de solo lectura para copias aisladas de archivos del sistema, que
deben borrarse cuando se complete la auditoría, o brindarles la protección adecuada si existe la obligación de
conservar dichos archivos según los requisitos de documentación de la auditoría.
5. Se deben identificar y acordar los requisitos para el procesamiento especial o adicional.
6. Las pruebas de auditoría que podrían afectar la disponibilidad del sistema deben realizarse fuera del horario comercial.

7. Todo acceso debe ser monitoreado y registrado para producir un rastro de referencia.
Machine Translated by Google

18.2 PISTA DE AUDITORÍA DE SEGURIDAD

Los registros de auditoría mantienen un registro de la actividad del sistema. Esta sección analiza cuestiones relacionadas con las pistas de auditoría.

Qué coleccionar
La elección de los datos a recopilar está determinada por una serie de requisitos. Una cuestión es la cantidad de datos a

recopilar, que está determinada por la variedad de áreas de interés y por la granularidad de la recopilación de datos. Aquí hay

un equilibrio entre cantidad y eficiencia. Cuantos más datos se recopilen, mayor será la penalización en el rendimiento del sistema.

Grandes cantidades de datos también pueden sobrecargar innecesariamente los diversos algoritmos utilizados para examinar y analizar

los datos.

Además, la presencia de grandes cantidades de datos crea la tentación de generar informes de seguridad excesivos en número o

extensión.

Teniendo en cuenta estas precauciones, la primera orden del día en el diseño de pistas de auditoría de seguridad es la

selección de los elementos de datos que se van a capturar. Estos pueden incluir:

Eventos relacionados con el uso del software de auditoría (es decir, todos los componentes de la Figura 18.1).

Eventos relacionados con los mecanismos de seguridad del sistema.

Cualquier evento que se recopile para su uso por los diversos mecanismos de prevención y detección de seguridad.
Estos incluyen elementos relevantes para la detección de intrusiones y elementos relacionados con el firewall.

operación.

Eventos relacionados con la gestión y operación del sistema.

Acceso al sistema operativo (por ejemplo, a través de llamadas al sistema como las enumeradas en la Tabla 8.2).

Tabla 18.2 Elementos auditables sugeridos en X.816

Eventos relacionados con la seguridad relacionados En lo que respecta a los servicios de seguridad individuales, los siguientes

con una conexión específica eventos relacionados con la seguridad son importantes

— Solicitudes de conexión — Autenticación: verificar el éxito

— Conexión confirmada — Autenticación: verificación fallida

— Solicitudes de desconexión — Control de acceso: decide el éxito del acceso

— Desconexión confirmada — Control de acceso: decidir si el acceso falla

— Estadísticas relativas a la — No repudio: origen no repudiable del mensaje.

conexión
— No repudio: recepción no repudiable de un mensaje.

Eventos relacionados con la seguridad relacionados con

— No repudio: repudio fallido de un evento.
Machine Translated by Google
el uso de servicios de seguridad

— No repudio: repudio exitoso del evento.

— Solicitudes de servicios de seguridad

— Integridad: uso del escudo.

— Uso de mecanismos de seguridad.

— Integridad: uso de unshield

— Alarmas de seguridad

— Integridad: validar el éxito

Eventos relacionados con la seguridad

relacionados con la gestión. — Integridad: falla de validación

— Operaciones de gestión — Confidencialidad: uso de hide

— Notificaciones de gestión — Confidencialidad: uso de revelar

La lista de eventos auditables debe — Auditoría: seleccione evento para auditar

incluir al menos
— Auditoría: deseleccionar evento para auditoría

­ Acceso denegado
— Auditoría: cambiar los criterios de selección de eventos de auditoría

— Autenticar

— Cambiar atributo

­ Crear objeto

— Eliminar objeto

— Modificar objeto

— Usar privilegio

Acceso a aplicaciones para aplicaciones seleccionadas.

Acceso remoto.

Un ejemplo es una lista sugerida de elementos auditables en X.816, que se muestra en la Tabla 18.2. La norma señala
que es posible que sea necesario auditar tanto las condiciones normales como las anormales; por ejemplo, cada solicitud
de conexión, tal como una solicitud de conexión TCP, puede ser objeto de un registro de seguimiento de auditoría de
seguridad, independientemente de si la solicitud fue anormal o no e independientemente de si la solicitud fue aceptada
o no. Éste es un punto importante. La recopilación de datos para auditoría va más allá de la necesidad de generar
alarmas de seguridad o proporcionar información a un módulo de firewall. Los datos que representan el comportamiento
que no activa una alarma se pueden utilizar para identificar patrones de uso normales versus anormales y así servir
como entrada para el análisis de detección de intrusiones. Además, en caso de un ataque, puede ser necesario un análisis
de toda la actividad de un sistema para diagnosticar el ataque y llegar a contramedidas adecuadas para el
futuro.

Otra lista útil de eventos auditables (ver Tabla 18.3) está contenida en ISO 27002. Al igual que X.816, el estándar ISO detalla
eventos autorizados y no autorizados, así como eventos que afectan las funciones de seguridad del sistema.

Tabla 18.3 Áreas de monitoreo sugeridas en ISO 27002

Machine Translated by Google

a. ID de usuario

b. actividades del sistema

c. fechas, horas y detalles de eventos clave, por ejemplo, inicio y cierre de sesión

d. identidad o ubicación del dispositivo, si es posible, e identificador del sistema

mi. registros de intentos exitosos y rechazados de acceso al sistema

F. registros de datos exitosos y rechazados y otros intentos de acceso a recursos g. cambios en la

configuración del sistema h. uso de privilegios

i. uso de utilidades y aplicaciones del sistema

j. archivos accedidos y el tipo de acceso k. direcciones

y protocolos de red

l. Alarmas generadas por el sistema de control de acceso.

metro. Activación y desactivación de sistemas de protección, como sistemas antivirus y de detección de intrusos.

sistemas

norte. registros de transacciones ejecutadas por usuarios en aplicaciones

A medida que el administrador de seguridad diseña una política de recopilación de datos de auditoría, resulta útil organizar
la pista de auditoría en categorías con el fin de elegir los elementos de datos que se recopilarán. A continuación, analizamos
categorías útiles para el diseño de pistas de auditoría.

PISTAS DE AUDITORÍA A NIVEL DE SISTEMA

Las pistas de auditoría a nivel del sistema se utilizan generalmente para monitorear y optimizar el rendimiento del sistema,
pero también pueden cumplir una función de auditoría de seguridad. El sistema aplica ciertos aspectos de la política de
seguridad, como el acceso al propio sistema. Un seguimiento de auditoría a nivel del sistema debe capturar datos como los
intentos de inicio de sesión, tanto exitosos como fallidos, los dispositivos utilizados y las funciones del sistema operativo
realizadas. Otras funciones a nivel del sistema pueden ser de interés para la auditoría, como el funcionamiento del sistema
y los indicadores de rendimiento de la red.

La Figura 18.4a, de NIST SP 800­12 (Introducción a la seguridad informática: Manual del NIST, octubre de 1995), es un ejemplo
de un seguimiento de auditoría a nivel de sistema en un sistema UNIX. El comando de apagado finaliza todos los
procesos y lleva el sistema al modo de usuario único. El comando su crea un shell UNIX.

27 de enero 17:14:04 inicio de sesión de host1: consola ROOT LOGIN

27 de enero 17:15:04 Apagado de host1: reinicio por root

27 de enero 17:18:38 inicio de sesión de host1: consola ROOT LOGIN

27 de enero 17:19:37 reinicio de host1: reiniciado por root

28 de enero 09:46:53 host1 su: 'su root' tuvo éxito para el usuario1 en /dev/ttyp0
Machine Translated by Google

28 de enero 09:47:35 Apagado de host1: reinicio por usuario1

28 de enero 09:53:24 host1 su: 'su root' tuvo éxito para el usuario1 en /dev/ttyp1

12 de febrero 08:53:22 host1 su: 'su root' tuvo éxito para el usuario1 en /dev/ttyp1

17 de febrero 08:57:50 fecha del host1: establecida por el usuario1

17 de febrero 13:22:52 host1 su: 'su root' tuvo éxito para el usuario1 en /dev/ttyp0

(a) Archivo de registro del sistema de muestra que muestra mensajes de autenticación

Abr 9 11:20:22 host1 AA06370: de=<usuario2@host2>, tamaño=3355, clase=0

Abr 9 11:20:22 host1 AA06370: a=<usuario1@host1>, retraso=00:00:02,stat=Enviado

Abr 9 11:59:51 host1 AA06436: de=<usuario4@host3>, tamaño=1424, clase=0

Abr 9 11:59:52 host1 AA06436: a=<usuario1@host1>, retraso=00:00:02, estadística=Enviado

Abr 9 12:43:52 host1 AA06441: de=<usuario2@host2>, tamaño=2077, clase=0

Abr 9 12:43:53 host1 AA06441: a=<usuario1@host1>, retraso=00:00:01, estadística=Enviado

(b) Registro de auditoría a nivel de aplicación para un sistema de entrega de correo

RCP usuario1 ttyp0 0,02 segundos viernes 8 de abril 16:02

es usuario1 ttyp0 0,14 segundos viernes 8 de abril 16:01

borrar usuario1 ttyp0 0,05 segundos viernes 8 de abril 16:01

rpcinfo usuario1 ttyp0 0,20 segundos viernes 8 de abril 16:01

nroff user2 ttyp2 0,75 segundos viernes 8 de abril 16:00

sh user2 ttyp2 0,02 segundos viernes 8 de abril 16:00

mv user2 ttyp2 0,02 segundos viernes 8 de abril 16:00

sh user2 ttyp2 0,03 segundos viernes 8 de abril 16:00

columna user2 ttyp2 0,09 segundos viernes 8 de abril 16:00

hombre usuario2 ttyp2 0,14 segundos viernes 8 de abril 15:57

(c) Registro de usuario que muestra una lista cronológica de comandos ejecutados por los usuarios

Figura 18.4 Ejemplos de pistas de auditoría

Machine Translated by Google

PISTAS DE AUDITORÍA A NIVEL DE APLICACIÓN

Se pueden utilizar pistas de auditoría a nivel de aplicación para detectar violaciones de seguridad dentro de una aplicación o para

detectar fallas en la interacción de la aplicación con el sistema. Para aplicaciones críticas, o aquellas que manejan datos confidenciales,

un registro de auditoría a nivel de aplicación puede proporcionar el nivel deseado de detalle para evaluar las amenazas y los

impactos en la seguridad. Por ejemplo, para una aplicación de correo electrónico, una pista de auditoría puede registrar al

remitente y al destinatario, el tamaño del mensaje y los tipos de archivos adjuntos. Un seguimiento de auditoría para una interacción

de base de datos que utiliza consultas SQL (lenguaje de consulta estructurado) puede registrar el usuario, el tipo de
transacción e incluso tablas, filas, columnas o elementos de datos individuales a los que se accede.

La figura 18.4b es un ejemplo de una pista de auditoría a nivel de aplicación para un sistema de entrega de correo.

PISTAS DE AUDITORÍA A NIVEL DE USUARIO

Un seguimiento de auditoría a nivel de usuario rastrea la actividad de usuarios individuales a lo largo del tiempo. Puede utilizarse

para responsabilizar a un usuario por sus acciones. Estas pistas de auditoría también son útiles como entrada para un programa

de análisis que intenta definir el comportamiento normal frente al anómalo.

Un seguimiento de auditoría a nivel de usuario puede registrar las interacciones del usuario con el sistema, como los comandos

emitidos, los intentos de identificación y autenticación, y los archivos y recursos a los que se accede. La pista de auditoría también

puede capturar el uso de las aplicaciones por parte del usuario.

La Figura 18.4c es un ejemplo de una pista de auditoría a nivel de usuario en un sistema UNIX.

PISTAS DE AUDITORÍA DE ACCESO FÍSICO

Las pistas de auditoría pueden ser generadas por equipos que controlan el acceso físico y luego las transmiten a un host central para

su posterior almacenamiento y análisis. Algunos ejemplos son los sistemas de tarjeta­llave y los sistemas de alarma. NIST SP 800­12

enumera los siguientes como ejemplos del tipo de datos de interés:

Se debe registrar la fecha y hora en que se intentó o realizó el acceso, al igual que el portón o puerta a través del cual se intentó o

realizó el acceso, y la persona (o ID de usuario) que intenta acceder al portón o puerta.

Los intentos no válidos deben ser monitoreados y registrados mediante pistas de auditoría no informáticas, tal como se hacen

con las pistas de auditoría de sistemas informáticos. Se debe informar a la gerencia si alguien intenta obtener acceso durante

horas no autorizadas.

La información registrada también debe incluir intentos de agregar, modificar o eliminar privilegios de acceso físico (por

ejemplo, otorgar acceso al edificio a un nuevo empleado o otorgar a los empleados transferidos acceso a su nueva

oficina [y, por supuesto, eliminar su acceso anterior, según corresponda). ).

Al igual que con los registros de auditoría de sistemas y aplicaciones, se puede implementar la auditoría de funciones

no informáticas para enviar mensajes al personal de seguridad indicando intentos válidos o no válidos de obtener acceso a

espacios controlados. Para no insensibilizar a un guardia o monitor, todo acceso no debe resultar en el envío de mensajes a

una pantalla. Sólo excepciones, como acceso fallido.

Machine Translated by Google

intentos, deben destacarse ante quienes supervisan el acceso.

Protección de datos de seguimiento de auditoría

RFC 2196 (Site Security Handbook, 1997) enumera tres alternativas para almacenar registros de auditoría:

Leer/escribir archivo en un host

Dispositivo de escritura una vez/lectura múltiple (p. ej., CD­ROM o DVD­ROM)

Dispositivo de sólo escritura (por ejemplo, una impresora de línea)

El registro del sistema de archivos es relativamente fácil de configurar y requiere menos recursos. Se puede acceder a los registros al

instante, lo que resulta útil para contrarrestar un ataque en curso. Sin embargo, este enfoque es muy vulnerable. Si un atacante obtiene

acceso privilegiado a un sistema, la pista de auditoría es vulnerable a modificaciones o eliminaciones.

Un DVD­ROM o un método de almacenamiento similar es mucho más seguro pero menos conveniente. Se necesita un suministro

constante de soportes grabables. El acceso puede retrasarse y no estar disponible de inmediato.

Los registros impresos proporcionan un rastro en papel, pero no son prácticos para capturar datos de auditoría detallados en sistemas

grandes o sistemas en red. RFC 2196 sugiere que el registro en papel puede ser útil cuando se requiere un registro permanente y

disponible de inmediato, incluso en caso de una falla del sistema.

La protección de la pista de auditoría implica tanto integridad como confidencialidad. La integridad es particularmente importante

porque un intruso puede intentar eliminar evidencia de la intrusión alterando la pista de auditoría. Para el registro del sistema de

archivos, quizás la mejor manera de garantizar la integridad sea la firma digital.

Los dispositivos de escritura única, como DVD­ROM o papel, proporcionan integridad automáticamente. Un fuerte control de acceso

es otra medida para garantizar la integridad.

La confidencialidad es importante si el registro de auditoría contiene información del usuario que es confidencial y no debe revelarse a

todos los usuarios, como información sobre cambios en el salario o el estado de la categoría salarial.

Un fuerte control de acceso ayuda en este sentido. Una medida eficaz es el cifrado simétrico (por ejemplo, utilizando AES [Advanced

Encryption Standard] o triple DES [Data Encryption Standard]). La clave secreta debe estar protegida y sólo disponible para el software

de seguimiento de auditoría y el software de análisis de auditoría posterior.

Tenga en cuenta que las medidas de integridad y confidencialidad protegen los datos de la pista de auditoría no sólo en el almacenamiento

local sino también durante la transmisión a un repositorio central.

Machine Translated by Google

18.3 IMPLEMENTACIÓN DEL REGISTRO

FUNCIÓN
La base de una instalación de auditoría de seguridad es la captura inicial de los datos de auditoría. Esto requiere que el software

incluya ganchos o puntos de captura que activen la recopilación y el almacenamiento de datos a medida que ocurren eventos

preseleccionados. Esta función de registro o recopilación de auditoría depende de la naturaleza del software y variará según el

sistema operativo subyacente y las aplicaciones involucradas. En esta sección, analizamos enfoques para implementar la

función de registro para pistas de auditoría a nivel de sistema y de usuario, por un lado, y pistas de auditoría a nivel de aplicación, por

el otro.

Registro a nivel del sistema

Gran parte del registro a nivel del sistema se puede implementar utilizando las instalaciones existentes que forman parte del sistema

operativo. En esta sección, analizamos la función del sistema operativo Windows y luego la función syslog que se encuentra en los

sistemas operativos UNIX.

REGISTRO DE EVENTOS DE WINDOWS

Un evento en el Registro de eventos de Windows es una entidad que describe algún suceso interesante en un sistema

informático. Los eventos contienen un código de identificación numérico, un conjunto de atributos (tarea, código de operación, nivel,

versión y palabras clave) y datos opcionales proporcionados por el usuario. Windows está equipado con tres tipos de registros de

eventos:

Registro de eventos del sistema: utilizado por aplicaciones que se ejecutan en cuentas de servicios del sistema (servicios del

sistema instalados), controladores o un componente o aplicación que tiene eventos relacionados con el estado del sistema

informático.

Registro de eventos de la aplicación: eventos para todas las aplicaciones a nivel de usuario. Este registro no está protegido y

está abierto a cualquier aplicación. Las aplicaciones que registran información extensa deben definir un registro

específico de la aplicación.

Registro de eventos de seguridad: el registro de auditoría de Windows. Este registro de eventos es para uso exclusivo

de la Autoridad de seguridad local de Windows. Los eventos de usuario pueden aparecer como auditorías si son

compatibles con la aplicación subyacente.

Para todos los registros de eventos o pistas de auditoría, la información de los eventos se puede almacenar en formato XML. La tabla

18.4 enumera los elementos de información almacenados para cada evento. La Figura 18.5 es un ejemplo de datos exportados

desde un registro de eventos del sistema de Windows.

Machine Translated by Google

Tabla 18.4 Elementos del esquema de eventos de Windows

Valores de propiedad de un evento que contiene datos binarios El preprocesador de seguimiento del software LevelName de Windows

(WPP) campo de seguimiento de depuración utilizado en eventos de depuración en depuración

canales

Datos binarios proporcionados por el nivel de registro de eventos de Windows que se representarán para un evento

Canal en el que se encuentra el evento renderizado. Nivel de gravedad de un evento

publicado

Datos complejos para un parámetro proporcionado por Campo de seguimiento de depuración de FormattedString WPP utilizado en la depuración

el proveedor del evento eventos en canales de depuración

ComponentName Campo de seguimiento de depuración de WPP Mensaje de evento representado para un evento

utilizado en eventos de depuración

Computadora en la que ocurrió el evento Código de operación que se representará para un evento

Dos valores de 128 bits que se pueden utilizar para encontrar La actividad o un punto dentro de una actividad que la aplicación

eventos relacionados estaba actuando cuando se planteó el evento

Nombre del elemento de datos del evento que causó una Elementos que definen un evento de instrumentación

error cuando se procesaron los datos del evento

Datos que constituyen una parte del tipo de datos complejos Información sobre el proveedor del evento que publicó el

proporcionados por el proveedor del evento. evento

Datos para un parámetro proporcionado por el proveedor del Editor del evento que publicó el evento representado

evento.

Valores de propiedad del seguimiento del software de Windows Información que se presentará para un evento.

eventos de preprocesador (WPP)

Machine Translated by Google

Código de error que apareció cuando había El identificador de seguridad del usuario.

un error al procesar los datos del evento

Una pieza de información estructurada que describe Campo de seguimiento de depuración de SequenceNum WPP utilizado en eventos

algún suceso interesante en el sistema. de depuración en canales de depuración

Número de identificación del evento SubComponentName Campo de seguimiento de depuración de WPP utilizado en

eventos de depuración en canales de depuración

Información sobre el proceso y el hilo en Información que el sistema completa automáticamente cuando el

que ocurrió el evento Se genera el evento o cuando se guarda en el archivo de registro.

Datos de eventos binarios para el evento que causó Tarea que se representará para un evento

un error cuando los datos del evento fueron

procesada

Información sobre el proceso y el hilo. Tarea con valor simbólico

el evento ocurrió en

Campo de seguimiento de depuración de FileLine WPP utilizado Información sobre la hora en que ocurrió el evento.

en eventos de depuración en canales de depuración

FlagsName Campo de seguimiento de depuración de WPP Parte definida por el proveedor que puede consistir en cualquier XML válido

utilizado en eventos de depuración en canales de depuración Contenido que comunica información del evento.

Campo de seguimiento de depuración de KernelTime WPP utilizado Campo de seguimiento de depuración de UserTime WPP utilizado en eventos de depuración en

en eventos de depuración en canales de depuración canales de depuración

Palabras clave que se representarán para un evento Versión del evento

Palabras clave utilizadas por el evento

Machine Translated by Google
Tipo de evento: Auditoría de éxito

Fuente del evento: Seguridad

Categoría de evento: (1)

ID de evento: 517

Fecha: 6/03/2006

Tiempo: 14:56:40

Usuario: AUTORIDAD NT[[barra invertida]]SISTEMA

Computadora: KENT

Descripción: Se borró el registro de auditoría.

Nombre de usuario principal: SISTEMA Dominio principal: AUTORIDAD DEL NT

ID de inicio de sesión principal: (0x0,0x3F7) Nombre de usuario del cliente: usuario

Dominio del cliente: KENT ID de inicio de sesión del cliente: (0x0,0x28BFD)

Figura 18.5 Ejemplo de entrada de registro del sistema de Windows

Windows permite al usuario del sistema habilitar la auditoría en nueve categorías diferentes:

Eventos de inicio de sesión de cuenta: actividad de autenticación del usuario desde la perspectiva del sistema que

validó el intento. Ejemplos: autenticación concedida; la solicitud del ticket de autenticación falló;

cuenta asignada para iniciar sesión; La cuenta no se pudo asignar para iniciar sesión. Acciones individuales en este

categoría no son particularmente instructivos, pero una gran cantidad de fallas pueden indicar escaneo

actividad, ataques de fuerza bruta a cuentas individuales o la propagación de exploits automatizados.

Gestión de cuentas: Actividad administrativa relacionada con la creación, gestión y

eliminación de cuentas individuales y grupos de usuarios. Ejemplos: cuenta de usuario creada; cambiar

intento de contraseña; cuenta de usuario eliminada; se agregó un miembro del grupo global con seguridad habilitada;

La política de dominio cambió.

Acceso al servicio de directorio: acceso a nivel de usuario a cualquier objeto de Active Directory que tenga un sistema

Lista de control de acceso definida. Una SACL crea un conjunto de usuarios y grupos de usuarios para los cuales

Se requiere una auditoría granular.

Eventos de inicio de sesión: actividad de autenticación del usuario, ya sea en una máquina local o a través de una red, desde

el sistema que originó la actividad. Ejemplos: inicio de sesión de usuario exitoso; error de inicio de sesión,

nombre de usuario desconocido o contraseña incorrecta; error de inicio de sesión porque la cuenta está deshabilitada; iniciar sesión

fracaso, porque la cuenta ha caducado; error de inicio de sesión, el usuario no tiene permiso para iniciar sesión en esta computadora;

cierre de sesión del usuario; error de inicio de sesión, cuenta bloqueada.

Acceso a objetos: acceso a nivel de usuario al sistema de archivos y objetos de registro que tienen acceso al sistema

Listas de Control definidas. Proporciona una forma relativamente sencilla de realizar un seguimiento del acceso de lectura, así como de los cambios,

a archivos confidenciales, integrados con el sistema operativo. Ejemplos: objeto abierto; objeto eliminado.

Cambios de política: cambios administrativos en las políticas de acceso, configuración de auditoría y otros

configuraciones a nivel del sistema. Ejemplos: derecho de usuario asignado; nuevo dominio de confianza; política de auditoría

cambió.

Uso de privilegios: Windows incorpora el concepto de derecho de usuario, permiso granular para

realizar una tarea determinada. Si habilita la auditoría de uso de privilegios, registra todas las instancias de usuarios
Machine Translated by Google

ejercer su acceso a funciones particulares del sistema (crear objetos, depurar código ejecutable o realizar copias de
seguridad del sistema). Ejemplos: se agregaron privilegios específicos al token de acceso de un usuario (durante
el inicio de sesión); un usuario intentó realizar una operación de servicio del sistema privilegiada.

Seguimiento de procesos: genera información de auditoría detallada cuando los procesos comienzan y finalizan,
se activan programas o se accede a objetos indirectamente. Ejemplos: se creó un nuevo proceso; proceso
salido; los datos auditables estaban protegidos; los datos auditables estaban desprotegidos; El usuario intentó instalar
un servicio.
Eventos del sistema: registra información sobre eventos que afectan la disponibilidad e integridad del sistema, incluidos
los mensajes de inicio y el mensaje de apagado del sistema. Ejemplos: el sistema se está iniciando; Windows se
está cerrando; agotamiento de recursos en el subsistema de explotación forestal; algunas auditorías se perdieron;
registro de auditoría borrado.

SISTEMA

Syslog es el mecanismo de registro de propósito general de UNIX que se encuentra en todas las variantes de UNIX y
Linux. Consta de los siguientes elementos:

syslog(): una interfaz de programa de aplicación (API) a la que hacen referencia varias utilidades estándar del
sistema y disponible para los programas de aplicación.
registrador: un comando UNIX utilizado para agregar entradas de una sola línea al registro del
sistema /etc/syslog.conf: el archivo de configuración utilizado para controlar el registro y el enrutamiento del registro del sistema
eventos

syslogd: el demonio del sistema utilizado para recibir y enrutar eventos de registro del sistema desde llamadas
syslog() y comandos de registro .

Las diferentes implementaciones de UNIX tendrán diferentes variantes de la función syslog y no existen formatos de registro
del sistema uniformes en todos los sistemas. El Capítulo 25 examina la función syslog de Linux. Aquí, proporcionamos una
breve descripción general de algunas funciones relacionadas con syslog y analizamos el protocolo syslog.

El servicio básico que ofrece UNIX syslog es un medio para capturar eventos relevantes, una instalación de
almacenamiento y un protocolo para transmitir mensajes syslog desde otras máquinas a una máquina central que actúa
como servidor syslog. Además de estas funciones básicas, hay otros servicios disponibles, a menudo como paquetes
de terceros y, en algunos casos, como módulos integrados. NIST SP 800­92 (Guía para la gestión de registros de seguridad
informática, septiembre de 2006) enumera las siguientes funciones adicionales más comunes:

Filtrado sólido: las implementaciones originales de syslog permitieron que los mensajes se manejaran de manera
diferente según su instalación y prioridad únicamente; no se permitió ningún filtrado más detallado. Algunas
implementaciones actuales de syslog ofrecen capacidades de filtrado más sólidas, como manejar mensajes de
manera diferente según el host o programa que generó un mensaje, o una expresión regular que coincida con el
contenido del cuerpo de un mensaje. Algunas implementaciones también permiten aplicar múltiples filtros a un solo
mensaje, lo que proporciona capacidades de filtrado más complejas.
Machine Translated by Google

Análisis de registros: originalmente, los servidores syslog no realizaban ningún análisis de los datos de registro; simplemente
proporcionaron un marco para registrar y transmitir datos de registro. Los administradores podrían utilizar programas
complementarios independientes para analizar los datos de syslog. Algunas implementaciones de syslog ahora tienen
capacidades limitadas de análisis de registros integradas, como la capacidad de correlacionar múltiples entradas de registro.
Respuesta al evento: algunas implementaciones de syslog pueden iniciar acciones cuando se detectan ciertos eventos.
Ejemplos de acciones incluyen enviar capturas SNMP, alertar a los administradores a través de páginas o correos
electrónicos e iniciar un programa o script independiente. También es posible crear un nuevo mensaje syslog que indique
que se detectó un determinado evento.
Formatos de mensajes alternativos: algunas implementaciones de syslog pueden aceptar datos en formatos que no son
syslog, como las capturas SNMP. Esto puede resultar útil para obtener datos de eventos de seguridad de hosts que no
admiten syslog y no se pueden modificar para hacerlo.
Cifrado de archivos de registro: algunas implementaciones de syslog se pueden configurar para cifrar archivos de registro
rotados automáticamente, protegiendo su confidencialidad. Esto también se puede lograr mediante el uso de un sistema
operativo o programas de cifrado de terceros.
Almacenamiento de bases de datos para registros: algunas implementaciones pueden almacenar entradas de registros tanto en

archivos syslog tradicionales como en una base de datos. Tener las entradas del registro en formato de base de datos puede resultar

muy útil para el análisis de registros posterior.

Limitación de velocidad: algunas implementaciones pueden limitar la cantidad de mensajes syslog o conexiones
TCP de una fuente particular durante un cierto período de tiempo. Esto es útil para evitar una denegación de
servicio para el servidor syslog y la pérdida de mensajes syslog de otras fuentes. Debido a que esta técnica está
diseñada para provocar la pérdida de mensajes de una fuente que abruma al servidor syslog, puede provocar que se
pierdan algunos datos de registro durante un evento adverso que genera una cantidad inusualmente grande de mensajes.

El protocolo syslog proporciona un transporte para permitir que una máquina envíe mensajes de notificación de eventos a través
de redes IP a recolectores de mensajes de eventos, también conocidos como servidores syslog. Dentro de un sistema, podemos
ver el proceso de captura y registro de eventos en términos de varias aplicaciones e instalaciones del sistema que envían
mensajes a syslogd para su almacenamiento en el registro del sistema. Debido a que cada proceso, aplicación e

implementación del sistema operativo UNIX puede tener diferentes convenciones de formato para los eventos registrados, el
protocolo syslog proporciona sólo un formato de mensaje muy general para la transmisión entre sistemas. Una versión común
del protocolo syslog se desarrolló originalmente en las implementaciones del sistema UNIX/TCP/IP de Berkeley Software
Distribution (BSD) de la Universidad de California. Esta versión está documentada en RFC 3164 (Protocolo
BSD Syslog, 2001).
Posteriormente, el IETF emitió el RFC 5424 (The Syslog Protocol 2009), que pretende ser un estándar de Internet y que
difiere en algunos detalles de la versión BSD. En lo que sigue, nosotros
describir la versión BSD.

Los mensajes en formato syslog BSD constan de tres partes:

PRI: Consiste en un código que representa los valores de Instalaciones y Severidad del mensaje, que se describen a
continuación.
Encabezado: Contiene una marca de tiempo y una indicación del nombre de host o dirección IP del dispositivo.
Mensaje: Consta de dos campos: El campo TAG es el nombre del programa o proceso que generó el mensaje; el
CONTENIDO contiene los detalles del mensaje. La parte del mensaje
Machine Translated by Google

Tradicionalmente ha sido un mensaje de formato libre de caracteres imprimibles que brinda información
detallada del evento.

La Figura 18.6 muestra varios ejemplos de mensajes syslog, excluyendo la parte PRI.

1 de marzo 06:25:43 servidor1 sshd[23170]: clave pública aceptada para el servidor2 de

172.30.128.115 puerto 21011 ssh2

1 de marzo 07:16:42 server1 sshd[9326]: Contraseña aceptada para murugiah de

10.20.30.108 puerto 1070 ssh2

1 de marzo 07:16:53 server1 sshd[22938]: comprobación de mapeo inverso getaddrinfo

para ip10.165.nist.gov falló ­ ¡POSIBLE INTENTO DE RUPTURA!

1 de marzo 07:26:28 servidor1 sshd[22572]: clave pública aceptada para el servidor2 de

172.30.128.115 puerto 30606 ssh2

1 de marzo 07:28:33 server1 su: BAD SU kkent para rootear en /dev/ttyp2

1 de marzo 07:28:41 server1 su: kkent para rootear en /dev/ttyp2

Figura 18.6 Ejemplos de mensajes Syslog

Todos los mensajes enviados a syslogd tienen una facilidad y una gravedad (consulte la Tabla 18.5). La
instalación identifica la aplicación o componente del sistema que genera el mensaje. La gravedad, o nivel del
mensaje, indica la gravedad relativa del mensaje y se puede utilizar para algunos filtrados rudimentarios.

Tabla 18.5 Instalaciones Syslog de UNIX y niveles de gravedad

(a) Instalaciones Syslog

Instalación Descripción del mensaje (generado por)

núcleo Núcleo del sistema

usuario Proceso de usuario

Machine Translated by Google
correo sistema de correo electrónico

demonio Demonio del sistema, como ftpd

autenticación
Inicio de sesión de programas de autorización , son , y getty

registro del sistema Mensajes generados internamente por syslogd

lpr Sistema de impresión

noticias Sistema de noticias UseNet

uucp subsistema UUCP

reloj demonio del reloj

ftp demonio FTP

ntp subsistema NTP

auditoría de registros Reservado para uso del sistema

alerta de registro Reservado para uso del sistema

Uso local 0–7 Hasta 8 categorías definidas localmente

(b) Niveles de gravedad de Syslog

Descripción de gravedad
Machine Translated by Google
emerger Mensajes más graves, como el cierre inmediato del sistema.

alerta Condiciones del sistema que requieren atención inmediata.

crítico Condiciones críticas del sistema, como fallas de hardware o software.

errar Otros errores del sistema; recuperable

advertencia Mensajes de advertencia; recuperable

aviso Situación inusual que amerita investigación; Un evento significativo que típicamente es parte del día normal.

operación de hoy

información
Mensajes informativos

depurar Mensajes para fines de depuración

Registro a nivel de aplicación

Las aplicaciones, especialmente aquellas con cierto nivel de privilegios, presentan problemas de seguridad que pueden
no ser capturado por datos de auditoría a nivel de sistema o de usuario. Vulnerabilidades a nivel de aplicación
constituyen un gran porcentaje de las vulnerabilidades reportadas en las listas de correo de seguridad. un tipo de
La vulnerabilidad que se puede explotar es la muy frecuente falta de controles dinámicos de los datos de entrada,
que hacen posible el desbordamiento del buffer (ver Capítulo 10). Otras vulnerabilidades explotan errores en
lógica de aplicación. Por ejemplo, una aplicación privilegiada puede diseñarse para leer e imprimir un
archivo específico. Un error en la aplicación podría permitir que un atacante aproveche una interacción inesperada
con el entorno shell para forzar a la aplicación a leer e imprimir un archivo diferente, lo que
resultar en un compromiso de seguridad.

La auditoría a nivel del sistema no proporciona el nivel de detalle para detectar errores de lógica de la aplicación.
comportamiento. Además, los sistemas de detección de intrusiones buscan firmas de ataques o comportamientos anómalos.
eso no aparecería con ataques basados en errores de lógica de aplicación. Tanto para la detección como
fines de auditoría, puede ser necesario capturar en detalle el comportamiento de una aplicación, más allá
su acceso a los servicios del sistema y sistemas de archivos. La información necesaria para detectar el nivel de aplicación.
Machine Translated by Google

Los ataques pueden faltar o ser demasiado difíciles de extraer de la información de bajo nivel incluida en los seguimientos
de llamadas del sistema y en los registros de auditoría producidos por el sistema operativo.

En el resto de esta sección, examinamos dos enfoques para recopilar datos de auditoría de aplicaciones:
bibliotecas interponibles y reescritura binaria dinámica.

Bibliotecas interponibles
Una técnica descrita en [KUPE99] y [KUPE04] proporciona auditoría a nivel de aplicación mediante la creación de
nuevos procedimientos que interceptan llamadas a funciones de biblioteca compartidas para instrumentar la actividad. La
interposición permite la generación de datos de auditoría sin necesidad de recompilar ni las bibliotecas del sistema ni la
aplicación de interés. Por lo tanto, los datos de auditoría se pueden generar sin cambiar las bibliotecas compartidas del
sistema ni necesitar acceso al código fuente del ejecutable en el que se realizará la interposición. Este enfoque se puede
utilizar en cualquier variante de UNIX o Linux y en algunos otros sistemas operativos.

La técnica aprovecha el uso de bibliotecas dinámicas en UNIX. Antes de examinar la técnica, proporcionamos una breve
descripción general de las bibliotecas compartidas.

BIBLIOTECAS COMPARTIDAS

El sistema operativo incluye cientos de funciones de biblioteca C en bibliotecas de archivo. Cada biblioteca consta de un
conjunto de variables y funciones que se compilan y vinculan entre sí. La función de enlace resuelve todas las referencias
de memoria a datos y códigos de programa dentro de la biblioteca, generando direcciones lógicas o relativas. Una
función se puede vincular a un programa ejecutable, bajo demanda, durante la compilación. Si una función no forma parte
del código del programa, el cargador de enlaces busca en una lista de bibliotecas y vincula el objeto deseado al ejecutable
de destino. Al cargar, se carga una copia separada de la función de biblioteca vinculada en la memoria virtual del programa.
Este esquema se conoce como bibliotecas vinculadas estáticamente.

Un esquema más flexible, introducido por primera vez con UNIX System V Release 3, es el uso de bibliotecas compartidas
vinculadas estáticamente. Al igual que con las bibliotecas vinculadas estáticamente, el cargador de vínculos
incorpora el objeto compartido al que se hace referencia en el ejecutable de destino en el momento del vínculo. Sin
embargo, a cada objeto en una biblioteca compartida vinculada estáticamente se le asigna una dirección virtual fija.
El cargador de enlaces conecta objetos externos referenciados a su definición en la biblioteca asignando sus direcciones
virtuales cuando se crea el ejecutable. Por lo tanto, sólo existe una copia de cada función de biblioteca. Además, la función
se puede modificar y permanece en su dirección virtual fija. Sólo es necesario recompilar el objeto, no los programas
ejecutables que hacen referencia a él. Sin embargo, la modificación generalmente debe ser menor; los cambios deben
realizarse de tal manera que la dirección de inicio y la dirección de cualquier variable, constante o etiqueta de programa en
el código no cambien.

UNIX System V Release 4 introdujo el concepto de bibliotecas compartidas vinculadas dinámicamente. Con
Machine Translated by Google

bibliotecas vinculadas dinámicamente, la vinculación a rutinas de biblioteca compartida se difiere hasta el momento de la carga. En
este momento, el contenido de la biblioteca deseado se asigna al espacio de direcciones virtuales del proceso. Por lo tanto, si
se realizan cambios en la biblioteca antes del tiempo de carga, cualquier programa que haga referencia a la biblioteca no se
verá afectado.

Para bibliotecas compartidas vinculadas estática y dinámicamente, las páginas de memoria de las páginas compartidas deben
marcarse como de solo lectura. El sistema utiliza un esquema de copia en escritura si un programa realiza una actualización
de memoria en una página compartida: el sistema asigna una copia de la página al proceso, que puede modificar sin afectar a
otros usuarios de la página.

EL USO DE BIBLIOTECAS INTERPOSABLES

La figura 18.7a indica el modo normal de operación cuando un programa invoca una rutina en bibliotecas compartidas
vinculadas dinámicamente. En el momento de la carga, la referencia a la rutina foo en el programa se resuelve en la dirección
de memoria virtual del inicio de foo en la biblioteca compartida.
Machine Translated by Google

Figura 18.7 El uso de una biblioteca interponible

Con la interpolación de bibliotecas, se construye una biblioteca interposable especial de modo que, en el momento de
la carga, el programa se vincule a la biblioteca interposable en lugar de a la biblioteca compartida. Para cada
función de la biblioteca compartida para la que se va a invocar la auditoría, la biblioteca interponible contiene una
función con el mismo nombre. Si la función deseada no está contenida en la biblioteca interpuesta, el cargador continúa
su búsqueda en la biblioteca compartida y se vincula directamente con la función de destino.
Machine Translated by Google

El módulo interpuesto puede realizar cualquier función relacionada con la auditoría, como registrar el hecho de
la llamada, los parámetros pasados y devueltos, la dirección de retorno en el programa que llama, etc.
adelante. Normalmente, el módulo interpuesto llamará a la función compartida real (consulte la Figura 18.7b) , por lo que
que el comportamiento de la aplicación no se altere, sólo se instrumente.

Esta técnica permite la interceptación de ciertas llamadas a funciones y el almacenamiento de estado entre
dichas llamadas sin requerir la recompilación del programa que realiza la llamada ni de los objetos compartidos.

[KUPE99] ofrece un ejemplo de una función de biblioteca interponible escrita en C (consulte la Figura 18.8). El
función se puede describir de la siguiente manera:

1 /******************************************

2 * Registrar el uso de ciertas funciones *

3 ****************************************/

4 caracteres *strcpy(char *dst, const char *src) {

5 char *(*fptr)(char *,const char *); /* puntero a la función real */

6 char *retval; /* el valor de retorno de la llamada */

8 AUDIT_CALL_START;

10 AUDIT_LOOKUP_COMMAND(char *(*)(char *,const char *),“strcpy”,fptr,NULL);

11

12 AUDIT_USAGE_WARNING(“strcpy”);

13

14 retval=((*fptr)(dst,src));

15

dieciséis retorno(retval);

17 }

(a) Definición de función (los elementos en mayúsculas representan macros definidas en otros lugares)

1 #definir AUDIT_LOOKUP_COMMAND(t,n,p,e)

2 p=(t)dlsym(RTLD_NEXT,n);

3 si (p==NULL) {

4 perror(“comando de búsqueda”);

5 syslog(LOG_INFO,“no se pudo encontrar %s en la biblioteca: %m”,n);

6 retorno(e);

7}
Machine Translated by Google

(b) Macro utilizada en función

Figura 18.8 Ejemplo de función en la biblioteca interpuesta

1. AUDIT_CALL_START (línea 8) se coloca al comienzo de cada función interpuesta. Este

facilita la inserción de código de inicialización arbitrario en cada función.
2. AUDIT_LOOKUP_COMMAND (línea 10 en la Figura 18.8a, detalle en la Figura 18.8b) realiza la búsqueda del
puntero a la siguiente definición de la función en las bibliotecas compartidas usando el comando dlsym(3x) . El
indicador especial RTLD_NEXT (consulte la Figura 18.8b, línea 2) indica que se devolverá la siguiente
referencia a lo largo de la ruta de búsqueda de biblioteca utilizada por el cargador en tiempo de ejecución. El puntero
de función se almacena en fptr si se encuentra una referencia o el valor de error se devuelve al programa que
llama.
3. La línea 12 contiene los comandos que se ejecutan antes de llamar a la función.

4. En este caso, la función interpuesta ejecuta la llamada a la función original y devuelve el

valor al usuario (línea 14). Otras acciones posibles incluyen el examen, registro o transformación de los
argumentos; la prevención de la ejecución real de la llamada a la biblioteca; y el examen, registro o transformación
del valor de retorno.
5. Se podría insertar código adicional antes de que se devuelva el resultado (línea 16), pero este ejemplo
no tiene ninguno insertado.

Reescritura binaria dinámica

La técnica de interposición está diseñada para funcionar con bibliotecas compartidas vinculadas dinámicamente. No puede
interceptar llamadas a funciones de programas vinculados estáticamente a menos que todos los programas del sistema se
vuelvan a vincular en el momento en que se introduce la biblioteca de auditoría. [ZHOU04] describe una técnica,
denominada reescritura binaria dinámica, que se puede utilizar con programas vinculados tanto estática como dinámicamente.

La reescritura binaria dinámica es una técnica de poscompilación que cambia directamente el código binario de los
ejecutables. El cambio se realiza en el momento de la carga y modifica sólo la imagen de memoria de un programa,
no el archivo del programa binario en el almacenamiento secundario. Al igual que con la técnica de interposición, la
reescritura binaria dinámica no requiere la recompilación del binario de la aplicación. La selección del módulo de auditoría
se pospone hasta que se invoca la aplicación, lo que permite una selección flexible de la configuración de auditoría.

La técnica se implementa en Linux utilizando dos módulos: un módulo de kernel cargable y un demonio de monitoreo.
Linux está estructurado como una colección de módulos, algunos de los cuales se pueden cargar y descargar
automáticamente según demanda. Estos bloques relativamente independientes se denominan módulos cargables [GOYE99].
En esencia, un módulo es un archivo objeto cuyo código se puede vincular y desvincular del kernel en tiempo de ejecución.
Normalmente, un módulo implementa alguna función específica, como un sistema de archivos, un controlador de dispositivo
o alguna otra característica de la capa superior del núcleo.
Machine Translated by Google

Un módulo no se ejecuta como su propio proceso o subproceso, aunque puede crear subprocesos del núcleo para
diversos fines según sea necesario. Más bien, un módulo se ejecuta en modo kernel en nombre del proceso
actual.

La figura 18.9 muestra la estructura de este enfoque. El módulo del kernel garantiza una instrumentación no
omitible al interceptar la llamada al sistema execve() . La función execve() carga un nuevo ejecutable en un
nuevo espacio de direcciones de proceso y comienza a ejecutarlo. Al interceptar esta llamada, el módulo del
kernel detiene la aplicación antes de que se ejecute su primera instrucción y puede insertar las rutinas de
auditoría en la aplicación antes de que comience su ejecución.

Figura 18.9 Entorno de ejecución para auditoría de aplicaciones

La instrumentación real de una aplicación la realiza el demonio de monitoreo, que es un proceso de espacio de
usuario privilegiado. El demonio gestiona dos repositorios: un repositorio de parches y un repositorio de auditoría.
El repositorio de parches contiene el código para instrumentar las aplicaciones monitoreadas. El
repositorio de auditoría contiene el código de auditoría que se insertará en una aplicación.
El código tanto en el repositorio de auditoría como en el de parches está en forma de bibliotecas dinámicas. Al
utilizar bibliotecas dinámicas, es posible actualizar el código en las bibliotecas mientras el demonio aún
se está ejecutando. Además, pueden existir varias versiones de las bibliotecas al mismo tiempo.

La secuencia de eventos es la siguiente:

1. La llamada al sistema execve() invoca una aplicación monitoreada .

2. El módulo del kernel intercepta la llamada, detiene la aplicación y establece el padre del proceso en el
demonio de monitoreo. Luego, el módulo del kernel notifica al demonio del espacio de usuario que
Machine Translated by Google

La aplicación supervisada se ha iniciado.

3. El demonio de monitoreo localiza las funciones de biblioteca de revisión y auditoría apropiadas para esta aplicación.
El demonio carga las funciones de la biblioteca de auditoría en el espacio de direcciones de la aplicación e
inserta llamadas a funciones de auditoría en ciertos puntos del código de la aplicación.
4. Una vez que la aplicación ha sido instrumentada, el demonio permite que la aplicación comience.
ejecución.

Se desarrolló un lenguaje especial para simplificar el proceso de creación de códigos de auditoría y parches. En esencia,
los parches se pueden insertar en cualquier punto de la llamada de función a una rutina de biblioteca compartida. El
parche puede invocar rutinas de auditoría y también invocar la rutina de biblioteca compartida, de una manera lógicamente
similar a la técnica de interposición descrita anteriormente.
Machine Translated by Google

18.4 ANÁLISIS DE PISTA DE AUDITORÍA

Los programas y procedimientos para el análisis de pistas de auditoría varían ampliamente, dependiendo
de la configuración del sistema, las áreas de mayor preocupación, el software disponible, la política de seguridad
de la organización y los patrones de comportamiento de usuarios legítimos e intrusos. Esta sección proporciona
algunas observaciones sobre el análisis de pistas de auditoría.

Preparación
Para realizar un análisis de auditoría útil, el analista o administrador de seguridad necesita comprender la información
disponible y cómo se puede utilizar. NIST SP 800­92 ofrece algunos consejos útiles en

al respecto, que resumimos en este subapartado.

ENTENDIENDO LAS ENTRADAS DE REGISTRO

El administrador de seguridad (u otra persona que revise y analice los registros) debe comprender el contexto que rodea
las entradas de los registros individuales. La información relevante puede residir en otras entradas del mismo registro,
entradas en otros registros y fuentes ajenas al registro, como entradas de gestión de configuración. El administrador
debe comprender la posibilidad de que se produzcan entradas no confiables, como las de un paquete de seguridad
que genera frecuentes falsos positivos cuando busca actividad maliciosa.

La mayoría de los formatos de archivos de auditoría contienen una combinación de lenguaje sencillo y mensajes o
códigos crípticos que son significativos para el proveedor de software, pero no necesariamente para el administrador. El
administrador debe hacer el esfuerzo de descifrar tanto como sea posible la información contenida en las entradas del registro.
En algunos casos, el software de análisis de registros realiza una tarea de reducción de datos que reduce la carga del
administrador. Aun así, el administrador debe tener un conocimiento razonable de los datos brutos que alimentan el
software de análisis y revisión para poder evaluar la utilidad de estos paquetes.

La forma más eficaz de obtener una comprensión sólida de los datos de registro es revisar y analizar partes de ellos con
regularidad (por ejemplo, todos los días). El objetivo es llegar a comprender la base de las entradas de registro típicas,
que probablemente abarquen la gran mayoría de las entradas de registro del sistema.

ENTENDIENDO EL CONTEXTO

Para realizar revisiones y análisis efectivos, los administradores deben tener un conocimiento sólido de cada uno de los
siguientes aspectos a partir de capacitación o experiencia práctica:
Machine Translated by Google

Las políticas de la organización con respecto al uso aceptable, para que los administradores puedan reconocer
violaciones de las políticas.

El software de seguridad utilizado por sus hosts, incluidos los tipos de eventos relacionados con la seguridad que cada

programa puede detectar y el perfil de detección general de cada programa (por ejemplo, falsos positivos conocidos).

Los sistemas operativos y las principales aplicaciones (por ejemplo, correo electrónico, Web) utilizados por sus hosts,

en particular las capacidades y características de seguridad y registro de cada sistema operativo y de las
principales aplicaciones.

Las características de las técnicas de ataque comunes, especialmente cómo se puede registrar el uso de estas técnicas en

cada sistema.

El software necesario para realizar análisis, como visores de registros, scripts de reducción de registros y herramientas

de consulta de bases de datos.

Momento

Los seguimientos de auditoría se pueden utilizar de varias formas. El tipo de análisis depende, al menos en parte, de cuándo se

realizará el análisis. Las posibilidades incluyen lo siguiente:

Revisión de seguimiento de auditoría después de un evento: este tipo de revisión se activa por un evento observado, como un

problema conocido de software de aplicación o sistema, una violación conocida de la política de seguridad existente por

parte de un usuario, o algún problema de usuario o sistema inexplicable. La revisión puede recopilar información para

elaborar lo que se sabe sobre el evento, diagnosticar la causa o el problema y sugerir acciones correctivas y

contramedidas futuras. Este tipo de revisión se centra en las entradas de la pista de auditoría que son relevantes para el
evento específico.

Revisión periódica de los datos de la pista de auditoría: este tipo de revisión analiza todos los datos de la pista de auditoría o

subconjuntos definidos de datos y tiene muchos objetivos posibles. Ejemplos de objetivos incluyen buscar eventos o patrones que

sugieran un problema de seguridad, desarrollar un perfil de comportamiento normal y buscar comportamiento anómalo, y

desarrollar perfiles por usuario individual para mantener un registro permanente por usuario.

Análisis de auditoría en tiempo real: las herramientas de análisis de auditoría también se pueden utilizar en tiempo real o

casi en tiempo real. El análisis en tiempo real es parte de la función de detección de intrusiones.

Revisión de auditoría

A diferencia del análisis de datos de seguimiento de auditoría utilizando herramientas de análisis y reducción de datos, se encuentra

el concepto de revisión de auditoría. Una capacidad de revisión de auditoría permite a un administrador leer información de

registros de auditoría seleccionados. La especificación de Criterios Comunes [CCPS12a] exige una capacidad que permita la

selección de auditoría previa o posterior al almacenamiento e incluya la capacidad de revisar selectivamente lo siguiente:
Machine Translated by Google

Las acciones de uno o más usuarios (por ejemplo, identificación, autenticación, entrada al sistema y acciones de control de
acceso)
Las acciones realizadas en un objeto o recurso del sistema específico. Todas o un
conjunto específico de excepciones auditadas. Acciones
asociadas con un sistema o atributo de seguridad específico.

La revisión de auditoría puede centrarse en registros que coincidan con ciertos atributos, como usuario o grupo de usuarios, ventana
de tiempo, tipo de registro, etc.

Una herramienta automatizada que puede resultar útil en la revisión de auditoría es la priorización de los registros de auditoría en
función de las aportaciones del administrador. Los registros se pueden priorizar en función de una combinación de factores.
Los ejemplos incluyen los siguientes:

Tipo de entrada (p. ej., código de mensaje 103, clase de mensaje CRÍTICO)
Novedad del tipo de entrada (es decir, ¿ha aparecido este tipo de entrada en los registros antes?)
Origen del
registro Dirección IP de origen o destino (por ejemplo, dirección de origen en una lista negra; dirección de destino de un sistema
crítico; eventos previos que involucran una dirección IP particular)
Hora del día o día de la semana (por ejemplo, una entrada puede ser aceptable durante ciertas horas pero no permitida durante
otras)
Frecuencia de la entrada (por ejemplo, x veces en y segundos)

Puede haber varios propósitos posibles para este tipo de revisión de auditoría. La revisión de auditoría puede permitir a un
administrador tener una idea del funcionamiento actual del sistema y el perfil de los usuarios y aplicaciones en el sistema, el nivel
de actividad de ataque y otros eventos relacionados con el uso y la seguridad. La revisión de auditoría se puede utilizar para
comprender después de un incidente de ataque y la respuesta del sistema al mismo, lo que lleva a cambios en el software y
los procedimientos.

Enfoques para el análisis de datos

El espectro de enfoques y algoritmos utilizados para el análisis de datos de auditoría es demasiado amplio para tratarlo aquí de
manera efectiva. En cambio, damos una idea de algunos de los enfoques principales, basados en la discusión en [SING04].

ALERTAS BÁSICAS

La forma más sencilla de análisis es que el software dé una indicación de que ha ocurrido un evento interesante en
particular. Si la indicación se da en tiempo real, puede servir como parte de un sistema de detección de intrusos. Para eventos
que pueden no alcanzar el nivel de desencadenar una alerta de intrusión, una indicación posterior de actividad sospechosa puede
conducir a un análisis más detallado.

BASE
Machine Translated by Google

La línea de base es el proceso de definir eventos y patrones normales versus inusuales. El proceso implica medir un conjunto de

datos conocidos para calcular un rango de valores normales. Estos valores de referencia pueden luego compararse con nuevos

datos para detectar cambios inusuales. Ejemplos de actividades hasta la línea de base incluyen los siguientes:

Cantidad de tráfico de red por protocolo: HTTP total, correo electrónico, FTP, etc.

Inicios de sesión/cierres de sesión

Accesos de cuentas de administrador.

Gestión de direcciones del Protocolo de configuración dinámica de host (DHCP), solicitudes de DNS

Cantidad total de datos de registro por hora/día

Número de procesos ejecutándose en cualquier momento

Por ejemplo, un gran aumento en el tráfico FTP podría indicar que su servidor FTP ha sido comprometido y está siendo

utilizado maliciosamente por un extraño.

Una vez que se establecen las líneas de base, es posible realizar un análisis con respecto a ellas. Un enfoque, que se analiza

con frecuencia en este texto, es la detección de anomalías. Un ejemplo de un enfoque simple para la detección de anomalías es
4
el controlador de detección de anomalías nunca antes visto (NBS) gratuito. La herramienta implementa una búsqueda de cadenas en la

base de datos muy rápida y le indica si una cadena determinada está en la base de datos (es decir, si ya ha sido vista).

4Consulte el sitio web del libro para encontrar el enlace a este software.

Considere el siguiente ejemplo que involucra DHCP. DHCP se utiliza para una fácil configuración TCP/IP de hosts dentro de una red.

Al iniciarse el sistema operativo, el host del cliente envía una solicitud de configuración que es detectada por el servidor DHCP. El

servidor DHCP selecciona los parámetros de configuración apropiados (dirección IP con máscara de subred adecuada y otros

parámetros opcionales, como la dirección IP de la puerta de enlace predeterminada, direcciones de servidores DNS, nombre de

dominio, etc.) para las estaciones cliente. El servidor DHCP asigna direcciones IP a los clientes dentro de un alcance predefinido

durante un período determinado (tiempo de concesión). Si se desea conservar una dirección IP, el cliente debe solicitar una extensión

del período de tiempo antes de que expire el contrato de arrendamiento. Si el cliente no ha requerido una ampliación del tiempo

de arrendamiento, la dirección IP se considera libre y puede ser asignada a otro cliente. Esto se realiza de forma automática y

transparente. Con NBS, es fácil monitorear las redes de la organización para detectar nuevas combinaciones de control de acceso al

medio/IP (MAC/IP) alquiladas por servidores DHCP. El administrador se entera inmediatamente de que se están alquilando nuevas

MAC y nuevas direcciones IP que normalmente no se alquilan. Esto puede tener o no implicaciones de seguridad. NBS también

puede buscar registros con formato incorrecto, consultas de clientes novedosos y una amplia gama de otros patrones.

Otra forma de análisis de referencia es el establecimiento de umbrales. El umbral es la identificación de datos que exceden un valor

de referencia particular. El umbral simple se utiliza para identificar eventos, como conexiones rechazadas, que ocurren más de un cierto

número de veces. El establecimiento de umbrales puede centrarse en otros parámetros, como la frecuencia de los eventos, en lugar

del simple número de eventos.

Machine Translated by Google

La ventana es la detección de eventos dentro de un conjunto determinado de parámetros, como dentro de un período de tiempo

determinado o fuera de un período de tiempo determinado; por ejemplo, establecer una referencia a la hora del día en que cada usuario

inicia sesión y marcar los inicios de sesión que quedan fuera de ese rango.

Correlación
Otro tipo de análisis es el de correlación, que busca relaciones entre eventos. Un ejemplo simple de correlación es, dada la presencia

de un mensaje de registro particular, alertar sobre la presencia de un segundo mensaje particular. Por ejemplo, si Snort (ver

Sección 8.9) informa un intento de desbordamiento del buffer desde un host remoto, un intento razonable de correlación tomaría cualquier

mensaje que contenga la dirección IP del host remoto. O el administrador podría querer anotar cualquier cambio de usuario

(su) en una cuenta en la que se inició sesión desde un host remoto nunca antes visto.
Machine Translated by Google

18.5 INFORMACIÓN DE SEGURIDAD Y

GESTIÓN DE EVENTOS
Existe una necesidad de sistemas que puedan procesar automáticamente la gran cantidad de datos de auditoría de
seguridad generados por las redes, servidores y hosts contemporáneos en organizaciones más grandes. Se generan
tantos datos que es esencialmente imposible para una persona extraer información útil y oportuna.
Esto incluye la necesidad de caracterizar la actividad normal y los umbrales para que el sistema genere alertas cuando
se detecten anomalías o patrones maliciosos. Por lo tanto, se requiere algún tipo de sistema de registro
centralizado, automatizado e integrado. El tipo de producto que puede abordar estos problemas se conoce como
sistema de gestión de eventos e información de seguridad (SIEM).

NIST SP 800­137 (Monitoreo continuo de seguridad de la información (ISCM) para organizaciones y sistemas de
información federales, septiembre de 2011), entre otros estándares, reconoce la necesidad de dichos sistemas como
control de seguridad clave. [TARA11] señala que se puede configurar un sistema SIEM para ayudar a implementar
muchos de los "20 controles críticos" desarrollados por SANS y otros, que mencionamos en el Capítulo 12.

Sistemas SIEM
El software SIEM es un paquete de software de registro centralizado similar a syslog, pero mucho más complejo. Los
sistemas SIEM proporcionan una instalación de almacenamiento de pistas de auditoría uniforme y centralizada y un
conjunto de programas de análisis de datos de auditoría. NIST SP 800­92 analiza la gestión de registros y los sistemas
SIEM. Señala que existen dos enfoques de configuración generales y que muchos productos ofrecen una combinación
de ambos:

Sin agente: el servidor SIEM recibe datos de los hosts generadores de registros individuales sin necesidad de
tener ningún software especial instalado en esos hosts. Algunos servidores extraen registros de los hosts, lo que
generalmente se hace haciendo que el servidor se autentique en cada host y recupere periódicamente sus
registros. En otros casos, los hosts envían sus registros al servidor, lo que generalmente implica que cada host se
autentique en el servidor y transfiera sus registros con regularidad. Luego, el servidor SIEM realiza filtrado y
agregación de eventos y normalización y análisis de registros en los registros recopilados.

Basado en agente: se instala un programa de agente en el host generador de registros para realizar filtrado
y agregación de eventos y normalización de registros para un tipo particular de registro, luego transmitir los
datos de registro normalizados a un servidor SIEM, generalmente en tiempo real o casi. base en tiempo real
para análisis y almacenamiento. Si un host tiene varios tipos de registros de interés, es posible que sea
necesario instalar varios agentes. Algunos productos SIEM también ofrecen agentes para formatos genéricos.
Machine Translated by Google

como syslog y SNMP. Un agente genérico se utiliza principalmente para obtener datos de registro de una fuente para la
cual no están disponibles un agente de formato específico ni un método sin agente. Algunos productos también permiten
a los administradores crear agentes personalizados para manejar fuentes de registro no compatibles.

El software SIEM es capaz de reconocer una variedad de formatos de registro, incluidos los de una variedad de sistemas
operativos, software de seguridad (por ejemplo, IDS y firewalls), servidores de aplicaciones (por ejemplo, servidores web
y servidores de correo electrónico) e incluso dispositivos de control de seguridad física. como lectores de credenciales. El
software SIEM normaliza estas diversas entradas de registro para que se utilice el mismo formato para el mismo elemento
de datos (por ejemplo, dirección IP) en todas las entradas. El software puede eliminar campos en las entradas del registro
que no son necesarios para la función de seguridad y entradas del registro que no son relevantes, lo que reduce en gran
medida la cantidad de datos en el registro central. El servidor SIEM analiza los datos combinados de múltiples
fuentes de registro, correlaciona eventos entre las entradas del registro, identifica y prioriza eventos importantes e inicia
respuestas a eventos si se desea. Los productos SIEM suelen incluir varias funciones para ayudar a los usuarios, como las
siguientes:

Interfaces gráficas de usuario (GUI) diseñadas específicamente para ayudar a los analistas a identificar problemas
potenciales y revisar todos los datos disponibles relacionados con cada problema. Una base de
conocimientos de seguridad, con información sobre vulnerabilidades conocidas, el significado probable de ciertos
mensajes de registro y otros datos técnicos; Los analistas de registros a menudo pueden personalizar la base
de conocimientos según sea
necesario. Capacidades de seguimiento y generación de informes de incidentes, a veces con funciones
sólidas de flujo de trabajo. Almacenamiento y correlación de información de activos (por ejemplo, dar mayor prioridad a un
ataque dirigido a un sistema operativo vulnerable o a un host más importante).

Los sistemas SIEM bien implementados pueden constituir un componente crítico en la infraestructura de seguridad de
una organización. Sin embargo, muchas organizaciones no planifican, instalan y gestionan adecuadamente dichos
sistemas. [HADS10] señala que un proceso apropiado incluye definir amenazas, documentar respuestas y configurar
informes estándar para cumplir con los requisitos de auditoría y cumplimiento.
Los apéndices de este documento proporcionan ejemplos de cada uno de estos que pueden adaptarse y ampliarse para
una organización determinada. Todo esto se puede hacer como parte de un proceso más amplio de evaluación de riesgos
de seguridad de TI que analizamos en los Capítulos 14 y 15. Este documento también enumera una serie de proveedores de
productos SIEM.
Machine Translated by Google

18.6 TÉRMINOS CLAVE,

PREGUNTAS DE REVISIÓN Y PROBLEMAS

Términos clave

auditoría de seguimiento de

auditoría a nivel de aplicación de detección

de anomalías

revisión de auditoría

pista de auditoría

análisis de seguimiento de

auditoría línea

de base reescritura binaria dinámica

biblioteca compartida vinculada dinámicamente

biblioteca interponible módulos

cargables

registrar acceso físico pista de auditoría

auditoría de seguridad

pista de auditoría de seguridad

gestión de eventos e información de seguridad (SIEM) biblioteca compartida biblioteca

vinculada estáticamente

biblioteca compartida vinculada

estáticamente syslog pista de auditoría a nivel de

sistema

umbrales pista de auditoría a nivel de

usuario

ventanas

Preguntas de revisión

18.1 Explique la diferencia entre un mensaje de auditoría de seguridad y una alarma de seguridad.

18.2 Enumerar y describir brevemente los elementos de un modelo de auditoría y alarmas de seguridad.

18.3 Enumerar y describir brevemente las principales funciones de auditoría de seguridad.

Machine Translated by Google

18.4 ¿En qué áreas (categorías de datos) se deben recopilar datos de auditoría?

18.5 Enumere y explique las diferencias entre cuatro categorías diferentes de pistas de auditoría.

18.6 ¿Cuáles son los elementos principales de una instalación syslog de UNIX?

18.7 Explique cómo se puede utilizar una biblioteca interposable para la auditoría a nivel de aplicación.

18.8 Explique la diferencia entre revisión de auditoría y análisis de auditoría.

18.9 ¿Qué es un sistema de gestión de eventos e información de seguridad (SIEM)?

Problemas

18.1 Compare las tablas 18.2 y 18.3. Discuta las áreas de superposición y las áreas que no se superponen y su significado.

a. ¿Hay elementos que se encuentran en la Tabla 18.2 y que no se encuentran en la Tabla 18.3 ? Discutir su

justificación.
b. ¿Hay elementos que se encuentran en la Tabla 18.3 y que no se encuentran en la Tabla 18.2 ? Discutir su

justificación.

18.2 En la Tabla 18.6 se muestra otra lista de eventos auditables, de [KUPE04] . Compare esto con las tablas 18.2 y 18.3.

Tabla 18.6 Lista sugerida de eventos a auditar

Identificación y autenticación Acceso fallido al programa La interacción del usuario

contraseña cambiada Parámetros de todo el sistema digitando rapido

eventos de inicio de sesión fallidos Actividad de CPU en todo el sistema errores de escritura

(carga)
intentos de inicio de sesión exitosos intervalos de escritura

actividad del disco en todo el sistema

tipo de terminal ritmo de escritura

memoria de todo el sistema

ubicación de inicio de sesión análogo de presión
uso

Se consulta la identidad del usuario. eventos de ventana

Accesos a archivos

intentos de inicio de sesión inexistentes múltiples eventos por

creación de archivos
cuentas ubicación

archivo leído
terminal usado múltiples localizaciones

escritura de archivos con eventos

tipo de inicio de sesión (interactivo/automático)

eliminación de archivos movimientos del mouse

método de autentificación

intentar acceder clics del mouse

hora de cerrar sesión
archivos de otros usuarios
tiempos muertos
tiempo total de conexión
intentar acceder
Tiempo de conección
motivo para cerrar sesión archivos "sensibles"

datos enviados desde

Operaciones del sistema operativo
Machine Translated by Google
accesos fallidos a archivos
Terminal

auditoría habilitada cambio de permiso

datos enviados a

intento de desactivar la auditoría cambio de etiqueta Terminal

intento de cambiar la configuración de auditoría modificación de directorio Impreso en papel

poner un objeto en otro usuario Información sobre archivos Actividad de red

espacio de memoria
nombre paquete recibido

eliminación de objetos de otros usuarios

marcas de tiempo protocolo
espacio de memoria

tipo Dirección de la fuente

cambio de privilegio

contenido dirección de destino

cambio en la etiqueta del grupo

propietarios Puerto de origen

Uso de comandos "sensibles"

grupo Puerto de destino

Acceso exitoso al programa

permisos longitud
nombres de comandos y argumentos

etiqueta tamaño de carga útil

tiempo de uso

dispositivo físico carga útil

dia de uso

bloque de disco suma de control

Tiempo de CPU utilizado

banderas
tiempo de pared transcurrido

puerto abierto
archivos accedidos

puerto cerrado
número de archivos accedidos

conexión
memoria máxima utilizada
solicitado

conexión cerrada

reajuste de conexion

máquina en marcha

abajo

a. ¿Hay elementos que se encuentran en las Tablas 18.2 y 18.3 que no se encuentran en la Tabla 18.6 ? Conversar

su justificación.
b. ¿Hay elementos que se encuentran en la Tabla 18.6 que no se encuentran en las Tablas 18.2 y 18.3? Conversar

su justificación.

18.3 Argumente las ventajas y desventajas de los enfoques de software SIEM con y sin agente
descritos en la Sección 18.5 .