Network Incident Investigation Runbook

Network incident investigation is not simply finding a suspicious IP address. The objective is to reconstruct what happened, determine how the attacker entered, understand what they reached, contain the threat, preserve evidence, and prevent recurrence.

Welcome to the Network Incident Investigation Runbook.

This runbook brings together the practical skills developed across:

• Network Security Fundamentals Lab
• ACL Security Lab
• Firewall Security Lab
• VPN Security Lab
• Network Threat Investigation Lab
• Network Security Assessment Runbook
• Firewall Review Runbook
• Network Device Hardening Runbook

The objective is to move from:

I can recognize suspicious network traffic.

to:

I can investigate a network-security incident systematically, correlate evidence across multiple sources, reconstruct the attack path, determine scope and impact, coordinate containment, and communicate the findings professionally.

🎯 Runbook Information

Item	Details
Runbook	Network Incident Investigation
Difficulty	Intermediate → Advanced
Estimated Time	3–8 Hours depending on incident
Primary Focus	Network Incident Investigation & Response
Target Roles	SOC Analyst, Network Security Engineer, Security Analyst, Incident Responder
Certification Alignment	CCST Cybersecurity, CCNA, CyberOps Associate, CCNP Security
Career Skill	Enterprise Network Incident Investigation
Output	Incident Timeline, Evidence Register, Attack Path, Findings, Containment Plan, Incident Report

🏢 Incident Scenario

It is 09:15 Monday morning.

The SOC receives several alerts:

Multiple failed VPN logins
        ↓
Successful VPN login
        ↓
Internal network scanning
        ↓
Connections to multiple servers
        ↓
Administrative authentication attempt

Shortly afterward, the firewall records unusual outbound communication from an internal server.

The security team asks:

Are these events related?

Management asks:

Has the organization been compromised?

Your responsibility is to determine:

What Happened?
      ↓
When Did It Start?
      ↓
How Did It Start?
      ↓
Which Identity Was Used?
      ↓
Which Systems Were Reached?
      ↓
What Did the Attacker Do?
      ↓
Is the Activity Still Active?
      ↓
What Should We Contain?
      ↓
What Was the Root Cause?

🎯 Investigation Objectives

By the end of this runbook, you should be able to:

• receive and classify an incident

• validate network alerts

• establish investigation scope

• preserve evidence

• analyze firewall logs

• analyze VPN logs

• analyze DNS evidence

• review authentication events

• identify reconnaissance

• identify port scanning

• investigate brute-force activity

• investigate password spraying

• identify suspicious remote access

• investigate lateral movement

• review network-device changes

• identify suspicious outbound traffic

• reconstruct attack paths

• build an incident timeline

• determine affected systems

• determine affected identities

• assess business impact

• coordinate containment

• validate recovery

• identify root cause

• document lessons learned

• produce an incident report

⚠️ Investigation Safety

During an active incident, avoid making uncontrolled changes.

Do not immediately:

• reboot systems

• delete logs

• remove files

• clear firewall sessions

• reset every account

• modify network configurations

• shut down infrastructure

unless containment requires it and the action is authorized.

Why?

Because these actions may:

• destroy evidence

• disrupt business

• alert the attacker

• make timeline reconstruction harder

🧠 Incident Response Principle

Use:

Preserve
   ↓
Understand
   ↓
Scope
   ↓
Contain
   ↓
Eradicate
   ↓
Recover
   ↓
Learn

🧭 Investigation Workflow

Use this workflow throughout the investigation:

Incident Intake
      ↓
Validate Alert
      ↓
Establish Timeline
      ↓
Identify Source
      ↓
Identify Destination
      ↓
Identify Identity
      ↓
Collect Evidence
      ↓
Correlate Events
      ↓
Map Attack Path
      ↓
Determine Scope
      ↓
Assess Impact
      ↓
Contain
      ↓
Eradicate
      ↓
Recover
      ↓
Root Cause Analysis
      ↓
Lessons Learned
      ↓
Report

01 — Receive the Incident

Start by documenting the initial report.

Capture:

• incident ID

• date/time

• reporter

• alert source

• affected asset

• suspected source

• initial severity

• current status

📋 Incident Intake Worksheet

Item	Details
Incident ID
Date / Time
Alert Source
Reporter
Source IP
Destination IP
User / Identity
Affected System
Initial Severity
Current Status
Investigator

02 — Understand the Initial Alert

Do not assume:

Alert = Confirmed Incident

Determine:

• which security control generated it

• what detection triggered

• what activity was observed

• when it occurred

• which systems were involved

