Network Security: Firewalls, IPS, and Visibility

How this module fits together

Both objectives start with the verb Describe. That tells you the depth Cisco expects: you need to know what each solution is, what it can and can't do, and where it belongs. You don't need to configure it yet. The hands-on objectives come later in Domain 2: 2.7 (secure management config) and 2.8 (FTD access control, AVC, URL, malware, and IPS policy).

The two objectives answer two questions:

1. 2.1: What enforces, and where do you put it? Firewalls, IPS/IDS, and next-generation firewalls, plus the deployment models: inline vs. passive, routed vs. transparent, appliance vs. virtual vs. cloud-delivered, and how they stay up (HA).
2. 2.2: How do you see what's happening? Syslog, SNMPv3, NetFlow/IPFIX, streaming telemetry, packet capture, firewall events, NDR, SIEM, and identity context from ISE/pxGrid.

Read the module top to bottom once. After that, each part stands alone for review. The coverage checklist at the very end shows where every 2.1/2.2 idea is taught.

Securing the Three Planes (Management, Control, and Data)

Role in this module: the organizing framework. Every firewall, IPS, and telemetry feature in the rest of this module protects or observes one of these planes.
Deeper coverage elsewhere: Layer 2 attacks (2.3), management options (2.4), CIS benchmarks (2.5), AAA troubleshooting (2.6), secure management config (2.7).

Why this matters

Modern networks get attacked from many directions at once, so no single device can protect everything. Defense has to be layered, and to layer it well you first need to know what kind of traffic you're protecting. Not all traffic on a router is the same. The packets an administrator uses to log in and configure the device are different from the routing updates two routers exchange. Both are different again from the user traffic flowing through the box.

Engineers group these into three planes: the management plane, the control plane, and the data plane (also called the forwarding plane). Each plane has its own job, its own protocols, its own attack surface, and its own hardening techniques. If you can look at any security feature and say "that protects the control plane" or "that protects the data plane," you'll answer a large slice of SCOR questions correctly without memorizing lists.

Learning objectives

• Classify any protocol or traffic type into the correct plane.
• Explain the primary attack against each plane and the defenses that counter it.
• Describe management-plane hardening: secure protocols, AAA, RBAC, NTP, logging, out-of-band management, and service reduction.
• Explain CoPP vs. CPPr and when each applies.
• Explain data-plane protections: ACLs, segmentation, encryption, uRPF, rate limiting, IPS, DLP, and the Layer 2 toolkit.

1. The three planes at a glance

Think of a router as a small office building:

• The management plane is the staff entrance and the control room. Only administrators come in here to run and adjust the building.
• The control plane is the internal chatter between building systems: elevators, fire alarms, and HVAC talking to each other to decide how the building runs.
• The data plane is the lobby and hallways where the public actually walks through.

A useful shortcut:

• Control-plane traffic is destined to the device's CPU, because the route processor has to think about it.
• Data-plane traffic is forwarded in hardware and is just passing through.
• Management-plane traffic also goes to the CPU, but it's you talking to the box, not another router.

That CPU distinction explains the control-plane defenses later. Anything that forces the CPU to stop and process packets is a potential denial-of-service lever.

2. Securing the management plane

The management plane is the keys to the kingdom. If attackers compromise it, they don't need to break your security: they become your security and reconfigure it at will.

2.1 Use secure, authenticated, encrypted protocols

SNMPv3's security levels are covered fully in SNMPv3. The configuration belongs to 2.7.

2.2 Harden the login path

• Session timeouts (exec-timeout) disconnect idle sessions so a forgotten one can't be hijacked.
• Login lockout (login block-for, or AAA-server lockout policy) is your front-line defense against brute-force and password-spray attacks.
• Centrally managed credentials through AAA (next), instead of local usernames on every box.

2.3 Centralize identity with AAA, and scope access with RBAC

AAA covers the three things every access decision needs: Authentication (who are you), Authorization (what may you do), and Accounting (what did you do: the audit trail).

RBAC applies least privilege by job function. An analyst role gets show commands only; an engineer role can enter configure terminal. Troubleshooting AAA is its own objective (2.6).

2.4 Keep clocks in sync with NTP, and log everything

