Surveillance de la sécurité du cloud

Le transfert de données et d'applications vers les nuages ​​est un nouveau problème pour les SOC d'entreprise qui ne sont pas toujours prêts à surveiller l'infrastructure des autres. Selon Netoskope, une entreprise de taille moyenne (apparemment toujours aux États-Unis) utilise 1246 services cloud différents, soit 22% de plus qu'il y a un an. 1246 services cloud !!! 175 d'entre eux concernent les services RH, 170 sont liés au marketing, 110 dans le domaine de la communication et 76 dans la finance et le CRM. Cisco utilise 700 services cloud externes au total. Par conséquent, je suis un peu confus par ces chiffres. Mais en tout cas, le problème ne vient pas d'eux, mais du fait que les nuages ​​sont activement utilisés par un nombre croissant d'entreprises qui souhaitent disposer des mêmes capacités de surveillance de l'infrastructure cloud que dans leur propre réseau. Et cette tendance s'accentue - selon l'American Audit Office, d'ici 2023, 1 200 centres de données vont fermer aux États-Unis (6 250 ont déjà fermé). Mais la transition vers le cloud n'est pas seulement «mais transférons nos serveurs à un fournisseur externe». Nouvelle architecture informatique, nouveaux logiciels, nouveaux processus, nouvelles restrictions ... Tout cela modifie considérablement le travail non seulement de l'informatique, mais aussi de la sécurité de l'information. Et si les fournisseurs ont appris à gérer la sécurité du cloud lui-même (l'avantage des recommandations est considérable), il y a alors des difficultés importantes avec la surveillance du cloud de la sécurité des informations, en particulier sur les plateformes SaaS, dont nous parlerons.



Disons que votre entreprise a déplacé une partie de son infrastructure vers le cloud ... Arrêtez. Pas comme ça. Si l'infrastructure est transférée et que vous ne réfléchissez qu'à la façon dont vous allez la surveiller, vous avez déjà perdu. Si ce n'est pas Amazon, Google ou Microsoft (et avec des réserves), vous n'aurez probablement pas beaucoup d'occasions de surveiller vos données et applications. Eh bien, si vous avez la possibilité de travailler avec des journaux. Parfois, des données sur les événements de sécurité seront disponibles, mais vous n'y aurez pas accès. Par exemple, Office 365. Si vous disposez de la licence E1 la moins chère, les événements de sécurité ne sont pas du tout disponibles. Si vous avez une licence E3, vous n'avez besoin de stocker les données que pendant 90 jours, et uniquement si vous avez E5 - la durée des journaux est disponible pendant un an (bien qu'il existe certaines nuances associées à la nécessité de demander séparément un certain nombre de fonctions de journalisation auprès du support Microsoft). Soit dit en passant, la licence E3 est beaucoup plus faible en termes de fonctions de surveillance que Corporate Exchange. Pour atteindre le même niveau, vous avez besoin d'une licence E5 ou d'une licence de conformité avancée supplémentaire, qui peut nécessiter de l'argent supplémentaire qui n'était pas inclus dans votre modèle financier pour la transition vers l'infrastructure cloud. Et ce n'est qu'un exemple d'une sous-estimation des problèmes liés à la surveillance du cloud IS. Dans cet article, sans prétendre être complet, je souhaite attirer l'attention sur certaines nuances à prendre en compte lors du choix d'un fournisseur de cloud du point de vue de la sécurité. Et à la fin de l'article, une liste de contrôle sera donnée, qui devrait être complétée avant de considérer que le problème de surveillance de la sécurité du cloud est résolu.

Il existe plusieurs problèmes typiques qui conduisent à des incidents dans des environnements cloud, auxquels les services de l'IB n'ont pas le temps de répondre ou ne voient pas du tout:

• Les journaux de sécurité n'existent pas. Il s'agit d'une situation assez courante, en particulier pour les débutants sur le marché du cloud. Mais y mettre fin tout de suite ne vaut pas la peine. Les petits acteurs, en particulier les acteurs nationaux, sont plus sensibles aux exigences des clients et peuvent rapidement mettre en œuvre certaines fonctions demandées en modifiant la feuille de route approuvée pour leurs produits. Oui, ce ne sera pas un analogue de GuardDuty d'Amazon ou du module Proactive Defense de Bitrix, mais au moins quelque chose.
• IB ne sait pas où les journaux sont stockés ou n'y a pas accès. Ici, il est nécessaire d'engager des négociations avec le fournisseur de services cloud - peut-être qu'il fournira ces informations s'il considère que le client est important pour lui-même. Mais en général, ce n'est pas très bon lorsque l'accès aux journaux est fourni «par une décision spéciale».
• Il arrive également que le fournisseur de cloud dispose de journaux, mais ils fournissent une surveillance et une journalisation des événements limitées, insuffisantes pour détecter tous les incidents. Par exemple, vous ne pouvez recevoir que les journaux des modifications sur le site ou les journaux des tentatives d'authentification des utilisateurs, mais ils ne peuvent pas donner d'autres événements, par exemple, sur le trafic réseau, qui vous cacheront toute une couche d'événements qui caractérisent les tentatives de percée dans votre infrastructure cloud.
• Il existe des journaux, mais leur accès est difficile à automatiser, ce qui les rend surveillés non pas en continu, mais selon un calendrier. Et si vous ne parvenez toujours pas à télécharger les journaux en mode automatique, le téléchargement des journaux, par exemple, au format Excel (comme avec certains fournisseurs de solutions cloud nationales), peut complètement conduire à la réticence à jouer avec eux depuis le service SI de l'entreprise.
• Aucune surveillance des journaux. C'est peut-être la raison la plus incompréhensible de la survenue d'incidents de sécurité des informations dans les environnements cloud. Il semble qu'il existe des journaux et vous pouvez automatiser l'accès à ceux-ci, mais personne ne le fait. Pourquoi?

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

Passer au cloud est toujours la recherche d'un équilibre entre la volonté de garder le contrôle de l'infrastructure et de la transférer aux mains plus professionnelles du fournisseur de cloud, spécialisé dans sa maintenance. Et dans le domaine de la sécurité du cloud, cet équilibre doit également être recherché. De plus, selon le modèle utilisé pour fournir des services cloud (IaaS, PaaS, SaaS), cet équilibre sera toujours différent. Dans toutes les situations, nous devons nous rappeler qu'aujourd'hui tous les fournisseurs de cloud suivent le soi-disant modèle de responsabilité partagée et de sécurité des informations partagées. Le cloud est responsable de quelque chose, le client est responsable de quelque chose, ayant placé ses données, ses applications, ses machines virtuelles et d'autres ressources dans le cloud. Il serait insensé de s’attendre à ce qu’étant passés dans le cloud, nous transférions toutes les responsabilités au fournisseur. Mais créer toute la sécurité par eux-mêmes lors du passage au cloud est également déraisonnable. Un équilibre est nécessaire, qui dépendra de nombreux facteurs: - stratégies de gestion des risques, modèles de menace disponibles pour le fournisseur de cloud de mécanismes de défense, législation, etc.



