I am reviewing a security configuration for Workstation security log review, we have an environment wherein the logs are captured and sent to ArcSight tool for analysis. However, how do we validate from the Domain Controller policies or Workstation logging settings to ensure the right security events from the workstation and user log-ins are being monitored.

The review involves other configurations as well for Workstation firewalls, HIDS and DLP settings etc. which are being addressed separately.

  • I'm not exactly sure what your question is. ArcSight is only as good as the logs. These are collected by a windows unified connector which is a standard arcsight connector. As long as windows is logging it the connector should get it. Once you have set up the connector you can open a channel and see all the events that are coming in from the connector and create custom ArcSight content from that channel focusing on the particular use cases you require. – TheJulyPlot Jan 7 '16 at 15:14

It ultimately depends on what you mean by "being monitored".

Here is a list of checks that you may need to make:

- Does the workstation respect its logging / policy configuration? Normally you should be able to trust that this is the case, i.e. that it raises the events that you expect given the configuration. There might be surprises in store though: I experienced the case where failed login was not getting logged - because we were using smartcards and the smartcard integration with Windows did not allow this event to be raised (the Bad PIN login failure was handled inside the smartcard and not exposed to the operating system)

- Has the workstation got the right logging / policy configuration? This depends on your requirements. I would verify that the configuration is applied correctly using a combination of provoking a subset of events that it is easy to provoke (successful login, failed login, for example), and examination of the security policy in the workstation local policy.

- Are workstation events being centralised to ArcSight? If you create an Active Channel from the smart connector that is monitoring the workstations, you should be able to see whether there are any events originating from each workstation.

- Is ArcSight filtering any events out at the point of import? Examine the smart connector configuration in ArcSight: you can check this from the Default tab of the configuration, then the Filter tab.

- Is ArcSight configured to react to particular events or chains of event? This depends on what correlation rules you have configured. The rule Conditions need to encompass workstation events. Only you know what you need to monitor. I presume you have been through the process of deciding this and then defining the correlation rules accordingly. If you want to test your rule set independently of the operational system, using synthetic events, then I believe that ArcSight provides the means to do this in a "sandboxed" fashion.

| improve this answer | |

When onboarding device types in Arcsight, I ask customers to provide specific requirements for the log events they're trying to observe. These requirements should be driven by their infosec policies. For each of the requirements, I require them to be able to generate a sample of the log entry, or while being monitored, to generate the event which would cause the log entry (so that I can see the sample event).

In my project documentation, I include the policy reference, the requirement, the sample entry and an example of how the log appears and is parsed in Arcsight.

This information is needed by the SIEM team to properly correlate events on the new data source, or to check for the absence of the events. It's also useful for auditors to know what they're looking for when they're trying to connect the policy requirement with the project's requirements to the resulting log entries and eventually reports, alerts and dashboards.

In my experience, there is always remedial work required in adjusting the event source log configuration so as to capture the events the customer is looking for or to tune down the insane verbosity of some kinds of logs.

As an auditor, I would assume that if there is no evidence collected in the onboarding project that the logs were captured even once, I think it's safer to assume that nobody actually ever checked and there will be gaps... the onus should be on the customer to be able to show that the events are present, not on the auditor to prove they're absent.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.