Surveillance de la sécurité dans le cloud

Le transfert de données et d'applications vers le cloud représente un nouveau défi pour les SOC d'entreprise, qui ne sont pas toujours prêts à surveiller l'infrastructure d'autrui. Selon Netoskope, une entreprise moyenne (apparemment aux États-Unis) utilise 1246 services cloud différents, soit 22 % de plus que l'année dernière. 1246 services cloud !!! 175 d'entre eux concernent les services RH, 170 sont liés au marketing, 110 à la communication et 76 aux finances et au CRM. Cisco utilise "seulement" 700 services cloud externes. Par conséquent, ces chiffres me laissent un peu perplexe. Quoi qu'il en soit, le problème ne réside pas dans ces chiffres, mais dans le fait que de plus en plus d'entreprises commencent à adopter le cloud et souhaitent disposer des mêmes capacités de surveillance de l'infrastructure cloud que dans leur propre réseau. Et cette tendance est en forte croissance — selon les données de la Cour des comptes américaine d'ici 2023, les États-Unis prévoient de fermer 1200 centres de données (6250 étant déjà fermés). Mais passer au cloud ne signifie pas simplement "allons transférer nos serveurs chez un fournisseur externe". Il s'agit d'une nouvelle architecture informatique, de nouveaux logiciels, de nouveaux processus, de nouvelles restrictions… Cela engendre des changements significatifs tant dans le domaine informatique que dans la sécurité de l'information. Et s'il y a suffisamment de recommandations pour assurer la sécurité du cloud lui-même, les défis relatifs à la surveillance de la sécurité de l'information dans le cloud, en particulier sur les plateformes SaaS, demeurent importants, et c'est ce dont nous allons parler.

Supposons que votre entreprise ait transféré une partie de son infrastructure vers le cloud… Stop. Ce n'est pas ça. Si l'infrastructure a été transférée et que vous vous demandez seulement maintenant comment vous allez la surveiller, alors vous avez déjà perdu. Si ce n'est pas Amazon, Google ou Microsoft (et encore, avec des réserves), il est probable que vous n'aurez pas beaucoup d'options pour surveiller vos données et applications. Bien, si l'on vous donne la possibilité de travailler avec des journaux. Parfois, les données sur les événements de sécurité seront disponibles, mais vous n'y aurez pas accès. Par exemple, avec Office 365. Si vous avez la licence E1 la moins chère, les événements de sécurité ne vous sont pas du tout accessibles. Avec la licence E3, vos données sont conservées pendant seulement 90 jours, et seulement avec la licence E5 — la durée des journaux est disponible pendant un an (en fait, il y a aussi des nuances, car vous devez demander séparément certaines fonctionnalités concernant les journaux au support de Microsoft). Au fait, la licence E3 est beaucoup moins puissante en matière de fonctions de surveillance que l'Exchange d'entreprise. Pour atteindre le même niveau, vous avez besoin de la licence E5 ou d'une licence supplémentaire Advanced Compliance, qui peuvent nécessiter des fonds supplémentaires non pris en compte dans votre modèle financier de transition vers l'infrastructure cloud. Et c'est juste un exemple de la sous-estimation des questions liées à la surveillance de la sécurité dans le cloud. Dans cet article, sans prétendre à une couverture complète, je souhaite attirer l'attention sur certains aspects à considérer lors du choix d'un fournisseur de cloud du point de vue de la sécurité. À la fin de l'article, une liste de contrôle sera donnée, que vous devez remplir avant de considérer que la question de la surveillance de la sécurité cloud est résolue.

On peut identifier plusieurs problèmes typiques conduisant à des incidents dans les environnements cloud, auxquels les services de sécurité ne parviennent pas à réagir ou ne les voient pas du tout :

• Les journaux de sécurité n'existent pas. C'est une situation assez répandue, surtout chez les nouveaux acteurs du marché des solutions cloud. Mais il ne faut pas tout de suite leur tourner le dos. Les petits acteurs, en particulier ceux nationaux, sont plus réceptifs aux exigences des clients et peuvent rapidement mettre en œuvre certaines fonctionnalités demandées, en modifiant la feuille de route approuvée pour leurs produits. Oui, ce ne sera pas un équivalent de GuardDuty d'Amazon ou du module "Protection Proactive" de Bitrix, mais c'est déjà quelque chose.
• La sécurité de l'information ne sait pas où sont stockés les journaux ou n'y a pas accès. Il est nécessaire d'engager des discussions avec le fournisseur de services cloud — il pourrait fournir cette information s'il considère le client comme important. Mais dans l'ensemble, ce n'est pas très bon lorsque l'accès aux journaux est accordé « sur décision spéciale ».
• Il arrive que le fournisseur cloud dispose de journaux, mais ils offrent une surveillance et un enregistrement des événements limités, insuffisants pour détecter tous les incidents. Par exemple, on peut simplement vous fournir les journaux de modification du site ou les journaux des tentatives d'authentification des utilisateurs, mais d'autres événements, comme le trafic réseau, ne sont pas fournis, ce qui vous prive de tout un ensemble d'événements caractérisant les tentatives de piratage de votre infrastructure cloud.
• Les journaux existent, mais l'accès à ceux-ci est difficile à automatiser, ce qui oblige à les surveiller non pas en continu, mais selon un calendrier. Et si en plus, il n'est pas possible de télécharger les journaux en mode automatique, l'exportation des journaux, par exemple au format Excel (comme le font certains fournisseurs nationaux de solutions cloud), pourrait mener à un désintérêt de la part du service de sécurité de l'information.
• Pas de surveillance des journaux. C'est probablement la raison la plus incompréhensible de l'émergence d'incidents de sécurité de l'information dans les environnements cloud. Il semble qu'il y ait des journaux, et qu'il soit possible d'automatiser l'accès à ceux-ci, mais personne ne le fait. Pourquoi ?

Concept de sécurité partagée dans le cloud

La transition vers le cloud consiste toujours à trouver un équilibre entre le désir de conserver le contrôle sur l'infrastructure et la remise de celle-ci à un fournisseur de cloud plus professionnel, spécialisé dans son entretien. En matière de sécurité des environnements cloud, cet équilibre doit également être recherché. D'autant plus que, selon le modèle de fourniture de services cloud utilisé (IaaS, PaaS, SaaS), cet équilibre variera constamment. Quoi qu'il en soit, il faut garder à l'esprit que tous les fournisseurs de cloud suivent aujourd'hui ce que l'on appelle le modèle de responsabilité partagée et de sécurité partagée. Le cloud est responsable de certaines choses, tandis que le client, qui a placé ses données, ses applications, ses machines virtuelles et d'autres ressources dans le cloud, en est responsable pour d'autres. Il serait imprudent de penser qu'en migrant vers le cloud, nous déléguons toute la responsabilité au fournisseur. Cependant, il serait également irréaliste de vouloir établir toute la sécurité par soi-même lors de la migration vers le cloud. Un équilibre est nécessaire, qui dépendra de nombreux facteurs : — stratégie de gestion des risques, modèles de menaces, mécanismes de protection disponibles chez le fournisseur de cloud, législation, etc.

