Thank you for the reply .. another doubt. Let assume that an S update is load on the IPS. In case of new signature, are new Signatures enabled by default ?

It can happend that some signatures enabled by the customer will be disabled after the S update ? In case of disabled S in ca be that the update will enable them ?

To answer this it is best if I give you a brief explanation of the internal workings of the sensor.

If you execute "show conf" on the sensor you will see multiple sections of configuration.

Each section starts with "service

The configuration is not stored on the sensor as a single file.

Instead each of these sections of "show conf" is actually a representation of an XML configuration file stored on the sensor. These XML files are the real configuration of the sensor.

The "service

Let's first look at the "service host" section of the configuration.

If you were to log in through a service account and switch to the /usr/cids/idsRoot/etc/config directory of the sensor you would see a "host" directory.

Within that "host" directory you would several files.

The "typedefs.xml" file is a listing of all of the parameters that can be used in the host configuration, as well as what the limits are.

The "default.xml" file is a listing of any default values for any of the parameters in the "typedefs.xml" file.

The "typedefs.sig.xml" and the "default.sig.xml" are just digital signatures for the other files so the sensor can verify they have not been altered.

The "current.xml" file is where your modifications to the "service host" configuration are store3d. So your sensors IP, default gateway, etc.. are stored in this file.

When you execute "show conf" the CLI will read in this XML file, and dynamically generates CLI commands from the XML.

The "service signature-definition sig0" follows a slightly different method used for the "service

If you went into the service account and switched to the /usr/cids/idsRoot/etc/config/signatureDefinition directory you would see a typedefs.xml, default.xml, typedefs.sig.xml, and default.sig.xml file similar to that used for the host configuraion.

BUT you would not see a current.xml file, and would instead see a instances directory.

Inside this the instances directory is the "sig0.xml" that is for the "service signature-definition sig0" portion of your configuration. If you had created a "sig1" then there would also be a "sig1.xml" file in the instances directory.

This "sig0.xml" is where all of your signature modifications are stored.

So what happens to these files when a Signature Update is installed?

The Signature Update will change the "default.xml" and "default.sig.xml" for the signature-definition section.

It will add new signatuers into that default.xml file, and will modify existing signatures in that default.xml file.

The Signature Update will NOT change the "sig0.xml" instance file.

So any tunings you have made that are seen in the "show conf" will stay the same and NOT be changed by the Signature Update.

So the Signature Update will change the default values for the signatures, but will not change anything that you have specifically set in the configuration.

Now lets look at some of your other questions:

Will "new" Signatures be enabled by default?

This is a determination made the signature team on a per signature basis.

MOST new signatures will be enabled (and unretired) by default.

However, there will be occasions when the signature will release a new signature that is Disabled by default (and possibly even retired).

This can happen if the signature team released a new signature for an old vulnerability that only affects a small number of customers running an old operating system inside their network.

It could also be that the signature detects normal traffic rather than attack traffic (like a signature P2P traffic). Only customers who to prevent that type of traffic would enable the signature, so it is disabled by default.

What happens if a customer enables a signature that Cisco disables in a later Signature Update.

If the change shows up in "show conf", then even though Cisco might change the default to disable it is the user setting of enable that will be used.

HOWEVER, understand that there are 2 parameters that are actually used to turn the sig ON. The signature must both be Enabled and UNRetired for it to be ON. So if in your "show conf" you have it as Enabled, if the next Signature Update both Disables and Retires the signature then the signature will be a Enabled but Retired state and will be internally turned OFF. So be sure to set the signature to both Enabled AND Unretired if you don't want future Signature Updates to turn it OFF.

NOTE: Engine Updates, Major Updates, Minor Updates, and Service Packs also contain Signature Updates within them. They generally operate the same as the Signature Update and do not change the "sig0.xml" of signature-definitions and "current.xml" of the other service configurations. So your tunings are kept in place during the upgrade.

HOWEVER, there are situations where the updates sometimes DO have to Convert the sig0.xml and current.xml files to work with the new version. On occasion a parameter has to be inside the configuration or the parameter name is changed. In these cases the upgrade script will automatically convert your old configuration to work with the new configuration. The conversion will attempt to keep all of your previous configuration, and only in very rare cases would something from your old configuration be removed.

NOTE: It is always best to save your sensor configuration before doing these types of upgrades.