Registrazione ArcSight - Workstations Windows

In definitiva dipende da cosa intendi per "essere monitorato".

Ecco un elenco di controlli che potresti aver bisogno di fare:

- La workstation rispetta la sua configurazione di registrazione / criterio? Normalmente dovresti essere in grado di credere che questo è il caso, cioè che solleva gli eventi che ti aspetti dalla configurazione. Ci potrebbero essere delle sorprese in sospeso: ho sperimentato il caso in cui il login fallito non veniva registrato - perché stavamo usando le smartcard e l'integrazione con smartcard con Windows non permetteva di sollevare questo evento (l'errore di accesso del PIN errato veniva gestito all'interno della smartcard e non esposto al sistema operativo)

- La workstation ha la corretta configurazione di registrazione / criteri? Ciò dipende dalle tue esigenze. Vorrei verificare che la configurazione sia applicata correttamente utilizzando una combinazione di provocazione di un sottoinsieme di eventi che è facile provocare (login riuscito, login fallito, per esempio), e l'esame della politica di sicurezza nella politica locale della workstation.

- Gli eventi workstation sono centralizzati su ArcSight? se si crea un canale attivo dal connettore smart che sta monitorando le workstation, si dovrebbe essere in grado di vedere se ci sono eventi provenienti da ciascuna workstation .

- ArcSight filtra gli eventi nel punto di importazione? Esamina la configurazione del connettore smart in ArcSight: puoi verificarlo dalla scheda Predefinito della configurazione, quindi dalla scheda Filtro.

- ArcSight è configurato per reagire a eventi o catene particolari di eventi? Ciò dipende dalle regole di correlazione che hai configurato. La regola Le condizioni devono comprendere eventi di workstation. Solo tu sai cosa devi monitorare. Presumo che tu abbia passato il processo per decidere questo e quindi definire di conseguenza le regole di correlazione. Se vuoi testare il tuo set di regole indipendentemente dal sistema operativo, usando eventi sintetici, allora credo che ArcSight fornisca i mezzi per farlo in un modo "sandboxed".

Quando si collegano i tipi di dispositivo in Arcsight, chiedo ai clienti di fornire requisiti specifici per gli eventi di registro che stanno cercando di osservare. Questi requisiti dovrebbero essere guidati dalle loro politiche infosec. Per ciascuno dei requisiti, richiedo che siano in grado di generare un campione della voce del registro o, mentre è monitorato, generare l'evento che causerebbe la voce del registro (in modo che possa vedere l'evento di esempio).

Nella documentazione del mio progetto, includo il riferimento alla politica, il requisito, la voce di esempio e un esempio di come il registro appare e viene analizzato in Arcsight.

Queste informazioni sono necessarie al team SIEM per correlare correttamente gli eventi sulla nuova origine dati o per verificare l'assenza degli eventi. È anche utile che i revisori sappiano cosa stanno cercando quando cercano di collegare i requisiti della politica con i requisiti del progetto alle voci di registro risultanti e alla fine segnalazioni, avvisi e dashboard.

Secondo la mia esperienza, è richiesto un lavoro di riparazione always per regolare la configurazione del log sorgente degli eventi in modo da catturare gli eventi che il cliente sta cercando o per ridurre la verbosità insana di alcuni tipi di log .

In qualità di auditor, suppongo che se non ci sono prove raccolte nel progetto di onboarding che i log siano stati catturati anche una sola volta, penso che sia più sicuro presumere che nessuno abbia mai verificato e che ci siano delle lacune ... l'onere dovrebbe essere sul cliente per essere in grado di dimostrare che gli eventi sono presenti, non sull'auditor per dimostrare che sono assenti.