Par exemple, la classification des données hébergées dans le cloud est toujours de la responsabilité du client. Le fournisseur de cloud ou le prestataire de services externe peut seulement aider avec les outils qui permettent de marquer les données dans le cloud, de détecter les violations, de supprimer les données non conformes à la législation ou de les masquer par différents moyens. En revanche, la sécurité physique est toujours de la responsabilité du fournisseur de cloud, responsabilité qu'il ne peut partager avec ses clients. Tout ce qui se trouve entre les données et l'infrastructure physique est précisément le sujet de discussion de cet article. Par exemple, la disponibilité du cloud est la responsabilité du fournisseur, tandis que la configuration des règles de sécurité ou l'activation du chiffrement relèvent de la responsabilité du client. Dans cet article, nous allons examiner quels mécanismes de surveillance de la sécurité de l'information sont actuellement fournis par les différents fournisseurs de cloud populaires en Russie, quelles sont les particularités de leur application, et quand il est judicieux de se tourner vers des solutions externes (comme Cisco E-mail Security) qui élargissent les capacités de votre cloud en matière de cybersécurité. Dans certains cas, notamment dans le cadre d'une stratégie multicloud, vous n'aurez d'autre choix que d'utiliser des solutions externes de surveillance de la sécurité de l'information dans plusieurs environnements cloud (comme Cisco CloudLock ou Cisco Stealthwatch Cloud). Dans d'autres cas, vous constaterez que le fournisseur de cloud que vous avez choisi (ou qui vous a été imposé) ne propose aucune possibilité de surveillance de la sécurité de l'information. C'est désagréable, mais cela permet également d'évaluer adéquatement le niveau de risque associé à l'utilisation de ce cloud.

Cycle de vie de la surveillance de la sécurité du cloud

Pour surveiller la sécurité des clouds que vous utilisez, vous avez trois options :

• compter sur les outils fournis par votre fournisseur de cloud,
• utiliser des solutions de tiers qui surveillent les plateformes IaaS, PaaS ou SaaS que vous utilisez,
• construire votre propre infrastructure de surveillance des environnements cloud (uniquement pour les plateformes IaaS/PaaS).

Examinons les caractéristiques de chacune de ces options. Mais d'abord, nous devons comprendre le schéma général qui sera utilisé pour la surveillance des plateformes cloud. Je mettrais en avant 6 composants principaux du processus de surveillance de la sécurité de l'information dans le cloud :

• Préparation de l'infrastructure. Définition des applications et de l'infrastructure nécessaires pour collecter les événements importants pour la sécurité de l'information, dans un stockage.
• Collecte. À ce stade, les événements de sécurité sont agrégés à partir de diverses sources pour être ensuite transmis pour traitement, stockage et analyse.
• Traitement. À ce stade, les données sont transformées et enrichies pour faciliter leur analyse ultérieure.
• Stockage. Ce composant est responsable du stockage à court et à long terme des données traitées et "brutes" récoltées.
• Analyse. À cette étape, vous avez la possibilité de détecter des incidents et d'y répondre de manière automatique ou manuelle.
• Rapports. Cette étape aide à formuler pour les parties prenantes (direction, auditeurs, fournisseur cloud, clients, etc.) des indicateurs clés qui nous aident à prendre certaines décisions, par exemple, changer de fournisseur ou renforcer la sécurité de l'information.

Comprendre ces composants vous permettra par la suite de déterminer rapidement ce que vous pouvez obtenir de votre fournisseur et ce que vous devrez faire vous-même ou avec l'aide de consultants externes.

Fonctionnalités intégrées des services cloud

J'ai déjà mentionné que de nombreux services cloud ne fournissent aucune option de surveillance de la sécurité de l'information. En général, ils n'accordent pas beaucoup d'attention à cette thématique. Par exemple, l'un des services russes populaires pour l'envoi de rapports aux autorités via Internet (je ne mentionnerai pas son nom). Toute la section sur la sécurité de ce service tourne autour de l'utilisation de systèmes certifiés de protection de l'information. En revanche, la section sur la sécurité de l'autre service cloud national dédié à la gestion électronique des documents est beaucoup plus complète. Elle aborde les certificats de clés publiques, la cryptographie certifiée, l'élimination des vulnérabilités web, la protection contre les attaques DDoS, l'utilisation de MSE, la sauvegarde des données et même la réalisation régulière d'audits de sécurité. Cependant, aucune mention n'est faite de la surveillance, ni de l'accès aux événements de sécurité de l'information qui pourraient intéresser les clients de ce fournisseur de services.

En général, la manière dont un fournisseur de cloud décrit sur son site et dans sa documentation les questions de sécurité de l'information permet de comprendre à quel point il prend ce sujet au sérieux. Par exemple, en lisant les guides des produits "Mon bureau", on constate qu'il n'y a pas un mot sur la sécurité. En revanche, dans la documentation d'un produit spécifique "Mon bureau. KS3", destiné à protéger contre l'accès non autorisé, il n'y a qu'une simple énumération des points du 17ème décret de la FSTEK que respecte "Mon bureau.KS3", sans expliquer comment il le fait, ni, surtout, comment intégrer ces mécanismes avec la sécurité de l'information d'entreprise. Il est possible qu'une telle documentation existe, mais je ne l'ai pas trouvée dans l'accès public sur le site de "Mon bureau". Peut-être que je n'ai tout simplement pas accès à ces informations secrètes ?

La situation pour Bitrix est bien meilleure. La documentation décrit les formats des journaux d'événements et, ce qui est intéressant, le journal d'intrusions, qui contient des événements liés aux menaces potentielles pour la plateforme cloud. De là, vous pouvez extraire l'IP, le nom d'utilisateur ou d'invité, la source de l'événement, l'heure, l'agent utilisateur, le type d'événement, etc. Il est vrai que travailler avec ces événements est possible soit depuis le panneau de contrôle du cloud, soit en exportant les données au format MS Excel. Automatiser le travail avec les journaux de Bitrix est actuellement difficile et vous devrez effectuer une partie du travail manuellement (exporter le rapport et le charger dans votre SIEM). Mais en se rappelant qu'il n'y a pas si longtemps cette possibilité n'existait pas, c'est un grand progrès. Je tiens à noter que de nombreux fournisseurs de cloud étrangers offrent également une fonctionnalité similaire