Ship logs from every device to a central Syslog server or SIEM. Authenticated NTP keeps every timestamp aligned, which correlation, certificate validation, and Kerberos all depend on. The foundation: inventory, time, and logs explains why this is the foundation of visibility.

2.5 Use out-of-band (OOB) management

Out-of-band means management traffic rides a separate path from user data: a dedicated management interface or network, or console access through a terminal server. If the production network is down or flooded, you can still reach your devices, and users have no path to the management plane at all. IOS Management Plane Protection (MPP) restricts which interfaces accept management protocols. In-band vs. OOB is part of 2.4.

2.6 Disable unused services

Every listening service is another door. Turn off what you don't use: the HTTP server, CDP/LLDP on untrusted edge ports, small servers, proxy ARP, legacy daemons. This is exactly what CIS benchmarks codify for IOS XE and Secure Firewall (2.5): a published, checkable list of "turn this off, turn that on."

3. Securing the control plane

Two risks dominate here: an attacker floods the CPU with control-destined traffic (DoS), or injects false control information (a bogus route, a rogue STP root, a spoofed ARP) to redirect or blackhole traffic.

3.1 Protect the CPU: CoPP and CPPr

Control Plane Policing (CoPP) applies one MQC QoS policy to all traffic punted to the route processor. You classify (SSH, SNMP, routing protocols, etc.) and rate-limit each class, so a flood can't starve the CPU.

Control Plane Protection (CPPr) splits the control plane into three subinterfaces you can police separately:

• Host: traffic that terminates on the device (SSH, SNMP, BGP to this router).
• Transit: traffic software-switched through the device.
• CEF-exception: packets needing special handling (ARP, L2 keepalives, TTL-expired, and similar).

CPPr also adds port-filtering (drop traffic to closed ports early) and queue-thresholding.

One-liner: CoPP = one aggregate policy. CPPr = the same idea split into host / transit / CEF-exception.

3.2 Authenticate control protocols

• Routing authentication: OSPF and EIGRP key chains (MD5/SHA), BGP MD5 or TCP-AO.
• GTSM (BGP TTL security) confirms eBGP peers are directly connected.
• FHRP authentication stops an attacker from becoming the HSRP/VRRP/GLBP active gateway.

3.3 Protect the Layer 2 control plane (full treatment: 2.3)

BPDU Guard / Root Guard / Loop Guard for STP, DHCP snooping against rogue DHCP servers, and Dynamic ARP Inspection against ARP spoofing.

4. Securing the data plane

The goals: allow only wanted traffic, keep it confidential and intact, contain the blast radius, and watch it for abuse. Most of the firewall and IPS content in Firewall and IPS solutions lives here.

5. Visibility (pointer)

Hardening reduces risk; monitoring catches what gets through. NetFlow, Syslog, SNMPv3, telemetry, NDR, and SIEM are the whole subject of Security monitoring and telemetry (2.2).

6. Attacker's view: threat → plane → defense

7. Exam traps: the three planes

• Which plane? ARP, CDP/LLDP, STP, and routing protocols are control. User traffic passing through is data. SSH/SNMP/Syslog between an admin and the box is management.
• RADIUS vs. TACACS+: RADIUS (UDP) encrypts only the password; TACACS+ (TCP 49) encrypts the whole body. RadSec encrypts all of RADIUS.
• CoPP vs. CPPr: aggregate policy vs. host/transit/CEF-exception subinterfaces.
• uRPF strict vs. loose: strict checks the arrival interface; loose only checks that the source exists in the FIB.
• Out-of-band means a separate management path that users can't reach, not just "another VLAN."

Firewall & IPS Solutions and Deployment Models

Maps to: 2.1 in full. Describe network security solutions and deployment models that provide intrusion prevention and firewall capabilities.
Reinforces: 2.4 (management options), 2.8 (FTD policy implementation), 3.4 (Multicloud Defense), 4.x (Secure Access).

Why this matters

Firewalls and IPS are the enforcement muscle of network security: the devices that sit in the traffic path and say yes or no. Visibility, identity, and segmentation all feed decisions that a firewall or IPS carries out.

Objective 2.1 has two halves, and candidates often study only the first:

• Solutions: what a firewall, IPS/IDS, and NGFW are, and which Cisco products provide them.
• Deployment models: how and where you deploy them. That means inline vs. passive, routed vs. transparent, physical vs. virtual vs. cloud-delivered, standalone vs. HA/cluster, and the hybrid mix that ties them together.