03 — Validate the Alert

Ask:

Does the underlying evidence support the alert?

Review:

• source

• destination

• protocol

• port

• timestamp

• action

• session information

• authentication result

🧠 Validation Principle

Move from:

Alert

to:

Evidence
   ↓
Context
   ↓
Conclusion

04 — Determine Whether Activity Is Expected

Ask:

• is the source a vulnerability scanner?

• is this an administrator?

• is this a monitoring platform?

• is this a scheduled job?

• is this an approved vendor?

🚨 Common Mistake

Treating legitimate administrative activity as malicious without checking context.

05 — Assign Initial Severity

Consider:

Asset Criticality
+
Privilege
+
Exposure
+
Observed Behavior
+
Potential Impact
=
Initial Severity

🔴 Critical

Potential examples:

• confirmed privileged infrastructure compromise

• widespread active lateral movement

• major production impact

🟠 High

Potential examples:

• confirmed unauthorized VPN access

• compromise of important server

• suspicious administrative activity

🟡 Medium

Potential examples:

• scanning from internal system

• repeated failed authentication

• suspicious but unconfirmed communication

🔵 Low

Potential examples:

• blocked reconnaissance

• isolated unsuccessful activity

06 — Open an Investigation Timeline

Immediately begin recording events.

Time	Source	Destination	Event	Evidence

🧠 Important

Do not wait until the investigation ends to build the timeline.

Build it:

as you investigate.

07 — Normalize Time

Confirm:

• timezone

• NTP synchronization

• timestamp format

Example:

Firewall: UTC
VPN: IST
Server: UTC
SIEM: UTC

Normalize before correlating.

08 — Preserve Evidence

Identify relevant evidence sources.

Examples:

• firewall logs

• VPN logs

• router logs

• switch logs

• DNS logs

• authentication logs

• endpoint telemetry

• SIEM alerts

• IDS/IPS events

• configuration-change logs

📁 Evidence Register

Evidence ID	Source	Time Range	Collected By	Notes

09 — Protect Original Evidence

Where applicable:

• preserve original exports

• work from copies

• record collection time

• document source

🧠 Investigation Discipline

You should be able to answer:

Where did this evidence come from?

10 — Identify the Initial Indicator

Start with the strongest known indicator.

Examples:

Source IP
User Account
Destination IP
Hostname
VPN Session
Domain
Firewall Rule

11 — Pivot From the Indicator

Example:

Suspicious IP
     ↓
Firewall Logs
     ↓
VPN Logs
     ↓
Authentication Logs
     ↓
DNS Logs
     ↓
Endpoint Evidence

This is called:

pivoting through evidence.

12 — Analyze Firewall Logs

Firewall logs can help answer:

• who communicated?

• with what?

• over which service?

• was it allowed?

• which rule permitted it?

• how much traffic was transferred?

📋 Firewall Investigation Fields

Review:

Timestamp
Source IP
Source Zone
Destination IP
Destination Zone
Protocol
Destination Port
Action
Rule
Session
Bytes

13 — Identify Suspicious Allowed Traffic

Do not focus only on:

DENY

Successful attacks frequently appear as:

ALLOW

🧠 Important Principle

The firewall may correctly allow traffic that an attacker is abusing.

Example:

VPN User
   ↓
RDP
   ↓
Internal Server
   ↓
ALLOW

The firewall is functioning.

The identity may be compromised.

14 — Identify Unusual Destinations

Look for:

• unfamiliar external IPs

• unexpected countries/regions

• unusual internal systems

• management networks

• database networks

15 — Identify Unusual Ports

Investigate unexpected communication using:

• administrative services

• file-sharing services

• database services

• uncommon high ports

Context determines whether a port is suspicious.

16 — Review Traffic Volume

Large outbound transfers may require investigation.

Example:

Internal Server
      ↓
External Destination
      ↓
Large Data Transfer

Ask:

Is this normal for this system?

17 — Identify the Firewall Rule

Determine which rule allowed suspicious communication.

Document:

Rule:
VPN-USERS-TO-INTERNAL

Source:
VPN

Destination:
Internal

Service:
ANY

This may expose a contributing security weakness.

18 — Review VPN Logs

If remote access is involved, collect:

• username

• source IP

• login time

• logout time

• authentication result

• MFA result where available

• assigned VPN IP

• group/policy

📋 VPN Session Worksheet

Field	Value
Username
Public Source IP
Assigned VPN IP
Login Time
Logout Time
Authentication
MFA
VPN Group

19 — Review Failed VPN Authentication

Look for:

Same User
   ↓
Many Password Attempts

or:

Same Source
   ↓
Many Usernames

20 — Identify Brute-Force Patterns

Example:

user1 → FAIL
user1 → FAIL
user1 → FAIL
user1 → FAIL
user1 → SUCCESS

This may indicate password guessing.

21 — Identify Password-Spray Patterns

Example:

user1 → FAIL
user2 → FAIL
user3 → FAIL
user4 → FAIL
user5 → FAIL

from the same or related source.

🧠 Difference

Brute Force

Many passwords
      ↓
One account

Password Spray

One/few passwords
      ↓
Many accounts

22 — Investigate Successful Login After Failures

Pattern:

Many Failures
      ↓
Successful Authentication

should receive additional attention.

Determine:

• source IP

• user

• device

• MFA result

• subsequent activity

23 — Compare With User History

Where available, compare:

• normal login locations

• normal login times

• typical devices

• usual VPN behavior

🚨 Suspicious Pattern

Normal:
India

Shortly Later:
Unusual Remote Location

Investigate whether the sequence is plausible and supported by evidence.

24 — Map VPN Identity to Internal IP

This step is critical.

Example:

External IP
   ↓
VPN Authentication
   ↓
User Identity
   ↓
Assigned VPN IP
   ↓
Firewall Activity

Now you can connect:

identity evidence

with:

network evidence.

25 — Review Authentication Logs

Investigate:

• successful logins

• failed logins

• privileged authentication

• account lockouts

• authentication source

26 — Identify Authentication Sequence

Example:

09:12 VPN Login
09:16 Server Authentication
09:18 Admin Authentication
09:20 Additional Server Access

This begins forming an attack story.

27 — Review Privileged Authentication

Pay special attention to:

• administrator accounts

• network administrator accounts

• server administrators

• privileged service accounts

28 — Identify Privilege Escalation Indicators

Example:

Standard User
      ↓
Internal Server
      ↓
Privileged Account Used

Ask:

How did the attacker obtain privileged credentials?

29 — Analyze DNS Logs

DNS can provide valuable context about external communication.

Review:

• requesting client

• domain

• timestamp

• resolved IP

• response

📋 DNS Investigation Worksheet

Time	Client	Domain	Result	Notes

30 — Identify Suspicious DNS Activity

Investigate:

• newly observed domains

• unusual query volume

• unusual subdomains

• domains contacted by only one host

🧠 DNS Investigation Question

Ask:

Which host requested this domain immediately before suspicious outbound communication?

31 — Correlate DNS With Firewall Logs

Example:

10:01
Host queries suspicious-domain.example

10:01
DNS returns 203.0.113.10

10:02
Host connects to 203.0.113.10

This creates stronger evidence than either log alone.

32 — Investigate Network Reconnaissance

Attackers often discover systems before moving laterally.

Look for:

One Source
   ↓
Many Destinations

or:

One Source
   ↓
Many Ports

33 — Identify Horizontal Scanning

Concept:

10.10.10.5 → 10.10.20.1:445
10.10.10.5 → 10.10.20.2:445
10.10.10.5 → 10.10.20.3:445
10.10.10.5 → 10.10.20.4:445

One service across many hosts.

34 — Identify Vertical Scanning

Concept:

10.10.10.5 → Server:22
10.10.10.5 → Server:80
10.10.10.5 → Server:443
10.10.10.5 → Server:445
10.10.10.5 → Server:3389

Many services on one host.

35 — Validate Whether Scanning Is Authorized

Before escalating, check whether the source is:

• vulnerability scanner

• network-monitoring system

• approved security test

36 — Investigate Lateral Movement

Ask:

After initial access, where did the source go next?

Example:

VPN Account
    ↓
User Workstation
    ↓
Application Server
    ↓
Database

37 — Look for Administrative Protocols

Depending on environment, investigate unexpected use of:

SSH
RDP
SMB
HTTPS Management
Database Services

🧠 Context Matters

RDP is not automatically malicious.

The important questions are:

• who initiated it?

• from where?

• to what?

• at what time?

• was it normal?

38 — Build a Lateral-Movement Matrix

Source	Destination	Service	Time	Expected?

39 — Identify New Source Systems

Suppose the investigation begins with:

HOST-A

and later discovers:

HOST-A → HOST-B
HOST-B → HOST-C

HOST-B now becomes:

another investigation pivot.

40 — Review East-West Firewall Logs

If internal segmentation exists, review traffic between:

• user networks

• application networks

• database networks

• management networks

41 — Identify Access to Management Networks