Si l'on ne considère pas l'option d'absence de logs, les fournisseurs de cloud vous offrent généralement trois options pour surveiller les événements de sécurité : des tableaux de bord, l'exportation de données et l'accès à celles-ci via API. La première semble résoudre beaucoup de problèmes pour vous, mais ce n'est pas tout à fait vrai : en présence de plusieurs journaux, il faut naviguer entre les écrans qui les affichent, perdant ainsi la vue d'ensemble. De plus, il est peu probable qu'un fournisseur de cloud vous donne la possibilité de corréler les événements de sécurité et de les analyser d'un point de vue sécurisé (vous vous retrouvez généralement avec des données brutes dont vous devez vous occuper vous-même). Il y a quelques exceptions, dont nous parlerons plus loin. Enfin, il convient de se demander quels événements votre fournisseur de cloud enregistre, sous quel format et dans quelle mesure ils correspondent à votre processus de surveillance de la sécurité de l'information ? Par exemple, l'identification et l'authentification des utilisateurs et des invités. Par exemple, Bitrix vous permet d'enregistrer, pour ces données d'événements, la date et l'heure de l'événement, le nom de l'utilisateur ou de l'invité (si le module « Analyse Web » est activé), l'objet auquel l'accès a été accordé et d'autres éléments typiques d'un site web. Mais les services de sécurité d'entreprise pourraient avoir besoin de savoir si l'utilisateur a accédé au cloud depuis un appareil de confiance (par exemple, dans un réseau d'entreprise, cette tâche est réalisée par Cisco ISE). Et une tâche aussi simple que la fonction géo-IP, qui aiderait à déterminer si le compte utilisateur du service cloud a été volé ? Même si le fournisseur de cloud vous la fournit, ce ne sera pas suffisant. Cisco CloudLock non seulement analyse la géolocalisation, mais utilise également l'apprentissage automatique et examine les données historiques de chaque utilisateur pour détecter différentes anomalies dans les tentatives d'identification et d'authentification. Une fonctionnalité similaire n'est disponible que sur MS Azure (avec un abonnement adéquat).

Il y a une autre difficulté : comme pour de nombreux fournisseurs de cloud, la surveillance de la sécurité de l'information est un sujet nouveau, qu'ils commencent tout juste à aborder, ils changent constamment leurs solutions. Aujourd'hui, ils ont une version de l'API, demain une autre, et le surlendemain une troisième. Il faut également être prêt à cela. Il en va de même pour les fonctionnalités, qui peuvent évoluer, ce qui doit être pris en compte dans votre système de surveillance de la sécurité de l'information. Par exemple, Amazon avait d'abord des services distincts pour la surveillance des événements dans le cloud - AWS CloudTrail et AWS CloudWatch. Ensuite, un service distinct de surveillance des événements de sécurité de l'information a été créé - AWS GuardDuty. Après un certain temps, Amazon a lancé un nouveau système de gestion, Amazon Security Hub, qui comprend l'analyse des données provenant de GuardDuty, Amazon Inspector, Amazon Macie et d'autres outils. Un autre exemple est l'outil d'intégration des journaux Azure avec SIEM - AzLog. De nombreux fournisseurs de SIEM l'utilisaient activement jusqu'à ce qu'en 2018, Microsoft annonce l'arrêt de son développement et de son support, ce qui a mis de nombreux clients utilisant cet outil devant un problème (comment cela a été résolu, nous en parlerons plus tard).

Il est donc crucial de suivre attentivement toutes les fonctionnalités de surveillance proposées par votre fournisseur de cloud. Sinon, vous pouvez faire confiance à des fournisseurs externes de solutions qui serviront d'intermédiaires entre votre SOC et le cloud que vous souhaitez surveiller. Oui, cela coûtera plus cher (bien que ce ne soit pas toujours le cas), mais vous déléguerez toute la responsabilité à d'autres. Ou pas complètement ? Rappelons-nous le concept de sécurité partagée et comprenons que nous ne pouvons rien déléguer - nous devrons nous débrouiller nous-mêmes pour comprendre comment différents fournisseurs de cloud assurent la surveillance de la sécurité de l'information de vos données, applications, machines virtuelles et autres ressources hébergées dans le cloud. Et nous commencerons par ce qu'Amazon propose dans ce domaine.

Exemple : Surveillance de la sécurité de l'information en IaaS basé sur AWS

Oui, je comprends que Amazon n'est peut-être pas le meilleur exemple, étant un service américain susceptible d'être bloqué dans le cadre de la lutte contre l'extrémisme et la diffusion d'informations interdites en Russie. Cependant, dans cette publication, je souhaite simplement montrer à quel point les différentes plateformes cloud diffèrent en termes de capacités de surveillance de la sécurité et sur quoi il convient de se concentrer lors du transfert de ses processus clés vers le cloud du point de vue de la sécurité. Et si certains développeurs russes de solutions cloud en tirent quelque chose de utile, ce serait vraiment formidable.

Tout d'abord, il faut dire qu'Amazon n'est pas une forteresse imprenable. Ses clients rencontrent régulièrement divers incidents. Par exemple, Deep Root Analytics a perdu les noms, adresses, dates de naissance et numéros de téléphone de 198 millions d'électeurs. Une entreprise israélienne, Nice Systems, a perdu 14 millions d'enregistrements concernant des abonnés Verizon. En même temps, les capacités intégrées d'AWS vous permettent de détecter un large éventail d'incidents. Par exemple :

• impact sur l'infrastructure (DDoS)
• compromission de nœud (injection de commandes)
• compromission de compte et accès non autorisé
• configuration incorrecte et vulnérabilités
• interfaces et API non sécurisées.

Cette incongruité est due au fait que la sécurité des données du client, comme nous l'avons établi précédemment, incombe au client lui-même. Et s'il ne prend pas soin d'activer des mécanismes de protection et d'implémenter des outils de surveillance, il n'apprendra l'incident que par les médias ou de la part de ses clients.

Pour détecter les incidents, un large éventail de services de surveillance développés par Amazon peut être utilisé (bien qu'ils soient souvent complétés par des outils externes, tels qu'osquery). Ainsi, dans AWS, toutes les actions des utilisateurs sont suivies, quel que soit leur mode de réalisation — que ce soit par la console de gestion, la ligne de commande, le SDK ou d'autres services AWS. Tous les enregistrements des actions de chaque compte AWS (y compris le nom d'utilisateur, l'action, le service, les paramètres d'activité et son résultat) et l'utilisation de l'API sont accessibles via le service AWS CloudTrail. Vous pouvez consulter ces événements (par exemple, la connexion à la console AWS IAM) depuis la console CloudTrail, les analyser à l'aide d'Amazon Athena ou les transmettre à des solutions externes, telles que Splunk, AlienVault, etc. Les journaux AWS CloudTrail sont stockés dans votre bucket AWS S3.

Deux autres services AWS offrent encore d'importantes fonctionnalités de surveillance. Tout d'abord, Amazon CloudWatch — un service de surveillance des ressources et des applications AWS qui permet, entre autres, d'identifier diverses anomalies dans votre cloud. Tous les services intégrés d'AWS, tels qu'Amazon Elastic Compute Cloud (serveurs), Amazon Relational Database Service (bases de données), Amazon Elastic MapReduce (analyse de données) et plus de 30 autres services Amazon, utilisent Amazon CloudWatch pour stocker leurs journaux. Les développeurs peuvent utiliser l'API ouverte d'Amazon CloudWatch pour ajouter la fonctionnalité de surveillance des journaux dans des applications et services personnalisés, ce qui permet d'élargir le spectre des événements analysés dans le contexte de la cybersécurité.