Par exemple, la classification des données hébergées dans le cloud est toujours à la charge du client. Un fournisseur de cloud ou un fournisseur de services externe ne peut l'aider qu'avec une boîte à outils qui aidera à marquer les données dans le cloud, à identifier les violations, à supprimer les données qui enfreignent la loi ou à les masquer à l'aide d'une méthode ou d'une autre. D'un autre côté, la sécurité physique est toujours la responsabilité du fournisseur de cloud, qu'il ne peut pas partager avec les clients. Mais tout ce qui se trouve entre les données et l'infrastructure physique est précisément le sujet de discussion dans cet article. Par exemple, la disponibilité du cloud est la responsabilité du fournisseur, et la définition des règles de l'UIT ou l'activation du chiffrement est la responsabilité du client. Dans cet article, nous essaierons de voir quels types de mécanismes de sécurité des informations sont fournis par divers fournisseurs de cloud populaires en Russie aujourd'hui, quelles sont les fonctionnalités de leur application et quand regarder dans la direction de solutions de superposition externes (par exemple, Cisco E-mail Security) qui étendent en partie les capacités de votre cloud la cybersécurité. Dans certains cas, en particulier lorsque vous suivez une stratégie multi-cloud, vous n'aurez d'autre choix que d'utiliser des solutions de surveillance de la sécurité externes dans plusieurs environnements cloud à la fois (par exemple, Cisco CloudLock ou Cisco Stealthwatch Cloud). Eh bien, dans certains cas, vous comprendrez que le fournisseur de cloud que vous avez choisi (ou imposé) n'offre aucune option pour surveiller la sécurité des informations. C'est désagréable, mais aussi beaucoup, car cela vous permet d'évaluer correctement 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 nuages ​​que vous utilisez, vous n'avez que trois options:

• compter sur les outils fournis par votre fournisseur de cloud,
• profiter de solutions tierces qui surveilleront les plateformes IaaS, PaaS ou SaaS que vous utilisez,
• Créez votre propre infrastructure de surveillance cloud (plates-formes IaaS / PaaS uniquement).

Voyons quelles sont les fonctionnalités de chacune de ces options. Mais d'abord, nous devons comprendre le schéma général qui sera utilisé dans la surveillance des plateformes cloud. Je voudrais souligner 6 principaux composants du processus de surveillance de la sécurité de l'information dans le cloud:

• Préparation des infrastructures. Identification des applications et de l'infrastructure nécessaires pour collecter les événements importants pour la sécurité des informations dans le référentiel.
• Collection. À ce stade, les événements de sécurité sont agrégés à partir de diverses sources pour une transmission ultérieure au traitement, au stockage et à l'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 collectées.
• Analyse. À ce stade, vous avez la possibilité de détecter les incidents et d'y répondre automatiquement ou manuellement.
• Rapports Cette étape permet de former des indicateurs clés pour les parties intéressées (direction, auditeurs, fournisseurs de cloud, clients, etc.) qui nous aident à prendre certaines décisions, par exemple, changer de fournisseur ou renforcer le SI.

La compréhension de ces composants vous permettra 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.

Services cloud intégrés

J'ai déjà écrit ci-dessus que tant de services cloud aujourd'hui ne fournissent aucune possibilité de surveillance de la sécurité des informations. En général, ils n'accordent pas beaucoup d'attention au sujet de la sécurité de l'information. Par exemple, l'un des services russes populaires pour l'envoi de rapports aux agences gouvernementales via Internet (je ne mentionnerai pas spécifiquement son nom). L'ensemble de la section sécurité de ce service tourne autour de l'utilisation d'outils de protection des informations cryptographiques certifiés. La section de la sécurité de l'information d'un autre service cloud national pour la gestion électronique des documents n'est plus un exemple. Il parle de certificats de clé publique, de cryptographie certifiée, d'élimination des vulnérabilités Web, de protection contre les attaques DDoS, d'application de l'UIT, de sauvegarde et même de réalisation d'audits de SI réguliers. Mais pas un mot sur la surveillance, ni sur la possibilité d'accéder à des événements de sécurité de l'information qui pourraient intéresser les clients de ce prestataire de services.

En général, par la façon dont le fournisseur de cloud décrit les problèmes de sécurité des informations sur son site Web et dans la documentation, on peut comprendre à quel point il prend ce problème au sérieux. Par exemple, si vous lisez les manuels des produits My Office, il n'y a pas un mot sur la sécurité et la documentation du produit séparé My Office. KS3 », conçu pour protéger contre les accès non autorisés, est l'énumération habituelle des clauses du 17ème ordre du FSTEC, qui exécute« My office.KS3 », mais n'est pas décrit comment il met en œuvre et, surtout, comment intégrer ces mécanismes avec la sécurité des informations de l'entreprise. Peut-être qu'une telle documentation existe, mais je ne l'ai pas trouvée dans le domaine public sur le site My Office. Bien que je n'aie peut-être tout simplement pas accès à ces informations classifiées? ..



La même situation Bitrix est bien meilleure. La documentation décrit les formats des journaux des événements et, fait intéressant, le journal des intrusions, qui contient les événements liés aux menaces potentielles pour la plate-forme cloud. De là, vous pouvez obtenir l'IP, le nom d'utilisateur ou le nom de l'invité, la source de l'événement, l'heure, l'agent utilisateur, le type d'événement, etc. Certes, vous pouvez travailler avec ces événements à partir du panneau de configuration du cloud lui-même ou télécharger des données au format MS Excel. Il est difficile d'automatiser le travail avec les journaux Bitrix maintenant et vous devrez effectuer une partie du travail manuellement (télécharger le rapport et le charger dans votre SIEM). Mais si vous vous souvenez que jusqu'à relativement récemment, et que cela n'était pas possible, c'est un grand progrès. Dans le même temps, je tiens à noter que de nombreux fournisseurs de cloud étrangers offrent des fonctionnalités similaires «pour les débutants» - regardez les journaux avec vos yeux à travers le panneau de configuration ou téléchargez des données pour vous-même (bien que la plupart des données soient téléchargées au format .csv, pas Excel).



