Yes, both 5.x and 6.x versions of the sensor support SDEE for monitoring of events.
SDEE clients support by Cisco:
CLI - uses an internal SDEE subscription when you run "show events"
IDM - uses an SDEE query when using the Events window in the Monitoring section
IEV - uses an SDEE subscription
SecMon (part of VMS) - uses an SDEE subscription
CS-MARS - uses an SDEE subscription
CIC - uses an SDEE subscription
CW SIMS - (an OEM from NetForensics) uses an SDEE subscription
The CLI, IDM, and IEV are available at no additional charge. CLI and IDM are targeted at debugging and not for general monitoring. IEV is targeted for monitoring small deployments of sensors.
SecMon(VMS), CS-MARS, CIC, and CW SIMS can all be purchased from Cisco. They are targeted at enterprise customers needing to monitor larger numbers of sensor as well as other security devices.
Some users have actually written their own SDEE clients. And I have heard that there may be some freeware SDEE clients out there (though I have never looked). And there are also other companies selling monitoring tools with SDEE clients that can connect to the sensors and monitor them through an SDEE subscription.
So how does the sensor have to be configured?
Just run the setup command and answer all of the standard questions (IP, gateway, etc..)
For SDEE one of the key things is to ensure that your SDEE client's IP Address (or Network) is in the Access List that you configure during setup.
Then either configure your SDEE client to connect with the "cisco" username and password, or create a special user account specifically for your SDEE client.
There is nothing else that needs to be configured on the sensor.
The SDEE server on the sensor is always running. You SDEE client just needs to be able to connect (allowed by the access list), and authenticate (with the username and password).
>>CS-MARS - uses an SDEE subscription
One of the things I've noticed with the latest version of CSMARS is that it doesn't use persistent connections to the IPS sensors, but rather connects on a schedule. Does that preclude CSMARS from using the SDEE subscription model? The documentation I have suggest that this does not preclude CSMARS from using a subscription, but I'm curious.
A persistent connection is not required for using SDEE subscriptions.
When a subscription is started the server will return a subscription ID to the client.
This subscription ID is not tied to that connection.
The Client just needs to use that subscription ID in any GET requests for that subscription.
So a Client using even HTTP 1.0 with only a single GET per connection can still be used for an SDEE subscription.
MARS's method of closing a connection after retreiving a chunk of data, and then opening a new connection for a GET of new data is fully supported.
In fact we have built specific options into SDEE to handle error situations that can specifically occur when using multiple connections for a single subscription.
This also means that a device like MARS that is rebooted can store off the subscription ID before reboot, and then execute a new connection after reboot continuing the same subscription with that subscription ID.
IPS software version 5.0 communicates events using the Security Device Event Exchange (SDEE) protocol; however, version 5.0 still uses RDEP for communicating configuration (IDM) and IP log information
The Version 4.x RDEP contains 3 different types of communcations.
- Event Subscriptions/Queries (alerts, status, and error messages)
- Execution Control Transactions (adding blocks, adding IP Logs, reset, etc..)
- Configuration Control Transactions (changing sensor configurations)
In Version 5.x and 6.0 the SDEE server was added for Subscription and Queries of events.
All events quereied through the SDEE server will be in the new SDEE format with CIDEE extensions.
However, RDEP Subscription/Queries are still supported, but the events queried through RDEP will be in the older RDEP format and will NOT contain any new SDEE fields that were added in 5.x and 6.0.
(NOTE: This RDEP support for subscriptions and queries will be removed in a future IPS version. The support in 5.x and 6.0 was put in so that users could have a couple of years to transition from RDEP to SDEE for event monitoring)
Version 5.x and 6.0 still use the Version 4.x Execution Control Transactions, and have added new ones as well.
Version 5.x and 6.0 use a new set of IDCONF Control Transactions for managing configuration. The version 4.x Configuration Control Transactions are not supported in 5.x and 6.x.
Is there any new documentation that describes the [new] specification. I have some older stuff, but I believe it must be out of date.
The date on the SDEE spec I have is:
August 20, 2003
I believe that is the latest SDEE specification.
However, understand that SDEE is really just a base that can be used by any company. SDEE allows for extensions that can be company specific.
For Cisco those extensions are in the "Cisco Intrusion Detection Event Exchange (CIDEE) Standard". CIDEE will be rev'd any time we add new fields.
If enough other companies want to use the same fields, then they would eventually be added to the SDEE standard for use by all companies.
So what you need is the latest CIDEE specification. I just checked on CCO and it does not appear to be updated for the latest 6.0 changes.
I would suggest contacting the TAC and requesting a copy of the latest CIDEE Schema.