# SPDX-License-Identifier: CC-BY-4.0
#
# profiles/saas_outbound_access/fiche.yaml
# Fiche NeuralWall — Accès sortant utilisateurs vers un SaaS
#
# Scénario adversarial n°2 : outbound HTTPS vers SaaS, déchiffrement SORTANT,
# exclusions légales/vie privée, DLP, identité par groupe annuaire, profils next-gen.
# Consulter docs/control-taxonomy.md pour le vocabulaire canonique.

# ─────────────────────────────────────────────────
# FRONTMATTER
# ─────────────────────────────────────────────────

# schema_version : version du CONTRAT d'ingestion (invariant 7).
# Distinct de `version` (contenu de la fiche).
schema_version: "1.0.0"

# id : clé primaire snake_case stable — correspond au nom du dossier.
id: saas_outbound_access

# version : semver du CONTENU de la fiche.
# 1.0.0 = version initiale, en cours de revue.
version: "1.0.0"

# trust_tier : reviewed = revue par un mainteneur avant merge (ADR-0002 §3).
trust_tier: reviewed

title:
  fr: "Accès sortant des utilisateurs internes vers un SaaS via Internet"
  en: "Internal users' outbound access to a SaaS service via the Internet"

description:
  fr: |
    Ce scénario couvre l'accès sortant d'utilisateurs authentifiés (identifiés par groupe
    annuaire) depuis le réseau interne vers un service SaaS hébergé sur Internet.
    Il active le déchiffrement SSL sortant (ssl_forward_proxy) pour permettre l'inspection
    L7 du trafic HTTPS, avec des exclusions réglementaires (santé, finance) pour préserver
    la vie privée et la conformité légale. Un profil DLP (prévention des fuites de données)
    est appliqué pour détecter les exfiltrations de données sensibles. Les profils
    c2_protection, IPS, url_filtering et dns_security couvrent les risques de shadow IT,
    de compte compromis et d'exfiltration via un SaaS légitime détourné.
    La conformité du poste (device_posture: compliant) est requise pour accéder au SaaS.
  en: |
    This scenario covers outbound access by authenticated users (identified by directory
    group) from the internal network to a SaaS service hosted on the Internet. It enables
    outbound SSL decryption (ssl_forward_proxy) for L7 inspection of HTTPS traffic, with
    regulatory exclusions (health, finance) to preserve privacy and legal compliance.
    A DLP (data loss prevention) profile is applied to detect sensitive data exfiltration.
    The c2_protection, IPS, url_filtering, and dns_security profiles address the risks of
    shadow IT, compromised accounts, and exfiltration through a hijacked legitimate SaaS.
    Device compliance (device_posture: compliant) is required to access the SaaS.

authors:
  - name: "NeuralWall Rules Team"
    email: "rules@neuralwall.io"
    org: "NeuralWall"

# includes : réservé à la composition Phase 2+. Omis en Phase 1 (fiches auto-contenues).

# ─────────────────────────────────────────────────
# THREAT CONTEXT — Champs AUTEURÉS (invariant 5, ADR-0002 §2)
# ─────────────────────────────────────────────────

mitre_attack:
  # T1567.002 : l'attaquant (ou un insider malveillant) utilise un service cloud/SaaS
  # légitime pour exfiltrer des données d'entreprise (ex. upload vers un espace de
  # stockage cloud personnel ou compromis).
  - technique_id: "T1567.002"
    name: "Exfiltration Over Web Service: Exfiltration to Cloud Storage"
    tactic: "exfiltration"

  # T1071.001 : utilisation du canal HTTPS vers un SaaS comme relais C2 discret.
  # Un implant sur un poste peut utiliser des APIs SaaS légitimes (ex. services
  # de messaging ou de stockage) comme canal de command-and-control.
  - technique_id: "T1071.001"
    name: "Application Layer Protocol: Web Protocols"
    tactic: "command-and-control"

  # T1078 : un attaquant ayant compromis les credentials d'un utilisateur se connecte
  # au SaaS avec un compte valide — le trafic est légitime en apparence, rendant
  # la détection difficile sans inspection du contenu (DLP).
  - technique_id: "T1078"
    name: "Valid Accounts"
    tactic: "defense-evasion"

  # T1048 : exfiltration via un protocole alternatif ou un canal non surveillé
  # (shadow IT, SaaS non approuvé accédé depuis le réseau interne).
  - technique_id: "T1048"
    name: "Exfiltration Over Alternative Protocol"
    tactic: "exfiltration"

