Cobertura especial: Windows Server 2008

Auditoría y cumplimiento en Windows Server 2008

Rob Campbell y Joel Yoker

Resumen:

• Aumento de la importancia del cumplimiento
• Comprensión de los cambios en su entorno
• Retos de la auditoría de eventos de seguridad
• Aspectos técnicos de las auditorías

En el mundo de la tecnología de la información, el cambio es una constante. Si su organización de TI es como la mayoría, no debe perder más tiempo y debe tratar de comprender los cambios que tienen lugar en su entorno. A medida que aumenta la complejidad y escala de los entornos de TI, también lo hace la repercusión de

los errores administrativos y las divulgaciones accidentales de datos. La sociedad de hoy en día demanda responsabilidad por dichos eventos, por lo que las organizaciones se consideran actualmente responsables legales de la protección de la información que administran.

Como resultado, la auditoría de los cambios en el entorno se ha convertido en un factor muy importante. ¿Por qué? Las auditorías proporcionan los medios para comprender y administrar los cambios en entornos de TI sumamente distribuidos y de gran tamaño tan frecuentes hoy en día. En este artículo, abarcamos los retos a los que se enfrentan la mayoría de las organizaciones, el entorno de cumplimiento y normativa de TI, algunos de los aspectos básicos de las auditorías en Windows® y cómo la funcionalidad de Windows Server® 2008 y los Servicios de recopilación de auditorías (ACS) de Microsoft® System Center Operations Manager 2007 pueden dar lugar a una estrategia de auditorías integral.

Auditoría de los retos

Un vistazo rápido a los titulares del día nos muestra que las divulgaciones de datos se están convirtiendo en un problema creciente. Muchos de estos incidentes implican una acción legal, pérdidas financieras y problemas de relaciones públicas para las organizaciones responsables. La capacidad de explicar qué cambios tuvieron lugar o la identificación rápida de problemas es la clave para reducir la repercusión de los incidentes de divulgación de datos.

Por ejemplo, digamos que su organización es responsable de administrar información de identificación personal para una base de clientes determinada. Aunque existen numerosas maneras de proteger la información contenida en los sistemas que debe administrar, todavía pueden darse divulgaciones no autorizadas. Una auditoría adecuada puede permitir a la organización saber exactamente qué sistemas se han visto comprometidos y, quizás, qué datos se han perdido. Sin la auditoría, la repercusión de la pérdida de datos podría ser mucho mayor, en gran parte porque no habría manera de estimar el alcance de los posibles daños.

Así pues, ¿por qué no la ponen en práctica las organizaciones de TI? El hecho es que la mayoría de las organizaciones no comprenden completamente los aspectos técnicos de una auditoría. Aunque los altos directivos comprenden generalmente conceptos como los de copia de seguridad y restauración, la complejidad inherente a la auditoría de los cambios en el entorno es un mensaje difícil de transmitir. Como resultado, tras un solo incidente significativo surgen gran cantidad de preguntas sobre la auditoría. Por ejemplo, puede que una auditoría básica esté habilitada pero, si el sistema no está configurado para llevar a cabo la auditoría de un cambio particular, debido a la falta de planeación, esta información no se recopilará.

Es más, los eventos de seguridad auditados tienen ciertos problemas inherentes que los profesionales de TI deben saber tratar. Una de estas dificultades es la distribución de sistemas dentro de los grandes entornos informáticos actuales. Este factor supone retos de recopilación y agregación significativos, puesto que el cambio puede darse en cualquier sistema o conjunto de sistemas y en cualquier momento. Esto nos lleva a otro reto, la correlación. La traducción de relaciones entre eventos en uno o varios sistemas es, con frecuencia, necesaria para obtener el verdadero significado de lo que está ocurriendo.

Otro problema a considerar es que las auditorías normalmente van más allá de los límites organizativos tradicionales. Las distintas estructuras de organización o equipo existen por distintos motivos y puede que no sea demasiado fácil obviarlas. Muchas organizaciones cuentan con un equipo de servicios de directorio, un equipo de infraestructura de mensajería y un equipo dedicado al escritorio pero, probablemente, sólo hay un equipo de seguridad responsable de todas estas áreas. Es más, el personal de seguridad dedicado de su organización puede que no esté físicamente presente en todas las ubicaciones. Por ejemplo, las sucursales a menudo dependen de una sola persona o un equipo pequeño para todas las tareas, incluida la administración del registro de eventos de seguridad.