Learning objectives

• Explain stateful inspection using the TCP handshake, and contrast it with stateless ACLs.
• Trace the evolution from packet filter to NGFW, and list what an NGFW adds.
• Distinguish IPS vs. IDS, the detection methods, and the IPS policy trade-off between security and connectivity.
• Describe the Cisco portfolio that provides firewall/IPS: Secure Firewall (FTD and ASA), virtual, Multicloud Defense, Secure Access, IOS XE, and Meraki MX.
• Compare inline vs. passive, routed vs. transparent, and the FTD IPS interface modes, and state which can block.
• Describe HA options (failover, clustering, multi-instance) and fail-open vs. fail-closed.
• Explain the hybrid mesh firewall idea and where firewalls go in a SAFE-style architecture.

1. What a firewall does

A firewall allows or blocks traffic according to policy. It always sits at the internet edge and, increasingly, inside the network as well. It has four core jobs:

1. Allow/block: the fundamental permit/deny decision.
2. Enforce policy: rules that say which traffic is allowed and which isn't.
3. Segment: terminate VLANs or zones on the firewall so policy applies between segments, not just at the edge.
4. Track connections: remember sessions so return traffic is handled automatically.

1.1 Stateful inspection

Walk through an outbound web request:

1. Your host sends a SYN. The firewall records a new connection attempt.
2. It expects a SYN-ACK from that server and lets it back in.
3. Your host sends the ACK. There is now an established entry in the state (connection) table.

From then on, the server's replies are permitted because they match the session. In effect it's a temporary, dynamic permit that lives only as long as the session and ages out after it. UDP and ICMP get a pseudo-state based on idle timeouts.

Without state, you'd have to write ACLs permitting every possible return flow, which is impossible to maintain and full of holes.

Stateless vs. stateful: a stateless ACL judges each packet alone with no memory. A stateful firewall judges each packet in the context of its conversation.

1.2 Common firewall features

2. From packet filter to NGFW

3. IPS and IDS

An Intrusion Prevention System (IPS) detects and blocks malicious traffic. An Intrusion Detection System (IDS) only detects and alerts. That one difference drives where each can be deployed (inline vs. passive).

3.1 How an IPS decides

• Signature-based: matches known attack patterns. Precise, but blind to brand-new (zero-day) attacks until a signature exists, so it needs regular rule updates. Cisco Talos writes and publishes the Snort rules.
• Anomaly/behavior-based: flags deviation from a learned baseline. Catches the unknown, but raises more false positives.
• Reputation-based: blocks IPs, domains, URLs, or files with a bad reputation. On FTD this is Security Intelligence, which is evaluated before deep inspection, so it's cheap and early.
• Policy-based: blocks anything that violates a defined policy (for example, any SMBv1).

On Cisco Secure Firewall the IPS engine is Snort. Snort 3 is the default on current FTD releases.

3.2 Getting the verdict right

Tuning is a trade-off between these two failures. On FTD, Cisco ships ready-made base intrusion policies that express that trade-off:

(Building these policies is 2.8; for 2.1 just know they exist and why.)

4. Next-generation firewalls (NGFW)

An NGFW = stateful firewall + integrated IPS + advanced visibility in one platform:

• Application Visibility and Control (AVC): identify thousands of apps regardless of port.
• URL filtering: allow/block by category and reputation.
• Malware defense: check file hashes and block known-bad files. Unknown files can go to a sandbox where they are detonated and judged. Cisco's sandbox is Secure Malware Analytics (formerly Threat Grid).
• User identity awareness: map IPs to users through ISE (pxGrid) or Active Directory, then write rules by user or group. For example, marketing may use social media; everyone else may not.
• Integrated IPS: Snort built in, no separate box.
• Security Intelligence: early blocking by Talos reputation feeds.

4.1 Security zones, and IOS Zone-Based Firewall

Firewalls reason in zones: groups of interfaces with the same trust level (inside, outside, DMZ). Policy is written between zones, not per interface. On IOS/IOS XE routers this is the Zone-Based Policy Firewall (ZBFW), which you'll build in Packet Tracer. Its rules are worth memorizing:

• Traffic between interfaces in the same zone is allowed by default.
• Traffic between different zones is dropped unless a zone-pair with a policy allows it.
• An interface in a zone cannot talk to an interface in no zone.
• The self zone is the router itself. Traffic to and from the router is allowed unless you define a self zone-pair.
• Policy actions are inspect (stateful; return traffic allowed automatically), pass (stateless and one-way, so you need a mirror rule for the return), and drop.

4.2 Encrypted traffic: decrypt, or fingerprint

Most traffic is TLS, so an NGFW can't see payloads by default. Two answers:

• TLS decryption (FTD decryption policy): Decrypt-Resign for outbound traffic (the firewall acts as a trusted man-in-the-middle with an internal CA), Decrypt-Known Key for your own inbound servers. It costs performance and has privacy implications.
• Encrypted Visibility Engine (EVE): fingerprints the TLS handshake (the ClientHello) to identify the client application, and flag malware, without decrypting.

5. Cisco solutions that provide firewall and IPS

Cisco now pitches these together as a hybrid mesh firewall: many enforcement points of different form factors, managed as one policy.

5.1 ASA vs. FTD (the classic comparison, updated)

5.2 Managing it (preview of 2.4)

6. Deployment model 1: inline vs. passive

Where you place a device in the path decides what it can do.

Inline: traffic passes through the device, so it can drop malicious packets before delivery. This is required for a firewall and for any IPS that should prevent.

• Downside: it's in the path, so it adds latency and becomes a potential bottleneck or single point of failure. Size it properly, use HA, and decide fail-open vs. fail-closed (resilience and scale).

Passive (out-of-band): the device gets a copy of traffic from a SPAN port or a network TAP. It can analyze and alert, but never block: the real packet has already moved on. This is IDS behavior.

Rule: if you want it to block, it must be inline.

TAP vs. SPAN: a TAP is a physical device that copies every frame, errors included, and never oversubscribes. A SPAN session is a switch feature that's free and flexible but can drop frames under load. Use a TAP where completeness matters.

7. Deployment model 2: firewall mode and interface mode

Two separate settings on Secure Firewall:

7.1 Firewall mode: routed vs. transparent

7.2 IPS-only interface modes (FTD)

FTD can also act purely as an IPS on some interfaces, without routing or bridging them:

Exam move: inline tap mode is the trick answer. It's physically inline but behaves like IDS. Put a new IPS in tap mode, review the events, then switch to inline once tuned.

8. Deployment model 3: resilience and scale

Fail-open vs. fail-closed. When an inline device or its inspection engine fails:

• Fail-open keeps forwarding uninspected: availability wins.
• Fail-closed stops forwarding: security wins.

Neither is "correct." It's a business decision about which risk is worse. Hardware bypass and Snort fail-open are the fail-open tools on FTD inline sets.

9. Deployment model 4: where it runs (on-prem, virtual, cloud, hybrid)

9.1 Where firewalls go in the architecture (SAFE view)

Cisco's SAFE model (objective 1.9) places in places in the network (PINs). Mapping firewall/IPS to them:

9.2 Umbrella and Secure Access (bridge to Domain 4)

The cloud-delivered security that SCOR v1.1 taught as Umbrella now lives in Cisco Secure Access, Cisco's SSE platform. For 2.1, just know that it is a cloud deployment model for firewall and IPS:

• DNS-layer security: blocks known-bad domains at resolution, before any connection.
• Secure Web Gateway (SWG): a full proxy that decrypts and inspects web traffic, with DLP.
• Cloud-delivered firewall (with IPS): L3–L7 rules for non-web traffic.
• CASB: discovers and controls shadow-IT apps.
• ZTNA: per-app private access instead of full-tunnel VPN.

SSE + SD-WAN = SASE. Configuration is objectives 4.2–4.4.

10. Attacker's view: what each control stops

11. Exam traps: firewall and IPS

