Network Intrusion Analysis: Firewall Events, Flows and Packets
Network Intrusion Analysis covers Cisco Secure Firewall intrusion events plus flow and packet evidence. You must trace a signature hit back through policy configuration, decide whether anything succeeded, and scope the blast radius.
From policy to event
Traffic passes the access control policy, whose rules invoke an intrusion policy containing Snort rules. A Snort rule has a header (action, protocol, source and destination, direction) and options such as msg, sid, rev, classtype, content, pcre, flow and metadata. Preprocessors normalize protocols and raise their own rules for anomalies that would otherwise evade signatures.
Event records matter as much as the signature: intrusion events carry an impact level (generally 1 to 4) expressing how likely the attempt is to succeed against that target, and an inline result stating whether traffic was actually dropped or merely would have been dropped. Tuning levers are rule suppression by host or subnet, thresholding, and event filters - all of which can also hide real coverage.
Flows, encryption and packets
NetFlow/IPFIX gives the five-tuple plus byte and packet counts; sampling rates must be accounted for before you claim a volume. Encrypted Traffic Analytics analyzes the initial data packet, TLS handshake metadata and sequence-of-packet-lengths patterns, so encrypted sessions are not automatically opaque. In Wireshark use display filters such as ip.addr== and tcp.flags.syn==1 && tcp.flags.ack==0, Follow TCP Stream, and Expert Information for retransmissions; tshark -Y reproduces this on the CLI. Security Intelligence feeds block by IP, URL, DNS or SNI reputation before intrusion inspection, so a rule hit implies the reputation layer did not stop the session.
Worked example
Hundreds of web-application signature events hit an internal web server from one external source, impact high, inline result 'would have dropped'. Reasoning: the policy is in detection mode, so production traffic was permitted. Check connection events and the server's own logs for the same timestamps and a 200 response with a suspicious POST. If the application processed the request, escalate to host analysis for webshell artifacts; only then recommend moving the rule to block, and verify the internal application does not legitimately trigger it first.
Traps that cost marks
- Reading 'would have dropped' as blocked traffic.
- Treating impact level as proof of compromise rather than likelihood against a target.
- Suppressing a noisy rule globally instead of scoping suppression to the affected host or variable.
- Ignoring the connection event that shows whether the session completed.