The sensors must each be independantly updated with the sensor update file.
The CSPM must also be updated with the CSPM update file.
The sensor update will make all the necessary binary changes for the new signatures.
It will also add these new signatures to the packetd.conf file, signature file, and other internal configuration files.
So if you install the sensor update, the sensor is now monitoring for the new signatures without any changes being made to CSPM.
The sensor update can be installed manually with the "-I" option, or you can setup idsupdate which will on a scheduled basis download new sensor updates from an ftp server and execute the updates itself with the "-I" option.
The CSPM update, adds configuration files to CSPM so it knows about the new signatures. This is so that the Event Viewer can put the proper name to the signatures, and CSPM can generate packetd.conf files with the new signatures.
There is no automatic update process with CSPM.
-----------------------------------------------------------------------------
What happens if I update my sensors but not CSPM?
Immediately after the update the sensor will start monitoring for the new signatures and generating alarms if it sees any. If you type nrvers on the sensor you will see that the new signature version is running. CSPM will receive the alarms, but the Event Viewer in CSPM won't be able to put a name to them, and you won't be able to select the alarm and look up a description in the NSDB.
BUT the next time you may make a change in CSPM and hit the Approve button, CSPM will come back and tell you that the versions do not match. You have the option of pushing the configuration even though the versions don't match. The problem is that CSPM has generated a new packetd.conf without these new signatures. So as soon as you hit approve and that packetd.conf file is sent across, the sensor will STOP alarming for those new signatures, and you might as well not have applied the signature update to the sensor.
--------------------------------------------------------------------------------------------------
What if I apply the signature update to CSPM, but not my sensors?
CSPM now knows about the new signatures.
Each sensor has a version field in CSPM.
You should always try to keep this in sync with what is actually loaded on the sensor, it does not change what is loaded on the sensor.
- If the version field in CSPM for that sensor is correct for the sensor (let's say S15), and we have a newer version (let's say S17) on CSPM itself then CSPM will be smart enough to know to create a packetd.conf file that only has signatures the sensor will know about (S15 sigs in this example), it will not place in sigs that the sensor does not know about (S16 and S17 sigs in this example).
- If the version field in CSPM for that sensor(let's say has S15) , however, is changed to match the latest version of sigs on CSPM (let's say S17), but the update was not loaded on the sensor (S17 not loaded on sensor) then you wind up in a weird situation. If you hit update and approve a new configuration for the sensor then CSPM will generate a packetd.conf file with the new signatures (S16 and S17) that the sensor does not actually know about. CSPM will warn you , but will let you push that configuration to the sensor. The sensor will IGNORE these new sigs (S16 and S17 sigs), and may even create errors in errors.packetd. The sensor will not monitor these new signatures unles it has had it's binaries upgraded to deal with the new signatures.
------------------------------------------------------------------------------------------
So what am I supposed to do?
1) Install the CSPM updates on CSPM. ( Refer to CSPM signature update installation steps 1-6 of the readme)
2) Install the sensor updates on the sensors. (Refer to CSPM signature update installation step 7, which actually means to run all stpes for the sensor update installation or use the idsupdate automatic update utility)
3) Now sync CSPM up with your sensors so that the sensor version field in CSPM for each sensor matches what is actually on the sensors.
(You can do step 3 manually by going to each sensor in CSPM and selecting the correct version that matches what is actually installed on the sensor, or you can do CSPM signature update installation step 8)
This queries each sensor to find out what version is installed and then automatically changes the version field in CSPM for each sensor to match what is installed on each sensor.
optional 4) If you want you can then Update and approve each sensor. The new signatures are already on each sensor if you have independantly updated each sensor (which you should have done), but by approving ech sensor you are just ensuring that the sensor configuration is in sync with what you see in CSPM. You could have also made changes prior to updating and approving such as changing severities or filters for the new signatures.
------------------------------------------------------------------
So you see, CSPM does not actually update the sensor. It just pushes configuration files. It's your job to update the sensors (or use idsupdate to help do it automatically), and then sync CSPM with the updated sensors. Then CSPM can push out configurations that match what is loaded on the sensors.
Many people thought the CSPM actually pushed signature updates out to the sensors, but unfortunately it can not. But rest assured that this customer requirement has been documented as an enhancment to our IDS management products. I can't comment on whether or not it will be fulfilled in the next version since I don't work on the IDS management products team (I work on the IDS sensor product team).
