Cas avances : audit, pentest et conformité¶

Méthodologie d'audit de code, tests d'intrusion, exigences reglementaires et organisation des équipes sécurité.

Audit de code : méthodologie¶

Un audit de code sécurité est une revue systematique du code source pour identifier les vulnérabilités logiques, les mauvaises pratiques et les défauts d'architecture.

Phases d'un audit¶

flowchart LR
    A[Cadrage] --> B[Reconnaissance]
    B --> C[Revue manuelle]
    C --> D[Analyse automatisee]
    D --> E[Verification et exploitation]
    E --> F[Rapport]
    F --> G[Remediation + retest]

Phase 1 — Cadrage

• Périmètre : quels composants, quelles fonctionnalités ?
• Profil d'attaquant : externe non authentifie, utilisateur authentifie, admin ?
• Contraintes : boite blanche (accès au code), boite grise, boite noire ?

Phase 2 — Reconnaissance

• Cartographie de l'application : endpoints, modèles de données, flux
• Identification des actifs critiques : données PII, paiements, secrets
• Stack technique : frameworks, librairies, versions

Phase 3 — Revue manuelle

• Suivi des flux de données de l'entree jusqu'à la sortie
• Contrôles d'accès : qui peut faire quoi ?
• Gestion des erreurs et des cas limites
• Logique métier : y a-t-il des raccourcis exploitables ?

Phase 4 — Analyse automatisee

• SAST : Semgrep, CodeQL sur le code source
• Scan de dépendances : snyk, grype
• Secrets dans l'historique : gitleaks, trufflehog

Checklist d'audit¶

## Controle d'acces
- [ ] Chaque endpoint verifie l'authentification
- [ ] Chaque action verifie l'autorisation (ownership)
- [ ] Pas de references directes a des objets sans validation

## Donnees sensibles
- [ ] Mots de passe hasches avec bcrypt/Argon2
- [ ] PII chiffrees au repos
- [ ] Pas de secrets dans les logs

## Entrees / Sorties
- [ ] Validation whitelist sur toutes les entrees
- [ ] Encodage contextuel sur toutes les sorties
- [ ] Requetes parametrees (pas de concatenation SQL)

## Sessions
- [ ] Tokens de session cryptographiquement aleatoires
- [ ] Invalidation cote serveur a la deconnexion
- [ ] Regeneration apres elevation de privilege

## Infrastructure
- [ ] Headers de securite configures
- [ ] TLS 1.2+ uniquement, ciphers forts
- [ ] Logs d'audit sur les actions sensibles

Penetration testing¶

Le pentest est une attaque simulee et autorisee contre un système pour identifier les vulnérabilités exploitables.

Types de pentest¶

Scope et règles d'engagement¶

Avant tout pentest, formaliser par écrit :

• Les systèmes dans le périmètre (IP, domaines, applications)
• Les systèmes hors périmètre (production live, tiers, partenaires)
• Les techniques autorisees et interdites (ex: pas de DoS en prod)
• La fenêtre temporelle
• Les contacts d'urgence en cas d'incident

Outils courants¶

# Reconnaissance passive
subfinder -d example.com -o subdomains.txt
httpx -l subdomains.txt -status-code -title

# Scan de vulnerabilites web
nuclei -u https://app.example.com -t cves/ -t vulnerabilities/

# Fuzzing d'endpoints
ffuf -w /wordlists/api-endpoints.txt -u https://app.example.com/FUZZ

# Test d'injection SQL
sqlmap -u "https://app.example.com/users?id=1" --batch --level=3

# Scanner de ports
nmap -sV -sC -p- --min-rate 5000 target.example.com

Conformité reglementaire¶

RGPD (GDPR)¶

Applicable à toute organisation traitant des données de residents europeens.

SOC 2¶

Certification pour les fournisseurs de services SaaS, basée sur 5 critères (Trust Service Criteria).

graph TD
    CC["Common Criteria\n(Controle acces, monitoring)"]
    AV["Availability\n(SLA, DR)"]
    PI["Processing Integrity\n(Validation des operations)"]
    CO["Confidentiality\n(Chiffrement, acces)"]
    PR["Privacy\n(RGPD-like pour USA)"]
    CC --> AV
    CC --> PI
    CC --> CO
    CC --> PR

Exigences techniques clés :

• Gestion des accès avec MFA pour les accès privilegies
• Logs d'audit conserves (généralement 1 an)
• Gestion des vulnérabilités avec SLA de remédiation
• Chiffrement en transit et au repos
• Plan de reprise d'activité teste annuellement

ISO 27001¶

Norme internationale de management de la sécurité de l'information.

• Annexe A : 93 contrôles techniques et organisationnels
• Certification par un organisme tiers accredite
• Revue annuelle obligatoire
• Périmètre défini explicitement (pas forcement toute l'organisation)

Bug bounty¶

Les programmes de bug bounty invitent des chercheurs en sécurité externes a tester vos applications contre recompense.

Avant de lancer un programme¶

• Corrections des vulnérabilités critiques connues (éviter les "low hanging fruit")
• Périmètre clairement défini et documente
• Équipe de triage en place (SLA de réponse)
• Budget de recompenses défini
• Processus legal (safe harbor pour les chercheurs)

Plateformes¶

Grille de rémunération typique¶

Security Champions¶

Le programme Security Champions distribué la culture sécurité dans les équipes de développement.

graph TD
    CISO["CISO / Equipe securite"] -->|"formation, outils, support"| SC1["Security Champion\nEquipe Frontend"]
    CISO -->|"formation, outils, support"| SC2["Security Champion\nEquipe Backend"]
    CISO -->|"formation, outils, support"| SC3["Security Champion\nEquipe Platform"]
    SC1 -->|"sensibilisation, revues"| Dev1["Developpeurs"]
    SC2 -->|"sensibilisation, revues"| Dev2["Developpeurs"]
    SC3 -->|"sensibilisation, revues"| Dev3["Developpeurs"]

Rôle du Security Champion :

• Relais entre l'équipe sécurité et son équipe produit
• Participation aux revues de code avec angle sécurité
• Formation des collegues aux vulnérabilités courantes
• Premier point de contact pour les questions sécurité
• Pas un expert sécurité à temps plein — un ambassadeur

Animer le programme :

• Formation trimestrielle (CTF, workshops OWASP)
• Canal de communication dédié (#security-champions)
• Reconnaissance visible (titre, budget formation)
• Partage des findings et post-mortems sécurité

Vers une culture sécurité¶

Le chemin de "reactif" a "optimise" prend typiquement 2 a 4 ans pour une équipe engagee.

Tutoriel complet. Retour a l'index pour revoir le parcours complet.