Treat unexpected communication toward:

• routers

• switches

• firewalls

• hypervisors

• administrative systems

as high priority.

42 — Review Network Device Logs

Collect relevant:

• login events

• failed login events

• configuration changes

• interface events

• ACL changes

• routing changes

43 — Investigate Administrative Login

Ask:

• who logged in?

• from which source?

• when?

• through which protocol?

44 — Investigate Configuration Changes

Examples:

Firewall rule modified
ACL modified
Route added
Interface changed
Logging disabled

🚨 High-Risk Pattern

Suspicious Admin Login
        ↓
Firewall Rule Added
        ↓
External Connection Allowed

45 — Compare Changes With Change Management

Determine whether configuration changes correspond to:

• approved ticket

• maintenance window

• known administrator

46 — Investigate Routing Changes

Unexpected routing changes may:

• redirect traffic

• bypass security controls

• disrupt services

47 — Investigate ACL Changes

Ask:

Did an ACL change create a new attack path?

Example:

Before:
Users X Management

After:
Users → Management

48 — Investigate Firewall Policy Changes

Review:

• new allow rules

• modified sources

• modified destinations

• service expansion

• logging disabled

49 — Investigate Logging Changes

Attackers with administrative access may attempt to reduce visibility.

Review unexpected:

• logging disablement

• log-destination changes

• monitoring changes

50 — Investigate Suspicious Outbound Communication

Look for:

Internal Host
      ↓
Unusual External Destination

Review:

• destination

• port

• frequency

• duration

• bytes transferred

51 — Identify Beaconing-Like Patterns

Conceptually:

Host
 ↓
External IP

Every 60 seconds
Every 60 seconds
Every 60 seconds

Regular communication patterns may warrant investigation.

Do not conclude maliciousness from periodicity alone.

52 — Review Long-Lived Sessions

Investigate unusual persistent connections from systems that normally do not maintain them.

53 — Review Unusual Egress Ports

Ask:

Does this workload normally initiate this type of external connection?

54 — Review Outbound DNS Context

Correlate:

DNS Query
   ↓
Resolved IP
   ↓
Firewall Session

55 — Review Data Transfer

Look for unexpectedly large:

Outbound Bytes

from sensitive systems.

⚠️ Important

Large transfer does not automatically mean:

data exfiltration.

Validate:

• destination

• application

• business process

• timing

56 — Identify Critical Assets Touched

Create:

Asset	Role	Activity	Criticality

Prioritize:

• identity infrastructure

• management systems

• databases

• security systems

• backup infrastructure

57 — Identify Affected Accounts

Create:

Account	Activity	Privilege	Status

58 — Identify Affected Networks

Document:

VPN
Users
Applications
Databases
Management
DMZ

as applicable.

59 — Expand Investigation Scope

For each confirmed compromised asset ask:

What did this system communicate with before and after the suspicious event?

🧠 Scope Expansion

Use:

Compromised Asset
      ↓
Inbound Connections
      ↓
Outbound Connections
      ↓
Authentication
      ↓
DNS
      ↓
Administrative Activity

60 — Avoid Premature Scope Closure

Do not stop after finding:

one compromised server.

Determine whether it was:

Target

or:

Pivot Point

61 — Build the Attack Path

Example:

External Source
      ↓
VPN Authentication
      ↓
Compromised User Account
      ↓
Internal VPN Address
      ↓
Server Access
      ↓
Internal Reconnaissance
      ↓
Application Server
      ↓
Privileged Authentication
      ↓
Database Access
      ↓
External Communication

62 — Annotate the Attack Path

Add:

• timestamps

• identities

• IP addresses

• protocols

• security controls

• evidence IDs

63 — Identify Security Controls Crossed

Example:

Internet
   ↓
VPN
   ↓
Firewall
   ↓
User Network
   ↓
Internal Firewall
   ↓
Server

Ask:

Which control should have prevented or detected each step?

64 — Identify Control Failures

Examples:

Weak Authentication
+
Broad VPN Access
+
Weak Segmentation
+
Insufficient Monitoring

These may combine to enable the incident.

65 — Separate Root Cause From Contributing Factors

Example:

Root Cause

Compromised Remote-Access Credential

Contributing Factors

Excessive VPN Access
Weak Internal Segmentation
Insufficient Alerting

This distinction matters.

66 — Build the Master Timeline

Example:

Time	Event	Evidence	Interpretation
08:55	VPN failures begin	VPN	Authentication attack
09:12	VPN success	VPN	Initial access
09:16	Internal scan	Firewall	Discovery
09:20	Server login	Auth	Lateral movement
09:28	Admin login	Auth	Privileged activity
09:34	External connection	Firewall	Suspicious egress