Si vous n'envisagez pas l'option sans journaux, les fournisseurs de cloud vous proposent généralement trois options pour surveiller les événements de sécurité - tableaux de bord, télécharger des données et y accéder via l'API. Le premier semble résoudre de nombreux problèmes pour vous, mais ce n'est pas entièrement vrai - s'il y a plusieurs magazines, vous devez basculer entre les écrans qui les affichent, perdant ainsi la vue d'ensemble. En outre, il est peu probable que le fournisseur de cloud vous offre la possibilité de corréler les événements de sécurité et généralement de les analyser d'un point de vue de sécurité (généralement, vous traitez des données brutes dont vous avez besoin de vous comprendre). Il existe des exceptions et nous en parlerons plus loin. Enfin, il convient de demander quels événements votre fournisseur de cloud enregistre, dans quel format et dans quelle mesure correspondent-ils à votre processus de surveillance des SI? Par exemple, l'identification et l'authentification des utilisateurs et des invités. Le même Bitrix vous permet d'enregistrer la date et l'heure de l'événement donné, le nom de l'utilisateur ou de l'invité (en présence du module Web Analytics), l'objet auquel l'accès est effectué et d'autres éléments typiques du site Web. Mais les services SI d'entreprise peuvent avoir besoin d'informations pour savoir si un utilisateur s'est connecté au cloud à partir d'un appareil de confiance (par exemple, dans un réseau d'entreprise, Cisco ISE implémente cette tâche). Et une tâche aussi simple que la fonction géo-IP, qui aidera à déterminer si le compte utilisateur du service cloud est volé? Et même si le fournisseur de cloud vous le fournit, cela ne suffit pas. Le même Cisco CloudLock n'analyse pas seulement la géolocalisation, mais utilise l'apprentissage automatique pour cela et analyse les données historiques pour chaque utilisateur et suit diverses anomalies dans les tentatives d'identification et d'authentification. Seul MS Azure a des fonctionnalités similaires (s'il existe un abonnement correspondant).



Il y a une difficulté supplémentaire - car pour de nombreux fournisseurs de cloud, la surveillance des SI est un nouveau sujet qu'ils commencent à peine à traiter, ils changent constamment quelque chose dans leurs décisions. Aujourd'hui, ils ont une version de l'API, demain une autre, le troisième jour après-demain. Il faut également s'y préparer. La même chose avec des fonctionnalités qui peuvent changer, qui doivent être prises en compte dans votre système de surveillance de la sécurité des informations. Par exemple, Amazon avait initialement des services de surveillance des événements cloud distincts - AWS CloudTrail et AWS CloudWatch. Puis est venu un service de surveillance des événements IS distinct - AWS GuardDuty. Après un certain temps, Amazon a lancé le nouveau système de gestion Amazon Security Hub, qui comprend une analyse des données reçues de GuardDuty, Amazon Inspector, Amazon Macie et plusieurs autres. Un autre exemple est l'outil d'intégration de journaux Azure avec SIEM - AzLog. De nombreux fournisseurs SIEM l'ont activement utilisé, jusqu'en 2018, Microsoft a annoncé la fin de son développement et de son support, ce qui a mis de nombreux clients qui utilisaient cet outil avant le problème (car il a été résolu, nous en parlerons plus tard).

Par conséquent, surveillez attentivement toutes les fonctions de surveillance que votre fournisseur de cloud vous propose. Ou faites confiance à des fournisseurs externes de solutions qui agiront comme intermédiaires entre votre SOC et le cloud que vous souhaitez surveiller. Oui, cela coûtera plus cher (mais pas toujours), mais vous transférerez ensuite toutes les responsabilités aux épaules des autres. Ou pas tous? .. Rappelez-vous le concept de sécurité partagée et comprenez que nous ne pouvons rien changer - vous devrez comprendre comment les différents fournisseurs de cloud assurent la surveillance de la sécurité des informations de vos données, applications, machines virtuelles et autres ressources situées dans le cloud. Et nous commencerons par ce qu'Amazon propose dans cette partie.

Exemple: surveillance de la sécurité dans IaaS basé sur AWS

Oui, oui, je comprends qu'Amazon n'est pas le meilleur exemple étant donné qu'il s'agit d'un service américain et qu'il peut être bloqué dans le cadre de la lutte contre l'extrémisme et la diffusion d'informations interdites en Russie. Mais dans cette publication, je voudrais simplement montrer comment les différentes plates-formes cloud diffèrent dans les capacités de sécurité des informations et ce à quoi vous devez faire attention lors du transfert de vos processus clés vers les clouds d'un point de vue de la sécurité. Eh bien, si certains des développeurs russes de solutions cloud obtiennent quelque chose d'utile, ce sera génial.



Je dois d'abord dire que l'Amazonie n'est pas une forteresse imprenable. Divers incidents arrivent régulièrement à ses clients. Par exemple, les noms, adresses, dates de naissance et téléphones de 198 millions d'électeurs ont été volés à Deep Root Analytics. 14 millions d'enregistrements d'abonnement Verizon volés à Nice Systems, Israël Dans le même temps, les capacités intégrées d'AWS vous permettent de détecter un large éventail d'incidents. Par exemple:

• Influence sur l'infrastructure (DDoS)
• compromis de nœud (injection de commande)
• compromission de compte et accès non autorisé
• mauvaise configuration et vulnérabilités
• interfaces et API non protégées.

Cette divergence est due au fait que le client lui-même est responsable de la sécurité des données client, comme nous l'avons constaté ci-dessus. Et s'il ne s'est pas inquiété de l'inclusion de mécanismes de protection et n'a pas inclus d'outils de surveillance, alors il n'apprendra l'incident que par les médias ou par ses clients.

Pour détecter les incidents, vous pouvez utiliser une large gamme de divers services de surveillance développés par Amazon (bien qu'ils soient souvent complétés par des outils externes, tels que l'osquery). Ainsi, dans AWS, toutes les actions des utilisateurs sont suivies, quelle que soit la façon dont elles sont effectuées - via 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 disponibles via AWS CloudTrail. Vous pouvez afficher ces événements (par exemple, vous connecter à la console AWS IAM) à partir de la console CloudTrail, les analyser à l'aide d'Amazon Athena ou les «donner» à des solutions externes, telles que Splunk, AlienVault, etc. Les journaux AWS CloudTrail eux-mêmes sont placés dans votre compartiment AWS S3.



Les deux autres services AWS offrent des capacités de surveillance plus importantes. Premièrement, Amazon CloudWatch est un service de surveillance des ressources et des applications AWS qui, entre autres, peut détecter diverses anomalies dans votre cloud. Tous les services AWS intégrés, tels qu'Amazon Elastic Compute Cloud (serveurs), Amazon Relational Database Service (bases de données), Amazon Elastic MapReduce (analyse des données) et 30 autres services Amazon, utilisent Amazon CloudWatch pour stocker leurs journaux. Les développeurs peuvent utiliser l'API ouverte Amazon CloudWatch pour ajouter une surveillance des journaux aux applications et services utilisateur, ce qui permet d'élargir la gamme d'événements analysés dans le contexte de la sécurité des informations.



Deuxièmement, le service VPC Flow Logs vous permet d'analyser le trafic réseau envoyé ou reçu par vos serveurs AWS (en externe ou en interne), ainsi qu'entre les microservices. Lorsqu'une de vos ressources AWS VPC interagit avec le réseau, le service VPC Flow Logs enregistre les informations de trafic réseau, y compris les interfaces 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 vus. Ceux qui ont une expérience de la sécurité des réseaux locaux reconnaissent cela comme un analogue des flux NetFlow .qui peuvent être créés par des commutateurs, des routeurs et des pare-feu de niveau entreprise. Ces journaux sont importants pour la surveillance de la sécurité des informations car, contrairement aux événements d'activité des utilisateurs et des applications, ils vous permettent également de ne pas manquer la communication réseau dans l'environnement de cloud privé virtuel AWS.



Ainsi, ces trois services AWS - AWS CloudTrail, Amazon CloudWatch et VPC Flow Logs - fournissent ensemble une vue assez efficace de l'utilisation de votre compte, du comportement des utilisateurs, de la gestion de l'infrastructure, de l'activité des applications et des services et de l'activité du réseau. Par exemple, ils peuvent être utilisés pour détecter les anomalies suivantes:

• Tente d'analyser le site, de rechercher des portes dérobées, de rechercher des vulnérabilités à travers des rafales de «404 erreurs».
• Injection- (, SQL injection) “ 500”.
• sqlmap, nikto, w3af, nmap .. User Agent.

Amazon Web Services a également développé d'autres services de cybersécurité qui répondent à de nombreux autres défis. Par exemple, AWS dispose d'un service intégré pour l'audit des stratégies et des configurations - AWS Config. Ce service fournit un audit continu de vos ressources AWS et de leurs configurations. Prenons un exemple simple: supposons que vous vouliez 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 facilite la vérification de cela pour tous vos serveurs. Il existe d'autres politiques qui peuvent être appliquées à vos serveurs cloud: «Aucun serveur ne peut utiliser le port 22», «Seuls les administrateurs peuvent modifier les règles de pare-feu» ou «Seul l'utilisateur Ivashko peut créer de nouveaux comptes d'utilisateurs, et il peut le faire ce n'est que le mardi. »À l'été 2016, AWS Config a été étendu pour automatiser la détection des violations des stratégies développées. Les règles de configuration AWS sont, en substance, des demandes de configuration continues pour les services Amazon que vous utilisez, qui génèrent des événements en cas de violation des politiques pertinentes. Par exemple, au lieu d'exécuter périodiquement des demandes AWS Config pour vérifier que tous les lecteurs de serveur virtuel sont cryptés, les règles AWS Config peuvent être utilisées pour vérifier en permanence les lecteurs de serveur pour cette condition. Et, plus important encore, dans le cadre de cette publication, toute violation génère des événements qui peuvent être analysés par votre service SI.Demandes de configuration continues pour les services Amazon que vous utilisez qui génèrent des événements lorsque les politiques sont violées. Par exemple, au lieu d'exécuter périodiquement des demandes AWS Config pour vérifier que tous les lecteurs de serveur virtuel sont cryptés, les règles AWS Config peuvent être utilisées pour vérifier en permanence les lecteurs de serveur pour cette condition. Et, plus important encore, dans le cadre de cette publication, toute violation génère des événements qui peuvent être analysés par votre service SI.Demandes de configuration continues pour les services Amazon que vous utilisez qui génèrent des événements lorsque les politiques sont violées. Par exemple, au lieu d'exécuter périodiquement des demandes AWS Config pour vérifier que tous les disques de serveur virtuel sont chiffrés, les règles AWS Config peuvent être utilisées pour vérifier en permanence les disques serveur pour cette condition. Et, plus important encore, dans le cadre de cette publication, toute violation génère des événements qui peuvent être analysés par votre service SI.Les règles de configuration AWS peuvent être utilisées pour vérifier en permanence les disques du serveur pour cette condition. Et, plus important encore, dans le cadre de cette publication, toute violation génère des événements qui peuvent être analysés par votre service SI.Les règles de configuration AWS peuvent être utilisées pour vérifier en permanence les disques du serveur pour cette condition. Et, plus important encore, dans le cadre de cette publication, toute violation génère des événements qui peuvent être analysés par votre service SI.



AWS a également ses équivalents aux solutions de sécurité des informations d'entreprise traditionnelles 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 - AWS Macie
• EDR (bien que parler des points de terminaison dans le cloud soit un peu bizarre) - AWS Cloudwatch + solutions open source osquery ou GRR
• Analyse de Netflow - Flux AWS Cloudwatch + AWS VPC
• Analyser DNS - AWS Cloudwatch + AWS Route53
• AD - Service d'annuaire AWS
• Gestion des comptes - AWS IAM
• SSO - AWS SSO
• analyse de sécurité - AWS Inspector
• gestion de la configuration - AWS Config
• WAF - AWS WAF.

Je ne détaillerai pas tous les services Amazon qui peuvent être utiles dans le contexte de la sécurité des informations. La principale chose à comprendre est qu'ils peuvent tous générer des événements que nous pouvons et devons analyser dans le contexte de la sécurité des informations, impliquant à la fois les capacités intégrées d'Amazon et des solutions externes, par exemple SIEM, qui peuvent apporter des événements de sécurité à votre centre de surveillance. et les analyser là-bas avec les événements d'autres services cloud ou de l'infrastructure interne, du périmètre ou des appareils mobiles.



Dans tous les cas, tout commence par des sources de données qui vous fournissent des événements IB. Ces sources comprennent, sans s'y limiter:

• CloudTrail - Utilisation de l'API et actions de l'utilisateur
• Trusted Advisor - Security Check for Best Practices
• Config —
• VPC Flow Logs —
• IAM —
• ELB Access Logs —
• Inspector —
• S3 —
• CloudWatch —
• SNS — .

Amazon, offrant une telle gamme de sources d'événements et d'outils pour leur génération, est très limité dans sa capacité à analyser les données collectées dans le contexte de la sécurité des informations. Vous devrez étudier indépendamment les journaux disponibles, en y recherchant les indicateurs de compromis correspondants. L'AWS Security Hub, récemment lancé par Amazon, vise à résoudre ce problème en devenant une sorte de SIEM cloud pour AWS. Mais s'il n'est qu'au début de son parcours et est limité à la fois par le nombre de sources avec lesquelles il travaille, et par d'autres restrictions établies par l'architecture et les abonnements d'Amazon lui-même.

Exemple: surveillance du SI dans IaaS basé sur Azure

Je ne veux pas m'engager dans un long débat sur lequel des trois fournisseurs de cloud (Amazon, Microsoft ou Google) est le meilleur (d'autant plus que chacun d'eux a ses spécificités et convient pour résoudre ses problèmes); se concentrer sur les capacités de surveillance de la sécurité fournies par ces joueurs. Certes, Amazon AWS a été l'un des premiers dans ce segment et a donc avancé le plus en termes de fonctions de sécurité de l'information (bien que beaucoup admettent que leur utilisation est difficile). Mais cela ne signifie pas que nous ignorerons les opportunités que Microsoft nous offre avec Google.

Les produits Microsoft se distinguent toujours par leur "ouverture" et dans Azure la situation est similaire. Par exemple, si AWS et GCP résultent toujours du concept de "tout ce qui n'est pas autorisé est interdit", Azure à l'approche exactement opposée. Par exemple, en créant un réseau virtuel dans le cloud et une machine virtuelle, tous les ports et protocoles sont ouverts et activés par défaut. Par conséquent, vous devez consacrer un peu plus d'efforts à la configuration initiale du système de contrôle d'accès dans le cloud de Microsoft. Et cela vous impose également des exigences plus strictes en termes de surveillance de l'activité dans le cloud Azure.



AWS a une particularité associée au fait que lorsque vous surveillez vos ressources virtuelles, alors si elles se trouvent dans différentes régions, vous avez des difficultés à combiner tous les événements et leur analyse unique, pour éliminer le recours à diverses astuces, telles que Créez un code personnalisé pour AWS Lambda qui transportera les événements entre les régions. Il n'y a pas un tel problème dans Azure - son mécanisme de journal d'activité surveille toutes les activités de l'organisation sans restrictions. Il en va de même pour l'AWS Security Hub, qui a été récemment développé par Amazon pour consolider de nombreuses fonctions de sécurité au sein d'un centre de sécurité unique, mais uniquement dans sa région, ce qui, cependant, n'est pas pertinent pour la Russie. Azure possède son propre centre de sécurité, qui n'est pas lié par des restrictions régionales,donnant accès à toutes les fonctionnalités de sécurité de la plateforme cloud. De plus, pour diverses équipes locales, il peut fournir son propre ensemble de capacités défensives, y compris les événements de sécurité qu'ils gèrent. L'AWS Security Hub s'efforce toujours de devenir comme Azure Security Center. Mais cela vaut la peine d'ajouter une mouche dans la pommade - vous pouvez extraire une grande partie de ce qui était précédemment décrit dans AWS à partir d'Azure, mais cela n'est plus pratique que pour Azure AD, Azure Monitor et Azure Security Center. Tous les autres mécanismes de défense Azure, y compris l'analyse des événements de sécurité, ne sont pas encore gérés de la manière la plus pratique. Une partie du problème est résolue par l'API qui imprègne tous les services Microsoft Azure, mais cela nécessitera des efforts supplémentaires pour intégrer votre cloud à votre SOC et la disponibilité de spécialistes qualifiés (en fait,comme avec tout autre. SIEM travaillant avec des API cloud). Certains SIEM, qui seront abordés plus loin, prennent déjà en charge Azure et peuvent automatiser la tâche de surveillance, mais il présente certaines difficultés - ils ne peuvent pas tous prendre tous les journaux d'Azure.



La collecte et la surveillance des événements dans Azure sont fournies à l'aide du service Azure Monitor, qui est le principal outil de collecte, de stockage et d'analyse des données dans le cloud Microsoft et ses ressources - référentiels Git, conteneurs, machines virtuelles, applications, etc. Toutes les données collectées par Azure Monitor sont divisées en deux catégories: les mesures en temps réel qui décrivent les indicateurs de performance clés du cloud Azure et les journaux d'enregistrement contenant des données organisées en enregistrements décrivant certains aspects des activités des ressources et services Azure. De plus, à l'aide de l'API Data Collector, le service Azure Monitor peut collecter des données à partir de n'importe quelle source REST pour créer ses propres scénarios de surveillance.



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

• Journaux d'activité - ce journal répond aux questions classiques «qui», «quoi» et «quand» concernant toute opération d'écriture (PUT, POST, DELETE) sur les ressources du cloud. Les événements liés à l'accès en lecture (GET) n'entrent pas dans ce journal, ainsi que dans un certain nombre d'autres.
• Journaux de diagnostic - contient des données sur les opérations avec une ressource particulière incluse dans votre abonnement.
• Rapports Azure AD - contient à la fois l'activité des utilisateurs et l'activité du système liée à la gestion des groupes et des utilisateurs.
• Journal des événements Windows et Linux Syslog - contient les événements des machines virtuelles hébergées dans le cloud.
• Metrics — “” . . 30 .
• Network Security Group Flow Logs — , Network Watcher .
• Storage Logs — , .

Pour la surveillance, vous pouvez utiliser un SIEM externe ou le moniteur Azure intégré et ses extensions. Nous parlerons davantage des systèmes de gestion des événements SI, mais pour l'instant, nous verrons ce qu'Azure nous offre pour analyser les 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 de sécurité et d'audit Log Analytics (la version gratuite prend en charge le stockage d'un nombre limité d'événements pour une seule semaine). Ce panneau est divisé en 5 zones principales qui visualisent des statistiques récapitulatives sur ce qui se passe dans votre environnement cloud:

• Domaines de sécurité - indicateurs quantitatifs clés liés à la sécurité des informations - nombre d'incidents, nombre de nœuds compromis, nœuds non corrigés, événements de sécurité réseau, etc.
• Problèmes notables - Affiche le nombre et l'importance des problèmes IB actifs
• Detections — ,
• Threat Intelligence — ,
• Common security queries — , .

Les extensions Azure Monitor incluent Azure Key Vault (protection des clés cryptographiques dans le cloud), Malware Assessment (analyse de la protection contre le code malveillant sur les machines virtuelles), Azure Application Gateway Analytics (analyse, entre autres, des journaux de pare-feu cloud), etc. . Ces outils, enrichis de certaines règles de traitement des événements, vous permettent de visualiser divers aspects de l'activité des services cloud, dont la sécurité, et d'identifier certains écarts par rapport au travail. Mais, comme cela arrive souvent, toute fonctionnalité supplémentaire nécessite un abonnement payant approprié, ce qui vous obligera à effectuer des investissements financiers appropriés, que vous devez planifier à l'avance.



Azure dispose d'un certain nombre de fonctionnalités de surveillance des menaces intégrées qui sont intégrées à Azure AD, Azure Monitor et Azure Security Center. Parmi eux, par exemple, la détection de l'interaction de machines virtuelles avec des adresses IP malveillantes connues (en raison de l'intégration avec les services Microsoft Threat Intelligence), la détection de logiciels malveillants dans l'infrastructure cloud en recevant des alarmes de machines virtuelles situées dans le cloud, des attaques comme «deviner les mots de passe» »Aux machines virtuelles, vulnérabilités dans la configuration du système d'identification des utilisateurs, connexion depuis des anonymiseurs ou des nœuds infectés, fuite de compte, connexion depuis des emplacements inhabituels, etc. Azure est aujourd'hui l'un des rares fournisseurs de cloud à vous offrir des fonctionnalités intégrées de Threat Intelligence pour enrichir les événements de sécurité des informations collectés.



Comme mentionné ci-dessus, 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 la même manière, mais nécessitent un certain abonnement qui inclut les fonctionnalités dont vous avez besoin, qui génère les événements correspondants pour surveiller la sécurité des informations. Par exemple, certaines des fonctions de surveillance des anomalies dans les comptes décrites dans le paragraphe précédent sont disponibles uniquement dans la licence P2 premium pour Azure AD. Sans cela, vous devrez, comme dans le cas d'AWS, analyser «manuellement» les événements de sécurité collectés. De plus, selon le type de licence pour Azure AD, tous les événements à analyser ne seront pas disponibles pour vous.

Sur le portail Azure, vous pouvez gérer les deux requêtes de recherche dans les journaux qui vous intéressent et configurer des tableaux de bord pour visualiser les principaux indicateurs de sécurité des informations. De plus, vous pouvez choisir les extensions Azure Monitor, qui vous permettent d'étendre les fonctionnalités des journaux Azure Monitor et d'obtenir une analyse plus approfondie des événements d'un point de vue de la sécurité.



Si vous avez besoin non seulement de la capacité de travailler avec des journaux, mais du centre de sécurité complet de votre plateforme cloud Azure, y compris la gestion des stratégies SI, vous pouvez parler de la nécessité de travailler avec Azure Security Center, dont la plupart sont utiles moyennant des frais, par exemple, la détection des menaces, la surveillance en dehors d'Azure, évaluation de la conformité, etc. (Dans la version gratuite, vous n'avez accès qu'à une évaluation de sécurité et à des recommandations pour résoudre les problèmes identifiés). Il regroupe tous les problèmes de sécurité en un seul endroit. En fait, nous pouvons parler d'un niveau de sécurité des informations plus élevé que celui fourni par Azure Monitor, car dans ce cas, les données collectées dans l'ensemble de votre usine cloud sont enrichies à l'aide de diverses sources, telles qu'Azure, Office 365, Microsoft CRM en ligne, Microsoft Dynamics AX, Outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) et Microsoft Security Response Center (MSRC), qui se superposent à divers algorithmes sophistiqués d'apprentissage automatique et d'analyse comportementale, ce qui devrait à terme augmenter l'efficacité de la détection et de la réponse aux menaces.

Azure a son propre SIEM - il est apparu au début de 2019. Il s'agit d'Azure Sentinel, qui s'appuie sur les données d'Azure Monitor et peut également s'intégrer à. des solutions de sécurité externes (par exemple, NGFW ou WAF), dont la liste est constamment mise à jour. De plus, grâce à l'intégration de l'API Microsoft Graph Security, vous pouvez connecter vos propres flux Threat Intelligence à Sentinel, ce qui améliore la capacité d'analyser les incidents dans votre cloud Azure. On peut affirmer qu'Azure Sentinel est le premier SIEM "natif" apparu dans les fournisseurs de cloud (le même Splunk ou ELK, qui peut être placé dans le cloud, par exemple, AWS, n'est toujours pas développé par les fournisseurs de services cloud traditionnels). Azure Sentinel and Security Center pourrait être appelé SOC pour le cloud Azure et ils pourraient être limités (avec certaines réservations) si vous n'aviez plus d'infrastructure et que vous transfériez toutes vos ressources informatiques vers le cloud et que ce serait un cloud Microsoft Azure



Mais comme les capacités intégrées d'Azure (même avec un abonnement Sentinel) ne sont souvent pas suffisantes pour la surveillance du SI et l'intégration de ce processus avec d'autres sources d'événements de sécurité (cloud et internes), il devient nécessaire d'exporter les données collectées vers des systèmes externes, qui peut inclure SIEM. Cela se fait à la fois à l'aide de l'API et à l'aide d'extensions spéciales officiellement disponibles pour le moment uniquement pour les SIEM suivants - Splunk (module complémentaire Azure Monitor pour Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight et ELK. Plus récemment, il y avait plus de tels SIEM, mais à partir du 1er juin 2019, Microsoft a cessé de prendre en charge Azure Log Integration Tool (AzLog), qui à l'aube d'Azure et en l'absence de normalisation normale du travail avec les journaux (Azure Monitor n'existait même pas) a rendu la tâche facile. Intégrez des SIEM externes à Microsoft Cloud. Maintenant, la situation a changé et Microsoft recommande la plate-forme Azure Event Hub comme principal outil d'intégration pour le reste de SIEM. Beaucoup ont déjà implémenté cette intégration, mais faites attention - ils peuvent ne pas capturer tous les journaux Azure, mais seulement certains (voir la documentation de votre SIEM).

Pour conclure une brève excursion sur Azure, je veux donner une recommandation générale sur ce service cloud - avant de dire quoi que ce soit sur les fonctions de surveillance de la sécurité dans Azure, vous devez les configurer très soigneusement et tester qu'elles fonctionnent comme indiqué dans la documentation et comme les consultants vous l'ont dit. Microsoft (et ils peuvent avoir des vues différentes sur les performances des fonctionnalités Azure). Si vous disposez des capacités financières d'Azure, vous pouvez extraire de nombreuses informations utiles concernant la surveillance de la sécurité des informations. Si vos ressources sont limitées, comme dans le cas d'AWS, vous ne devrez compter que sur vos propres ressources et données brutes qu'Azure Monitor vous fournit. Et n'oubliez pas que de nombreuses fonctions de surveillance coûtent de l'argent et qu'il est préférable de vous familiariser à l'avance avec les prix. Par exemple, vous pouvez stocker gratuitement les données pendant 31 jours pour un maximum de 5 Go pour un client - dépasser ces valeurs vous obligera à débourser en plus (environ 2 $ + pour stocker chaque Go supplémentaire du client et 0,1 $ pour stocker 1 Go chaque mois supplémentaire ) L'utilisation de la télémétrie et des métriques d'application peut également nécessiter des ressources financières supplémentaires, ainsi que l'utilisation d'alertes et de notifications (une certaine limite est disponible gratuitement, ce qui peut ne pas être suffisant pour vos besoins).

Exemple: surveillance des SI dans IaaS basée sur Google Cloud Platform

La plate-forme Google Cloud dans le contexte d'AWS et Azure semble assez jeune, mais cela est en partie bon. Contrairement à AWS, qui renforçait progressivement ses capacités, y compris défensives, avec des problèmes de centralisation; GCP, comme Azure, est beaucoup mieux géré de manière centralisée, ce qui réduit le nombre d'erreurs et le temps de mise en œuvre dans l'entreprise. D'un point de vue de la sécurité, GCP est, curieusement, situé entre AWS et Azure. Il a également une seule inscription à l'événement pour l'ensemble de l'organisation, mais elle est incomplète. Certaines fonctions sont toujours en mode bêta, mais progressivement cette lacune devrait être éliminée et GCP deviendra une plateforme plus mature en termes de surveillance de la sécurité de l'information.



Le principal outil d'enregistrement des événements dans GCP est Stackdriver Logging (un analogue d'Azure Monitor), qui vous permet de collecter des événements sur l'ensemble de votre infrastructure cloud (ainsi qu'avec AWS). Du point de vue de la sécurité dans GCP, chaque organisation, projet ou dossier possède quatre journaux:

• Activité administrateur - contient tous les événements liés à l'accès administrateur, par exemple, la création d'une machine virtuelle, la modification des droits d'accès, etc. Ce journal est toujours écrit, quel que soit votre désir, et conserve ses données pendant 400 jours.
• Accès aux données - contient tous les événements liés à l'utilisation des données des utilisateurs du cloud (créer, modifier, lire, etc.). Par défaut, ce journal n'est pas écrit, car son volume gonfle très rapidement. Pour cette raison, sa durée de conservation n'est que de 30 jours. De plus, loin de tout est écrit dans ce journal. Par exemple, les événements liés aux ressources qui sont accessibles au public à tous les utilisateurs ou qui sont accessibles sans accès à GCP n'y sont pas écrits.
• Événement système - contient des événements système qui ne sont pas liés aux utilisateurs ou aux 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 de bord qui enregistre 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 leurs responsabilités professionnelles. Ce journal est stocké pendant 400 jours et n'est pas disponible pour tous les clients GCP, mais uniquement sous réserve d'un certain nombre de conditions (support Gold ou Platinum, ou présence de 4 rôles d'un certain type dans le cadre du support d'entreprise). Une fonctionnalité similaire est également disponible, par exemple, dans Office 365 - Lockbox.

Exemple de journal: accès à la transparence