Por último, la cantidad total de eventos supone un reto en sí. Los eventos de seguridad auditados ocurren en un volumen mucho mayor que otros tipos de registro de eventos. El número de eventos recopilados dificulta la retención y la revisión efectivas de los registros. Además, al estipular los requisitos de retención de esta información, las normativas actuales y propuestas no ayudan a reducir esta carga en las infraestructuras informáticas actuales.

En el pasado, la auditoría del acceso a la información podía resumirse como el deseo de conocer y el intento de garantizar la seguridad. Actualmente, puesto que las organizaciones, y el equipo directivo responsable de las mismas, se consideran responsables legales de la pérdida de información o de la ausencia de una protección adecuada de la misma, es muy importante para los administradores de TI familiarizarse con la normativa aplicable a sus entornos. Para compañías globales, los retos son incluso más complejos, puesto que cada país tiene sus propias reglas referentes a la información y a su protección. Algunos ejemplos de la legislación existente sobre cumplimiento de normativas se indican en la Figura 1, junto con las expectativas asociadas que afectan a las organizaciones de TI.

Figure 1 Normativas y su significado para los profesionales de TI

En este escenario de presión legal, ¿qué deben hacer los profesionales de TI? Los administradores y los técnicos de TI necesitan crear una historia clara y concisa para presentarla al personal dentro y fuera de la organización. Esto incluye el desarrollo de una estrategia apropiada de auditoría, la cual requiere medidas proactivas e inversiones. El concepto clave en este caso es que la auditoría no puede ser una idea tardía en el diseño, como lo es con mucha frecuencia.

Los retos de TI como estos pueden normalmente resolverse con una buena combinación de personal, procesos y tecnología. En las auditorías, lo que importa es el proceso. Por lo tanto, el primer paso debe ser dominar los aspectos básicos de manera que pueda responder a las necesidades y los requisitos de su organización en torno al cumplimiento de la normativa. Abarquemos ahora algunos de los aspectos básicos de la auditoría en Windows. A continuación, nos dedicaremos a los cambios integrados en Windows Server 2008 y Windows Vista®.

Auditoría de eventos de seguridad

Todos los eventos auditados se registran en el registro de eventos de seguridad de Windows. Estos eventos no suelen requerir una acción inmediata y, normalmente, son de naturaleza informativa. Cada evento registra una Auditoría correcta o un Error de auditoría para un tipo específico de acceso que haya ocurrido. Esto es diferente a los registros de eventos de aplicación o del sistema, donde los problemas pueden identificarse a través de codificación en colores (sugerencia: busque los eventos en rojo para identificar problemas).

El registro de eventos de seguridad es diferente porque los eventos auditados se ocultan, con frecuencia, por su volumen y, tal como se ha mencionado antes, la correlación de los datos de seguridad puede suponer un reto significativo. Incluso una simple infracción de datos en un solo sistema es problemática. El registro de eventos de seguridad debería analizarse con el objeto de identificar qué cuenta se usó para obtener acceso a los datos. Esto requiere que el administrador efectúe un seguimiento de todo el registro para encontrar la cuenta. Desgraciadamente, los ataques sofisticados actuales son, a menudo, coordinados y distribuidos, y dificultan bastante esta clase de análisis para la víctima.

Dicho esto, es importante comprender los elementos clave que permiten que la información se registre en el registro de eventos de seguridad de Windows: Directiva de auditoría y Listas de control de acceso del sistema (SACL). Las directivas de auditoría son parámetros configurables para un equipo local a través de la Directiva de grupo o la Directiva de seguridad local, y definen la recopilación de eventos correctos y con error de tipos específicos de acceso. Las siguientes categorías principales de directivas de auditoría han estado presentes en Windows durante muchos años (más sobre la nueva directiva de auditoría granular en Windows Server 2008 en unos momentos):

• Auditar eventos de inicio de sesión de cuenta
• Auditar la administración de cuentas
• Auditar el acceso del servicio de directorio
• Auditar eventos de inicio de sesión
• Auditar el acceso a objetos
• Auditar el cambio de directivas
• Auditar el uso de privilegios
• Auditar el seguimiento de procesos
• Auditar eventos del sistema

