The Logging controlled by the Action Field is specifically for IP Logging and not for whether or not the alarm gets logged.
IP Logging is the loggingin a binary (non human readable format) of the packets that came from the source ip address of the alarm after the alarm fired. The binary packets are logged in the /usr/nr/var/iplog and /usr/nr/var/iplog/new directories.
The determination as to whether or not the alarm is logged, is determined by the severity of the alarm, and the minimum severity levels for a destination.
If the alarm is a level 3 and my destination (in the destinations file) is set to receive level 2 alarms or higher, then the level 3 alarm will be logged along with level 2,4, and 5 alarms. (Only level 0, and level 1 alarms will not be logged to that specific destination.)
The only way to prevent an alarm from being logged is to set it severity level to be less than the smallest destination level. So if your smallest destination severity level is 2, then setting the alarm severity to 1 or 0 will prevent it from being logged.
User's understanding of how this works, however, has been affected by how the maangement tools were coded.
In CSPM, the developers unfortunately labeled the IP Log action as simply Log instead of calling it IP Log or even Binary Packet Log. So users incorrectly assumed that they had to set the action to Log in order to have the alarm logged in the /usr/nr/var/log.xxx file. When what is really happening is that they are telling the sensor to log the binary packets from the source of the attack.
Some users have inadvertantly set the majority of their alarms to Log action, and unknowingly are filling their sensors with these binary IP Logs which they never look at it. Then end result is that the sensor is working very hard to log all of these packets that the user never looks at, and this slows down the sensor's performance where it could be missing attacks.
The other misconception came when CSPM added an option to Disable a signature. In the GUI the severity stayed looking the same when Disable was selected, but when the signature is written in the packetd.conf file the severities were all changed to 0, because there is no other way to prevent the signature from being logged to a destination with a severity level of 1. So what CSPM shows the user isn't exactly what is written to the sensor, because there is no real enable/disable flag in packetd.conf.
I can't remember if the Unix Director has similar issues or not.
As for the question about has this changed. The answer is NO, this is the way the sensors have ALWAYS worked. Sorry for any confusions you may have had.
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...