IDS MC doesn't act as a server who can listen on RDEP protocol that is to say no other application can make a rdep connection to the IDS MC. Rather it acts kind of like a client when making RDEP connection to sensor.
I hope this answers your question. Thanks,
So how is an organization supposed to get a data feed from the VMS?
I cant see Cisco believing that Enterprise customers will not have in place reporting systems (i.e. netForensics, e-Security, Intellitactics) and want to get the log data retrieved from the sensors for use by their own systems.
Does Cisco publish any information as to how to accomplish data retrieval from the IDSMC?
In the case of NetForensics 3.x, there is a specific agent for CSIDS4 which works just like the VMS server itself - that is, you tell NF how to contact each sensor (appliance, blade, whatever) and it contacts them directly to poll for the data. This of course requires an NF license for each sensor. This stands in contrast to how NF handles the CSA data, where they have an agnet that lives on the VMS server and takes the aggragated logs from there and pipes them to NF, only using one host license in the process.
If you need assistance configuring NF to get to your sensors, I can help - you may wish to do this out-of-band...
Contact the customer support group for the vendor of your product.
FYI, I know Intellitactics has an RDEP client for NSM, just in case your wondering.
I'd say it's safe to assume any other vendor that claims Cisco IDS compatibility will have developed one as well...
That is the rub. Our reporting solution does not on the public internet (and we'd like to keep it that way).
Yet IDSMC also acts as a client and runs no RDEP server, so even intellitactics could not get data from it because it runs as a client.
True enough, the NSM RDEP Listener and other "RDEP Clients" aren't going to help you.
Why have your VMS/IDSMC system act as an RDEP Server though when your sensor(s) are already doing this? Why not instead build your own in-house RDEP Client?
After all, Cisco has made the RDEP specs available to anyone with a CCO login (which we're using right now to access the NetPro Forum...)
You'll find the RDEP specifications here:
OK, I'm working with akahomer. here is the deal. With the current (for 9 more days) Director platform, the "director forward" utility is used to send the centralized event data else where. If you wrote a system around this way of life, you have a rude awakening with the new version, as there is no way to get it out of the centralized data store (outside of NF or Info Center). The real issue here is not being able to retrieve event data from a central point such as VMS. We do not want to have dual feeds to our sensors (one VMS feed for mgmt. and one feed to get the events) If we can focus on that, it would be great.
The older Unix Director platform could act as both a client for receiving alarms as well as a server for passing alarms up to a higher level management station.
The current version of Security Monitoring Center (monitoring portion of VMS) lacks this functionality. It can receive alarms but is not able to forward them on to another management station.
So what are the options if you are moving to Security Monitoring Center from Unix Director and you used to use the forwarding functionality?
1) The current version of Security Monitoring Center does have the ability to extract alarms from the database into a text file. This text file can then be imported into another management station. You would schedule this export to happen as often as you wanted, and then run a separate command to upload the data into another management station somehow:
2) Use a monitoring tool other than Security Monitoring Center. The IDS Management Center and the Security Monitoring Center do not have to be run together. You can continue to use IDS Management Center for configuring the sensors, and use NetForensics or even your own company built RDEP Client to pull the events.
SIDE NOTE: Security Monitoring Center uses RDEP for pulling events from the sensor, but the current version of IDS Management Center does not use RDEP for configuring the sensor. IDS MC configuration is currently done through a SSH connection. So Security Monitor makes HTTP(s) connections to the sensor while IDS MC makes SSH connections to the sensor.
It my above statements I specifically use the word "current" versions. This is because that the VMS development teams have heard the requests from users like yourselves. They are making modifications to the software for the next version currently in development.
If you need to find out the new features being added and scheduled release dates then please contact your Cisco Sales Representative for more information.