La necesidad de definir la directiva de auditoría y estas categorías asociadas queda normalmente bien comprendida por parte de la mayoría de las organizaciones de TI, pero la directiva de auditoría representa sólo una parte de la solución. Las SACL juegan también una función significativa en la implementación de un plan de auditoría integral. Dos categorías específicas de directivas de auditoría, auditar el acceso del servicio de directorio y auditar el acceso a objetos, dependen por completo de las SACL para devolver información en el registro de eventos de seguridad. Así pues, ¿qué son exactamente las SACL?

Cada objeto (archivo, registro o servicio de directorio) tiene una Lista de control de acceso (ACL) con una o más Entradas de control de acceso (ACE) divididas en dos tipos: una lista de control de acceso discrecional (DACL) y una SACL (la última define la configuración que registra los intentos de acceso a los objetos protegidos). Cada una de las ACE en una SACL especifica los tipos de intentos de acceso de un administrador de confianza especificado que deben registrarse en el registro de eventos de seguridad. Las ACE definen el registro de intentos de acceso correctos y/o con error a los objetos especificados. La Figura 2 muestra el uso de una SACL en un objeto para generar eventos de tipos específicos de acceso.

Figura 2** Uso de una SACL en un objeto **(Hacer clic en la imagen para ampliarla)

La comprensión de la relación entre la directiva de auditoría y las SACL es importante, puesto que la configuración es necesaria para capturar los eventos auditados "correctos" en consonancia con los cambios en el entorno. Tal como se ha mencionado, las categorías "auditar el acceso del servicio de directorio" y "auditar el acceso a objetos" sólo permiten la generación de auditorías en el registro de eventos de seguridad para estas categorías específicas, pero los eventos sólo se generan si un objeto tiene una ACE de auditoría configurada en su SACL. Una vez que estas piezas están en su lugar, la Autoridad de seguridad local (LSA) de Windows genera eventos de seguridad que se escriben en el registro de eventos de seguridad.

Los eventos consisten en dos áreas diferenciadas: el encabezado, que es estático y está predefinido para cada identificador de evento (Id. de evento) y el cuerpo, que es dinámico y contiene detalles diferentes para eventos diferentes. La Figura 3 muestra estos dos elementos en un evento de seguridad de Windows Server 2008 de ejemplo. La comprensión de estos componentes de evento es importante para la fase de análisis de cualquier proyecto de auditoría, y es de particular interés con respecto a cómo se devuelve la información en herramientas como ACS.

Figura 3** El encabezado y el cuerpo de un evento auditado **(Hacer clic en la imagen para ampliarla)

Windows Eventing 6.0

Ahora que entendemos el problema, ¿cómo ayuda Windows Server 2008 a las organizaciones a enfrentarse a estos desafíos? Windows Server 2008 es el primer servidor que contiene el nuevo subsistema de eventos Windows Eventing 6.0, el cual mejora en gran medida el entorno de administración de los eventos de seguridad. Tenga en cuenta que, aunque en este artículo nos hemos centrado en Windows Server 2008, el 95% del nuevo conjunto de características existe también en Windows Vista.

Una de las primeras novedades que los usuarios advertirán en Windows Eventing 6.0 es la nueva interfaz de usuario. El nuevo complemento de Microsoft Management Console (MMC) Visor de eventos ofrece una página excelente de introducción y resumen, vistas personalizadas flexibles y texto explicativo ampliamente mejorado. Estas interfaces pueden ayudar al usuario final o al administrador del sistema a encontrar información de eventos y a configurar opciones del registro de eventos muy importantes directamente en el Visor de eventos.

Un problema clave que a menudo repercutía en los datos de seguridad dentro del registro de eventos era la retención de datos. Anteriormente, el subsistema de registro de eventos (incluidos todos los registros) tenía límites de escalabilidad. Si se excedían estos límites, todo el subsistema detenía los eventos de registro. No obstante, este no es el caso en Windows Eventing 6.0; las organizaciones están limitadas ahora sólo por la cantidad disponible de espacio en disco. Sin embargo, tenga en cuenta que los registros de eventos muy grandes pueden ser complicados de analizar, puesto que cada entrada de registro individual se debe evaluar durante el filtrado, por lo que, definitivamente, deseará mantener su registro a un tamaño razonable.