Deuxièmement, le service VPC Flow Logs permet d'analyser le trafic réseau envoyé ou reçu par vos serveurs AWS (de l'extérieur ou de l'intérieur), ainsi qu'entre microservices. Lorsqu'une de vos ressources AWS VPC interagit avec le réseau, le service VPC Flow Logs enregistre des informations sur le trafic réseau, y compris l'interface réseau source et de destination, ainsi que les adresses IP, les ports, le protocole, le nombre d'octets et le nombre de paquets que vous avez observés. Ceux qui ont de l'expérience en sécurité réseau locale le reconnaîtront comme l'équivalent des flux NetFlow, qui peuvent être générés par des commutateurs, des routeurs et des pare-feu de niveau entreprise. Ces journaux sont importants pour les objectifs de surveillance de la cybersécurité, car ils, contrairement aux événements d'actions des utilisateurs et des applications, permettent également de ne pas négliger les interactions réseau dans un environnement de cloud privé virtuel AWS.

Ainsi, ces trois services AWS — AWS CloudTrail, Amazon CloudWatch et VPC Flow Logs — fournissent ensemble une vue suffisamment efficace sur l'utilisation de votre compte, le comportement des utilisateurs, la gestion de l'infrastructure, l'activité des applications et services, ainsi que l'activité réseau. Par exemple, ils peuvent détecter les anomalies suivantes :

• Tentatives de scan de site, recherche de backdoors, recherche de vulnérabilités à travers des pics de “erreurs 404”.
• Attaques par injection (par exemple, injection SQL) à travers des pics de “erreurs 500”.
• Outils connus pour des attaques comme sqlmap, nikto, w3af, nmap, etc., à travers l'analyse du champ User Agent.

Amazon Web Services a également développé d'autres services pour les besoins de la cybersécurité, permettant de résoudre de nombreuses autres problématiques. Par exemple, AWS dispose d'un service intégré pour l'audit des politiques et des configurations - AWS Config. Ce service assure un audit continu de vos ressources AWS et de leur configuration. Prenons un exemple simple : supposons que vous souhaitiez vous assurer que les mots de passe des utilisateurs sont désactivés sur tous vos serveurs et que l'accès n'est possible que sur la base de certificats. AWS Config permet de vérifier facilement cela pour tous vos serveurs. D'autres politiques peuvent également être appliquées à vos serveurs cloud : « Aucun serveur ne peut utiliser le port 22 », « Seuls les administrateurs peuvent modifier les règles du pare-feu » ou « Seul l'utilisateur Ivashko peut créer de nouveaux comptes utilisateurs, et il ne peut le faire que les mardis ». À l'été 2016, le service AWS Config a été étendu pour automatiser la détection des violations des politiques établies. AWS Config Rules sont, en substance, des requêtes de configuration continues pour les services Amazon que vous utilisez, qui génèrent des événements en cas de violation des politiques correspondantes. Par exemple, au lieu d'exécuter périodiquement des requêtes AWS Config pour vérifier que tous les disques de votre serveur virtuel sont chiffrés, vous pouvez utiliser AWS Config Rules pour vérifier en permanence les disques de serveur afin de garantir ce critère. Et, ce qui est le plus important, dans le contexte de cette publication, toute violation génère des événements qui peuvent être analysés par votre service de sécurité informatique.

AWS propose également ses équivalents aux solutions traditionnelles de sécurité d'entreprise, qui génèrent également des événements de sécurité que vous pouvez et devez analyser :

• détection d'intrusion - AWS GuardDuty
• contrôle des fuites d'information - AWS Macie
• EDR (bien que parler des terminaux dans le cloud soit un peu étrange) - AWS Cloudwatch + solutions open source osquery ou GRR
• analyse Netflow - AWS Cloudwatch + AWS VPC Flow
• analyse DNS - AWS Cloudwatch + AWS Route53
• AD - AWS Directory Service
• gestion des comptes - AWS IAM
• SSO - AWS SSO
• analyse de la sécurité - AWS Inspector
• gestion des configurations - AWS Config
• WAF - AWS WAF.

Je ne vais pas détailler tous les services Amazon qui peuvent être utiles dans le contexte de la sécurité de l'information. L'essentiel à comprendre est que tous peuvent générer des événements que nous pouvons et devons analyser dans le cadre de la cybersécurité, en utilisant à la fois les capacités intégrées d'Amazon et des solutions externes, comme les SIEM, qui peuvent récupérer les événements de sécurité dans votre centre de surveillance et les analyser aux côtés des événements d'autres services cloud ou de l'infrastructure interne, du périmètre ou des dispositifs mobiles.

Quoi qu'il en soit, tout commence par les sources de données qui vous fournissent des événements de cybersécurité. Parmi ces sources, on peut notamment citer :

• CloudTrail – utilisation des API et actions des utilisateurs
• Trusted Advisor – vérification de la sécurité par rapport aux meilleures pratiques
• Config – inventaire et configuration des comptes et des paramètres des services
• VPC Flow Logs – connexions aux interfaces virtuelles
• IAM – service d'identification et d'authentification
• ELB Access Logs – journaux du répartiteur de charge
• Inspector – vulnérabilités dans les applications
• S3 – stockage de fichiers
• CloudWatch – activité des applications
• SNS – service de notifications.

Amazon, en proposant une telle gamme de sources d'événements et d'outils pour leur génération, est cependant très limité dans ses capacités d'analyse des données collectées en matière de cybersécurité. Vous devrez examiner les journaux disponibles par vous-même, à la recherche des indicateurs de compromission pertinents. AWS Security Hub, récemment lancé par Amazon, vise à résoudre ce problème, agissant comme une sorte de SIEM cloud pour AWS. Mais pour l'instant, il en est seulement à ses débuts et limité tant par le nombre de sources avec lesquelles il fonctionne que par d'autres contraintes liées à l'architecture et aux abonnements d'Amazon.

Exemple : Surveillance de la cybersécurité dans IaaS basé sur Azure

Je ne souhaite pas entrer dans un long débat sur lequel des trois fournisseurs de cloud (Amazon, Microsoft ou Google) est le meilleur (sachant que chacun d'eux a sa propre spécificité et convient à des besoins différents) ; concentrons-nous sur les capacités de surveillance de la sécurité de l'information que ces acteurs offrent. Il faut reconnaître qu'Amazon AWS a été l'un des premiers dans ce secteur et qu'il a donc avancé le plus en ce qui concerne ses fonctionnalités de sécurité (bien que beaucoup reconnaissent qu'il est assez difficile de les utiliser). Mais cela ne signifie pas que nous allons ignorer les possibilités offertes par Microsoft et Google.

Les produits Microsoft ont toujours été caractérisés par leur « ouverture », et la situation est similaire avec Azure. Par exemple, alors qu'AWS et GCP partent toujours du principe que « tout ce qui n'est pas autorisé est interdit », Azure adopte une approche diamétralement opposée. Par exemple, en créant un réseau virtuel dans le cloud et une machine virtuelle au sein de celui-ci, tous les ports et protocoles sont, par défaut, ouverts et autorisés. Par conséquent, vous devrez consacrer un peu plus d'efforts à la configuration initiale du système de contrôle d'accès dans le cloud de Microsoft. Cela impose également des exigences plus strictes en matière de surveillance des activités dans le cloud Azure.

