Le Cloud est sur toutes les lèvres, surtout en ces temps inhabituels de travail à distance. De nombreuses organisations revoient la manière avec laquelle elles conçoivent et mettent en œuvre leurs activités afin de passer avec succès vers des fournisseurs de services cloud (CSP). Mais cette tendance « Move to Cloud » pourrait aussi être l’occasion pour les équipes de sécurité de reprendre le contrôle et de détecter les incidents mieux que jamais !
L’année dernière, j’ai eu la chance de travailler avec différentes organisations dans leur transformation du Cloud, et chacune d’elles a fourni à notre équipe de consultants Wavestone des idées et des leçons clés sur ce que les systèmes de détection basés sur le Cloud peuvent et ne peuvent pas apporter à une organisation.
Au cours de cette année, j’ai eu la chance de travailler avec différentes organisations dans leur transformation Cloud, et chacune d’entre elles a fourni à notre équipe de consultants Wavestone des retours d’expériences et des leçons clés sur ce que les systèmes de détection basés sur le Cloud peuvent et ne peuvent pas apporter à une organisation.
Pour cet article, gardez à l’esprit que nous considérerons tout changement de configuration conduisant à une dégradation du niveau de sécurité comme un incident. Bien qu’il ne corresponde peut-être pas à la définition exacte et habituelle d’un incident de sécurité, la mauvaise configuration d’un service public cloud (où les ressources et les données peuvent être directement accessibles par Internet) est un problème trop grave pour ne pas donner lieu à une alerte immédiate sur la sécurité du système d’information.
Embrassez les victoires rapides
Lorsque vous utilisez le Public Cloud des principaux fournisseurs (Amazon Web Services, Microsoft Azure et Google Cloud Platform), il est assez facile d’activer les fonctionnalités de détection natives et de d’obtenir une capacité de détection basique mais efficace. La plupart des éditeurs fournissent une plateforme de sécurité centrale qui vous permettra de détecter les erreurs de configuration sur l’infrastructure que vous avez déployée, d’évaluer votre niveau de conformité par rapport à une norme donnée et de lever certaines alertes lorsque les incidents les plus typiques se produiront (voir plus loin). Il n’y a pratiquement aucune raison de passer sur ces fonctionnalités, qui sont parfois gratuites à activer (que ce soit pour un essai ou de manière permanente).
En outre, la journalisation est quasiment un non-problème dans votre feuille de route de sécurité. Les fournisseurs de cloud vous permettent généralement de diffuser les journaux de vos machines virtuelles (par l’intermédiaire d’agents), de vos composants PaaS (via une poignée de clics, ou de quelques paramètres dans vos modèles d’Infrastructure as Code) et du plan de gestion (management plane) de votre abonnement (souvent activé par défaut). Cela permet à votre équipe de sécurité de comprendre rapidement l’activité en cours sur la plate-forme et de commencer à construire sur la base des journaux pour obtenir quelques alertes. En outre, certains fournisseurs de cloud possèdent des systèmes SIEM (tels que Azure Sentinel) prêts à être branchés via des connecteurs pour les appliances et les sources de données externes. Ces systèmes SIEM analysent les journaux et retire une partie du travail lourd nécessaire lors de la mise en place de la journalisation.
Saisissez l’occasion d’améliorer la sécurité dès maintenant
Une fois que vous avez appris les bases des outils natifs de détection Cloud, il est temps de construire votre propre expertise pour pouvoir compter sur vos propres outils ! Vous pouvez également vous appuyer sur des solutions tierces telles que les solutions de gestion de la posture de sécurité dans les Cloud (CSPM) et les configurer de manière à couvrir vos besoins.
Comme indiqué ci-dessus, les fonctionnalités natives des fournisseurs de services Cloud offrent quelques alertes de base qui peuvent aller loin. Avec AWS Guard Duty, vous pouvez détecter la compromission des jetons d’accès AWS EC2 ou un accès anormal aux seaux S3. Azure Security Center vous avertira lorsqu’une activité potentiellement malveillante est détectée sur une machine virtuelle, ou lorsque les comptes Azure AD sont susceptibles d’être pris en charge… Si vous devez être capable de détecter rapidement des attaques, il existe un moyen d’exploiter les alertes natives et prêtes à l’emploi disponibles (bien que certaines d’entre elles puissent nécessiter la licence premium après un essai gratuit).
L’un des principaux avantages de la détection du Cloud est que vous pouvez agir immédiatement en y remédiant automatiquement ! Par exemple, les erreurs de configuration sont une réelle source de préoccupation pour les équipes de sécurité, comme en témoignent les téraoctets de données qui ont fui par des seaux S3 accidentellement exposés. Alors pourquoi ne pas reconfigurer tout seau exposé, à moins qu’il n’ait été spécifiquement défini dans une « liste d’autorisation » ? L’automatisation vous permettra de détecter le modèle d’exposition, de lancer une fonction sans serveur qui corrigera la mauvaise configuration et pourrait même avertir le propriétaire de la ressource ou l’équipe de sécurité.
Cela peut être fait pour une mauvaise configuration, mais aussi pour une activité malveillante : si vous détectez qu’un jeton EC2 est volé dans les métadonnées d’une instance, vous pouvez temporairement lui retirer ses droits d’accès. Si vous constatez que la journalisation est désactivée, réactivez-la et verrouillez les comptes d’utilisateurs responsables. Cela vous permettra de réagir plus rapidement aux incidents de sécurité.
Bien entendu, vous devez encore travailler sur le processus global de gestion des incidents : à la fois sur la manière d’éviter la mauvaise configuration des services (par la formation des développeurs et les contrôles dans les canaux CICD s’ils existent) et sur la manière de les gérer une fois qu’ils se produisent (le modèle de fonctionnement est abordé plus loin).
Se rapprocher de l’entreprise et de l’amélioration continue
Le passage au Cloud est généralement un moment où les applications et les charges de travail devront à nouveau passer par un examen de sécurité pour s’assurer que l’architecture et la conception sont solides et sûres. Mais c’est aussi l’occasion de rendre la détection de sécurité plus pertinente pour l’application.
Pour que cela compte, mon conseil serait le suivant:
- Passer par le processus de « Service Enablement » pour les nouveaux services : comme le passage au cloud permet aux équipes commerciales et informatiques d’utiliser des centaines de nouvelles fonctionnalités et de nouveaux composants, il est important de réunir les architectes et les équipes de sécurité pour évaluer les principaux risques pour chaque nouvelle technologie, trouver des contre-mesures pour limiter ces risques et commencer à réfléchir aux alertes qui devront être mises en œuvre dans le SIEM ;
- Construire un catalogue d’alerte pour chaque scénario et composant de risque typique, la logique de l’alerte étant déjà prédéfinie et seules les spécificités de l’entreprise devant être personnalisées. Le « time to market » de la supervision devrait également diminuer, car une bonne partie des composants utilisés pour les opérations dans le Cloud est commune à la plupart des applications (machines virtuelles, bases de données, applications et fonctions sans serveur, systèmes de découplage) ;
- Tenez-vous au courant des attaques liées au Cloud afin de comprendre les dernières vulnérabilités et les chemins empruntés par les attaquants, et intégrez-les dans vos systèmes de détection.
Toutes ces spécificités applicatives doivent s’ajouter aux alertes transversales couvrant les fonctions essentielles de votre Cloud (IAM, mise en réseau, zones d’atterrissage, etc.). Pour vous aider à mettre en place cette capacité de détection du noyau, vous pouvez évidemment compter sur notre équipe, mais je vous recommande également de vous renseigner sur la communauté CloudSec, qui ne cesse de s’agrandir et qui partage son expertise en permanence grâce à des outils open-source (comme cette vue consolidée ) ou sur des plateformes en direct et en ligne (comme le Forum sur la sécurité dans le Cloud et son premier Fwd:CloudSec conférence cette année).
Mais tout n’est pas facile !
D’après tout ce qui précède, il peut sembler facile d’obtenir une compétence de détection et de réaction d’un Cloud solide. Cependant, certains défis restent à relever.
Le premier qui vient à l’esprit est la tarification. Souvent proposé comme argument de vente pour les programmes Move to Cloud, il n’est pas aussi facile qu’il y paraît d’estimer avec précision le prix que votre fournisseur vous fera payer pour les détections Cloud. Au fil des ans, de nombreuses solutions de sécurité des CSP sont passées à une tarification basée sur les composants pour les IaaS et à une tarification basée sur les transactions pour les composants PaaS. Le stockage des journaux et les alertes sont parfois encore plus complexes, car certaines solutions vous factureront en fonction du transit et de l’agrégation des journaux, tandis que d’autres vous factureront le nombre d’évaluations par rapport aux alertes que vous avez lancées. Un travail important est nécessaire pour déterminer un budget réel et ne pas faire faillite.
Le deuxième point essentiel est de comprendre ce que votre fournisseur offre et ce qu’il n’offre pas en termes de détection. Si la plupart des solutions prétendront résoudre tous vos problèmes d’un seul coup, c’est malheureusement loin d’être le cas. Et pour chaque cas d’utilisation de la sécurité, il faut savoir si l’option gratuite, si elle existe, vous convient, si l’option premium est nécessaire ou si vos équipes de sécurité peuvent se débrouiller seules. De manière réaliste, vous devrez commencer par l’option native, jusqu’à ce que votre équipe de sécurité soit suffisamment mature, en termes de Cloud, pour passer à un processus fait maison.
En outre, et c’est peut-être l’aspect le plus important, vous devez concevoir un modèle d’exploitation qui vous permettra de travailler avec plusieurs abonnements, plusieurs équipes/entreprises et éventuellement plusieurs fournisseurs de Cloud. De plus en plus d’organisations parallélisent leurs opérations en choisissant différents CSP pour différents cas d’utilisation, ce qui entraîne une complexité accrue pour les équipes de sécurité – car elles doivent gérer des incidents sur différentes plateformes, les responsabilités étant réparties entre les DevOps, les SecOps et les équipes sur site. Cela sera d’autant plus difficile qu’une mauvaise configuration entraînera des risques de sécurité immédiats et qu’il faudra choisir entre les opérations et la sécurité. En l’absence d’une division solide des tâches entre tous les fournisseurs et toutes les équipes, il y a de fortes chances qu’une petite erreur de configuration se transforme en une fuite de données importante.
Enfin, n’oubliez pas que la surveillance de vos applications dans le Cloud peut également créer des risques. Outre le verrouillage des fournisseurs, vous pouvez perdre toutes les fonctions de sécurité ainsi que vos applications si tout se trouve sous le même plan de gestion. Si les droits d’administration globale du locataire SIEM sont repris par un attaquant, il aura toute liberté d’affecter les ressources sous-jacentes (c’est-à-dire d’effacer les journaux, de désactiver les alertes ou de supprimer les capacités de correction). Il vaut la peine d’y réfléchir avant d’empiler votre SIEM et vos applications critiques sous le même toit.
Pour résumer, en fin de compte :
- Attrapez les fruits qui pendent : votre fournisseur de Cloud vous aidera à collecter et à consolider les bûches facilement. Il n’y a pratiquement plus d’obstacles techniques pour ne plus utiliser les bûches. En outre, activez les fonctions de sécurité de base fournies par votre fournisseur de services dans le Cloud pour détecter les attaques les plus évidentes.
- Développez votre maturité en matière de Cloud avec des équipes de Cloud : Le mouvement Cloud a poussé les équipes commerciales et informatiques (SecDevOps) à travailler plus étroitement que jamais. Adoptez cette philosophie en comprenant mieux les besoins des entreprises en termes de sécurité, en personnalisant les alertes et en automatisant votre réponse pour permettre à votre capacité d’évoluer.
- Optimiser les coûts et les modèles de fonctionnement pour exceller : La virtualisation a facilité de nombreux aspects techniques pour les équipes, mais les processus peuvent être difficiles à adapter. Veillez à concevoir avec soin votre modèle d’exploitation de détection/réponse aux incidents pour vous assurer que toutes vos applications et tous vos fournisseurs de services dans le Cloud sont couverts. Enfin, pensez à l’optimisation des coûts lorsqu’il s’agit de la gestion des logs !