Por supuesto, esto todavía deja al administrador de TI la responsabilidad del desarrollo de un plan de archivado de registros de eventos en muchos sistemas. Como ayuda para esta tarea en el nivel de servidor local, una característica que forma ahora parte de Windows Eventing 6.0 es la opción "Archivar el registro cuando esté lleno; no sobrescribir eventos". En versiones anteriores de Windows, esta opción sólo se podía configurar directamente a través de la modificación del valor del Registro AutoBackupLogFiles. Aunque esto suministra un mecanismo para el archivo local de registros, no ofrece una solución para la administración de estos archivos a largo plazo, ni soluciona el problema de agregación en varios sistemas. Los Servicios de recopilación de auditorías ofrecen una solución completa para esto, a la que llegaremos en breve.

La nueva interfaz es sólo el principio. La verdadera ventaja de Windows Eventing 6.0 es el nuevo servicio Registro de eventos de Windows y el motor subyacente basado en XML. Estos componentes son los que proporcionan la mejora de la escalabilidad, la accesibilidad y las opciones de administración. Los eventos se almacenan ahora en un formato XML flexible que posibilita soluciones personalizadas que pueden aprovechar esta información de manera nativa.

Windows Eventing 6.0 ofrece también la capacidad de asociar acciones administrativas con eventos específicos. Esto lo consigue integrando el servicio Recopilador de eventos de Windows con el Programador de tareas para ofrecer eventos basados en tareas. Se trata de un nuevo paradigma para el Programador de tareas, que anteriormente estaba limitado a activar eventos basados en la hora. El asistente para "Adjuntar tarea a este evento" (disponible en el menú contextual de cualquier evento en el Visor de eventos de Windows Server 2008) proporciona una manera fácil de iniciar un programa, enviar un correo electrónico o mostrar un mensaje siempre que se registre un evento específico. Esto puede ser muy útil a la hora de identificar las acciones específicas que tienen lugar en su entorno y que se pueden aislar en un evento de seguridad específico. Por ejemplo, si está realizando la auditoría de cambios en la clave del Registro "Schema Update Allowed" en sus controladores de dominio, puede crear una tarea que envíe un mensaje de correo electrónico a los administradores de seguridad específicos para notificarles la modificación de esta clave del Registro.

Además de la nueva capacidad de recopilar y almacenar un gran número de entradas de evento, ahora también puede controlar mejor qué eventos se registran en el registro de eventos. Esto es posible gracias a una nueva característica denominada Directiva de auditoría granular (GAP). En versiones anteriores de Windows, las nueve categorías de auditoría existentes con frecuencia provocaban una sobrecarga de eventos. Estas categorías de nivel superior se pueden controlar ahora a través de 50 subcategorías granulares, cada una de las cuales representa un subconjunto relacionado de eventos.

Esto le ofrece la capacidad de filtrar información que no sea crítica del registro de eventos sin perder visibilidad en el nivel de categorías. Por ejemplo, si en un sistema particular desea supervisar los cambios sólo en el Registro, pero no en el sistema de archivos, previamente sólo podía elegir la generación de informes de éxito o error en la categoría Acceso a objetos. Con GAP, puede filtrar subcategorías como Sistema de archivos, Servicios de certificación y Recurso compartido de archivos, y generar informes de eventos sólo en la subcategoría Registro. Para explorar las subcategorías de GAP en un sistema Windows Server 2008, debe ejecutar el comando Auditpol en un símbolo del sistema elevado. Para enumerar las subcategorías disponibles de GAP, escriba lo siguiente:

auditpol /list /subcategory:*

Para obtener una lista de las subcategorías de GAP configuradas en su sistema, escriba esto:

auditpol /get /category:*

Tenga en cuenta que GAP no se puede configurar a través de la interfaz de usuario estándar de la directiva de grupo y debe administrarse a través de auditpol.exe. El artículo de Knowledge Base en support.microsoft.com/kb/921469 ofrece instrucciones acerca de cómo implementar la configuración de GAP a través de la directiva de grupo para sistemas Windows Server 2008 y Windows Vista.

Windows Server 2008 también puede capturar valores tanto nuevos como anteriores de los tipos específicos en el registro de eventos de seguridad. En versiones anteriores de Windows, el subsistema de auditoría sólo registraba el nombre del atributo de objeto de Active Directory® o el valor del Registro que se cambiaba; no registraba los valores anteriores y actuales del atributo. Esta nueva capacidad se aplica a los Servicios de dominio de Active Directory, a Active Directory Lightweight Directory Services y al Registro de Windows. Al habilitar Auditoría correcta o Error de auditoría en las subcategorías de "Registro" o "Cambios de servicio de directorio" y configurar las SACL asociadas, surgirán eventos detallados en el registro de eventos para las acciones en estos objetos. Esto se puede realizar mediante los siguientes comandos auditpol:

auditpol /set /subcategory:"Registry" /success:enable
auditpol /set /subcategory:"Directory Service     
    Changes" /success:enable

En cuanto a los cambios del Registro, estos aparecen como eventos con el identificador 4657, tal como muestra la Figura 4.

Figura 4** Antes y después de un cambio en el Registro **(Hacer clic en la imagen para ampliarla)

Esta característica es especialmente útil al efectuar el seguimiento de los cambios en objetos de Active Directory. Para Cambios de servicio de directorio, estos cambios aparecen en un par de eventos con el identificador 5136, tal como muestra la Figura 5. Cada evento tiene el objeto, el atributo y la operación del servicio de directorio en el cuerpo del evento. Para cambios a los atributos con datos existentes, contemplamos dos operaciones: Valor eliminado y Valor agregado. Para los atributos que no se han rellenado, sólo veríamos la operación Valor agregado al escribir datos en dicho atributo. Por ejemplo, cuando se lleva a cabo una operación de modificación satisfactoria en un atributo de un objeto de usuario, como telephoneNumber, Active Directory registra los valores previos y actuales del atributo en entradas detalladas del registro de eventos.

Figura 5** Antes y después de un evento de Cambios de servicio de directorio **(Hacer clic en la imagen para ampliarla)

Si se crea un objeto nuevo, se registran los valores de los atributos que se rellenan en el momento de la creación del objeto. Si se mueve un objeto dentro de un dominio, se registra la ubicación anterior y la nueva (en forma de nombre distintivo). Esta característica "anterior y nueva" está habilitada de manera predeterminada cuando se aplica la configuración apropiada de la directiva de auditoría. Si hay un atributo del cual desea mantener la confidencialidad, como los cambios del número de identificación de empleados, puede excluir específicamente los atributos con tan sólo realizar una sencilla modificación del esquema. Al modificar la propiedad searchFlags del atributo en el esquema a 0x100 (valor 256 -NEVER_AUDIT_VALUE), tal como se muestra en la Figura 6, no surgirá el evento Cambios de servicio de directorio cuando tengan lugar cambios en el atributo.

Figura 6** Exclusión de un atributo de Cambios de servicio de directorio **(Hacer clic en la imagen para ampliarla)

Por último, una de las nuevas características más atractivas en Windows Eventing 6.0 es Suscripciones de eventos. Tal como hemos mencionado, el acceso al registro de eventos y la revisión del mismo constituyen tareas clave de administración del sistema. La nueva capacidad Suscripciones de eventos ofrece un método para reenviar eventos directamente entre sistemas. Las Suscripciones de eventos consisten en un Recopilador de eventos que reúne eventos y Orígenes de eventos que se han configurado para reenviar eventos a hosts especificados. La capacidad de consumir eventos viene proporcionada por el servicio Recopilador de eventos de Windows (novedad en Windows Eventing 6.0), y la funcionalidad de suscriptor está integrada en el servicio Registro de eventos de Windows. Un recopilador se puede configurar para reunir eventos de muchos orígenes de eventos, que pueden ser de los sistemas Windows Server 2008 o Windows Vista.

Todos los datos recopilados de orígenes de eventos residen en un Registro de eventos discreto, denominado Eventos reenviados (ForwardedEvents.evtx), y se administran a través del servicio Registro de eventos en el recopilador. La configuración en ambos extremos (recopilador y origen) es necesaria y se puede automatizar (winrm quickconfig –q en el origen; wecutil qc /q en el recopilador). Es importante tener en cuenta que esta capacidad de suscripción de eventos no fue diseñada para empresas ni para reemplazar sistemas que envían eventos a una base de datos externa.

Un ejemplo de aprovechamiento de esta capacidad puede darse en una pequeña granja de servidores web. Suponga que tiene un conjunto reducido de sistemas asociados con un sitio web particular (incluidos servidores web y SQL Server). Esos sistemas pueden consolidar su información del registro de eventos de seguridad en un único sistema que usa la nueva funcionalidad Suscripción de eventos. Los entornos de mayor tamaño requerirán normalmente un conjunto de herramientas de consolidación del registro de eventos más avanzado.

Servicios de recopilación de auditorías