AWS présente une particularité : lorsque vous surveillez vos ressources virtuelles situées dans différentes régions, il devient difficile de regrouper tous les événements et de les analyser de manière unifiée. Pour cela, vous devez recourir à diverses astuces, comme la création d'un code personnalisé pour AWS Lambda permettant de transférer des événements entre régions. En revanche, Azure ne rencontre pas ce problème car son mécanisme de Journal d'activité suit toute l'activité au sein de l'organisation sans aucune restriction. De même, AWS Security Hub, récemment développé par Amazon pour consolider de nombreuses fonctionnalités de sécurité en un seul centre de sécurité, est limité à son propre région, ce qui, pour la Russie, n'est pas pertinent. Azure dispose de son propre Centre de sécurité, sans restrictions régionales, offrant un accès à toutes les fonctionnalités de sécurité de la plateforme cloud. De plus, pour différentes équipes locales, il peut fournir un ensemble de capacités de protection, y compris la gestion des événements de sécurité. AWS Security Hub aspire encore à se rapprocher de l'Azure Security Center. Cependant, il convient de noter qu'il est possible d'extraire de nombreuses fonctionnalités d'Azure qui ont été précédemment décrites pour AWS, mais cela est plus facilement réalisable uniquement pour Azure AD, Azure Monitor et Azure Security Center. Tous les autres mécanismes de protection d’Azure, y compris l'analyse des événements de sécurité, ne sont pas encore gérés de manière très pratique. En partie, cette problématique est atténuée par l'API qui traverse tous les services de Microsoft Azure, mais cela nécessitera des efforts supplémentaires pour intégrer votre cloud avec votre SOC et disposer de spécialistes qualifiés (comme pour tout autre SIEM travaillant avec des API cloud). Certains SIEM, dont nous parlerons plus loin, prennent déjà en charge Azure et peuvent automatiser la tâche de sa surveillance, mais là encore, des complications subsistent — tous ne peuvent pas récupérer tous les journaux disponibles dans Azure.

La collecte et la surveillance des événements dans Azure sont assurées par le service Azure Monitor, qui est l'outil principal de collecte, de stockage et d'analyse des données dans le cloud Microsoft et de ses ressources — dépôts Git, conteneurs, machines virtuelles, applications, etc. Toutes les données collectées par Azure Monitor se divisent en deux catégories : les métriques, collectées en temps réel et décrivant les indicateurs clés de la performance du cloud Azure, et les journaux d'enregistrement, qui contiennent des données organisées en enregistrements, caractérisant divers aspects de l'activité des ressources et des services Azure. De plus, grâce à l'API Data Collector, le service Azure Monitor peut collecter des données à partir de toute source REST pour construire ses propres scénarios de surveillance.

Voici quelques sources d'événements de sécurité que vous propose Azure et auxquelles vous pouvez accéder via Azure Portal, CLI, PowerShell ou REST API (et certaines uniquement via Azure Monitor / Insight API) :

• Les journaux d'activité — ce journal répond aux questions classiques “qui”, “quoi” et “quand” concernant toute opération d'enregistrement (PUT, POST, DELETE) sur les ressources cloud. Les événements liés à l'accès en lecture (GET) ne figurent pas dans ce journal, tout comme d'autres événements.
• Les journaux de diagnostic — contiennent des données sur les opérations avec une ressource donnée entrant dans votre abonnement.
• Les rapports Azure AD — contiennent à la fois l'activité des utilisateurs et l'activité système liée à la gestion des groupes et des utilisateurs.
• Les journaux d'événements Windows et les journaux Syslog Linux — contiennent des événements provenant des machines virtuelles hébergées dans le cloud.
• Les métriques — contiennent des télémétries sur l'état de la performance et la “santé” de vos services et ressources cloud. Elles sont mesurées chaque minute et conservées pendant 30 jours.
• Les journaux de flux du groupe de sécurité réseau — contiennent des données sur les événements de sécurité réseau, collectées à l'aide du service Network Watcher et du monitoring des ressources au niveau du réseau.
• Les journaux de stockage — contiennent des événements liés à l'accès aux stockages.

Pour le monitoring, vous pouvez utiliser des SIEM externes ou le Cloud Azure Monitor avec ses extensions. Nous aborderons les systèmes de gestion des événements de sécurité plus tard, mais commençons par examiner ce qu'Azure propose pour l'analyse des données dans le contexte de la sécurité. L'écran principal pour tout ce qui concerne la sécurité dans Azure Monitor est le tableau de bord Log Analytics Security and Audit (la version gratuite conserve un volume limité d'événements pendant une semaine seulement). Ce tableau de bord est divisé en 5 zones principales, visualisant des statistiques résumées sur ce qui se passe dans l'environnement cloud que vous utilisez :

• Domaines de Sécurité — indicateurs quantitatifs clés liés à la sécurité — nombre d'incidents, nombre de nœuds compromis, nœuds non patchés, événements de sécurité réseau, etc.
• Problèmes Notables — affiche le nombre et l'importance des problèmes actifs de sécurité
• Détections — affiche les modèles des attaques utilisées contre vous
• Intelligence sur les Menaces — affiche des informations géographiques sur les nœuds externes qui vous attaquent
• Requêtes de sécurité courantes — requêtes typiques qui vous aideront à mieux surveiller votre sécurité.

Parmi les extensions de Azure Monitor, on peut citer Azure Key Vault (protection des clés cryptographiques dans le cloud), Malware Assessment (analyse de la protection contre les malwares sur les machines virtuelles), Azure Application Gateway Analytics (analyse, entre autres, des journaux du pare-feu cloud), etc. Ces outils, enrichis de certaines règles de traitement des événements, permettent de visualiser divers aspects des activités des services cloud, y compris la sécurité, et d'identifier certains écarts de fonctionnement. Mais, comme cela arrive souvent, toute fonctionnalité supplémentaire nécessite un abonnement payant, ce qui exigera de votre part des investissements financiers que vous devrez planifier à l'avance.