{  insertId:  "abcdefg12345"  jsonPayload: {  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"  location: {   principalOfficeCountry:  "US"   principalEmployingEntity:  "Google LLC"   principalPhysicalLocationCountry:  "CA"  }  product: [   0:  "Cloud Storage"  ]  reason: [   detail:  "Case number: 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.com%2Faccess_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 à ces journaux est possible de plusieurs manières (de la même manière que précédemment envisagées par Azure et AWS) - via l'interface Log Viewer, via l'API, via le SDK Google Cloud ou via la page Activité de votre projet, selon laquelle 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. Ce dernier se fait en exportant les journaux vers le stockage BigQuery ou Cloud Pub / Sub.

En plus de Stackdriver Logging, la plate-forme GCP offre également la fonctionnalité Stackdriver Monitoring, qui vous permet de suivre les métriques clés (performances, MTBF, é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 sécurité. Mais il convient de noter que cette fonctionnalité ne sera pas très riche précisément dans le contexte de la sécurité des informations, car aujourd'hui GCP n'a pas d'analogue du même AWS GuardDuty et ne peut pas distinguer les mauvais de tous les événements enregistrés (Google a développé la détection des menaces d'événements, mais jusqu'à présent, il est en version bêta et parler de son utilité au début). Stackdriver Monitoring pourrait être utilisé comme un système de détection des anomalies, qui sera ensuite étudié pour trouver les causes de leur apparition. Mais dans les conditions de pénurie de personnel qualifié dans le domaine de la sécurité de l'information GCP sur le marché, cette tâche semble pour le moment difficile.



Il est également utile de répertorier certains des modules de sécurité des informations qui peuvent être utilisés dans votre cloud GCP et qui sont similaires à ce qu'offre AWS:

• Cloud Security Command Center est un analogue d'AWS Security Hub et Azure Security Center.
• Cloud DLP - détection et édition automatiques (par exemple, masquage) des données situées dans le cloud, selon plus de 90 politiques de classification prédéfinies.
• Cloud Scanner est un scanner des vulnérabilités connues (XSS, Flash Injection, bibliothèques non corrigées, etc.) dans App Engine, Compute Engine et Google Kubernetes.
• Cloud IAM - contrôle d'accès à toutes les ressources GCP.
• Cloud Identity - Gérez les comptes d'utilisateurs, les appareils et les applications GCP à partir d'une seule console.
• Cloud HSM - protection des clés cryptographiques.
• Cloud Key Management Service - gestion des clés cryptographiques dans GCP.
• Contrôle de service VPC - Créez 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 à BigQuery pour analyse ou exportation vers d'autres systèmes, y compris SIEM. Comme déjà mentionné ci-dessus, GCP est une plateforme activement développée et Google développe actuellement un certain nombre de nouveaux modules de sécurité de l'information pour sa plateforme. Parmi eux, Event Threat Detection (désormais disponible en version bêta), qui analyse les journaux de Stackdriver à la recherche de traces d'activité non autorisée (similaire à GuardDuty dans AWS), ou Policy Intelligence (disponible en alpha), qui permettra de développer des politiques d'accès intelligent aux ressources GCP.

J'ai fait un bref examen des capacités de surveillance intégrées dans les plates-formes cloud populaires. Mais avez-vous des spécialistes capables de travailler avec les journaux bruts du fournisseur IaaS (tout le monde n'est pas prêt à acheter des fonctionnalités avancées d'AWS ou Azure ou Google)? En outre, de nombreuses personnes connaissent le proverbe «Faites confiance, mais vérifiez», ce qui, dans le domaine de la sécurité, est plus vrai que jamais. Dans quelle mesure faites-vous confiance aux capacités intégrées du fournisseur de cloud qui vous envoient des événements IB? Dans quelle mesure se concentrent-ils sur la sécurité des informations?

Parfois, il vaut la peine de chercher des solutions de superposition pour surveiller les infrastructures cloud qui peuvent compléter la sécurité cloud intégrée, et parfois ces solutions sont le seul moyen d'obtenir des données sur la sécurité de vos données et applications situées dans le cloud. De plus, ils sont tout simplement plus pratiques, car ils assument toutes les tâches d'analyse des journaux nécessaires générés par différents services cloud de différents fournisseurs de cloud. Un exemple d'une telle solution imposée est le Cisco Stealthwatch Cloud, qui se concentre sur la seule tâche - surveiller les anomalies du SI dans les environnements cloud, y compris non seulement Amazon AWS, Microsoft Azure et Google Cloud Platform, mais aussi les clouds privés.

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

AWS fournit une plate-forme informatique flexible, mais cette flexibilité permet aux entreprises de commettre plus facilement des erreurs entraînant des problèmes de sécurité. Et le modèle SI partagé n'y contribue que. L'exécution de logiciels dans le cloud avec des vulnérabilités inconnues (par exemple, AWS Inspector ou GCP Cloud Scanner peut lutter contre des vulnérabilités connues), des mots de passe faibles, des configurations incorrectes, des initiés, etc. Et tout cela affecte le comportement des ressources cloud, qui peut être observé par Cisco Stealthwatch Cloud, qui est un système de surveillance de la sécurité des informations et de détection des attaques. nuages ​​publics et privés.



L'une des principales caractéristiques du Cisco Stealthwatch Cloud est la possibilité de modéliser des entités. Avec son aide, vous pouvez créer un modèle de programme (c'est-à-dire une simulation presque en temps réel) de chacune de vos ressources cloud (peu importe qu'il s'agisse d'AWS, Azure, GCP ou autre). Il peut s'agir de serveurs et d'utilisateurs, ainsi que de types de ressources spécifiques à votre environnement cloud, tels que des groupes de sécurité et des groupes à mise à l'échelle automatique. Ces modèles utilisent des flux de données structurés fournis par les services cloud comme entrée. Par exemple, pour AWS, il s'agira des journaux de flux VPC, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda et AWS IAM. La modélisation d'entité détecte automatiquement le rôle et le comportement de n'importe laquelle de vos ressources (vous pouvez parler de profiler toute l'activité du cloud). Parmi ces rôles figurent un appareil mobile Android ou Apple, un serveur Citrix PVS, un serveur RDP, une passerelle de messagerie, un client VoIP, un serveur de terminaux, un contrôleur de domaine, etc. Il surveille ensuite en continu leur comportement pour déterminer quand un comportement à risque ou menaçant la sécurité se produit. Vous pouvez identifier la recherche de mots de passe, les attaques DDoS, les fuites de données, l'accès à distance illégal, le code malveillant, l'analyse des 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 de votre organisation (Corée du Sud) vers le cluster Kubernetes via SSH:



Et voici à quoi ressemble la fuite présumée d'informations de la base de données Postgress dans un pays qui n'a pas été précédemment interagi:



Enfin, voici à quoi ressemblent trop de tentatives d'accès SSH échouées depuis la Chine et l'Indonésie à partir d'un périphérique distant externe:



Ou, supposons qu'une instance de serveur dans un VPC, conformément à la politique, ne doit jamais être une destination pour la connexion à distance. En outre, supposez qu'une connexion à distance s'est produite sur cet ordinateur en raison d'une modification erronée de la stratégie de règle de pare-feu. La fonctionnalité de modélisation d'entité détectera et signalera cette activité («accès à distance inhabituel») en temps quasi réel et pointera vers un appel spécifique à l'API 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é la modification de la règle de l'UIT. Et puis ces informations peuvent être transmises au SIEM pour analyse.



Des fonctionnalités similaires sont disponibles pour tout environnement cloud pris en charge par Cisco Stealthwatch Cloud:



La modélisation d'entités est une forme unique d'automatisation de la sécurité qui peut détecter un problème inconnu avec vos employés, vos processus ou vos technologies. Par exemple, il vous permet de détecter, entre autres, des problèmes de sécurité tels que:

• Quelqu'un a-t-il trouvé une porte dérobée dans le logiciel que nous utilisons?
• Existe-t-il un logiciel ou un appareil tiers dans notre cloud?
• Un utilisateur autorisé abuse-t-il des privilèges?
• Y a-t-il eu une erreur de configuration qui a permis l'accès à distance ou toute autre utilisation par inadvertance des ressources?
• Y a-t-il des fuites de données de nos serveurs?
• Quelqu'un a-t-il essayé de nous connecter à partir d'une situation géographique atypique?
• Notre cloud est-il infecté par un code malveillant?

L'événement IB détecté peut être transmis sous la forme d'un ticket approprié à Slack, Cisco Spark, système de gestion des incidents PagerDuty, et également envoyé à divers SIEM, y compris Splunk ou ELK. En résumé, nous pouvons dire que si votre entreprise utilise une stratégie multi-cloud et n'est pas limitée à un seul fournisseur de cloud, les capacités de surveillance de la sécurité des informations décrites ci-dessus, puis l'utilisation de Cisco Stealthwatch Cloud est une bonne option pour obtenir un ensemble unifié de capacités de surveillance pour les principaux acteurs du cloud - Amazon , Microsoft et Google. La chose la plus intéressante est que si vous comparez les prix du Stealthwatch Cloud avec des licences avancées de surveillance de la sécurité dans AWS, Azure ou GCP, il peut s'avérer que la solution Cisco sera encore moins chère que les capacités intégrées des solutions Amazon, Microsoft et Google. Paradoxalement, ça l'est. Et plus vous utiliserez de nuages ​​et de capacités, plus l'avantage d'une solution consolidée sera évident.



En outre, Stealthwatch Cloud peut également surveiller les clouds privés déployés dans votre organisation, par exemple, sur la base de conteneurs Kubernetes ou en surveillant les flux Netflow ou le trafic réseau reçu via la mise en miroir dans l'équipement réseau (même la production nationale), les données AD ou les serveurs DNS etc. Toutes ces données seront enrichies par des informations sur les menaces recueillies par Cisco Talos, le plus grand groupe non gouvernemental mondial de chercheurs sur les menaces liées aux SI.



Cela vous permet de mettre en œuvre 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 (par défaut, Splunk, ELK, SumoLogic et plusieurs autres sont pris en charge).

Ceci conclut la première partie de l'article dans laquelle j'ai examiné les outils intégrés et externes de surveillance des plates-formes IaaS / PaaS qui nous permettent de détecter et de répondre rapidement aux incidents dans les environnements cloud que notre entreprise a choisis. Dans la deuxième partie, nous continuerons le sujet et examinerons les options de surveillance des plates-formes SaaS utilisant Salesforce et Dropbox à titre d'exemple, et nous essaierons également de résumer et de tout assembler, créant un système de surveillance de la sécurité des informations unifié pour différents fournisseurs de cloud.