Yeah, the product is overcomplicated to say the least. Sometimes we have to read open-source Snort manuals from https://snort.org in order to understand what Cisco documentation says, but oftentimes this doesn't help too.
NAP is basically an interface to configure Snort2 preprocessors (in Snort3 they're called inspectors). You can have single default NAP for your Access Control Policy (ACP > Advanced > Network Analysis and Intrusion Policies) or you can create NAP rules to configure those preprocessors differently for different sources/destinations (this is rarely needed). You can also choose between few pre-configured NAP policies (less strict and more strict), but it's not easy to understand what exact consequences this may have on your traffic. You can even create new NAP policy and edit it (almost nobody does this). The most complicated part is understanding which NAP settings apply to traditionally used routed/transparent firewall modes, which ones apply to inline set mode and which ones apply to passive monitoring modes (SPAN, ERSPAN, etc.). The problem is that traffic normalization/conditioning is actually done by underlying Lina/ASA engine if firewall runs in routed or transparent mode, so many NAP settings do not apply. But few of them still do apply in these modes.
In a nutshell, preprocessors are responsible for packet decoding/parsing, IP defragmentation, TCP reassembly, traffic normalization and few other things. They can generate intrusion events the same way as intrusion rules do, but GID will differ from 1 ("Standard Text Rule") in the event. Corresponding Intrusion Rule needs to be enabled sometimes and the action can be set to alert or alert and generate events, otherwise corresponding feature won't work or work silently. But sometimes signatures can be disabled, but the feature still works.
For example, Stream Preprocessor can generate events with GID 129. It is configured in two places: in the NAP GUI and also by enabling corresponding Signatures Rules with GID 129 and setting action to alert or drop+alert.
For example, you can run "system support diagnostic-cli" and "show run all tcp-map", observe that "no checksum-verification" is configured by default on Lina/ASA and ask yourself "What would happen if I launch an attack through FTD and insert TCP segments into the stream (as retransmissions) with random payloads and put invalid TCP checksum into the TCP header of those packets? Will corresponding signature fire on FTD"? In NAP you have NAP > Checksum Verification setting. Does it apply to routed/transparent firewall mode?
Another example. "syn-data allow" is configured by default on ASA/Lina. Will "Remove Data on SYN" modify my packet if NAP Inline Normalizer is enabled and set to "Remove Data on SYN"? Or should "Stateful Inspection Anomalies" be enabled in the Stream Preprocessor instead. Will corresponding Intrusion rule 129:2 "Data in SYN" generate an alert or not? Should it be enabled for that or not?
Etc. Nightmare.