🧠 Timeline Principle

The timeline should tell:

the story of the incident.

67 — Identify Earliest Known Malicious Activity

Do not assume the alert time is the incident start.

If the alert occurred at:

10:00

search backward.

You may discover:

08:45 First Failed Login
09:12 Successful Login
09:30 Reconnaissance
10:00 Alert

68 — Determine Incident Scope

At minimum identify:

Affected Identities
Affected Systems
Affected Networks
Affected Applications
Affected Security Controls

69 — Assess Business Impact

Ask:

• was production affected?

• was privileged access obtained?

• were critical systems reached?

• was sensitive data potentially accessed?

• was availability affected?

70 — Update Incident Severity

Severity may change as evidence develops.

Example:

Initial:
Medium

After confirming privileged lateral movement:
High

71 — Develop the Containment Strategy

Containment should balance:

Security Risk
     ↔
Business Impact

72 — Consider Identity Containment

Depending on the incident:

• disable compromised account

• reset credentials

• revoke sessions

• require reauthentication

Coordinate with identity teams.

73 — Consider Network Containment

Possible authorized actions:

• block malicious source

• isolate compromised host

• restrict firewall access

• disable suspicious VPN session

• restrict affected subnet

⚠️ Do Not Over-Contain Blindly

Example:

Block Entire Database Network

may create a major outage.

Understand dependencies first.

74 — Contain the Attack Path

Instead of thinking only:

Which IP should we block?

Ask:

Which part of the attack path can we safely break?

Example:

Attacker
   ↓
VPN
   X
Internal Network

or:

Compromised Host
      X
Management Network

75 — Preserve Evidence Before Containment

Where practical and authorized, capture relevant evidence before making changes that may destroy it.

76 — Document Every Containment Action

Create:

Time	Action	Owner	Reason	Result

77 — Validate Containment

After containment ask:

• has suspicious traffic stopped?

• are sessions terminated?

• can the attacker still authenticate?

• can compromised hosts reach critical networks?

🧠 Containment Validation

Do not assume:

rule applied = incident contained.

Verify.

78 — Begin Eradication

Once containment is stable, identify what must be removed or corrected.

This may include:

• compromised credentials

• unauthorized accounts

• malicious persistence

• unauthorized configuration

• vulnerable services

79 — Remove Unauthorized Network Changes

Review and remediate:

• malicious firewall rules

• unauthorized ACLs

• suspicious routes

• logging changes

80 — Address Compromised Credentials

Coordinate appropriate:

• password reset

• credential rotation

• token/session revocation

• privileged account review

81 — Address Vulnerable Entry Point

If exploitation occurred, identify the affected service and coordinate remediation.

82 — Begin Recovery

Recovery may include:

• restoring normal connectivity

• re-enabling accounts safely

• returning systems to service

• validating security controls

83 — Increase Monitoring During Recovery

Watch for recurrence.

Example:

Recovered Host
      ↓
Unexpected External Communication

may indicate incomplete eradication.

84 — Validate Firewall Controls

Confirm:

Required Business Traffic
      ↓
ALLOW

and:

Known Malicious / Unauthorized Path
      ↓
DENY

85 — Validate VPN Controls

Confirm:

• compromised sessions terminated

• account access corrected

• least-privilege authorization enforced

86 — Validate Network Device Integrity

Review:

• firewall policy

• ACLs

• routes

• administrator accounts

• logging

87 — Perform Root-Cause Analysis

Ask:

What allowed the incident to begin?

Possible categories:

Credential Compromise
Vulnerable Service
Misconfiguration
Excessive Access
Weak Administrative Control

88 — Use the Five Whys Carefully

Example:

Why was the database reached?

Because the application server had access.

Why was the application server compromised?

Because the attacker moved from a VPN session.

Why could the VPN user reach the server?

Because the VPN policy was broad.

Why was the policy broad?

Because access had never been recertified.

This helps expose systemic weaknesses.

89 — Identify Detection Gaps

Ask:

Which attacker activity occurred before the SOC received an alert?

Example:

VPN Attack
   ↓
Internal Scan
   ↓
Server Access
   ↓
Privileged Login
   ↓
ALERT

Could earlier stages have been detected?

90 — Identify Prevention Gaps

Ask:

Which controls could have stopped the attack earlier?

Examples:

• stronger authentication

• narrower VPN authorization

• network segmentation

• management ACLs

• least privilege

91 — Identify Process Gaps