• IPS vs. IDS: IPS prevents (inline); IDS only alerts (passive).
• To block, be inline. Passive, SPAN, TAP, and ERSPAN can never block.
• Inline tap mode is physically inline but cannot block.
• Routed vs. transparent: routed is an L3 hop with an IP per interface; transparent is an L2 bridge you insert without re-addressing (management IP on the BVI).
• FTD HA is active/standby. Active/active is an ASA feature that needs multiple contexts.
• ASA vs. FTD: the NGFW/IPS features are built into FTD. ASA is stateful FW + NAT + VPN.
• Multi-instance (FTD) ≈ multiple contexts (ASA).
• CDO is now Cisco Security Cloud Control. FMC = many devices; FDM = one device.
• ZBFW: inter-zone traffic is denied by default; zone ↔ no-zone is always denied; pass is stateless, inspect is stateful.
• Base intrusion policies: Balanced is the default recommendation; Maximum Detection is not for production.
• Umbrella → Secure Access (SSE). DNS-layer blocks at resolution; SWG is a decrypting proxy.

12. Self-check: firewall and IPS

1. A team wants to evaluate a new IPS on a production link without any chance of dropping traffic, then start blocking once it's tuned. Which FTD interface modes, in what order?

Start with an inline set in tap mode: it sits in the path, but only copies traffic to Snort, so it can't drop anything. After tuning, disable tap mode so the inline set can block. Optionally enable hardware bypass or Snort fail-open to protect availability.

2. You must add NGFW inspection between a server VLAN and its default gateway without changing any IP addresses. Which firewall mode?

Transparent mode. The firewall bridges the segment (bridge group + BVI) as a bump in the wire, so hosts keep their gateway.

3. A security architect asks for "active/active" Firepower Threat Defense HA. What do you tell them?

FTD failover is active/standby only. For several units sharing load, use clustering. Active/active failover exists only on ASA in multiple context mode.

4. On an IOS XE router, an admin creates zones INSIDE and OUTSIDE, assigns G0/0 and G0/1, and leaves G0/2 unassigned. Can hosts on G0/2 reach hosts on G0/0?

No. Traffic between an interface in a zone and an interface in no zone is always dropped.

5. Name two ways an NGFW can identify malware inside TLS sessions, and one trade-off of each.

Decryption (Decrypt-Resign): full payload visibility, but it costs performance, needs a trusted internal CA on endpoints, and raises privacy and compliance concerns. Encrypted Visibility Engine: no decryption needed, but it only sees handshake fingerprints, not content.

6. Which Cisco solution gives firewall + IPS to a remote user working from a café, with no hardware involved?

Cisco Secure Access, the cloud-delivered firewall/IPS in Cisco's SSE platform, with traffic steered by Cisco Secure Client.

Security Monitoring & Telemetry Technologies

Maps to: 2.2 in full. Describe security monitoring and telemetry technologies.
Reinforces: 2.7 (SNMPv3, secure syslog, NTP config), 6.5 (exfiltration), 6.6 (XDR/SIEM/SOAR), 6.8 (Splunk).

Why this matters

You can't protect what you can't see. If an asset isn't in your inventory, you don't know to defend it. If an event isn't logged, you can't investigate it. If "normal" was never recorded, you can't recognize "abnormal."

Monitoring is also the half of security that catches what prevention misses. The firewall and IPS part put enforcement in the path; this part is about how you prove they're working and notice the attacker who got past them.

Learning objectives

• Explain why inventory, NTP, and centralized off-box logging are the foundation.
• Compare the visibility technologies (Syslog, SNMP, NetFlow/IPFIX, NSEL, streaming telemetry, packet capture, firewall events, endpoint flow, identity context) by what they tell you and how they deliver it.
• Explain SNMPv3 security levels, MIB/OID, and traps vs. informs.
• Describe NetFlow versions, Flexible NetFlow's building blocks, and IPFIX.
• Describe SPAN, RSPAN, ERSPAN, and TAPs as telemetry sources.
• Describe Secure Network Analytics (NDR) and its components, Encrypted Traffic Analytics, and Secure Client NVM.
• Explain how ISE and pxGrid share context, and how SIEM, SOAR, and XDR fit together.
• Choose correctly between NetFlow and telemetry.

1. The foundation: inventory, time, and logs

Know what you have. An accurate asset inventory (workstations, network devices, servers, applications, data) is step zero. Unknown assets are unmonitored assets, and unmonitored assets are where breaches live.

Logs are the story of what happened. When an incident hits, logs are how you reconstruct who logged in, what changed, what was dropped, and when a service failed. Enable logging deliberately, not by default.

Synchronize time with authenticated NTP. Comparing a firewall log, a switch log, and a server log only works if their clocks agree. Authenticate NTP so an attacker can't skew time to sabotage logs or certificates.