Azure dispose de plusieurs fonctionnalités intégrées pour la surveillance des menaces, qui sont intégrées dans Azure AD, Azure Monitor et Azure Security Center. Parmi celles-ci, par exemple, la détection des interactions entre les machines virtuelles et des IP malveillantes connues (grâce à l'intégration avec les services de Threat Intelligence de Microsoft), la détection de logiciels malveillants dans l'infrastructure cloud grâce à des alertes provenant des machines virtuelles hébergées dans le cloud, des attaques par « force brute » sur les machines virtuelles, des vulnérabilités dans la configuration du système d'identification des utilisateurs, les connexions via des anonymiseurs ou des nœuds infectés, les fuites de comptes, les connexions à partir de localisations inhabituelles, etc. Aujourd'hui, Azure est l'un des rares fournisseurs de cloud à vous offrir des capacités intégrées de Threat Intelligence pour enrichir les événements de sécurité collectés.

Comme mentionné précédemment, la fonctionnalité de protection et, par conséquent, les événements de sécurité générés par celle-ci ne sont pas accessibles à tous les utilisateurs de manière égale, mais nécessitent un abonnement spécifique incluant les fonctionnalités souhaitées, qui génèrent les événements correspondants pour la surveillance de la sécurité des informations. Par exemple, certaines des fonctionnalités de surveillance des anomalies dans les comptes décrites dans le paragraphe précédent ne sont disponibles que dans la licence premium P2 du service Azure AD. Sans cela, tout comme dans le cas d'AWS, vous devrez analyser les événements de sécurité collectés « manuellement ». De plus, en fonction du type de licence Azure AD, tous les événements ne seront pas accessibles pour analyse.

Sur le portail Azure, vous pouvez gérer à la fois les requêtes de recherche pour les journaux d'enregistrement qui vous intéressent et configurer des tableaux de bord pour visualiser les indicateurs clés de sécurité. De plus, vous pouvez également sélectionner les extensions Azure Monitor, qui vous permettent d'élargir la fonctionnalité des journaux Azure Monitor et d'obtenir une analyse plus approfondie des événements du point de vue de la sécurité.

Si vous avez besoin non seulement de la possibilité de travailler avec des journaux, mais également d'un centre de sécurité complet pour votre plateforme cloud Azure, y compris la gestion des politiques de sécurité, il est nécessaire de considérer l'utilisation d'Azure Security Center, dont la plupart des fonctionnalités utiles sont disponibles moyennant un coût supplémentaire, telles que la détection des menaces, la surveillance hors d'Azure, l'évaluation de la conformité, etc. (dans la version gratuite, vous n'avez accès qu'à l'évaluation de la sécurité et aux recommandations pour résoudre les problèmes identifiés). Il regroupe toutes les questions de sécurité en un seul endroit. En substance, on peut parler d'un niveau de sécurité plus élevé que celui offert par Azure Monitor, car dans ce cas, les données collectées à travers votre usine cloud sont enrichies par de nombreuses sources, telles qu'Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, outlook.com, MSN.com, la Microsoft Digital Crimes Unit (DCU) et le Microsoft Security Response Center (MSRC), auxquelles sont appliqués divers algorithmes avancés d'apprentissage automatique et d'analyse comportementale, ce qui doit finalement améliorer l'efficacité de la détection des menaces et de la réponse à celles-ci.

Azure dispose également de son propre SIEM, qui a été lancé au début de l'année 2019. C'est Azure Sentinel, qui s'appuie sur des données provenant d'Azure Monitor et peut également s'intégrer à des solutions de sécurité externes (comme les NGFW ou WAF), dont la liste est constamment mise à jour. De plus, grâce à l'intégration de l'API Microsoft Graph Security, vous avez la possibilité de connecter vos propres flux d'intelligence sur les menaces à Sentinel, ce qui enrichit les capacités d'analyse des incidents dans votre cloud Azure. On peut affirmer qu'Azure Sentinel est le premier SIEM « natif » disponible pour les fournisseurs de cloud (tels que Splunk ou ELK, qui peuvent être déployés dans le cloud, par exemple AWS, ont tout de même été développés par des fournisseurs de services cloud traditionnels). Azure Sentinel et Security Center pourraient être considérés comme le SOC pour le cloud Azure et pourraient suffire (avec certaines réserves) si vous n'aviez plus aucune infrastructure et que toutes vos ressources de calcul étaient transférées dans le cloud, ce qui serait alors le cloud Microsoft Azure.

Cependant, les fonctionnalités intégrées d'Azure (même avec un abonnement à Sentinel) sont souvent insuffisantes pour les besoins de surveillance de la sécurité de l'information et pour l'intégration de ce processus avec d'autres sources d'événements de sécurité, tant cloud qu internes. Cela génère le besoin d'exporter les données collectées vers des systèmes externes, parmi lesquels peut figurer un SIEM. Cela se fait à la fois via API et à l'aide d'extensions spécifiques, qui sont actuellement officiellement disponibles uniquement pour les SIEM suivants : Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight et ELK. Il y a peu, il y avait davantage de ces SIEM, mais depuis le 1er juin 2019, Microsoft a cessé de prendre en charge l'outil d'intégration des journaux Azure (AzLog), qui au début de l'existence d'Azure, et en l'absence d'une normalisation adéquate dans le traitement des journaux (Azure Monitor n'existait même pas encore), permettait d'intégrer facilement les SIEM externes avec le cloud de Microsoft. La situation a maintenant changé et Microsoft recommande la plateforme Azure Event Hub comme principal outil d'intégration pour les autres SIEM. Beaucoup ont déjà réalisé cette intégration, mais soyez prudents : ils peuvent ne pas capturer tous les journaux Azure, mais uniquement certains d'entre eux (voir la documentation de votre SIEM).

En terminant ce bref aperçu d'Azure, je souhaite donner une recommandation générale sur ce service cloud : avant de faire des affirmations concernant les fonctionnalités de surveillance de la sécurité de l'information (SI) dans Azure, il est essentiel de les configurer avec soin et de tester pour vérifier qu'elles fonctionnent comme indiqué dans la documentation et comme vous l'ont expliqué les consultants Microsoft (qui peuvent avoir des opinions divergentes sur l'efficacité des fonctions d'Azure). Si vos ressources financières le permettent, vous pouvez tirer beaucoup de bénéfices d'Azure en matière de surveillance de la SI. En revanche, si vos ressources sont limitées, comme pour AWS, vous devrez compter uniquement sur vos propres forces et les données brutes fournies par Azure Monitor. N'oubliez pas que de nombreuses fonctionnalités de surveillance sont payantes, il est donc conseillé de se familiariser avec la politique tarifaire à l'avance. Par exemple, vous pouvez stocker gratuitement des données pendant 31 jours, avec une limite de 5 Go par client — tout dépassement de ces valeurs vous coûtera des frais supplémentaires (environ 2+ dollars pour chaque Go de stockage supplémentaire et 0,1 dollar pour chaque Go supplémentaire par mois). Travailler avec la télémétrie des applications et des métriques peut également nécessiter des fonds supplémentaires, tout comme la gestion des alertes et des notifications (un certain quota gratuit est disponible, qui peut ne pas suffire à vos besoins).

Exemple : Surveillance de la SI en IaaS sur Google Cloud Platform

Google Cloud Platform, face à AWS et Azure, semble encore jeune, mais c'est en partie une bonne chose. Contrairement à AWS, qui a progressivement développé ses capacités, y compris en matière de sécurité, rencontrant des problèmes de centralisation, GCP, tout comme Azure, est beaucoup mieux géré de manière centralisée, ce qui réduit le nombre d'erreurs et le temps d'implémentation en entreprise. En termes de sécurité, GCP se situe, curieusement, entre AWS et Azure. Il dispose effectivement d'un enregistrement des événements unique pour toute l'organisation, mais il est incomplet. Certaines fonctionnalités sont encore en version bêta, mais ce manque devrait être progressivement corrigé, et GCP deviendra une plateforme plus mature en matière de surveillance de la SI.

L'outil principal pour l'enregistrement des événements dans GCP est Stackdriver Logging (l'équivalent d'Azure Monitor), qui vous permet de collecter des événements dans l'ensemble de votre infrastructure cloud (ainsi que depuis AWS). En termes de sécurité dans GCP, chaque organisation, projet ou dossier dispose de quatre journaux d'enregistrement :

• Activité administrateur — contient tous les événements liés à l'accès administratif, comme la création d'une machine virtuelle, la modification des droits d'accès, etc. Ce journal est toujours écrit, indépendamment de votre souhait, et conserve ses données pendant 400 jours.
• Accessibilité des données — contient tous les événements liés au travail des utilisateurs cloud avec les données (création, modification, lecture, etc.). Par défaut, ce journal n'est pas écrit, car son volume augmente très rapidement. Pour cette raison, sa durée de conservation est de seulement 30 jours. De plus, tous les événements ne sont pas enregistrés ici. Par exemple, les événements liés aux ressources accessibles publiquement à tous les utilisateurs ou accessibles sans connexion à GCP ne sont pas consignés dans ce journal.
• Événement système — contient des événements système non liés aux utilisateurs ou des actions d'un administrateur qui modifie la configuration des ressources cloud. Il est toujours écrit et conservé pendant 400 jours.
• Access Transparency — est un exemple unique de journal d'enregistrement, qui consigne toutes les actions des employés de Google (mais pas encore pour tous les services GCP) qui accèdent à votre infrastructure dans le cadre de l'exercice de leurs fonctions. Ce journal est conservé pendant 400 jours et n'est pas accessible à tous les clients GCP, mais uniquement dans certaines conditions (soit un support de niveau Gold ou Platinum, soit disposer de 4 rôles spécifiques dans le cadre du support d'entreprise). Une fonction similaire existe également, par exemple, dans Office 365 — Lockbox.

