Dans le domaine du Secure Access Service Edge (SASE), l’intégration de systèmes de détection et de prévention des intrusions (IDPS) est presque universelle.
Son rôle ne se limite pas à contrecarrer les exploits connus, il sert de sentinelle vigilante pour les IOC (Indicateurs de Compromis), offrant ainsi une couche de protection complète.
Je dirais même que l’IDPS est de plus en plus utilisé par les organisations pour les indicateurs de compromission et les indicateurs d’attaque.
La puissance de l’IDPS réside dans sa capacité à fournir de riches informations sur le trafic réseau ; il ne se contente pas d’extraire des métadonnées de connexion telles que les 5 tuples de la connexion, mais se plonge également dans les détails nuancés de divers champs de protocole.
Cette profondeur d’extraction permet d’obtenir des informations inestimables sur les caractéristiques des données qui traversent le réseau, améliorant ainsi la connaissance du contexte.
IDPS utilise plusieurs méthodes pour renforcer la sécurité du réseau.
Il détecte et bloque efficacement les exploits et les logiciels malveillants connus grâce à des méthodes de détection basées sur les signatures.
En outre, il se protège contre les données anormales en employant des règles capables d’identifier des paquets ou des flux irréguliers.
Ces règles étendent leur champ d’application aux tailles anormales des attributs de protocole et aux comportements imprévus des valeurs de protocole.
Si les caractéristiques et l’efficacité des IDPS dans le cadre de SASE peuvent varier légèrement d’un fournisseur de services à l’autre, les capacités de base restent largement similaires, en raison de l’utilisation de bases de données de signatures provenant généralement de fournisseurs tiers de renseignements sur les menaces.
En outre, les technologies IDPS ont mûri et développé des capacités similaires, même face aux multiples techniques d’évasion employées par les attaquants.
Selon moi, la principale différence entre les fournisseurs réside dans le domaine de l’observabilité et dans les facilités qu’ils offrent pour la chasse aux menaces, en mettant l’accent sur la minimisation des faux positifs et des faux négatifs.
L’objectif de cet article n’est pas d’approfondir la différenciation des caractéristiques IDPS entre les services SASE.
Il cherche plutôt à explorer les points précis du trajet des paquets où les fonctions IDPS sont exécutées par les services SASE et à déterminer si ces points d’insertion détectent efficacement les schémas d’attaque dans le trafic d’origine.
Certains pensent qu’il suffit d’incorporer la fonctionnalité du système de détection et de prévention des intrusions (IDPS) au niveau du proxy dans les services Secure Access Service Edge (SASE).
Leur raisonnement repose sur le fait que de nombreuses organisations utilisent déjà le système IDPS OnPrem pour la détection des intrusions sur le trafic générique.
Le principal problème de l’IDPS OnPrem réside dans son incapacité à inspecter le trafic crypté TLS.
Étant donné que les proxys SASE effectuent une inspection TLS de type MITM (Man-in-the-Middle), ils ont accès au trafic non crypté.
Par conséquent, on estime qu’il est suffisant d’avoir le point d’insertion de l’IDPS au niveau des serveurs mandataires.
En outre, certains affirment qu’un grand nombre de systèmes sont correctement protégés contre les attaques au niveau du réseau (L3/L4) et au niveau TLS.
En réponse, les attaquants se sont recentrés sur l’emploi de tactiques plus sophistiquées au niveau des applications (L7) et des données.
Par conséquent, l’idée qui prévaut est qu’il est justifié de ne pas étendre la fonctionnalité IDPS au-delà du niveau proxy au sein du réseau.
Toutefois, cet argument n’est pas valable dans tous les cas. Pensez aux appareils IoT qui continuent à fonctionner avec des systèmes d’exploitation plus anciens et rarement mis à jour.
Ces appareils peuvent rester vulnérables à un plus grand nombre d’attaques, ce qui nécessite une approche globale de la sécurité.
Beaucoup reconnaissent également que les services SASE doivent intégrer l’IDPS aux niveaux proxy et L3 pour garantir l’inspection complète de tout le trafic réseau.
Pour parvenir à une détection complète des attaques, la fonctionnalité IDPS devrait être appliquée non seulement au niveau du proxy, comme nous l’avons vu plus haut, mais aussi au niveau des interfaces WAN, où le trafic entre et sort des interfaces désignées pour le trafic en provenance et à destination de l’internet.
Bien que cette approche représente une amélioration par rapport au déploiement de l’IDPS uniquement au niveau du proxy, elle pose un problème.
Dans les cas où le trafic passe par les proxys, l’IDPS peut ne pas avoir de visibilité sur le trafic d’origine dans les deux sens des sessions.
En règle générale, les serveurs mandataires mettent fin aux connexions et en établissent de nouvelles.
Comme ils s’appuient sur la pile TCP/IP locale, ils réassemblent les paquets d’origine, réordonnent les données TCP, recréent les options IP/TCP et régénèrent les messages d’échange TLS.
Par conséquent, l’IDPS au niveau de l’interface WAN peut manquer de visibilité sur le trafic original provenant du réseau interne, ce qui peut l’amener à ignorer des schémas d’attaque qui faisaient partie du trafic original.
Il convient de noter que les attaquants ne sont pas toujours externes ; il peut également s’agir d’attaquants internes.
En outre, les attaques peuvent provenir de systèmes internes en raison d’infections antérieures par des logiciels malveillants.
Il est donc essentiel de veiller à ce que l’IDPS observe en permanence le trafic d’origine dans les deux sens pour une détection et une prévention efficaces des menaces.