Examples:

• no firewall recertification

• no vendor-access review

• weak privileged-account lifecycle

• incomplete incident procedures

92 — Create Incident Findings

Use:

Condition
+
Evidence
+
Attack Path
+
Impact
+
Root Cause
+
Recommendation

📄 Standard Incident Finding Format

Finding ID:

Title:

Severity:

Affected Assets:

Observation:

Evidence:

Timeline:

Attack Path:

Root Cause:

Contributing Factors:

Business Impact:

Containment:

Recommendation:

Validation:

93 — Example Finding — Excessive VPN Access

Finding ID:
NIR-001

Title:
Compromised VPN Account Had Excessive Internal Network Access

Severity:
High

Observation:
A remote-access identity was able to communicate with multiple internal server networks following successful VPN authentication.

Risk:
Compromise of a remote user credential could provide extensive internal reachability and facilitate reconnaissance and lateral movement.

Root Cause:
VPN authorization was broader than required for the user's business role.

Recommendation:
Implement role-based VPN authorization and restrict users to required applications, networks, and services.

94 — Example Finding — Weak Internal Segmentation

Finding ID:
NIR-002

Title:
Insufficient Internal Segmentation Enabled Lateral Movement

Severity:
High

Observation:
The compromised source was able to establish connections across multiple internal trust zones.

Risk:
Initial compromise of one endpoint may provide attackers with access paths toward higher-value systems.

Recommendation:
Implement least-privilege segmentation between user, application, database, and management networks.

95 — Example Finding — Detection Gap

Finding ID:
NIR-003

Title:
Internal Reconnaissance Was Not Detected Before Lateral Movement

Severity:
Medium / High

Observation:
The compromised system communicated with multiple internal systems before security monitoring generated an actionable alert.

Risk:
Attackers may perform discovery and identify valuable targets without timely security-team awareness.

Recommendation:
Develop and tune detections for unusual internal scanning and network reconnaissance.

96 — Example Finding — Administrative Logging Gap

Finding ID:
NIR-004

Title:
Network Device Administrative Activity Was Not Centrally Logged

Severity:
High

Observation:
Relevant administrative events were available only locally on network devices.

Risk:
Unauthorized configuration changes may be difficult to detect or reconstruct during an incident.

Recommendation:
Forward network-device authentication and configuration-change events to centralized monitoring.

97 — Build the Remediation Roadmap

Categorize recommendations.

Immediate

• contain compromised identities

• isolate affected systems

• block confirmed malicious paths

• preserve evidence

Short Term

• restrict excessive VPN access

• strengthen segmentation

• remediate exposed services

• improve monitoring

Medium Term

• improve privileged access

• centralize network-device logging

• implement rule recertification

Strategic

• redesign network trust boundaries

• improve identity architecture

• strengthen enterprise detection engineering

📋 Remediation Matrix

Finding	Priority	Owner	Target	Status

98 — Conduct Lessons Learned

After recovery, ask:

What worked?

Examples:

• firewall logs were available

• VPN logs were retained

• SOC escalated quickly

What failed?

Examples:

• VPN permissions were too broad

• segmentation was weak

• logging was incomplete

What should change?

Examples:

• stronger detections

• narrower access

• better runbooks

• better telemetry

99 — Measure Detection and Response

Useful operational metrics may include:

Time to Detect
Time to Validate
Time to Scope
Time to Contain
Time to Recover

🧠 Important

Metrics should improve response capability, not simply create reporting numbers.

100 — Prepare the Incident Report

Recommended structure:

1. Executive Summary
2. Incident Classification
3. Scope
4. Detection
5. Initial Access
6. Investigation Methodology
7. Evidence Sources
8. Timeline
9. Attack Path
10. Affected Identities
11. Affected Systems
12. Network Activity
13. Lateral Movement
14. Privileged Activity
15. Containment
16. Eradication
17. Recovery
18. Root Cause
19. Contributing Factors
20. Security Control Gaps
21. Findings
22. Remediation Roadmap
23. Lessons Learned
24. Conclusion

📄 Example Executive Summary

The investigation identified unauthorized remote access followed by internal reconnaissance and lateral movement across multiple network segments.

A compromised remote-access identity successfully established a VPN session and subsequently accessed internal systems using permissions broader than required for the user's business role.

Network and authentication evidence showed reconnaissance activity followed by connections to additional internal systems and privileged resources.

The incident was contained by revoking the compromised access, restricting affected network paths, and isolating systems requiring further investigation.