Exemple de journal : Access Transparency

{
 insertId: "abcdefg12345"
 jsonPayload: {
 @type: "type.googleapis.com/google.cloud.audit.TransparencyLog"
 location: {
 principalOfficeCountry: "États-Unis"
 principalEmployingEntity: "Google LLC"
 principalPhysicalLocationCountry: "Canada"
 }
 product: [
 0: "Cloud Storage"
 ]
 reason: [
 detail: "Numéro de dossier : bar123"
 type: "CUSTOMER_INITIATED_SUPPORT"
 ]
 accesses: [
 0: {
 methodName: "GoogleInternal.Read"
 resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
 }
 ]
 }
 logName: "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.comaccess_transparency"
 operation: {
 id: "12345xyz"
 }
 receiveTimestamp: "2017-12-18T16:06:37.400577736Z"
 resource: {
 labels: {
 project_id: "1234567890"
 }
 type: "project"
 }
 severity: "NOTICE"
 timestamp: "2017-12-18T16:06:24.660001Z"
}

L'accès aux journaux spécifiés est possible de plusieurs manières (de la même manière que pour Azure et AWS précédemment examinés) — via l'interface Log Viewer, via l'API, via Google Cloud SDK ou via la page Activité de votre projet où vous êtes intéressé par les événements. De la même manière, ils peuvent également être exportés vers des solutions externes pour une analyse supplémentaire. Cela se fait par l'exportation des journaux vers le stockage BigQuery ou Cloud Pub/Sub.

En plus de Stackdriver Logging, la plateforme GCP propose également la fonctionnalité Stackdriver Monitoring, qui permet de suivre les métriques clés (performance, temps de fonctionnement, état général, etc.) des services et applications cloud. Les données traitées et visualisées peuvent faciliter la recherche de problèmes dans votre infrastructure cloud, y compris dans le contexte de la sécurité. Mais il faut noter que cette fonctionnalité sera assez limitée dans le contexte de la cybersécurité, car à ce jour, GCP n'a pas d'équivalent à AWS GuardDuty et ne peut pas distinguer parmi tous les événements enregistrés les mauvais événements (Google a développé Event Threat Detection, mais il est encore en version bêta et il est prématuré de parler de son utilité). Stackdriver Monitoring pourrait être utilisé comme système de détection des anomalies, qui seraient ensuite enquêtées pour chercher les causes de leur apparition. Cependant, dans un marché où il manque des professionnels qualifiés en cybersécurité, cette tâche semble compliquée pour le moment.

Il convient également de dresser une liste de certains modules de cybersécurité qui peuvent être appliqués dans votre cloud GCP, et qui sont similaires à ceux proposés par AWS :

• Cloud Security Command Center — c'est l'équivalent de AWS Security Hub et Azure Security Center.
• Cloud DLP — détection et édition automatiques (par exemple, masquage) des données stockées dans le cloud selon plus de 90 politiques de classification prédéfinies.
• Cloud Scanner — scanner des vulnérabilités connues (XSS, injection Flash, bibliothèques non patchées, etc.) dans App Engine, Compute Engine et Google Kubernetes.
• Cloud IAM — gestion des accès à toutes les ressources GCP.
• Cloud Identity — gestion des comptes utilisateurs, des dispositifs et des applications GCP depuis une console unique.
• Cloud HSM — protection des clés cryptographiques.
• Cloud Key Management Service — gestion des clés cryptographiques dans GCP.
• VPC Service Control — création d'un périmètre sécurisé autour de vos ressources GCP pour les protéger des fuites.
• Titan Security Key — protection contre le phishing.

Beaucoup de ces modules génèrent des événements de sécurité qui peuvent être envoyés à un stockage BigQuery pour analyse ou exportation vers d'autres systèmes, y compris les SIEM. Comme mentionné ci-dessus, GCP est une plateforme en développement actif et Google développe actuellement plusieurs nouveaux modules de sécurité pour sa plateforme. Parmi eux, Event Threat Detection (actuellement en bêta), qui analyse les journaux Stackdriver à la recherche de traces d'activités non autorisées (similaire à GuardDuty sur AWS), ou Policy Intelligence (disponible en alpha), qui permettra de développer des politiques d'accès intelligentes aux ressources GCP.

J'ai fait un petit aperçu des capacités de surveillance intégrées dans les plateformes cloud populaires. Mais avez-vous des spécialistes capables de travailler avec des journaux "bruts" du fournisseur IaaS (tout le monde n'est pas prêt à acheter des fonctionnalités avancées d'AWS, Azure ou Google) ? De plus, beaucoup connaissent le dicton "fais confiance, mais vérifie", qui est plus vrai que jamais dans le domaine de la sécurité. Dans quelle mesure faites-vous confiance aux capacités intégrées du fournisseur cloud qui vous envoie des événements de sécurité ? À quel point se concentrent-ils vraiment sur la sécurité ?

Il est parfois judicieux d'envisager des solutions de surveillance superposées pour les infrastructures cloud, qui peuvent compléter la sécurité intégrée du cloud. Parfois, ces solutions sont la seule option pour obtenir des données sur la sécurité de vos données et applications hébergées dans le cloud. De plus, elles sont plus pratiques, car elles prennent en charge toutes les tâches d'analyse des journaux nécessaires, générés par divers services cloud de différents fournisseurs. Un exemple de cette solution superposée est Cisco Stealthwatch Cloud, qui se concentre sur une seule tâche : la surveillance des anomalies de sécurité dans les environnements cloud, y compris Amazon AWS, Microsoft Azure et Google Cloud Platform, ainsi que les clouds privés.

