It will work. The issue is that the sensors create ACLs which are not CSPM aware. So the next time CSPM pushes out the configurations for the routers, the ACLs applied by the sensors will be overwritten.
Another problem also exits in that the sensor will overwrite any acls applied by CSPM on the same interface/direction that the sensor is managing.
So CSPM may configure the router to block certain types of traffic, but as soon as the sensor begins shunning on the router then the traffic is allowed through, and the user is unaware that they are once again vulnerable to attack.
There is a possible workaround that exists if CSPM is consistent in it's naming of ACLs.
1) Use CSPM to configure the router initially.
2) Determine which interface/direction you wish to have the sensor manage.
3) Determine what the ACL name/number is used by CSPM for that interface/direction on the router.
4) Configure the sensor to manage the router (use CSPM v2.3.1i and IDS 3.0).
5) The 3.0 sensor configuration for the interface/direction has 2 new fields: Pre and Post Shun ACLs. Place the name/number of the CSPM ACL as the PostShun ACL in the sensor's configuration.
This way when the sensor telnet's to the router it will read the contents of the CSPM ACL and place those at the bottom of the sensor generated ACL.
NOTE1: This will work if CSPM is consistent in it's naming convention of the ACLs so it always applies the same ACL to the same interface/direction. If it changes then you will have to keep changing the sensor configuration to keep it current.
NOTE2: You can not have both CSPM and the sensor make changes at the exact same so you have to temporarilly disable the sensor shunning when CSPM is updating the router configuration.
How to do this:
1) Be sure to set the approval status on both the sensor and the router for Manual approval so the
configurations are not pushed automatically when the Update button is pressed in CSPM.
2) Select the Disable Future Blocks under the Advanced Menu of the Event Viewer.
3) Now that the sensor is no longer configuring the router you can press the Manual Approval button for the router so CSPM can configure the router.
4) Once CSPM is finished configuring the router, you can select the Enable Future Blocks menu option to have the sensor once again shun on the router.
NOTE3: Even if you don't use CSPM to configure the router, I would suggest using the Disable, and Enable Future Shun menu options to keep the sensor from making router changes when you are personally configuring the router.
This is new capability in v3.0 of the sensor for just this sort of issue. The CSPM documents still
have the old warning because they were originally written with the 2.5 sensor in mind which would overwrite the CSPM ACLs and provided no means of pulling in the CSPM ACLs.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...