La détection des menaces AWS consiste à identifier et à hiérarchiser les activités malveillantes ou suspectes dans AWS en analysant cloud à la recherche de signes de comportement d'attaquant.
Plutôt que d'évaluer des événements isolés, cette approche examine ce qu'un acteur fait à travers ses identités, ses rôles et ses services. Les environnements AWS génèrent de grands volumes de journaux et de métadonnées qui sont difficiles à interpréter indépendamment. Le fait de relier ces données télémétriques à des signaux comportementaux permet de révéler les mouvements des attaquants tout au long du cycle de vie cloud , ce qui est important car des activités non corrélées peuvent retarder l'enquête et la réponse.
En pratique, la détection des menaces AWS relie les actions connexes à des modèles comportementaux qui peuvent être examinés et classés par ordre de priorité. Plutôt que de traiter cloud comme un ensemble d'alertes sans rapport entre elles, elle interprète l'activité comme la preuve d'une possible séquence d'attaques. Cette distinction est importante, car de nombreuses actions AWS sont techniquement légitimes tout en représentant un abus d'accès, de rôles ou de services.
Afin de réduire l'incertitude pendant les enquêtes, la détection des menaces AWS se concentre sur les comportements qui indiquent la progression des attaquants, notamment les types d'activités suivants qui révèlent leurs intentions au fil du temps et à travers les services :
La surveillance centrée sur les journaux dans AWS ne parvient souvent pas à mettre en évidence le comportement des attaquants, car les événements sont analysés comme des enregistrements autonomes. L'attribution s'arrête fréquemment au rôle ou aux informations d'identification temporaires les plus récents, ce qui conduit les enquêtes à se concentrer sur une abstraction erronée. En conséquence, les défenseurs peuvent ne pas identifier l'acteur d'origine à temps pour contenir l'activité avant qu'elle n'ait un impact.
Pour éviter de mal hiérarchiser les tâches, les équipes doivent reconnaître les modes de défaillance spécifiques qui peuvent se produire lorsque l'activité AWS est évaluée comme des événements isolés :
Pour comprendre comment les pirates informatiques se déplacent dans AWS, il faut aller au-delà des actions individuelles des services. La détection axée sur le comportement met en évidence des schémas de progression, tels que l'enchaînement des rôles, le contournement de la journalisation et l'accès latéral aux services, qui peuvent sembler légitimes lorsqu'ils sont considérés isolément.
Afin que les enquêtes restent axées sur les risques réels, la détection des menaces AWS met en évidence les comportements des attaquants qui ont de l'importance, car ils indiquent la séquence, l'intention et l'impact opérationnel :
Découvrez comment les pirates exploitent les rôles et les identités sur AWS →
Tous les signaux dans AWS n'ont pas la même valeur pour l'enquête. Les efforts de détection donnent la priorité aux indicateurs qui reflètent un comportement anormal ou en plusieurs étapes lié à un acteur spécifique. Les indicateurs précoces peuvent être subtils et dispersés, tandis que les signaux tardifs n'apparaissent souvent qu'après que des dommages importants se sont produits.
Pour accélérer le triage sans avoir à deviner l'intention derrière un événement, la détection des menaces AWS s'appuie sur des signaux pertinents, car ils permettent d'attribuer une activité et d'identifier sa progression :
La détection des menaces dans AWS a encore ses limites. Bien qu'elle permette d'identifier les comportements suspects, la détection des menaces n'empêche pas automatiquement les risques cloud et n'y remédie pas. Cela signifie que les équipes doivent toujours s'appuyer sur des workflows de réponse et le jugement des analystes. Confondre détection et prévention peut créer des angles morts qui retardent la maîtrise des menaces.
Voici quelques idées reçues courantes concernant la détection des menaces :
Pour prendre en charge la détection des menaces AWS, il est nécessaire de comprendre le comportement des attaquants à travers les identités, le réseau et cloud comme un continuum unique. La Vectra AI aborde ce problème en corrélant les actions plutôt qu'en traitant les événements AWS comme des alertes isolées, ce qui réduit l'incertitude lorsque les rôles, les identifiants temporaires et l'activité multiservices obscurcissent l'attribution.
Pour plus de clarté, la Vectra AI est conçue pour vous aider en :
Suivez cette visite guidée des attaques AWS pour découvrir comment les identités compromises, le chaînage des rôles, les mouvements latéraux et les activités d'exfiltration s'articulent en une seule progression d'attaque, et comment les équipes peuvent mener l'enquête et réagir avec clarté.
La surveillance CloudTrail enregistre les événements individuels, tandis que la détection des menaces AWS vise à relier les événements entre les identités, les rôles, les services et le temps afin de révéler le comportement des attaquants. Les événements isolés consignés dans les journaux peuvent montrer ce qui s'est passé, mais ils ne révèlent souvent pas l'intention ou la progression, en particulier lorsque les attaquants utilisent des identifiants temporaires et des rôles usurpés. La différence pratique réside dans l'investigation : la détection des menaces donne la priorité aux modèles de comportement en plusieurs étapes qui peuvent être attribués et sur lesquels il est possible d'agir, au lieu de laisser les analystes assembler manuellement le récit à partir des journaux bruts.
Non. La détection des menaces AWS ne permet pas à elle seule de prévenir ou de corriger les problèmes d'architecture ou de configuration. La gestion des erreurs de configuration vise à identifier les paramètres non sécurisés et les conditions d'exposition, tandis que la détection des menaces vise à identifier les activités malveillantes ou suspectes qui se produisent dans un environnement AWS. Il est important de ne pas confondre ces fonctions, car les équipes pourraient supposer que la détection remplace la sécurité de la configuration, laissant ainsi les principaux points d'entrée sans protection tout en espérant que la détection des menaces compensera cette lacune.
L'identité et les rôles sont essentiels, car les attaquants utilisent souvent des mécanismes d'accès légitimes après la compromission initiale, notamment des rôles usurpés et des identifiants temporaires. Les actions peuvent sembler valides au niveau de l'API, même lorsqu'elles constituent un abus. Il est donc essentiel de déterminer qui a lancé une séquence et si celle-ci correspond au comportement attendu. Cela est important, car l'enchaînement des rôles peut masquer l'acteur d'origine, et les enquêtes peuvent échouer si elles s'arrêtent au dernier rôle temporaire utilisé.
Les comportements en plusieurs étapes qui utilisent des mécanismes AWS légitimes sont les plus difficiles à détecter lorsqu'ils sont évalués événement par événement. Le chaînage des rôles, les séquences d'informations d'identification temporaires et les actions qui semblent normales prises isolément nécessitent souvent une corrélation entre les services et les identités pour devenir significatifs. Ces modèles sont difficiles à détecter, car ils peuvent être répartis sur plusieurs services AWS et fenêtres temporelles, et parce que les dernières informations d'identification utilisées peuvent ne pas refléter l'acteur d'origine. Cela est important, car les comportements subtils à un stade précoce peuvent passer inaperçus jusqu'à ce que des indicateurs apparaissent à un stade avancé.
Oui, mais uniquement lorsque l'approche relie les activités entre les environnements au lieu de traiter AWS comme un domaine isolé. Les attaques hybrides peuvent provenir d'ordinateurs portables compromis ou de fournisseurs d'identité, puis se propager vers AWS en utilisant des relations d'identité fiables et des rôles assumés. Sans corrélation entre l'identité et la télémétrie associée, l'activité AWS peut sembler déconnectée du chemin d'attaque initial. Cela est important, car les défenseurs doivent comprendre comment cloud sont liées à l'accès initial afin de définir correctement la portée de la réponse et l'attribution.