Defense & Mitigation Strategies
Zero Trust architecture, network detection and response, incident handling, security operations, and comprehensive defense frameworks
Chapter 14: Defense & Mitigation Strategies
The Zero Trust Mandate
In May 2021, President Biden signed Executive Order 14028, mandating that U.S. federal agencies adopt Zero Trust architecture. This wasn’t just policy posturing—it was a response to years of devastating breaches that traditional perimeter security had failed to prevent.
SolarWinds showed that attackers inside the network could move laterally for months. The Colonial Pipeline ransomware attack disrupted fuel supply to the eastern United States. Microsoft Exchange vulnerabilities exposed thousands of organizations. Each incident highlighted the same fundamental failure: once attackers got past the perimeter, they had free reign.
Zero Trust represents a paradigm shift: assume breach, verify explicitly, and enforce least privilege. But Zero Trust alone isn’t enough. Organizations need detection capabilities, incident response plans, and security operations that can identify and respond to threats in real-time.
This chapter synthesizes the defensive techniques introduced throughout Part II into a comprehensive security strategy, from architecture to operations.
Defense in Depth Revisited
Layered Security Model
Modern Defense in Depth
Modern Defense in Depth:
═══════════════════════════════════════════════════════════════════
┌─────────────────────────────────────────────────────────────────┐
│ GOVERNANCE & POLICY │
│ Security policies, standards, compliance, risk management │
└─────────────────────────────────────────────────────────────────┘
│
┌─────────────────────────────┴───────────────────────────────────┐
│ IDENTITY & ACCESS │
│ IAM, MFA, privileged access, zero trust principles │
└─────────────────────────────────────────────────────────────────┘
│
┌─────────────────────────────┴───────────────────────────────────┐
│ PERIMETER DEFENSE │
│ Firewalls, WAF, DDoS protection, email security │
└─────────────────────────────────────────────────────────────────┘
│
┌─────────────────────────────┴───────────────────────────────────┐
│ NETWORK SECURITY │
│ Segmentation, IDS/IPS, NDR, network monitoring │
└─────────────────────────────────────────────────────────────────┘
│
┌─────────────────────────────┴───────────────────────────────────┐
│ ENDPOINT SECURITY │
│ EDR, antimalware, patch management, hardening │
└─────────────────────────────────────────────────────────────────┘
│
┌─────────────────────────────┴───────────────────────────────────┐
│ APPLICATION SECURITY │
│ Secure development, code review, SAST/DAST, WAF rules │
└─────────────────────────────────────────────────────────────────┘
│
┌─────────────────────────────┴───────────────────────────────────┐
│ DATA SECURITY │
│ Encryption, DLP, classification, access controls │
└─────────────────────────────────────────────────────────────────┘
│
┌─────────────────────────────┴───────────────────────────────────┐
│ SECURITY OPERATIONS & RESPONSE │
│ SIEM, SOC, incident response, threat hunting │
└─────────────────────────────────────────────────────────────────┘Defense Categories
| Layer | Preventive | Detective | Responsive |
|---|---|---|---|
| Network | Firewall, segmentation | IDS, NDR | Isolation, blocking |
| Endpoint | AV, hardening | EDR, logging | Quarantine, wipe |
| Identity | MFA, least privilege | Behavior analytics | Account disable |
| Data | Encryption, DLP | Data monitoring | Access revocation |
| Application | Input validation | WAF, RASP | Patching, rollback |
Zero Trust Architecture
Zero Trust Principles
Zero Trust Fundamentals
Zero Trust Fundamentals:
═══════════════════════════════════════════════════════════════════
CORE PRINCIPLES:
1. NEVER TRUST, ALWAYS VERIFY
- Authenticate every access request
- Continuous verification, not one-time
2. ASSUME BREACH
- Design as if attacker is already inside
- Limit blast radius of compromise
3. VERIFY EXPLICITLY
- All data points: user, device, location, resource
- Real-time risk assessment
4. LEAST PRIVILEGE ACCESS
- Minimum necessary permissions
- Just-in-time access
5. MICRO-SEGMENTATION
- Segment by application, not network
- Isolate workloadsZero Trust Network Architecture
Traditional vs Zero Trust
Traditional vs Zero Trust:
═══════════════════════════════════════════════════════════════════
TRADITIONAL (Castle and Moat):
┌─────────────────────────────────────────────────────────────────┐
│ TRUSTED ZONE │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Server │ │ Server │ │ User │ │ User │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ All internal traffic trusted │
│ Once inside, free lateral movement │
└────────────────────────┬────────────────────────────────────────┘
│ Firewall
┌────────────────────────┴────────────────────────────────────────┐
│ UNTRUSTED ZONE (Internet) │
└─────────────────────────────────────────────────────────────────┘
ZERO TRUST:
┌─────────────────────────────────────────────────────────────────┐
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ POLICY ENGINE │ │
│ │ Identity │ Device │ Location │ Time │ Risk Score │ │
│ └──────────────────────────┬───────────────────────────────┘ │
│ │ │
│ ┌───────────┐ ┌───────────┴──────────┐ ┌───────────┐ │
│ │ Server │◄─┤ Policy Enforcement ├─►│ Server │ │
│ │ (Isolated)│ │ Point │ │ (Isolated)│ │
│ └───────────┘ └───────────┬──────────┘ └───────────┘ │
│ │ │
│ ┌───────────┐ │ ┌───────────┐ │
│ │ User ├──────────────┴────────────┤ User │ │
│ │ (Verified)│ │ (Verified)│ │
│ └───────────┘ └───────────┘ │
│ │
│ Every access verified │ Micro-segmented │ Logged │
└─────────────────────────────────────────────────────────────────┘Implementing Zero Trust
Zero Trust Implementation Phases
Zero Trust Implementation Phases:
═══════════════════════════════════════════════════════════════════
PHASE 1: VISIBILITY
─────────────────────
□ Asset inventory (devices, applications, data)
□ User and service account inventory
□ Data classification
□ Traffic flow mapping
□ Current access patterns
PHASE 2: IDENTITY
─────────────────────
□ Strong authentication (MFA everywhere)
□ Identity governance
□ Privileged access management
□ Service identity (workload identity)
□ Conditional access policies
PHASE 3: DEVICE
─────────────────────
□ Device inventory and health checks
□ Endpoint detection and response
□ Device compliance enforcement
□ Certificate-based device identity
PHASE 4: NETWORK
─────────────────────
□ Micro-segmentation
□ Software-defined perimeter
□ Encrypted communications (TLS everywhere)
□ Network detection and response
PHASE 5: APPLICATION & DATA
─────────────────────
□ Application-aware policies
□ API security
□ Data loss prevention
□ Encryption at rest and in transitNetwork Detection and Response (NDR)
NDR Capabilities
NDR Architecture
NDR Architecture:
═══════════════════════════════════════════════════════════════════
┌──────────────────────────────────────────────────────────────┐
│ NETWORK TRAFFIC │
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │ TAP │ │ TAP │ │ TAP │ │ TAP │ │ TAP │ │
│ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ │
└───────┼─────────┼─────────┼─────────┼─────────┼──────────────┘
│ │ │ │ │
└─────────┴────┬────┴─────────┴─────────┘
│
┌────────┴─────────┐
│ NDR SENSOR │
│ │
│ • Packet capture │
│ • Flow analysis │
│ • Protocol decode│
│ • ML/Behavioral │
└────────┬─────────┘
│
┌────────┴────────┐
│ NDR PLATFORM │
│ │
│ • Correlation │
│ • Threat intel │
│ • Investigation │
│ • Response │
└─────────────────┘NDR Detection Categories
| Category | Detection Method | Examples |
|---|---|---|
| Signature | Known patterns | Malware C2, exploits |
| Behavioral | Anomaly from baseline | Beaconing, exfiltration |
| ML/AI | Model-based detection | Novel threats, variants |
| Threat Intel | IOC matching | Known bad IPs, domains |
| Protocol | Protocol violations | DNS tunneling, HTTP anomalies |
Open Source NDR Stack
# Zeek (Bro) - Network analysis framework
zeek -i eth0 local
# Outputs detailed logs:
# conn.log - Connections
# dns.log - DNS queries
# http.log - HTTP transactions
# ssl.log - SSL/TLS connections
# files.log - File transfers
# Suricata - IDS/IPS with NDR capabilities
suricata -c /etc/suricata/suricata.yaml -i eth0
# RITA - Beacon and C2 detection
rita import --database mydb zeek_logs/
rita html-report --database mydb
# Arkime (Moloch) - Full packet capture and search
arkime-capture -c /etc/arkime/config.iniSecurity Information and Event Management (SIEM)
SIEM Architecture
Modern SIEM Architecture
Modern SIEM Architecture:
═══════════════════════════════════════════════════════════════════
DATA SOURCES:
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│Firewall │ │ EDR │ │ Cloud │ │ Network │ │ Apps │
│ Logs │ │ Logs │ │ Logs │ │ Flow │ │ Logs │
└────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘
│ │ │ │ │
└───────────┴─────┬─────┴───────────┴───────────┘
│
┌────────┴────────┐
│ COLLECTION │
│ & PARSING │
│ (Syslog, API, │
│ Agent) │
└────────┬────────┘
│
┌────────┴────────┐
│ NORMALIZATION │
│ & ENRICHMENT │
│ (Common schema, │
│ threat intel) │
└────────┬────────┘
│
┌────────┴────────┐
│ ANALYTICS │
│ & DETECTION │
│ (Correlation, │
│ ML, Rules) │
└────────┬────────┘
│
┌────────┴────────┐
│ INVESTIGATION │
│ & RESPONSE │
│ (Case mgmt, │
│ SOAR) │
└─────────────────┘Detection Rules (Sigma)
# Sigma rule example - DNS Tunneling Detection
title: DNS Query Length Anomaly
status: experimental
description: Detects DNS queries with unusually long subdomain
logsource:
category: dns
detection:
selection:
query|re: '.{50,}\.' # Subdomain > 50 chars
condition: selection
fields:
- query
- src_ip
- dst_ip
falsepositives:
- CDN domains with long names
- Legitimate encoded data
level: medium
tags:
- attack.command_and_control
- attack.t1071.004
# Convert to SIEM format
sigmac -t splunk rule.yml
sigmac -t elastic rule.ymlKey Detection Use Cases
Essential SIEM Detection Categories
Essential SIEM Detection Categories:
═══════════════════════════════════════════════════════════════════
AUTHENTICATION:
□ Failed login threshold exceeded
□ Login from new location/device
□ Impossible travel
□ Service account anomalies
□ Brute force detection
NETWORK:
□ Port scanning
□ DNS anomalies (tunneling, DGA)
□ Beaconing patterns
□ Large data transfers
□ Communication with threat intel IOCs
ENDPOINT:
□ Suspicious process execution
□ Persistence mechanisms
□ Credential dumping tools
□ Living off the land binaries (LOLBins)
□ Lateral movement patterns
DATA:
□ Unusual data access patterns
□ Data exfiltration indicators
□ Sensitive file access
□ Permission changesIncident Response
Incident Response Process
NIST Incident Response Lifecycle
NIST Incident Response Lifecycle:
═══════════════════════════════════════════════════════════════════
┌───────────────────────────────────────────────────────────────┐
│ │
│ ┌──────────────┐ ┌──────────────────┐ │
│ │ PREPARATION │─────►│ DETECTION & │ │
│ │ │ │ ANALYSIS │ │
│ │ • IR plan │ │ │ │
│ │ • Team │ │ • Monitoring │ │
│ │ • Tools │ │ • Triage │ │
│ │ • Training │ │ • Investigation │ │
│ └──────────────┘ └────────┬─────────┘ │
│ ▲ │ │
│ │ ▼ │
│ ┌──────┴───────┐ ┌──────────────────┐ │
│ │ POST-INCIDENT│◄─────│ CONTAINMENT, │ │
│ │ ACTIVITY │ │ ERADICATION, │ │
│ │ │ │ RECOVERY │ │
│ │ • Lessons │ │ │ │
│ │ • Improve │ │ • Isolate │ │
│ │ • Document │ │ • Remove threat │ │
│ └──────────────┘ │ • Restore │ │
│ └──────────────────┘ │
│ |
└───────────────────────────────────────────────────────────────┘Network-Focused IR Actions
Network Incident Response Playbook
Network Incident Response Playbook:
═══════════════════════════════════════════════════════════════════
DETECTION CONFIRMED:
1. □ Document initial indicators
2. □ Preserve volatile network data (connections, flows)
3. □ Capture relevant traffic (if not already)
4. □ Identify affected systems
CONTAINMENT:
1. □ Isolate affected systems (VLAN, firewall rules)
2. □ Block C2 communications
3. □ Block attacker IPs at perimeter
4. □ Disable compromised accounts
5. □ Preserve evidence before changes
ERADICATION:
1. □ Identify all compromised systems
2. □ Remove malware/implants
3. □ Reset credentials
4. □ Patch vulnerabilities exploited
5. □ Remove persistence mechanisms
RECOVERY:
1. □ Restore from clean backups
2. □ Rebuild if necessary
3. □ Gradual reconnection with monitoring
4. □ Validate security controls
POST-INCIDENT:
1. □ Timeline documentation
2. □ Root cause analysis
3. □ Detection improvements
4. □ Control gaps addressedContainment Strategies
| Scenario | Containment Action | Considerations |
|---|---|---|
| Single host compromised | VLAN isolation | Preserve for forensics |
| Lateral movement detected | Segment affected systems | May disrupt business |
| C2 communications | Block at firewall/DNS | May alert attacker |
| Data exfiltration | Terminate connections | Evidence preservation |
| Ransomware spreading | Network isolation | Immediate action required |
Network Hardening Checklist
Layer-by-Layer Hardening
Comprehensive Network Hardening
Comprehensive Network Hardening:
═══════════════════════════════════════════════════════════════════
LAYER 2 - DATA LINK:
□ Port security enabled
□ DHCP snooping enabled
□ Dynamic ARP Inspection
□ 802.1X authentication
□ BPDU Guard on access ports
□ Disable DTP (switchport nonegotiate)
□ Change native VLAN
□ Private VLANs where appropriate
□ MAC address limits per port
LAYER 3 - NETWORK:
□ Ingress/egress filtering (BCP38)
□ Unicast RPF enabled
□ ICMP rate limiting
□ IP source routing disabled
□ Directed broadcasts disabled
□ RPKI for BGP validation
□ BGP prefix filtering
□ TTL security for BGP
LAYER 4 - TRANSPORT:
□ SYN cookies enabled
□ SYN flood protection
□ Connection limits per source
□ TCP timestamps considered
□ Invalid flag combinations dropped
LAYER 7 - APPLICATION:
□ DNS security (DNSSEC validation)
□ Unnecessary services disabled
□ Strong encryption only (TLS 1.2+)
□ Certificate validation
□ Rate limiting on services
INFRASTRUCTURE:
□ Management network isolated
□ Out-of-band management
□ Strong device authentication
□ Encrypted management protocols (SSH, HTTPS)
□ Logging centralized
□ NTP authenticated
□ Configuration backups securedSecurity Operations Center (SOC)
SOC Functions
SOC Operating Model
SOC Operating Model:
═══════════════════════════════════════════════════════════════════
TIER 1 - ALERT TRIAGE (24/7):
┌─────────────────────────────────────────────────────────────────┐
│ • Initial alert review │
│ • False positive identification │
│ • Basic investigation │
│ • Escalation to Tier 2 │
│ • Metrics: Alerts per day, time to triage │
└─────────────────────────────────────────────────────────────────┘
TIER 2 - INCIDENT HANDLING:
┌─────────────────────────────────────────────────────────────────┐
│ • Deep investigation │
│ • Malware analysis │
│ • Containment actions │
│ • Coordination with IT teams │
│ • Escalation to Tier 3 │
└─────────────────────────────────────────────────────────────────┘
TIER 3 - ADVANCED ANALYSIS:
┌─────────────────────────────────────────────────────────────────┐
│ • Threat hunting │
│ • Advanced forensics │
│ • Threat intelligence │
│ • Detection engineering │
│ • Process improvement │
└─────────────────────────────────────────────────────────────────┘
METRICS:
- MTTD (Mean Time to Detect)
- MTTR (Mean Time to Respond)
- Alert-to-incident ratio
- False positive rate
- Escalation accuracyDetection Engineering
# Detection-as-Code Example
# Store in version control, test before deployment
name: lateral_movement_psexec
description: Detects PsExec-style lateral movement
mitre_attack:
- T1569.002 # Service Execution
- T1021.002 # SMB/Windows Admin Shares
data_sources:
- windows_security_events
- network_flows
detection_logic: |
(EventID == 4648 AND LogonType == 3) # Network logon
AND (ProcessName CONTAINS "PSEXESVC"
OR ServiceName LIKE "PSEXE%")
AND SourceIP != DestinationIP
response_actions:
- alert_soc_tier2
- isolate_source_host
- preserve_evidence
testing:
- atomic_red_team: T1569.002
- validation_data: test_data/psexec_sample.jsonContinuous Improvement
Security Metrics
| Metric Category | Example Metrics |
|---|---|
| Detection | MTTD, detection coverage, false positive rate |
| Response | MTTR, containment time, escalation accuracy |
| Prevention | Patch compliance, vulnerability age, pen test findings |
| Compliance | Policy violations, audit findings, training completion |
| Risk | Risk score trend, accepted risks, risk treatment progress |
Maturity Assessment
Security Program Maturity Levels
Security Program Maturity Levels:
═══════════════════════════════════════════════════════════════════
LEVEL 1 - INITIAL:
• Ad-hoc security
• Reactive only
• No formal processes
LEVEL 2 - DEVELOPING:
• Basic controls in place
• Some documentation
• Limited monitoring
LEVEL 3 - DEFINED:
• Documented processes
• Consistent implementation
• Regular assessments
LEVEL 4 - MANAGED:
• Metrics-driven
• Continuous monitoring
• Proactive threat hunting
LEVEL 5 - OPTIMIZING:
• Continuous improvement
• Threat intelligence integration
• Automated response
• Industry leadershipKey Takeaways
-
Defense in depth remains essential—no single control is sufficient
-
Zero Trust is a paradigm shift—verify explicitly, assume breach
-
NDR complements EDR—network visibility catches what endpoints miss
-
Detection engineering is continuous—adversaries evolve, so must detection
-
Incident response requires preparation—you can’t build the plane while flying
-
Metrics drive improvement—measure what matters, improve what you measure
Self-Assessment
-
Comprehension: How does Zero Trust fundamentally differ from traditional perimeter security?
-
Application: Design a detection strategy for DNS tunneling using your SIEM.
-
What if: Your organization discovers a breach that’s been ongoing for 6 months. How does your incident response differ from a new breach?
Review Questions
- What are the core principles of Zero Trust architecture?
- How does NDR differ from traditional IDS/IPS?
- What are the phases of NIST incident response?
- Why is micro-segmentation important in modern networks?
- What metrics should a SOC track to measure effectiveness?
- How does detection engineering improve security over time?
Part II Conclusion
Throughout Part II, we’ve explored attacks at every layer of the network stack—from physical access and Layer 2 manipulation to application exploitation and advanced persistent threats. Each attack technique reveals a corresponding defensive opportunity.
The security landscape continues to evolve. New protocols bring new vulnerabilities. Cloud and IoT expand the attack surface. Adversaries become more sophisticated. But the fundamental principles remain:
- Know your assets and their vulnerabilities
- Layer your defenses so no single failure is catastrophic
- Monitor continuously for threats
- Respond quickly when incidents occur
- Learn and improve from every event
In Part III, we’ll put these concepts into practice with hands-on labs that build practical skills for both offensive testing and defensive operations.