- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Remedy Integration
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
We could use some trouble ticket integration with Peregrine Service Center, but I'm concerned about some things that RSA still can't address... i.e. I need to know if a monitored device suddenly stops reporting. Can't figure out how to do that yet.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Easy to do;
enVision already has a basic correlation rule based upon the Packager service that can tell you this - NIC023. This basic rule will most likely have to be tweaked for your environment, and it is not always 100% reliable.
There are more accurate ways of telling when a device has stopped logging...I am playing with some ideas at the moment.
Mark Nadir.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
I don't know why I keep being told to use an alert. Perhaps I'm not being clear. I do not want an alert. I want a report that shows the time stamp of the last record received from a device. A report. Not an alert.
Reasoning:... we have hundreds of Macintoshes reporting to enVision. They are all DHCP clients. When the IP address has changed, the old IP address remains in enVision. The local collectors have a limit of 1024 devices. With hundreds of Macs changing their address we soon exceed said limit. A report that showed the last date stamp would enable me to remove the very stale devices.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Hi Mike:
Probably because you can create/run a report that shows the number of times this alert has fired?
It makes sense to run a report based upon the firing of the correlation rule. Every time an alert is triggered, that event is also logged to the IPDB.
Running a report to show the last time any device has logged takes a bit trial and error. For you to know precisely when this occurred you would have to go into the IPDB directory itself and look at the timestamps on the files.
Having a report that provides details on the number of times the Correlation Rule NIC023 has fired is a lot easier than having to do this manually.
Why would this not be feasible for you?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Mike,
See if creating a rule similar to the NIC023 works. For instance, create a correlated alert that contains a Circuit that looks for the NIC event ID 508100.
Packager, <source>,<username>,<obj_type>,<obj_name>,<action> Detail: <pid>: Device <laddr> (<device>): <count> messages processed <@msg:*PARMVAL($MSG)><@level:*SYSVAL($LEVEL)>
Then you can create a view specifying that you want an alert to be generated once both event ID 508100 and the Device Type X (such as Macintoshes) are correlated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
A new thread should have probably been made for this question, but, I'll post here anyway. This might not get you 100% of what you want but with a little report tweaking on your end hopefully it will be helpful none the less. Please see the attached doc.
