registro de ArcSight - Estaciones de trabajo de Windows

En última instancia, depende de lo que quieres decir con "ser monitoreado".

Aquí hay una lista de los cheques que puede necesitar:

- ¿La estación de trabajo respeta su configuración de política / registro? Normalmente, debería poder confiar en que este es el caso, es decir, que genera los eventos que espera dada la configuración. Sin embargo, podría haber sorpresas en la tienda: experimenté el caso de que el inicio de sesión fallido no se estaba registrando, ya que estábamos usando tarjetas inteligentes y la integración de la tarjeta con Windows no permitió que se produjera este evento (el error de inicio de sesión con PIN incorrecto se manejó dentro de la tarjeta inteligente y no expuesto al sistema operativo)

: ¿Tiene la estación de trabajo la configuración de políticas / registro adecuada? Esto depende de sus requisitos. Verificaría que la configuración se aplique correctamente mediante una combinación de provocar un subconjunto de eventos que sea fácil de provocar (inicio de sesión exitoso, inicio de sesión fallido, por ejemplo) y análisis de la política de seguridad en la política local de la estación de trabajo.

: ¿Se centralizan los eventos de la estación de trabajo en ArcSight? Si crea un canal activo desde el conector inteligente que está monitoreando las estaciones de trabajo, debería poder ver si hay eventos que se originen en cada estación de trabajo. .

: ¿ArcSight filtra algún evento en el punto de importación? Examine la configuración del conector inteligente en ArcSight: puede verificar esto en la pestaña Predeterminado de la configuración, luego en la pestaña Filtro.

: ¿ArcSight está configurado para reaccionar ante eventos o cadenas de eventos en particular? Esto depende de las reglas de correlación que haya configurado. Las condiciones de la regla deben abarcar los eventos de la estación de trabajo. Solo tú sabes lo que necesitas monitorear. Supongo que ha pasado por el proceso de decidir esto y luego definir las reglas de correlación en consecuencia. Si desea probar su conjunto de reglas independientemente del sistema operacional, usando eventos sintéticos, entonces creo que ArcSight proporciona los medios para hacer esto de manera "de espacio aislado".

Al incorporar tipos de dispositivos en Arcsight, les pido a los clientes que proporcionen requisitos específicos para los eventos de registro que intentan observar. Estos requisitos deben ser impulsados por sus políticas infosec. Para cada uno de los requisitos, les pido que puedan generar una muestra de la entrada del registro, o mientras están siendo monitoreados, para generar el evento que causaría la entrada del registro (de modo que pueda ver el evento de la muestra).

En la documentación de mi proyecto, incluyo la referencia de la política, el requisito, la entrada de muestra y un ejemplo de cómo aparece y se analiza el registro en Arcsight.

El equipo de SIEM necesita esta información para correlacionar correctamente los eventos en la nueva fuente de datos, o para verificar la ausencia de los eventos. También es útil para los auditores saber qué buscan cuando intentan conectar los requisitos de la política con los requisitos del proyecto a las entradas de registro resultantes y, finalmente, a los informes, alertas y paneles.

En mi experiencia, hay un siempre trabajo de remediación necesario para ajustar la configuración del registro de la fuente del evento a fin de capturar los eventos que el cliente está buscando o afinar la locura de algunos tipos de registros. .

Como auditor, asumo que si no hay evidencia recopilada en el proyecto de incorporación de que los registros se capturaron una sola vez, creo que es más seguro suponer que nadie realmente verificó y habrá vacíos ... la responsabilidad debe estar en el cliente para poder demostrar que los eventos están presentes, no en el auditor para demostrar que están ausentes.