threat_model:
  summary:
    fr: |
      L'accès sortant vers un SaaS présente trois catégories de risque distinctes.
      (1) Exfiltration intentionnelle ou accidentelle : un utilisateur (ou son poste
      compromis) transfère des données sensibles vers un stockage cloud externe.
      (2) Shadow IT : accès à des SaaS non approuvés, hors contrôle de l'entreprise,
      qui peuvent ne pas respecter les exigences de sécurité ou de résidence des données.
      (3) Compte compromis : un attaquant authentifié avec des credentials volés utilise
      un SaaS légitime comme relais C2 ou comme canal d'exfiltration. Sans déchiffrement
      ssl_forward_proxy, l'inspection L7 (DLP, IPS, c2_protection) est aveugle.
      Les exclusions de déchiffrement (finance, health) sont des exigences légales et
      de vie privée qui créent un angle mort contrôlé et documenté.
    en: |
      Outbound SaaS access presents three distinct risk categories. (1) Intentional or
      accidental exfiltration: a user (or their compromised endpoint) transfers sensitive
      data to external cloud storage. (2) Shadow IT: access to unapproved SaaS services
      outside the company's control, which may not meet security or data residency
      requirements. (3) Compromised account: an authenticated attacker with stolen
      credentials uses a legitimate SaaS as a C2 relay or exfiltration channel.
      Without ssl_forward_proxy decryption, L7 inspection (DLP, IPS, c2_protection)
      is blind. Decryption exclusions (finance, health) are legal and privacy requirements
      that create a controlled, documented blind spot.
  attacker_goal:
    fr: |
      Exfiltrer des données sensibles de l'entreprise (propriété intellectuelle,
      données personnelles, informations financières) via un SaaS légitime détourné,
      ou établir un canal C2 persistant via les APIs d'un service cloud approuvé,
      en exploitant la confiance accordée au trafic HTTPS sortant vers des domaines
      connus.
    en: |
      Exfiltrate sensitive company data (intellectual property, personal data, financial
      information) through a hijacked legitimate SaaS, or establish a persistent C2
      channel via the APIs of an approved cloud service, exploiting the trust granted
      to outbound HTTPS traffic toward known domains.
  key_controls:
    - ssl_forward_proxy    # Sans déchiffrement sortant, DLP/IPS/c2_protection sont aveugles
    - dlp                  # Détection et blocage de l'exfiltration de données sensibles
    - c2_protection        # Blocage des communications C2 via SaaS détourné
    - identity_user_group  # Restreint l'accès aux groupes autorisés (moindre privilège)
    - device_posture       # Seuls les postes conformes accèdent au SaaS
    - url_filtering        # Blocage des SaaS non approuvés (shadow IT)
    - dns_security         # Sinkhole des domaines malveillants détournant le trafic SaaS

# ─────────────────────────────────────────────────
# RULES — Règles du scénario complet (ADR-0002 §1)
# Règle 1 : flux SaaS sortant principal (internal -> internet)
# Règle 2 : dépendance DNS depuis le réseau interne vers le résolveur
# Règle 3 : deny par défaut — SaaS non approuvés / trafic non identifié
# ─────────────────────────────────────────────────