Exemple : Surveillance de la sécurité avec Stealthwatch Cloud

AWS offre une plateforme de calcul flexible, mais cette flexibilité rend plus facile pour les entreprises de commettre des erreurs menant à des problèmes de sécurité. De plus, le modèle partagé de sécurité ne fait qu'accentuer ce problème. Le déploiement dans le cloud de logiciels avec des vulnérabilités inconnues (pour lesquelles il peut y avoir des solutions telles que AWS Inspector ou GCP Cloud Scanner pour les vulnérabilités connues), des mots de passe faibles, des configurations incorrectes, des initiés, etc. Tout cela affecte le comportement des ressources cloud, que Cisco Stealthwatch Cloud peut surveiller, étant un système de surveillance de la sécurité et de détection des attaques dans les clouds publics et privés.

Une des caractéristiques clés de Cisco Stealthwatch Cloud est la capacité de modélisation des entités. Grâce à cet outil, vous pouvez créer un modèle logiciel (c'est-à-dire une simulation presque en temps réel) de chacune de vos ressources cloud (qu'il s'agisse d'AWS, Azure, GCP ou d'autres). Cela peut inclure des serveurs et des utilisateurs, ainsi que des types de ressources spécifiques à votre environnement cloud, comme des groupes de sécurité et des groupes d'auto-scalabilité des services. Ces modèles utilisent comme données d'entrée des flux de données structurés fournis par les services cloud. Par exemple, pour AWS, cela comprendra les VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda et AWS IAM. La modélisation des entités détecte automatiquement le rôle et le comportement de chacune de vos ressources (on peut parler du profilage de toute l'activité cloud). Parmi ces rôles se trouvent un appareil mobile Android ou Apple, un serveur Citrix PVS, un serveur RDP, une passerelle de messagerie, un client VoIP, un serveur terminal, un contrôleur de domaine, etc. Ensuite, il suit en continu leur comportement pour déterminer quand un comportement risqué ou menaçant pour la sécurité se produit. Vous pouvez identifier des tentatives de piratage, des attaques DDoS, des fuites de données, un accès à distance illégal, l'exécution de code malveillant, des scans de vulnérabilités et d'autres menaces. Par exemple, voici à quoi ressemble la détection d'une tentative d'accès à distance depuis un pays atypique pour votre organisation (Corée du Sud) vers un cluster Kubernetes par SSH:

Voici à quoi ressemble une fuite de données présumée d'une base de données Postgress vers un pays avec lequel il n'y a eu auparavant aucune interaction:

Enfin, voici à quoi ressemble un nombre excessif de tentatives d'accès SSH infructueuses en provenance de Chine et d'Indonésie depuis un appareil distant externe:

Ou supposons qu'une instance de serveur dans un VPC, conformément à la politique, ne doit jamais être un point de destination pour un accès à distance. Supposons en outre qu'un accès à distance ait eu lieu sur cet ordinateur en raison d'un changement erroné de la politique des règles de pare-feu. La fonction de modélisation des entités détectera et signalera cette activité (« Accès à distance inhabituel ») en quasi temps réel et indiquera l'appel API spécifique d'AWS CloudTrail, Azure Monitor ou GCP Stackdriver Logging (y compris le nom d'utilisateur, la date et l'heure, entre autres détails) qui a provoqué le changement dans la règle du pare-feu. Ensuite, cette information peut être envoyée à un SIEM pour analyse.

Des capacités similaires sont mises en œuvre pour tout environnement cloud pris en charge par Cisco Stealthwatch Cloud :

La modélisation des entités est une forme unique d'automatisation de la sécurité qui peut détecter des problèmes inconnus concernant vos personnes, vos processus ou vos technologies. Par exemple, elle permet de détecter parmi d'autres de tels problèmes de sécurité, tels que :

• Quelqu'un a-t-il découvert un backdoor dans le logiciel que nous utilisons ?
• Y a-t-il un logiciel ou un appareil tiers dans notre cloud ?
• Un utilisateur autorisé abuse-t-il de ses privilèges ?
• Une erreur de configuration a-t-elle été commise, permettant un accès à distance ou une autre utilisation non intentionnelle des ressources ?
• Y a-t-il eu des fuites de données sur nos serveurs ?
• Quelqu'un a-t-il essayé de se connecter à nous depuis un lieu géographique atypique ?
• Notre cloud est-il infecté par un code malveillant ?

Un événement de sécurité identifié peut être transmis sous la forme d'un ticket approprié dans Slack, Cisco Spark, le système de gestion des incidents PagerDuty, ainsi que dans divers SIEM, tels que Splunk ou ELK. En résumé, si votre entreprise utilise une stratégie multi-cloud et n'est pas limitée à un fournisseur de cloud unique, les capacités de surveillance de la sécurité décrites ci-dessus font de Cisco Stealthwatch Cloud une option intéressante pour obtenir un ensemble unifié de fonctionnalités de surveillance pour les principaux acteurs du cloud : Amazon, Microsoft et Google. Fait intéressant, si l'on compare les prix de Stealthwatch Cloud avec des licences avancées de surveillance de la sécurité sur AWS, Azure ou GCP, il peut s'avérer que la solution Cisco soit même moins chère que les fonctionnalités intégrées des solutions Amazon, Microsoft et Google. C'est paradoxal, mais c'est une réalité. Plus vous utilisez de clouds et de leurs fonctionnalités, plus l'avantage d'une solution consolidée est évident.

De plus, Stealthwatch Cloud peut surveiller des clouds privés déployés au sein de votre organisation, par exemple, ceux basés sur des conteneurs Kubernetes ou en surveillant les flux Netflow ou le trafic réseau obtenu par le mirroring dans les équipements réseau (même ceux de fabrication nationale), des données AD ou des serveurs DNS, etc. Toutes ces données seront enrichies par des informations sur les menaces, collectées par l'équipe Cisco Talos, qui est le plus grand groupe de recherche sur les menaces de sécurité au monde.

Cela vous permet de mettre en place un système de surveillance unifié pour les clouds publics et hybrides que votre entreprise peut utiliser. Les informations collectées peuvent ensuite être analysées à l'aide des fonctionnalités intégrées de Stealthwatch Cloud ou envoyées à votre SIEM (Splunk, ELK, SumoLogic et d'autres sont pris en charge par défaut).

Nous avons terminé la première partie de cet article, dans laquelle j'ai examiné les outils intégrés et externes de surveillance de la sécurité des plateformes IaaS/PaaS, qui nous permettent de détecter et de réagir rapidement aux incidents survenant dans les environnements cloud choisis par notre entreprise. Dans la seconde partie, nous poursuivrons ce sujet et explorerons les options de surveillance des plateformes SaaS en prenant exemple sur Salesforce et Dropbox, tout en essayant de résumer et de rassembler le tout pour créer un système unifié de surveillance de la sécurité des différents fournisseurs de cloud.

Source : habr.com