Recherchez des services SASE avec plusieurs points d’insertion IDPS

Nous préconisons que les services SASE offrent la flexibilité d’insérer des IDPS en plusieurs points, tous actifs simultanément.
Les organisations devraient avoir la liberté de choisir de déployer l’IDPS à chaque interface L3 et au niveau du proxy.
Cette approche permet à l’IDPS d’inspecter le trafic original à partir des terminaux client et serveur des sessions, même lorsque le trafic est crypté TLS et qu’il passe par les proxys.
En outre, les organisations devraient rechercher activement des services SASE qui évitent de générer des alertes et des journaux en double résultant de points d’insertion multiples.
Par exemple, le trafic qui ne passe par aucun proxy mais qui traverse plusieurs interfaces L3 (reçu sur une interface et envoyé par une autre) peut être vu par deux instances IDPS, ce qui peut entraîner des alertes et des journaux en double.
Il est conseillé aux organisations de veiller à ce que cette redondance des journaux soit réduite au minimum, afin d’éviter d’inonder le personnel administratif qui est déjà aux prises avec un volume élevé de journaux générés par les fonctions de sécurité.
Idéalement, les services SASE devraient faire preuve d’intelligence sur la base d’une session de trafic et éviter intelligemment l’exécution en double de la fonction IDPS si aucune modification du trafic n’a lieu au sein du service SASE.
En outre, les organisations devraient rechercher des solutions qui permettent la corrélation des journaux générés par de multiples fonctions de sécurité, y compris diverses instances IDPS, pour une session de trafic donnée.
Cette corrélation permet d’améliorer l’observabilité et de rationaliser le travail des chasseurs de menaces en simplifiant le mappage des événements de sécurité.
Conscientes de la forte intensité de calcul de l’IDPS, les organisations devraient également s’efforcer de conserver les ressources dans la mesure du possible.
Par exemple, si elles utilisent déjà des IDS hôtes (HIDS) ou des IDPS sur site, elles peuvent souhaiter garder le contrôle sur la désactivation des IDPS sur des instances spécifiques pour certains types de trafic.
Les services SASE qui offrent un pilotage de l’IDPS basé sur des politiques peuvent permettre aux organisations de dicter quel trafic doit être inspecté par différentes instances IDPS dans le cadre de SASE.
En résumé, l’efficacité de l’IDPS dans le paradigme SASE va au-delà de ses caractéristiques ; elle dépend de la flexibilité que SASE offre en ce qui concerne les points d’insertion de l’IDPS et du degré de contrôle qu’il permet aux organisations d’aligner sur leurs exigences spécifiques.

  • Blog CTO Insights

    La série de blogs Aryaka CTO Insights fournit un leadership éclairé sur les thèmes du réseau, de la sécurité et de la SASE.
    Pour les spécifications des produits Aryaka, consultez les fiches techniques d’Aryaka.