The sensor appliance supports creation of custom signatures, but this is not supported on the IDSM.
The IDSM does support the following (each of which can be configured directly in CSPM).
Tuning of some of the Cisco Signatures
Creation of TCP and UDP Connection Sigs
Creation of Custom String Matching Sigs for TCP Sesssions (not as versatile and full featured as the custom signatures supported on the appliances)
No sure what you are asking about "what code base"?
The Cisco signatures for the IDSM are coded to look for the same things as the Cisco signatures for the appliances. However, on the appliances the new signatures can be easily created like custom signatures, but on the IDSM the source code has to be modified and recompiled. An IDSM and an appliance of the same S level (Signature Update level) can usually monitor for the same signatures (with only a few exceptions). But because of the recompiling on the IDSM, the IDSM Signature Update usually lags begind the update for the appliances.
As for buffer threshold, the IDSM uses postoffice for sending alarms to CSPM.
Postoffice has an internal buffer in RAM of up to 1000 alarms. So if CSPM goes down the postoffice can buffer the next 1000 alarms waiting for CSPM to come back up. NOTE: The buffer is in RAm and not on the harddrive, so rebooting the IDSM will delete the buffer.
There is no way for the user to see what is in the buffer, other than restarting CSPM and see what alarms come across.
I am aware that you are working on transitioning all signatures to the engine
style of implementation so we would be, in effect, able to see all of the
signatures in this format, including unprotecting all fields for read only fo as to enable to see exactly what the signature specifics are. This capacity would spin off from the 4 code base. By code base I meant that if some of the IDSM signatures are still based on the old binary format, what would be the associated present code base?
The "4" in the "4 code base" is version 4.0(1)Sx of the sensor software which is currently in development. It will be for the current IDS-42xx appliances and any New IDS hardware in the future. All signatures in 4.0(1)Sx will be created using engines. (BUT in some cases the engines are specially coded and compiled for the signature, so even though it is engine based you may still not be able to tell exactly why the signature fires because the real info is compiled code. Luckily there are only a few of these signatures, and in most cases they are explained in the NSDB)
The current IDS-42xx appliances are running version 3.1(3)S36. So their code base is a version 3 code base for the appliances. It has signature engines, which allow users to look at the signature definitions similar to v4, but many of the fields in v3 were hidden from the user. (Unfortunately the hidden fields were usually the ones you are most interested in like the regex fields)
NOTE: In version 4.0(1)Sx of the appliance the majority of the signature fields will no longer be hidden. (so you can see what the regex's are.) (A few still remain hidden because of the Cisco or partner company proprietary information that it may contain)
The current Cat 6K IDSMs are running 3.0(5)S29. Their code base is a version 3 code base for the modules. BUT the module code base for the IDSM differs from the appliance code base. The appliance version 3 code base used signature engines, but the IDSM version 3 code base still uses compiled in signatures (more similar to the older v2.5 code base of hte appliances) Since signature engines are not supported on the modules, you can't see what makes the signature fire.
BenefitsDocumentationPrerequisiteImage Download LinksLimitationsSupported PlatformsLicense RequirementsTopologyStep-By-Step ConfigurationConfigure Virtual ServiceActivate the virtual service and configure guest IPsConfiguring UTD (Service Plane)Configurin...
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...