incident-response-network

Network forensics evidence collection and analysis during security incidents. Guides volatile evidence preservation, lateral movement detection via flow records and ARP/MAC/CAM table analysis, and read-only containment verification across Cisco IOS-XE/NX-OS, Juniper JunOS, and Arista EOS. Scoped to network artifacts only — packet captures, flow data (NetFlow/sFlow/IPFIX), forwarding tables, routing state, and device logs. Not general incident response, endpoint forensics, or malware analysis.

# Network Incident Response — Network Forensics

Network-specific evidence collection and analysis during security incidents.
This skill covers network artifacts only: packet captures, flow records
(NetFlow/sFlow/IPFIX), ARP/MAC/CAM tables, routing table state, and device
syslog events. It does not cover general incident response lifecycle (NIST
800-61), endpoint forensics, malware analysis, or organizational
communication plans.

The procedure follows an event-driven lifecycle shaped around forensic
evidence: preserve volatile data → triage scope → detect lateral movement →
verify containment → reconstruct timeline → document findings. All commands
are read-only. Containment verification confirms that previously applied
controls are effective — it does not execute containment actions.

Commands use `[Cisco]`, `[JunOS]`, or `[EOS]` vendor labels where syntax
diverges. See `references/cli-reference.md` for the full command reference
and `references/forensics-workflow.md` for evidence methodology,
chain-of-custody templates, and timeline reconstruction guidance.

## When to Use

- **Active security incident** requiring network-level evidence collection
  (packet captures, flow analysis, device logs)
- **Post-incident network forensics** — reconstructing what happened on the
  network after a confirmed security event
- **Lateral movement investigation** — tracing attacker movement between
  internal hosts using flow records, ARP/MAC table changes, and routing
  state analysis
- **Unauthorized access investigation** — identifying how an external or
  internal actor reached target systems via network path analysis
- **Data exfiltration analysis** — quantifying outbound data transfers via
  flow record byte counts and packet capture content analysis
- **Containment verification** — confirming (read-only) that ACLs, null
  routes, or VLAN isolation applied by responders are blocking attacker
  traffic effectively

## Prerequisites

- **Device CLI access** — read-only access to network devices in the
  incident scope is sufficient for all evidence collection commands.
  No enable/configure privilege is required.
- **Flow collection infrastructure** — NetFlow, sFlow, or IPFIX collectors
  must be receiving exports from network devices. Verify with flow export
  commands in `references/cli-reference.md`. Without flow data, lateral
  movement analysis (Step 3) is limited to ARP/MAC/syslog correlation.
- **Centralized logging** — device syslog events must be forwarded to a
  SIEM or syslog server. Local device log buffers are small and rotate
  quickly. Missing centralized logs create timeline gaps.
- **NTP synchronization** — all devices must be time-synchronized. Verify
  with `[Cisco]` `show ntp status`, `[JunOS]` `show system ntp`,
  `[EOS]` `show ntp status`. Skewed clocks corrupt timeline correlation.
- **Known-good baseline** — saved copies of routing tables, ARP tables, and
  device configurations from before the incident for comparison. Without
  baselines, anomaly detection relies on general heuristics rather than
  delta analysis.

## Procedure

Follow these six steps in order. Earlier steps capture volatile evidence
before it ages out; later steps analyze and document. Each step references
specific commands from `references/cli-reference.md` and methodology from
`references/forensics-workflow.md`.

### Step 1: Evidence Preservation

Capture volatile network evidence before it ages out or is overwritten.
Follow the volatility ordering from `references/forensics-workflow.md` —
most volatile first.

**1a. ARP / MAC / CAM tables** (highest volatility — minutes to hours):

Collect the current ARP and MAC address tables from every device in the
incident scope. These tables map IP addresses to MAC addresses and MAC
addresses to physical switch ports — essential for identifying which hosts
were connected where.

- **[Cisco]** — `show arp` and `show mac address-table`
- **[JunOS]** — `show arp no-resolve` and `show ethernet-switching table`
- **[EOS]** — `show arp` and `show mac address-table`

Save output to files with timestamps. ARP entries typically age out in
4 hours; CAM entries in 5 minutes. Delay here means losing L2 mapping.

**1b. Active packet captures** (real-time — exists only while traffic flows):

If the incident is active and the investigation requires payload-level
evidence, initiate packet captures on relevant interfaces immediately.

- **[Cisco]** — `monitor capture CAP1 interface <intf> both` then
  `monitor capture CAP1 start` — export with
  `monitor capture CAP1 export flash:evidence.pcap`
- **[JunOS]** — `monitor traffic interface <intf> write-file /var/tmp/capture.pcap`
- **[EOS]** — `bash tcpdump -i <intf> -w /mnt/flash/evidence.pcap -c 10000`

> **Performance note:** On-device packet capture consumes CPU. Monitor
> device health during capture and set packet count or duration limits.

**1c. Routing table snapshots** (hours — convergence overwrites state):

- **[Cisco]** — `show ip route` and `show ip route summary`
- **[JunOS]** — `show route` and `show route summary`
- **[EOS]** — `show ip route` and `show ip route summary`

Also capture routing protocol adjacency state (`show ip ospf neighbor`,
`show ip bgp summary` or vendor equivalents) to document peering status
at the time of collection.

**1d. Flow export verification** (hours to days — collector retention):

Confirm that flow data from the incident time window is available in the
flow collector. Verify export is active and records exist:

- **[Cisco]** — `show flow monitor` and `show flow exporter <name> statistics`
- **[JunOS]** — `show services flow-monitoring version-ipfix template` and
  `show services accounting status`
- **[EOS]** — `show flow tracking` and `show flow tracking counters`

**1e. Device configuration and comprehensive state:**

Save the running configuration and full technical support output for each
device in scope:

- **[Cisco]** — `show tech-support | redirect flash:tech-<hostname>-<date>.txt`
- **[JunOS]** — `request support information | save /var/tmp/tech-<hostname>-<date>.txt`
- **[EOS]** — `show tech-support | redirect flash:tech-<hostname>-<date>.txt`

Compute SHA-256 hashes immediately after saving evidence files (see
`references/forensics-workflow.md` for hash verification commands).

### Step 2: Initial Triage

Determine the scope of the incident — affected devices, time window,
involved IP addresses — using log and flow data collected in Step 1.

**Identify the time window:** Find the earliest indicator (first alert,
first anomalous event) and the latest known malicious activity. Add a
buffer of ±2 hours to account for undetected precursor activity.

**Identify involved IPs:** Extract unique source and destination IP
addresses from alerts, SIEM events, and flow records within the time
window. Classify each as internal, external, or infrastructure.

**Identify affected devices:** Determine which network devices handled
traffic to/from involved IPs. Use routing tables to trace the forwarding
path and identify all transit devices.

**Scope assessment output:** A list of (1) affected time window, (2)
involved IP addresses with classification, (3) affected network devices,
and (4) evidence types available for each device. This scoping drives
the depth of Steps 3–5.

### Step 3: Lateral Movement Detection

Trace internal-to-internal connections that indicate attacker movement
between hosts. Lateral movement leaves evidence in flow records (new
internal connections), ARP/MAC tables (new L2 entries), and syslog
(authentication events, new sessions).

**Flow record analysis:** Query the flow collector for internal-to-internal
connections involving known compromised IPs during the incident time
window. Look for:

- Connections to ports commonly used for lateral movement (SMB/445,
  RDP/3389, SSH/22, WinRM/5985, WMI/135)
- Connections from a compromised host to hosts it has never contacted
  before (new destination analysis)
- High byte-count transfer