NeuralWall Rules Kit
reviewed saas_outbound_access

Accès sortant des utilisateurs internes vers un SaaS via Internet

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.

Schéma:
1.0.0
Version:
1.0.0
Auteurs:
NeuralWall Rules Team (NeuralWall)

Confiance & attestations

Trust tierreviewed
Chargement des infos de confiance…
community
reviewed
verified

Prochain palier : verified
Aperçu {} Machine JSON AI IA/RAG Markdown ~ YAML source RAG [en]

Modèle de menace

Résumé
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é.
Objectif attaquant
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.
Contrôles clés
ssl_forward_proxydlpc2_protectionidentity_user_groupdevice_postureurl_filteringdns_security

MITRE ATT&CK

Technique Nom Tactique
T1567.002 Exfiltration Over Web Service: Exfiltration to Cloud Storage exfiltration
T1071.001 Application Layer Protocol: Web Protocols command-and-control
T1078 Valid Accounts defense-evasion
T1048 Exfiltration Over Alternative Protocol exfiltration

Règles

# App ID Action Direction Zones Risque Profils sécurité Déchiffrement
0 saas_generic allow outbound internal → internet 3 antivirus, c2_protection, dlp, dns_security, file_control, ips, sandboxing, url_filtering ssl_forward_proxy
1 dns allow internal trust → internal 2 dns_security none
2 saas_generic drop outbound internal → internet 4 — —

Détail des règles

Règle 0 — saas_generic (allow)

Rationale

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.

Application

app_id:
saas_generic
category:
saas
risk:
3
depends_on:
dns, ssl

Zones

internal → internet

direction: outbound

Profils de sécurité

antivirus: action=block c2_protection: action=block, min_severity=medium dlp: action=block, patterns=credit_card+national_id+iban+api_key+pii_email+source_code dns_security: action=block, sinkhole=true file_control: block_types=encrypted_archive+database_dump, direction=outbound ips: action=block, min_severity=medium sandboxing: enabled=true, file_types=pe+pdf+office+script url_filtering: alert_categories=unknown+parked+grayware, block_categories=malware+phishing+c2+newly_registered_domain+proxy_avoidance+hacking, credential_phishing=block, uncategorized_action=block

Déchiffrement

mode=ssl_forward_proxy

exclusions: finance, health

Journalisation

log_start: false
log_end: true
forwarding → siem_dlp_priority

Règle 1 — dns (allow)

Rationale

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é.

Application

app_id:
dns
category:
networking
risk:
2

Zones

trust → internal

direction: internal

Profils de sécurité

dns_security: action=block, sinkhole=true

Déchiffrement

mode=none

Journalisation

log_end: true
forwarding → siem_default

Règle 2 — saas_generic (drop)

Rationale

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).

Application

app_id:
saas_generic
category:
saas
risk:
4

Zones

internal → internet

direction: outbound

Journalisation

log_start: true
log_end: true
forwarding → siem_high_priority