IDS/IPS — Intrusion Detection & Prevention

Use IDS when:
  └─ You cannot risk blocking legitimate traffic (e.g., healthcare, critical infrastructure)
  └─ You have a strong SOC team to review alerts
  └─ Monitoring historical traffic forensics
  └─ Deploying a new signature set (tune before enabling prevention)

Use IPS when:
  └─ You have a mature detection engineering process
  └─ False positives are well-understood and minimised
  └─ You need to block known threats automatically
  └─ Regulatory compliance requires active blocking

Best practice: Start with IDS, tune for 30-90 days, then switch to IPS.

Pros:
  └─ Very low false positive rate when well-tuned
  └─ Fast — can inspect traffic at line rate
  └─ Easy to understand and maintain
  └─ Effective against known malware and exploits

Cons:
  └─ Cannot detect unknown attacks (zero-days)
  └─ Signature updates required constantly
  └─ Small variations in attack bypass signatures
  └─ High maintenance overhead (tuning)

Pros:
  └─ Can detect novel attacks (zero-days)
  └─ Detects insider threats (unusual behaviour)
  └─ Adapts to network changes

Cons:
  └─ High false positive rate
  └─ Difficult to tune
  └─ Resource-intensive (requires ML/statistical analysis)
  └─ Attacker can slowly train the baseline (blind spot)

Example: A user logs in at 3 AM from a foreign country
  → Signature: Valid credentials (passes auth)
  → Anomaly: 3 AM login from unusual location
  → Behavioral: User has never accessed this server before
  → Combined: Score = HIGH → alert

[action] [protocol] [source_ip] [source_port] -> [dest_ip] [dest_port] ([options])

False Positive Reduction:
  └─ Target with src_ip/dst_ip — narrow scope
  └─ Add content matching — more specific is better
  └─ Use `threshold` to limit alert volume
  └─ Set `priority` to filter noise
  └─ Whitelist known-good through `pass` rules

Example Tuning:
  # Original — too broad, high false positives
  alert tcp any any -> any 80 (msg:"Possible attack"; content:"GET"; sid:999999;)

  # Tuned — specific to known vulnerable endpoint
  alert tcp $EXTERNAL_NET any -> $DMZ_NET 80 (
    msg:"SQLi attempt on login.php";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"/login.php"; http_uri;
    content:"' OR "; http_client_body;
    classtype:web-application-attack;
    sid:1000007;
    rev:1;
  )

Internet
   │
   ▼
┌──────────────┐
│   Firewall    │
└──────┬───────┘
       │
       ▼
┌──────────────┐     ┌──────────────────┐
│  IPS (Inline) │────▶│  DMZ Web Servers  │
└──────┬───────┘     └──────────────────┘
       │
       ▼
┌──────────────┐     ┌──────────────────┐
│  IDS (SPAN)   │────▶│ Internal Network  │
└──────────────┘     └──────────────────┘
       │
       ▼
┌──────────────┐
│    SIEM       │
│ (Logs, Alerts)│
└──────────────┘

Why IDS/IPS Failed:
  └─ Attacker signed malicious code with trusted certificates
     → No signature existed for known-malware
  └─ Communication with C2 via HTTP to AWS IPs
     → Looked like normal API traffic
  └─ Beacon intervals mimicked legitimate SolarWinds updates
     → Anomaly detection saw no deviation from baseline
  └─ Code was injected into legitimate SolarWinds DLL
     → File hash and signature were valid

Detection Challenge:
  Traditional IDS/IPS could not detect because:
    - No known malware signature
    - Traffic blended with legitimate SolarWinds traffic
    - Certificate pinning would not help (attacker had valid cert)

What Eventually Detected It:
  └─ FireEye (who was also compromised) noticed attacker tools on their own systems
  └─ Manual forensic analysis of SolarWinds build pipeline
  └─ No automated detection — required human investigation

Lesson:
  IDS/IPS is essential but not sufficient for sophisticated supply chain attacks.
  Defence-in-depth with behavioral analytics, integrity monitoring, and threat hunting is required.