Don't leave logs on the box. Local logs rotate and overwrite (you may hold only days), and attackers delete local logs to cover their tracks. Ship logs off-device to a Syslog server or SIEM, and treat that store as protected and access-controlled.

Takeaway: local logs are convenient but ephemeral and tamperable. Centralized, time-synced, off-box logging is the real control.

1.1 What should you actually log?

2. The visibility toolkit at a glance

3. Syslog

The standard for event logging. Every message has a facility (the source category, e.g. local7) and a severity 0–7, where the lowest number is the most severe:

Mnemonic: Every Awesome Cisco Engineer Will Need Icecream Daily. Setting a logging level sends that level and everything more severe (lower number). logging trap 4 sends 0–4.

• Classic syslog is UDP 514: unreliable and cleartext.
• Secure syslog runs over TLS (TCP 6514), so logs can't be read or altered in transit. Configuring it is 2.7.
• Add service timestamps log datetime msec and NTP, or the timestamps are useless.

4. SNMPv3

SNMP lets a management station read device data (counters, CPU, uptime) and, when permitted, write changes. The manager polls on UDP 161; devices send notifications to UDP 162.

• Traps are fire-and-forget notifications.
• Informs are acknowledged notifications, retransmitted until confirmed. Use informs when delivery matters.

SNMPv1/v2c use plaintext community strings. Only SNMPv3 (User-based Security Model) adds authentication and encryption:

MIB vs. OID:

• The MIB is the tree, or database, of everything a device exposes.
• An OID is the exact address of one item. For example, 1.3.6.1.2.1.1.1.0 walks iso → org → dod → internet → mgmt → mib-2 → system → sysDescr.
• An SNMP walk returns every OID under a branch.

Restrict SNMP with a view (read-only, limited OIDs) and an ACL of allowed managers. Least privilege applies here too.

5. NetFlow, IPFIX, and NSEL: conversation metadata

NetFlow records who talked to whom, using what, and how much. It is not a packet capture: no payload, only metadata. A flow is identified by its key fields, classically the 5-tuple (source/destination IP, source/destination port, protocol) plus ingress interface and ToS. Counters such as bytes, packets, timestamps, and TCP flags are added as non-key fields.

5.1 Versions

5.2 Flexible NetFlow building blocks

1. Flow record: match = key fields (which packets form a flow); collect = non-key fields (what to count).
2. Flow exporter: where to send records (collector IP, port, version).
3. Flow monitor: ties a record and an exporter together, with cache settings.
4. Apply the monitor to an interface, input and/or output.

5.3 Why security teams love it: an example

Row three should stop you cold. DNS almost never moves nearly 10 MB in one sustained conversation to an external host. That's a textbook signature of DNS tunneling exfiltration (objective 6.5). NetFlow didn't capture the data, but it told you exactly where to look. Top talkers reports surface outliers like this quickly.

5.4 NSEL: NetFlow from the firewall

NetFlow Secure Event Logging (NSEL) is how ASA (and FTD) export connection events as NetFlow v9 records: flow-create, flow-teardown, and flow-denied, including NAT translations. Router NetFlow says "this conversation happened"; NSEL adds "the firewall built, closed, or denied it."

6. Packet capture and traffic mirroring

When metadata isn't enough, you need the packets. These are also the feeds for the passive IDS described in inline vs. passive:

Full capture gives the most detail but costs the most storage and raises privacy concerns. Use it targeted, not everywhere.

7. Streaming telemetry (model-driven telemetry)

Traditional monitoring polls (SNMP asks every N minutes). Model-driven telemetry (MDT) flips this: devices push structured data, defined by YANG models, to a collector continuously or on change.

Why it beats SNMP polling: near-real-time, structured (no MIB parsing), scales to far more data points, and lower CPU on the device. Security uses it for management by exception: stream what's normal, alert in real time on what isn't.

8. Firewall and IPS events (FTD / FMC)

The NGFW is itself a rich telemetry source. FMC records:

These leave the FMC via syslog, SNMP traps, eStreamer (a high-volume event streaming API, used by the Splunk integration), or Cisco Security Analytics and Logging, to land in a SIEM or Cisco XDR.

9. NDR: Cisco Secure Network Analytics