rules:

  # ── Règle 1 : Flux SaaS HTTPS sortant principal ─────────────────────────────
  # Posture next-gen : identification par app_id 'saas_generic' (catégorie saas),
  # couplée à l'identité de groupe pour le contrôle d'accès granulaire.
  # Le déchiffrement ssl_forward_proxy est OBLIGATOIRE : sans lui, DLP, IPS et
  # c2_protection voient un flux HTTPS opaque et sont inopérants.
  - application:
      app_id: saas_generic
      # category: saas — catégorie canonique pour les applications SaaS (taxonomy §1).
      category: saas
      default_ports:
        - tcp/443
      # depends_on : dns est requis pour résoudre les FQDNs des endpoints SaaS.
      depends_on:
        - dns
        - ssl
      # risk=3 : SaaS approuvé, mais vecteur d'exfiltration et de C2 identifié.
      risk: 3

    # identity : OBLIGATOIRE pour les règles d'accès sortant (principle of least privilege).
    # user_group restreint l'accès aux groupes annuaire autorisés — pas à l'ensemble des
    # utilisateurs du réseau interne (shadow IT mitigation).
    identity:
      user_group:
        - "saas_authorized_users"
        - "remote_workers"
      # device_posture: compliant — seuls les postes gérés ET conformes (MDM, patches,
      # agents de sécurité actifs) peuvent accéder au SaaS. Un poste non conforme
      # (ex. patching en retard) est exclu automatiquement.
      device_posture: compliant

    zones:
      source:
        - internal
      destination:
        - internet

    direction: outbound

    service:
      protocol: tcp
      ports:
        - "443"
      app_default: true

    action: allow

    # security_profiles : profils complets — obligatoires sur action=allow (CLAUDE.md).
    security_profiles:

      # antivirus : inspection des fichiers téléchargés depuis le SaaS (downloads).
      # action: block — les fichiers malveillants en provenance du SaaS sont bloqués.
      antivirus:
        action: block

      # ips : protection contre les exploits applicatifs dans les réponses SaaS.
      # Un SaaS compromis ou un CDN détourné peut servir des exploits navigateur.
      # min_severity: medium — seuil équilibré pour les flux sortants d'utilisateurs.
      ips:
        action: block
        min_severity: medium

      # c2_protection : blocage des communications C2 via le canal SaaS.
      # Un poste compromis peut utiliser les APIs d'un SaaS approuvé comme relais C2
      # (ex. polling d'un bucket de stockage cloud pour des instructions).
      # min_severity: medium — les faux positifs sur un SaaS légitime sont plus fréquents.
      c2_protection:
        action: block
        min_severity: medium

      # url_filtering : blocage des SaaS non approuvés et des catégories à risque.
      # block_categories empêche l'accès au shadow IT et aux proxies d'évitement
      # qui tenteraient de contourner le ssl_forward_proxy.
      url_filtering:
        block_categories:
          - malware
          - phishing
          - c2
          - newly_registered_domain
          - proxy_avoidance
          - hacking
        alert_categories:
          - unknown
          - parked
          - grayware
        # uncategorized_action : durcissement — bloque les sites non catégorisés.
        uncategorized_action: block
        # credential_phishing : empêche la soumission d'identifiants d'entreprise vers
        # des sites non fiables. Effectif UNIQUEMENT grâce au ssl_forward_proxy ci-dessous
        # (sans déchiffrement, seul le SNI est visible — cf. linter LNT-004).
        credential_phishing: block

      # file_control : contrôle des types de fichiers en upload SORTANT.
      # Direction outbound : on contrôle ce que les utilisateurs envoient vers le SaaS.
      # Les types de fichiers sensibles (archives chiffrées, bases de données) sont bloqués
      # pour limiter l'exfiltration non détectée par le DLP.
      file_control:
        block_types:
          - "encrypted_archive"
          - "database_dump"
        direction: outbound

      # sandboxing : détonation des fichiers téléchargés depuis le SaaS.
      # Les SaaS de partage de fichiers peuvent servir de vecteur de distribution de malware.
      sandboxing:
        enabled: true
        file_types:
          - "pe"
          - "pdf"
          - "office"
          - "script"

      # dns_security : sinkhole des domaines malveillants dans le flux DNS associé.
      # Protège contre le DNS hijacking et les domaines typosquattés imitant le SaaS.
      dns_security:
        action: block
        sinkhole: true

      # dlp : OBLIGATOIRE sur ce scénario — c'est le contrôle central contre l'exfiltration.
      # patterns : identifiants logiques des types de données sensibles à détecter.
      # L'action block arrête l'upload si un pattern est détecté dans le flux inspecté.
      # ATTENTION : le DLP ne fonctionne QUE si ssl_forward_proxy est actif (voir decryption).
      dlp:
        patterns:
          - "credit_card"        # Numéros de carte bancaire (PAN)
          - "national_id"        # Numéros d'identité nationale
          - "iban"               # Coordonnées bancaires
          - "api_key"            # Clés d'API en clair (risque de fuite de credentials)
          - "pii_email"          # Emails personnels dans des contextes non attendus
          - "source_code"        # Blocs de code source (propriété intellectuelle)
        action: block

    # decryption : ssl_forward_proxy OBLIGATOIRE pour l'inspection du trafic HTTPS sortant.
    # Sans déchiffrement sortant, DLP, IPS et c2_protection sont aveugles sur le contenu.
    #
    # exclusions : catégories exclues du déchiffrement pour des raisons légales et de vie privée.
    # - finance : les accès aux services bancaires et financiers ne sont pas déchiffrés
    #   (réglementation PCI-DSS, obligation légale dans certaines juridictions).
    # - health : les accès aux portails de santé ne sont pas déchiffrés (HIPAA, RGPD
    #   données de santé — données de catégorie spéciale, risque légal élevé).
    # Ces exclusions créent un angle mort documenté et accepté. Elles doivent être
    # auditées régulièrement pour éviter leur détournement (ex. un SaaS malveillant
    # qui se déguise en service financier).
    decryption:
      mode: ssl_forward_proxy
      exclusions:
        - finance
        - health

    logging:
      log_start: false
      log_end: true
      log_forwarding: true
      profile: "siem_dlp_priority"

    rationale:
      fr: |
        Cette règle autorise les utilisateurs des groupes annuaire autorisés (postes
        conformes uniquement) à accéder aux SaaS approuvés via HTTPS sortant.
        Le déchiffrement ssl_forward_proxy est activé pour permettre l'inspection L7
        complète — sans lui, le DLP (contrôle central d'exfiltration) est inopérant.
        Les exclusions finance et health respectent les contraintes légales et de vie privée
        et créent un angle mort explicitement documenté. Le profil DLP bloque les uploads
        contenant des données sensibles (PAN, PII, code source). Le user_group restreint
        l'accès au principe de moindre privilège et limite le shadow IT. La conformité
        du poste (device_posture: compliant) empêche les accès depuis des équipements
        non gérés ou compromis.
      en: |
        This rule allows users in the authorized directory groups (compliant devices only)
        to access approved SaaS services over outbound HTTPS. The ssl_forward_proxy
        decryption mode is enabled to allow full L7 inspection — without it, DLP (the
        central exfiltration control) is inoperative. The finance and health exclusions
        respect legal and privacy constraints and create an explicitly documented blind
        spot. The DLP profile blocks uploads containing sensitive data (PAN, PII, source
        code). The user_group restricts access to the least-privilege principle and limits
        shadow IT. Device compliance (device_posture: compliant) prevents access from
        unmanaged or compromised endpoints.

  # ── Règle 2 : Dépendance DNS — résolution des FQDNs SaaS ───────────────────
  # Les clients internes ont besoin de résoudre les FQDNs des endpoints SaaS
  # (ex. api.saas-vendor.example, cdn.saas-vendor.example).
  # Le flux DNS est restreint vers un résolveur interne de confiance (pas directement
  # vers Internet) pour éviter le DNS rebinding et le tunneling DNS.
  # La règle est séparée car le flux (trust->internal) et la direction (internal) diffèrent
  # du flux principal.
  - application:
      app_id: dns
      category: networking
      default_ports:
        - udp/53
        - tcp/53
      risk: 2

    zones:
      source:
        - trust
      destination:
        - internal

    direction: internal

    service:
      protocol: udp
      ports:
        - "53"
      app_default: true

    action: allow

    security_profiles:
      # dns_security + sinkhole : atténue le tunneling DNS.
      # Un poste compromis dans le réseau interne peut tenter d'utiliser le DNS comme
      # canal C2 (T1071.001 via DNS) ou d'exfiltrer via des sous-domaines encodés.
      dns_security:
        action: block
        sinkhole: true

    # decryption mode: none — DNS UDP standard n'est pas chiffré.
    # Justification : protocole non chiffré par nature ; le déchiffrement est N/A.
    # Note : DNS-over-HTTPS (DoH) est couvert par ssl_forward_proxy sur le flux principal.
    decryption:
      mode: none

    logging:
      log_end: true
      log_forwarding: true
      profile: "siem_default"

    rationale:
      fr: |
        La résolution DNS est requise pour que les postes internes puissent résoudre les
        FQDNs des services SaaS. Le flux est restreint vers un résolveur interne contrôlé
        (moindre privilège, pas de résolution directe vers Internet). Le profil dns_security
        avec sinkhole bloque le tunneling DNS depuis les postes compromis. Le déchiffrement
        est non applicable : DNS UDP standard n'est pas un flux chiffré.
      en: |
        DNS resolution is required for internal endpoints to resolve SaaS service FQDNs.
        The flow is restricted to a controlled internal resolver (least privilege, no
        direct Internet resolution). The dns_security profile with sinkhole blocks DNS
        tunneling from compromised endpoints. Decryption is not applicable: standard
        DNS over UDP is not an encrypted flow.

  # ── Règle 3 : Deny — SaaS non approuvés et trafic HTTPS non identifié ───────
  # Cette règle de shadow IT mitigation bloque l'accès à tout service SaaS non
  # explicitement approuvé. Elle s'applique à TOUS les utilisateurs (pas uniquement
  # le groupe autorisé) pour couvrir les tentatives de contournement.
  # Note : l'absence de security_profiles sur action=drop est correcte — les profils
  # d'inspection ne s'appliquent que sur action=allow (taxonomy §6 et §7).
  - application:
      app_id: saas_generic
      category: saas
      default_ports:
        - tcp/443
      risk: 4

    zones:
      source:
        - internal
      destination:
        - internet

    direction: outbound

    service:
      protocol: tcp
      ports:
        - "443"
      app_default: true

    # action: drop — blocage silencieux du shadow IT non approuvé.
    action: drop

    logging:
      log_start: true
      log_end: true
      log_forwarding: true
      profile: "siem_high_priority"

    rationale:
      fr: |
        Règle de shadow IT mitigation : tout accès à un SaaS depuis le réseau interne qui
        ne correspond pas aux critères d'identité et de conformité de la règle principale
        (groupe non autorisé, poste non conforme) est bloqué silencieusement. Cela inclut
        les tentatives d'accès à des SaaS non approuvés depuis des postes non gérés.
        Le log en mode high_priority permet de détecter les comportements anormaux et
        les tentatives de contournement de la politique (shadow IT, insider threat).
      en: |
        Shadow IT mitigation rule: any SaaS access from the internal network that does not
        match the identity and compliance criteria of the main rule (unauthorized group,
        non-compliant device) is silently dropped. This includes attempts to access
        unapproved SaaS services from unmanaged devices. High-priority logging enables
        detection of abnormal behavior and policy circumvention attempts (shadow IT,
        insider threat).
