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.