Cisco Secure Network Analytics (formerly Stealthwatch) is Cisco's on-prem Network Detection and Response (NDR). It turns the NetFlow/IPFIX your network already produces into security detections using behavioral analytics and machine learning: baselining every host, then flagging deviations.

Related pieces to recognize:

• Encrypted Traffic Analytics (ETA): Catalyst switches and routers add handshake-derived fields (initial data packet, sequence of packet lengths and times) to flow records, so SNA can detect malware in encrypted traffic without decrypting it. It also audits which crypto is in use.
• Secure Client Network Visibility Module (NVM): the endpoint exports flows tagged with user, process, and device context. That tells you which application made a connection, even off-network.
• Secure Cloud Analytics (formerly Stealthwatch Cloud), the SaaS NDR for cloud and on-prem telemetry, is now part of Cisco XDR.

A behavioral-analytics example. Dao, an engineer, has worked only on Project Falcon for six months: that's her baseline. Today she accesses Project Harbor, which she has never touched. NDR flags it. Has she legitimately changed projects, or have her credentials been compromised? Analytics doesn't decide; it surfaces the anomaly so a human investigates. That's how lateral movement and account takeover get caught. (This user-and-entity approach is called UEBA.)

10. ISE and pxGrid: adding who and what

A firewall knows IPs and ports, not people. Cisco ISE knows who and what is on the network because it let them on (via RADIUS/802.1X/MAB). In the process it authenticates, profiles device type, checks posture, and applies policy. The result is a live picture of every session: user, device type, location, IP, posture, VLAN/SGT, time. This is contextual telemetry, not CPU counters.

pxGrid (Platform Exchange Grid) is the publish/subscribe fabric (certificate-authenticated) that shares this context:

It works both ways. When a SIEM, NDR, or firewall decides an endpoint is compromised, it can tell ISE over pxGrid, and ISE applies an Adaptive Network Control (ANC) policy, using CoA to quarantine the endpoint. This is Rapid Threat Containment: detection in one product drives enforcement in another. (ISE in depth is Domain 6.)

Don't confuse: ISE is the context broker (it collects). pxGrid is the sharing fabric (it distributes).

11. SIEM, SOAR, and XDR

• SIEM (e.g. Splunk, which Cisco now owns) ingests, normalizes, correlates, and alerts. Example: the firewall allowed a connection → it hit a web server → the source IP is on a Talos blocklist → correlated alarm.
• SOAR automates the response with playbooks: push a block, open a ticket, trigger ISE quarantine. SIEM = brain; SOAR = hands.
• EDR / NDR / XDR: endpoint, network, and cross-domain detection and response. Cisco XDR stitches endpoint, network, email, cloud, and identity telemetry into one incident.

Configuring Splunk ingestion and automation belongs to 3.5, 6.6, and 6.8. For 2.2, know each one's role.

12. NetFlow vs. telemetry: the decision table

Memory aid: patterns, conversations, how much, top talkers → NetFlow. Real-time, streaming, continuous, device stats → telemetry. What was in the packet → capture.

13. How it all fits together

1. Inventory everything, so nothing is invisible.
2. Time-sync everything with authenticated NTP.
3. Collect: Syslog, SNMPv3, NetFlow/IPFIX/NSEL, streaming telemetry, firewall events, NVM, and targeted capture.
4. Enrich with identity from ISE/pxGrid and threat intel from Talos.
5. Analyze: NDR (Secure Network Analytics) for behavior; SIEM (Splunk) for correlation.
6. Respond: an analyst investigates; SOAR automates the playbook; ISE ANC quarantines the endpoint; the firewall blocks the indicator.
7. XDR ties network, endpoint, email, and cloud into one investigation.

14. Exam traps: monitoring and telemetry

• NetFlow ≠ packet capture. It's metadata (key fields + counters), no payload.
• v5 is fixed and IPv4-only; v9 is template-based; IPFIX is the IETF standard based on v9 (UDP 4739).
• NSEL = firewall connection events (create/teardown/deny) exported as NetFlow v9.
• SPAN vs. RSPAN vs. ERSPAN: same switch / across L2 via a VLAN / across L3 via GRE.
• SNMP traps vs. informs: informs are acknowledged. The secure SNMPv3 level is authPriv.
• Syslog severity: 0 is the most severe; the configured level includes everything more severe. Secure syslog = TLS on TCP 6514.
• Dial-in vs. dial-out telemetry: the collector subscribes vs. the device initiates.
• Stealthwatch = Secure Network Analytics (NDR, on-prem). Secure Cloud Analytics is now part of Cisco XDR.
• ETA detects threats in encrypted traffic without decryption.
• ISE vs. pxGrid: broker vs. fabric. pxGrid shares context, not CPU stats.
• SIEM vs. SOAR: detect and correlate vs. automate the response.

