Surveillance sur mesure avec des règles de configuration AWS personnalisées

Chez FloQast, nous sommes toujours à la recherche de nouveaux moyens d'accroître la visibilité de nos environnements et de trouver des opportunités d'amélioration de la sécurité. À cette fin, en juin 2022, nous avons mis en place une surveillance des instances AWS EC2 utilisant des images de machine Amazon non approuvées. En plus de pouvoir détecter les anomalies, nous avions besoin d'une solution qui nous permettrait de :

• Évaluer les configurations avec un haut degré de flexibilité
• Déclenchement fiable de l'évaluation en cas de modification des ressources
• Gestion centralisée des configurations dans plusieurs environnements
• Alerte sur les détections
• Flexibilité et fiabilité

Le choix naturel serait d'utiliser AWS Config, mais cela fonctionnera-t-il ? AWS fournit en fait une option de règle par défaut pour les AMI approuvées, mais elle est limitée à une liste de 10 ID. Que se passe-t-il si vous souhaitez pouvoir étendre la liste et évaluer les images en fonction d'autres attributs que l'ID ? Heureusement, Config prend en charge les règles Lambda personnalisées, qui permettent à la logique d'évaluation d'être aussi sophistiquée que nécessaire. Config découvre les ressources et enregistre les éléments de configuration pour les changements, ce qui répond à nos deux premières exigences.

Gestion centrale

Une gestion centralisée peut être obtenue en combinant AWS Config avec AWS Organizations. En désignant un compte comme administrateur délégué pour Config, les règles peuvent être définies et mises à jour dans les comptes membres sans effort supplémentaire. L'activation des permissions d'administrateur délégué ne nécessite que quelques commandes. Nous pouvons même exiger que la lambda d'évaluation réside dans le compte de l'administrateur délégué. Cela signifie que nous devons également configurer des rôles inter-comptes pour permettre à la lambda d'interroger les données des comptes membres et de renvoyer le résultat de l'évaluation.

C'est une bonne chose car si nous devons modifier la logique de la règle, il n'y a qu'une seule lambda à mettre à jour. Cela nous donne également l'assurance que la logique de la règle ne peut pas être mise à jour par un utilisateur privilégié potentiellement compromis dans un compte de membre.

Alerte

L'alerte en cas de détection est l'étape la plus intéressante. Notre objectif initial était d'intégrer les alertes dans notre processus de gestion des vulnérabilités AWS, qui repose sur AWS SecurityHub. S'il était possible de tout intégrer dans SecurityHub, notre outil existant serait en mesure d'interroger SecHub pour obtenir les résultats pertinents et de gérer le reste (Spoiler Alert : AWS fournit maintenant cela en mode natif, mais nous y reviendrons plus tard). À première vue, cela semble facile, car Config inclut l'option d'agréger les évaluations de règles à partir des comptes d'organisation. Cependant, la configuration de l'agrégation ne rend pas les données des autres comptes accessibles à partir d'une source unique, sauf par le biais de la console. Pouvoir cliquer entre les comptes dans la console est une bonne chose, mais les points de terminaison qui le permettent ne sont pas mis à la disposition des utilisateurs.

Nous avons essayé de mettre en place un bus EventBridge pour collecter les événements Config pour les règles qui nous intéressaient, mais Config n'émet pas réellement d'événements pour les évaluations qui sont agrégées à partir d'autres comptes. Il serait possible de mettre en place un bus d'événements dans chaque compte et de les faire converger vers le compte de gestion, mais cela devient désordonné et entre en conflit avec notre objectif de gestion centrale. Nous avons également envisagé d'utiliser le sujet Config SNS, mais il n'y a aucun moyen de filtrer efficacement une règle spécifique puisque les attributs du message Config SNS ne peuvent pas être configurés.

Architecture finale

Après quelques essais et erreurs, il est devenu clair que la meilleure solution était de supprimer l'intermédiaire. La lambda d'évaluation reçoit déjà tout ce dont elle a besoin pour envoyer une alerte, alors pourquoi ne pas lui faire écrire un journal dans un seau S3 pour qu'il soit ingéré par notre SIEM, ainsi que pour qu'il fasse un rapport à Config ? Bien que nous n'ayons pas accès aux mises à jour automatiques de l'état des ressources par Config, nous aurions un moyen fiable d'être informés des problèmes.

Nous avons fini par opter pour l'approche lambda à double sortie, mais quelques jours plus tard, nous avons découvert qu'AWS avait ajouté une fonctionnalité permettant d'intégrer nativement Config et SecHub. C'est bien d'avoir été en avance sur la courbe, mais une telle annonce est vraiment douce-amère dans les circonstances actuelles. SecHub ne convient peut-être pas à toutes les organisations, de sorte que l'approche lambda peut encore être utile pour certaines applications.

Conformément aux conventions informelles établies à FloQast, cet outil a été baptisé, par le biais d'un backronyme, Italic, ou "Image Trust Allow-List Inspection Controller" (contrôleur d'inspection de la liste d'autorisation de la confiance dans les images). À l'avenir, nous pourrons l'étendre pour ajouter plus de règles et couvrir plus de types de ressources, mais pour l'instant, il remplit efficacement son objectif de surveillance des images non autorisées.

Trevr Fernald

Trevr est ingénieur en sécurité chez FloQast et se passionne pour l'automatisation et la résolution de problèmes. En dehors du travail, il aime lire, jouer de la guitare et skier.