The primary contributing weaknesses were excessive remote-access permissions, insufficient internal segmentation, and delayed detection of internal reconnaissance.

Longer-term remediation should focus on role-based remote access, stronger segmentation, privileged-access controls, centralized network telemetry, and earlier-stage behavioral detection.

101 — Build the Investigation Checklist

Investigation Area	Status	Evidence
Incident intake completed
Alert validated
Severity assigned
Timeline started
Time normalized
Evidence preserved
Firewall logs reviewed
VPN logs reviewed
Authentication reviewed
DNS reviewed
Reconnaissance reviewed
Lateral movement reviewed
Network-device logs reviewed
Configuration changes reviewed
Outbound traffic reviewed
Affected identities identified
Affected systems identified
Attack path created
Scope determined
Business impact assessed
Containment completed
Containment validated
Eradication completed
Recovery validated
Root cause identified
Detection gaps identified
Findings created
Lessons learned completed

🎤 Network Incident Investigation Interview Questions

Practise answering these without notes.

1. How would you investigate a network-security incident?

2. What would you do immediately after receiving an alert?

3. How do you determine whether an alert is a true positive?

4. Which logs would you collect during a network investigation?

5. What information can firewall logs provide?

6. Why are allowed firewall connections important during an investigation?

7. How would you investigate suspicious VPN access?

8. What is the difference between brute force and password spraying?

9. How would you map a VPN session to internal activity?

10. Why are DNS logs useful?

11. How would you identify port scanning?

12. What is horizontal scanning?

13. What is vertical scanning?

14. How would you identify lateral movement?

15. Which protocols may indicate administrative lateral movement?

16. How would you investigate a suspicious network-device configuration change?

17. How would you identify suspicious outbound communication?

18. What is an incident timeline?

19. How do you determine incident scope?

20. What is the difference between containment and eradication?

21. How would you validate containment?

22. What is root-cause analysis?

23. What is the difference between root cause and a contributing factor?

24. How would you identify detection gaps?

25. What should an incident report contain?

🚨 Scenario Interview Question 1

You observe 200 failed VPN logins followed by one successful login.

Do not immediately conclude compromise.

Investigate:

Source IP
   ↓
Username
   ↓
Authentication History
   ↓
MFA
   ↓
Successful Session
   ↓
Internal Activity

🚨 Scenario Interview Question 2

A VPN user starts scanning hundreds of internal systems.

Discuss:

• identity

• VPN source

• assigned IP

• scanning pattern

• user history

• authorized tools

• subsequent connections

• containment

🚨 Scenario Interview Question 3

A compromised workstation connects to five servers using SMB and RDP.

Discuss:

Initial Host
     ↓
Authentication
     ↓
SMB / RDP
     ↓
Destination Systems
     ↓
Account Used
     ↓
Lateral Movement Scope

🚨 Scenario Interview Question 4

A server communicates with an unfamiliar external IP every 60 seconds.

Do not say:

That’s definitely command and control.

Instead investigate:

• destination ownership/context

• DNS

• frequency

• duration

• process/endpoint evidence where available

• historical behavior

• other affected systems

🚨 Scenario Interview Question 5

A firewall administrator account creates a new internet-access rule at 02:00.

Investigate:

Administrator
      ↓
Source IP
      ↓
Authentication
      ↓
Change Record
      ↓
Rule Created
      ↓
Traffic Through Rule

🚨 Scenario Interview Question 6

The attacker has already been blocked. Is the incident finished?

No.

Continue investigating:

• initial access

• other accounts

• lateral movement

• persistence

• affected systems

• configuration changes

• root cause

🚨 Scenario Interview Question 7

The suspicious IP has been blocked, but another internal server begins contacting it.

This indicates the original incident scope may have been incomplete.

Expand the investigation.

🚨 Scenario Interview Question 8

You find evidence that the attacker accessed the management network.

Increase priority.

Review:

• routers

• switches

• firewalls

• administrative identities

• configuration changes

• logs

🚨 Scenario Interview Question 9

Firewall logs are missing for the suspected incident period.

Do not invent conclusions.

Document the evidence gap and seek alternative telemetry:

VPN
DNS
Authentication
Endpoints
Network Devices
SIEM

🚨 Scenario Interview Question 10

Management asks, “Are we safe now?”

A professional response should address:

Containment Status
+
Known Scope
+
Remaining Investigation
+
Recovery Status
+
Residual Risk
+
Monitoring

rather than simply:

Yes.

🧠 Investigation Interview Framework

Use:

Validate
 ↓
Collect
 ↓
Correlate
 ↓
Timeline
 ↓