Dadas todas las nuevas capacidades de Windows Server 2008, la solución real para la administración y el archivado a largo plazo de la información del registro de eventos de seguridad es posible gracias a una base de datos centralizada de la información de auditoría. Servicios de recopilación de auditorías es una característica principal de System Center Operations Manager 2007. ACS ofrece un mecanismo para reenviar, recopilar, almacenar y analizar los datos de eventos de seguridad. Los eventos de seguridad se recopilan prácticamente en tiempo real y se almacenan en un repositorio central de SQL. ACS proporciona a las organizaciones un método para ofrecer acceso con privilegios mínimos a la información de auditoría puesto que no se requiere acceso físico a los sistemas que se están auditando. Veamos cómo funciona ACS.

ACS consta de tres componentes principales. En primer lugar, el Reenviador, que es la parte del agente Operations Manager que transmite los datos del registro de eventos desde el cliente a la infraestructura ACS. Los reenviadores transmiten datos al segundo componente, el Recopilador, que es el agente de escucha del servidor. Los Reenviadores de ACS se conectan a través del puerto TCP 51909 para comunicarse con su Recopilador asignado de una manera segura. Antes de la transmisión, los datos del registro de eventos se normalizan en XML, lo cual significa que la información excesiva se elimina y la información de eventos se resume en campos asignados según la información específica del encabezado y el cuerpo del evento. Una vez que la información alcanza el recopilador, se envía al tercer y último componente, la base de datos de ACS. Esta se convierte en el repositorio para un almacenamiento a largo plazo de la información de eventos de seguridad. Una vez almacenada, la información se puede extraer directamente a través de consultas SQL o se representa mediante informes HTML a través de SQL Server® Reporting Services. ACS ofrece tres vistas predeterminadas, tal como se muestra en la Figura 7.

Figure 7 Vistas de ACS

Desde el punto de vista del rendimiento, un único recopilador de ACS puede administrar un pico máximo de 100.000 eventos por segundo y un máximo continuo de 2500 eventos por segundo. Para facilitar la planeación, un único recopilador de ACS puede ser compatible con 150 controladores de dominio, 3000 servidores miembro o 20.000 estaciones de trabajo, según la configuración predeterminada de la directiva de auditoría. En un escenario real y probado, alrededor de 150 controladores de dominio mostraron un máximo de, aproximadamente, 140 eventos por segundo con un promedio máximo de 500.000 eventos por hora. En apenas 14 días (la configuración predeterminada de retención para ACS), unos 150 GB de datos de eventos de seguridad se almacenaron en la base de datos de SQL Server. Una configuración más agresiva de directiva de auditoría y SACL asociada generará obviamente aún más datos (por hora, por día y en general).

Lo más importante a tener en cuenta es que, con este volumen de datos, nadie tendría capacidad para revisar cada evento en un entorno empresarial normal de gran tamaño. Sin embargo, las organizaciones no deben atemorizarse ante las cifras representadas aquí. La comprensión de los cambios que suceden en su entorno supone el análisis de grandes cantidades de datos.

En este aspecto es donde destaca ACS. Gracias a SQL Server Reporting Services y ACS, puede identificar problemas normalmente ocultos en el registro de eventos de seguridad de la misma manera y con la facilidad que identifica los eventos con codificación en colores que se encuentran en el registro de eventos de aplicación. Aunque ACS incluye un conjunto de informes predeterminados, ampliarlos para las necesidades específicas de su entorno es bastante sencillo.

Considere el siguiente escenario: debido a la importancia de las confianzas externas en el entorno, la administración nos ha solicitado desarrollar un informe que detalle la creación de confianzas de Active Directory. Después de llevar a cabo cierta investigación, sabemos que se crea un objeto trustedDomain en el contenedor cn=System dentro del contexto de nomenclatura de dominio específico en Active Directory cuando se crea una confianza. Después de editar la SACL en este contenedor para auditar la creación correcta de cualquier objeto del dominio de confianza, tenemos la capacidad de capturar eventos de seguridad cada vez que se crea un objeto de este tipo. Esto se representa en un evento 566 en el registro de eventos de seguridad del DC en el que se lleva a cabo la creación de la confianza. A continuación, podemos escribir una consulta SQL sencilla para recuperar esta información desde ACS:

select * from AdtServer.dvAll 
where EventID = '566' and
String05 like '%trustedDomain%'
order by CreationTime desc

