Device Status Monitoring Pack
Appreciate that there are some threads that talk about Device Status Monitoring (DSM), but we have released a content pack to help you get started in ensuring that you always get your event logs. This is aimed more at people that are new to ArcSight and just getting started, as I'm sure that the more seasoned of you will already have something setup.
The success of any SIEM system relies on receiving events from the respective in scope source devices and servers. Without any events, the SIEM platform effectively becomes useless. Part of setting up a good SIEM system is creating mechanisms to ensure that these events are received and the most effective approach to do this is by using the Device Status Monitoring (DSM) capability built-in to the ArcSight platform.
This content pack utilises the DSM capability to track and alert on any event sources that stop sending events, so that you can take the appropriate action to re-establish the event flow. The pack also contains mechanisms to detect servers/devices that have potentially been removed from the network.
+ Attached is the user guide, and the complete pack is available from our website http://www.edgeseven.com/resources.html.
+ This also ties into our blog (http://totalsiem.blogspot.com), where we are currently discussing the "Golden Rules of SIEM"
Hope you all find this useful ... please do provide feedback 😉
Chances are that you are using an older version of ESM ... more than likely 4.5. We developed the pack on v5sp2, and should really only be used on a system with the same version, although it should work on all v5 systems.
Have you been using this for a while? Have you had any issues with device status monitoring simply not functioning (even though configured)?
We have noticed this issue particularly with all the Windows Unified Connectors, but also with one of our syslog connectors.
ArcSight support is, as usual, at a loss - I am curious if we are the only user whos connectors stop sending the device status monitoring.
Typically if the DSM events stop sending, they will repair themselves (without any intervention) and continue sending within 1-2 hours at the most (event data functions .
Good guide and useful content in your blog! It is odd that ArcSight doesnt include something like this as canned content
Also FYI: there was also another presentation that is extremely useful in this area given by Harry Halladay and Wells Fargo at the protect conference this year. It allows you to set multiple 'outage' criteria (such as timeout, warning, critical, and more), with individual settings per event feed, in a single active list. We have tweaked it quite a bit to remove some extra content that wasn't necessary to us and plan to rebuild all the static DSM we have using the method listed in their doc. You can easily use the DSM events you mention instead of the CRES events they list.
We also monitor and test a number of the 'key' functions of our SIEM to ensure they are functioning. We have to insert specific event types at regular intervals to do this, which can be accomplished via signature products (IDS/AV), or inserting raw syslog events into a syslog connector, or creating your own flex connector...
We test and are notified of issues regarding:
Cases (hourly - via inserted events and a rule)
Notifications (hourly- via inserted events and a rule)
Active lists (hourly- via inserted events and a rule)
Rules (hourly- via inserted events and a rule)
Trend runs (hourly)
Sometimes one of those functions (most commonly for us - reports and notifications and periodically cases) will cease to function and you wouldn't know unless you were testing it intentionally.
Many thanks for yours and everyone else's feedback ... its really appreciated.
We've been using DSM since it was first introduced as a connector feature.
Yes, we've seen something similar ... however mostly in the older versions of the connector (pre version 5) ... and specifically around the WUC connector. Never managed to find a resolution, but a restart of the connector fixed it in most instances.
We'll certainly look into Harry's presentation.
We are also working on an updated version, that is more advanced at determining whether or not the device has actually stopped sending events.