15. Self-check: monitoring and telemetry

1. A branch router can't export NetFlow, but you need flow visibility for that segment in Secure Network Analytics. What do you add?

A Flow Sensor fed by a SPAN or TAP. It generates flow records (with application detail) for the Flow Collector.

2. Your IDS sensor sits in the data center, three routed hops away from the switch whose traffic you need to inspect. Which mirroring method?

ERSPAN. It GRE-encapsulates the mirrored traffic so it can cross a Layer 3 network.

3. NetFlow shows 10.20.5.80 sending 9.8 MB over UDP/53 to an external IP for five minutes. What's the likely activity, and which two tools would you use next?

Likely DNS tunneling exfiltration. Next, check ISE/pxGrid to find which user and device own 10.20.5.80, and run a targeted packet capture or check DNS-layer security / firewall events to see the queried domains. Then contain the host, for example with ISE ANC quarantine.

4. The NOC wants interface utilization every 10 seconds from 400 switches, with less CPU impact than today's SNMP polling. What do you recommend?

Model-driven streaming telemetry, periodic subscription (dial-out gRPC or dial-in gNMI/NETCONF) using YANG models.

5. An auditor asks how you guarantee that monitoring traffic from routers to the NMS can't be read or forged. Which settings?

SNMPv3 at authPriv (SHA + AES), restricted by view and ACL; secure syslog over TLS (TCP 6514); and authenticated NTP so timestamps can't be skewed.

6. What does pxGrid let a firewall do that it couldn't do with IP addresses alone, and what can a SIEM ask ISE to do in return?

The firewall can write user- and group-based rules from ISE session context. In return, a SIEM or SOAR can ask ISE to apply an ANC quarantine policy (via CoA) to a compromised endpoint.

Module wrap-up: how 2.1 and 2.2 connect

• 2.1 is enforcement plus placement. A firewall tracks state and enforces zones; an IPS drops malicious patterns; an NGFW fuses both with app, URL, user, and malware awareness. Then the deployment questions: inline or passive? routed or transparent? appliance, virtual, cloud-native, or cloud-delivered? standalone, HA pair, or cluster?
• 2.2 is evidence. Syslog, SNMPv3, NetFlow/IPFIX/NSEL, streaming telemetry, capture, firewall events, NDR, ISE context, and SIEM/XDR tell you whether the enforcement works and what got past it.
• The three planes tell you which traffic each control protects or observes.

The five reflexes to carry into the exam

1. Name the plane: management, control, or data.
2. Inline blocks; passive (and inline tap) only alerts.
3. Know the pairs cold: IPS/IDS · stateful/stateless · routed/transparent · ASA/FTD · FMC/FDM · NetFlow/telemetry · SPAN/ERSPAN · traps/informs · SIEM/SOAR · ISE/pxGrid.
4. Secure the management plane first: SSH/HTTPS, SNMPv3 authPriv, AAA, authenticated NTP, secure syslog, OOB.
5. You can't defend what you can't see. Visibility is how prevention gets verified.

Coverage checklist: SCOR v2.0 2.1 and 2.2

2.1 Network security solutions and deployment models (firewall & IPS)

2.2 Security monitoring and telemetry technologies

Labs for this module

2.1 and 2.2 are "Describe" objectives, so the labs build intuition rather than test config. They come later as part of the Domain 2 Packet Tracer series (showcase walkthrough + downloadable baseline):

• IOS Zone-Based Firewall: zones, zone-pairs, self zone; prove inspect vs. pass, and the "zone ↔ no-zone" drop.
• Basic ASA: security levels, stateful return traffic, NAT.
• Visibility basics: Syslog with NTP-aligned timestamps, SNMP, and NetFlow export to a collector.

Not possible in Packet Tracer (FTD inline sets, FMC, Secure Network Analytics, ISE/pxGrid): these stay conceptual here or move to CML.