Para reunir esto en un informe, use la versión de Visual Studio® 2005 que se incluye con SQL Server 2005 Reporting Services, puesto que se ofrece específicamente para el desarrollo de informes. Una vez que finaliza el asistente, será muy fácil crear informes similares al que aparece en la Figura 8. Además, cualquier cambio en el entorno que se pueda representar en el registro de eventos de seguridad se puede resumir en un informe similar de aspecto muy profesional.

Figura 8** Informe de ACS de ejemplo **(Hacer clic en la imagen para ampliarla)

Desarrollo de un plan de auditoría

Ahora que entendemos los retos, así como los aspectos legales y técnicos de las auditorías, ¿cómo deben los administradores de TI enfocar el desarrollo de un "plan de auditoría" para su organización? Al igual que la mayoría de las cosas, el desarrollo de una directiva de auditoría integral es un proceso que comprende varios pasos. El primer paso consiste en determinar lo que se debe auditar. Esto incluye el análisis de su entorno y la determinación de los tipos de eventos y cambios que deben generar auditorías. Esto podría incluir elementos sencillos, como los bloqueos de cuenta, los cambios de grupo con distinción, la creación de confianzas o cambios más complejos, como las modificaciones de elementos de configuración dentro de las aplicaciones de su entorno. La clave en este caso es que la administración debe implicarse en la determinación de los elementos que deben formar parte de un plan de auditoría. Este ejercicio necesita realizarse en papel y debe repetirse a intervalos regulares, no sólo después de incidentes significativos.

El segundo paso implica la identificación de cómo la información de auditoría relativa a cambios específicos se devuelve en forma de eventos de seguridad. La información de auditoría es, en ocasiones, críptica y no fácilmente legible. Antes de la implementación, deben establecerse las correlaciones entre los eventos de seguridad y varias acciones para entender lo que realmente significan los eventos de seguridad. Después de un incidente no es el mejor momento para averiguar las relaciones de los eventos con las acciones.

El tercer paso es el momento de la verdad que se produce cuando implementa su directiva de auditoría y las SACL. Tal como se ha mencionado anteriormente, necesitará definir la configuración de la directiva de auditoría (para habilitar la generación de eventos de seguridad) y las SACL (para generar las trazas de auditoría de acciones asociadas) en el directorio, el sistema de archivos y el Registro con el fin de obtener una visión completa de los cambios en estas áreas.

Todo esto nos lleva al cuarto y último paso: la recopilación, los desencadenadores y el análisis. Según el tamaño y las necesidades de su organización, esto se puede realizar con las capacidades nativas de Windows Server 2008 o con soluciones avanzadas, como la funcionalidad Servicios de recopilación de auditorías de System Center Operations Manager. Un error común cometido por la mayoría de las organizaciones es configurar sólo la directiva de auditoría sin definir las SACL. El último paso abarca la implementación de una solución de tecnología para generar informes y compartir datos con las partes interesadas de la organización. Como se mencionó anteriormente, la mayoría de las organizaciones tienen una entidad establecida responsable de la seguridad, y un plan de auditoría se debe estructurar en consonancia con los elementos existentes de la organización para ser efectivo. La clave de este paso final es recopilar y presentar la información de una manera significativa para todos los responsables de forma que comprendan los cambios en el entorno.

La mayoría de las organizaciones de TI esperan a que se produzca un evento significativo para pasar de considerar un plan de auditoría integral a realmente requerir uno. Windows Server 2008 ofrece mecanismos de mejora para la recopilación y el análisis de los datos de eventos de seguridad en comparación con plataformas anteriores. Las tecnologías avanzadas de recopilación y de generación de informes como ACS exponen los problemas que solían quedar ocultos por el volumen de eventos y la distribución, con lo cual estos cambios son obvios al instante.

Al igual que ocurre con la mayoría de los problemas de TI, el proceso es el reto principal. La configuración y el análisis adicionales siempre son necesarios para capturar lo que los administradores de TI esperan. Así pues, el desarrollo de un conocimiento profundo de los requisitos de su entorno y de las capacidades de la plataforma Windows le permitirá superar estos retos en el futuro. Suerte.

Rob Campbell y Joel Yoker Rob Campbell es especialista técnico senior y Joel Yoker es consultor senior en el equipo Microsoft Federal. Joel y Rob se dedican a desarrollar e implementar soluciones de seguridad para clientes del gobierno de Estados Unidos.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.