Attack Path
 ↓
Scope
 ↓
Impact
 ↓
Contain
 ↓
Eradicate
 ↓
Recover
 ↓
Root Cause
 ↓
Improve

💬 Interview Tip

Avoid:

“I would check firewall logs and block the IP.”

A stronger answer is:

“I would first validate the alert and establish an investigation timeline. I would correlate firewall, VPN, DNS, authentication, endpoint, and network-device telemetry to identify the source identity, affected systems, reconnaissance, lateral movement, privileged activity, and suspicious outbound communication. I would then reconstruct the attack path, determine scope and business impact, coordinate evidence-preserving containment, validate eradication and recovery, identify root cause and contributing control gaps, and document remediation.”

That demonstrates Incident Responder and Network Security Engineer thinking.

📁 Portfolio Deliverables

Create a sanitized investigation package containing:

1. Incident Intake Form

Document:

• alert

• severity

• affected system

• investigator

2. Evidence Register

Track collected evidence.

3. Investigation Timeline

Example:

VPN Attack
   ↓
Successful Access
   ↓
Reconnaissance
   ↓
Lateral Movement
   ↓
Privileged Activity
   ↓
Suspicious Egress

4. Attack-Path Diagram

Show:

External Source
      ↓
Identity
      ↓
VPN
      ↓
Internal System
      ↓
Lateral Movement
      ↓
Critical Asset

5. Firewall Analysis

Document suspicious:

• source

• destination

• ports

• rules

6. VPN Analysis

Document:

• authentication

• source

• assigned IP

• session

7. DNS Analysis

Correlate domains and network activity.

8. Lateral-Movement Matrix

Document affected systems and services.

9. Findings Register

Create at least five professional findings.

10. Remediation Roadmap

Separate:

Immediate
Short Term
Medium Term
Strategic

11. Executive Incident Summary

Explain the incident in language suitable for management.

📝 Resume Examples

Instead of:

Knowledge of network incident response.

Use:

Investigated simulated enterprise network-security incidents by correlating firewall, VPN, DNS, authentication, and network-device telemetry to reconstruct attack timelines and lateral-movement paths.

Or:

Performed incident scoping and attack-path analysis covering suspicious remote access, internal reconnaissance, privileged authentication, network configuration changes, and outbound communications.

Or:

Developed containment, eradication, recovery, and remediation recommendations based on root-cause and security-control-gap analysis.

⭐ Runbook Readiness Check

After completing this runbook, you should be able to:

• validate network alerts

• establish an incident timeline

• preserve relevant evidence

• analyze firewall logs

• analyze VPN sessions

• investigate authentication attacks

• identify brute-force activity

• identify password spraying

• analyze DNS evidence

• identify reconnaissance

• distinguish horizontal and vertical scanning

• investigate lateral movement

• review privileged activity

• investigate network-device changes

• analyze suspicious outbound traffic

• correlate multiple evidence sources

• reconstruct attack paths

• identify affected identities

• identify affected systems

• determine incident scope

• assess business impact

• coordinate containment

• validate containment

• support eradication

• validate recovery

• perform root-cause analysis

• identify contributing factors

• identify detection gaps

• create incident findings

• prepare professional reports

• answer scenario-based interview questions

The objective is not:

I found the malicious IP and blocked it.

The objective is:

I can explain how the incident started, which identity and systems were involved, how the attacker moved through the network, which controls failed, what was affected, how the threat was contained, and what must change to prevent recurrence.

🏆 Runbook Complete

You have now progressed through:

Network Architecture
      ↓
Firewall Security
      ↓
Network Device Hardening
      ↓
Network Threat Investigation
      ↓
Incident Scoping
      ↓
Attack-Path Reconstruction
      ↓
Containment
      ↓
Eradication
      ↓
Recovery
      ↓
Root-Cause Analysis
      ↓
Lessons Learned

This directly supports roles such as:

• SOC Analyst

• Network Security Engineer

• Security Analyst

• Incident Responder

• Cybersecurity Engineer

• Security Consultant

More importantly, you should now be able to approach an incident with a repeatable methodology instead of randomly searching through logs.

🚀 What’s Next?

You have completed the practical network-security lab and runbook sequence.

You should now circle back through the labs and runbooks and build a job-ready Network Security portfolio from your sanitized:

• network diagrams

• firewall assessments

• hardening checklists

• investigation timelines

• attack-path diagrams

• findings

• remediation plans

• incident reports

The next step in your certification and career journey is to use these practical artifacts alongside your Cisco certification preparation and begin practising scenario-based technical interviews.