🥇Surveillance de la sécurité du Cloud

Le déplacement des données et des applications vers le cloud présente un nouveau défi pour les SOC des entreprises, qui ne sont pas toujours prêts à surveiller l'infrastructure des autres. Selon Netoskope, l'entreprise moyenne (apparemment aux États-Unis) utilise 1246 22 services cloud différents, soit 1246 % de plus qu'il y a un an. 175 services cloud !!! 170 d'entre eux concernent les services RH, 110 sont liés au marketing, 76 sont dans le domaine de la communication et 700 sont dans la finance et le CRM. Cisco utilise « seulement » XNUMX services cloud externes. Je suis donc un peu confus par ces chiffres. Mais dans tous les cas, le problème ne vient pas d'eux, mais du fait que le cloud commence à être utilisé assez activement par un nombre croissant d'entreprises qui souhaiteraient disposer des mêmes capacités de surveillance de l'infrastructure cloud que dans leur propre réseau. Et cette tendance s'accentue - selon selon la Chambre américaine des comptes D’ici 2023, 1200 6250 centres de données vont être fermés aux États-Unis (XNUMX XNUMX ont déjà fermé). Mais la transition vers le cloud ne consiste pas simplement à « déplacer nos serveurs vers un fournisseur externe ». Nouvelle architecture informatique, nouveaux logiciels, nouveaux processus, nouvelles restrictions... Tout cela apporte des changements importants non seulement au travail informatique, mais aussi à la sécurité de l'information. Et si les fournisseurs ont appris à assurer d'une manière ou d'une autre la sécurité du cloud lui-même (heureusement, il existe de nombreuses recommandations), alors avec la surveillance de la sécurité des informations dans le cloud, en particulier sur les plates-formes SaaS, il existe des difficultés importantes, dont nous parlerons.

Disons que votre entreprise a migré une partie de son infrastructure vers le cloud… Stop. Pas de cette façon. Si l'infrastructure a été transférée et que vous réfléchissez seulement maintenant à la manière dont vous allez la surveiller, alors vous avez déjà perdu. À moins qu'il ne s'agisse d'Amazon, de Google ou de Microsoft (et sous réserve), vous n'aurez probablement pas beaucoup de possibilités pour surveiller vos données et vos applications. C'est bien si vous avez la possibilité de travailler avec des journaux. Parfois, les données des é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 vous sont pas du tout disponibles. Si vous disposez d'une licence E3, vos données ne sont stockées que pendant 90 jours, et seulement si vous disposez d'une licence E5, la durée des journaux est disponible pendant un an (cependant, cela a aussi ses propres nuances liées à la nécessité de séparer séparément demander un certain nombre de fonctions pour travailler avec les journaux auprès du support Microsoft). À propos, la licence E3 est beaucoup plus faible en termes de fonctions de surveillance que celle d'entreprise Exchange. Pour atteindre le même niveau, vous avez besoin d'une licence E5 ou d'une licence Advanced Compliance supplémentaire, ce qui peut nécessiter des fonds supplémentaires qui n'ont pas été pris en compte dans votre modèle financier pour passer à l'infrastructure cloud. Et ce n’est là qu’un exemple de sous-estimation des problèmes liés à la surveillance de la sécurité des informations dans le cloud. Dans cet article, sans prétendre être complet, je souhaite attirer l'attention sur certaines nuances qui doivent être prises en compte lors du choix d'un fournisseur cloud du point de vue de la sécurité. Et à la fin de l'article, une liste de contrôle sera présentée, qui mérite d'être complétée avant de considérer que le problème de la surveillance de la sécurité des informations dans le cloud a été résolu.

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

Les journaux de sécurité n'existent pas. Il s'agit d'une situation assez courante, notamment chez les acteurs novices sur le marché des solutions cloud. Mais il ne faut pas les abandonner tout de suite. Les petits acteurs, notamment nationaux, sont plus sensibles aux exigences des clients et peuvent rapidement mettre en œuvre certaines fonctions requises 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 Protection » de Bitrix, mais au moins quelque chose.
La sécurité des informations ne sait pas où les journaux sont stockés ou il n'y a pas d'accès à ceux-ci. Ici, il est nécessaire d'entamer des négociations avec le fournisseur de services cloud - peut-être qu'il fournira de telles informations s'il considère le client important pour lui. Mais en général, ce n’est pas très bon lorsque l’accès aux journaux est fourni « par décision spéciale ».
Il arrive également que le fournisseur de cloud dispose de journaux, mais ceux-ci fournissent une surveillance et un enregistrement des événements limités, qui ne suffisent pas à détecter tous les incidents. Par exemple, vous pouvez recevoir uniquement des journaux de modifications sur un site Web ou des journaux de tentatives d'authentification des utilisateurs, mais pas d'autres événements, comme le trafic réseau, ce qui vous cachera toute une couche d'événements qui caractérisent les tentatives de piratage de votre infrastructure cloud.
Il existe des journaux, mais leur accès est difficile à automatiser, ce qui oblige à les surveiller non pas en continu, mais selon un calendrier. Et si vous ne pouvez pas télécharger les journaux automatiquement, le téléchargement des journaux, par exemple au format Excel (comme c'est le cas pour un certain nombre de fournisseurs nationaux de solutions cloud), peut même conduire à une réticence de la part du service de sécurité des informations de l'entreprise à les bricoler.
Pas de surveillance des journaux. C’est peut-être la raison la moins claire de l’apparition d’incidents de sécurité des informations dans les environnements cloud. Il semble qu'il existe des journaux et qu'il est possible d'en automatiser l'accès, mais personne ne le fait. Pourquoi?

Concept de sécurité cloud partagé

La transition vers le cloud est toujours une recherche d'équilibre entre la volonté de garder le contrôle de l'infrastructure et son transfert entre les mains plus professionnelles d'un 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 de prestation de services cloud utilisé (IaaS, PaaS, SaaS), cet équilibre sera toujours différent. Dans tous les cas, nous devons nous rappeler que tous les fournisseurs de cloud suivent aujourd’hui le modèle dit de responsabilité partagée et de sécurité des informations partagées. Le cloud est responsable de certaines choses, et pour d'autres le client est responsable, en plaçant ses données, ses applications, ses machines virtuelles et autres ressources dans le cloud. Il serait imprudent de s’attendre à ce qu’en passant au cloud, nous transférions toute la responsabilité sur le fournisseur. Mais il n’est pas non plus judicieux de mettre en place toute la sécurité vous-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èle de menace, mécanismes de sécurité dont dispose le fournisseur de cloud, législation, etc.

Par exemple, la classification des données hébergées dans le cloud relève toujours de la responsabilité du client. Un fournisseur de cloud ou un fournisseur de services externe ne peut l'aider qu'avec des outils qui permettront de marquer les données dans le cloud, d'identifier les violations, de supprimer les données qui enfreignent la loi ou de les masquer en utilisant une méthode ou une autre. En revanche, la sécurité physique relève toujours de la responsabilité du fournisseur de cloud, qu’il ne peut partager avec les clients. Mais tout ce qui se situe entre données et infrastructure physique est justement le sujet de discussion dans cet article. Par exemple, la disponibilité du cloud relève de la responsabilité du fournisseur, et la configuration des règles de pare-feu ou l'activation du cryptage relève de la responsabilité du client. Dans cet article, nous allons essayer d'examiner quels mécanismes de surveillance de la sécurité des informations sont proposés aujourd'hui par divers fournisseurs de cloud populaires en Russie, quelles sont les caractéristiques de leur utilisation et quand vaut-il la peine de se tourner vers des solutions de superposition externes (par exemple, Cisco E- mail Security) qui étendent les capacités de votre cloud en termes de cybersécurité. Dans certains cas, notamment si vous suivez une stratégie multi-cloud, vous n'aurez d'autre choix que d'utiliser des solutions externes de surveillance de la sécurité des informations dans plusieurs environnements cloud à la fois (par exemple, Cisco CloudLock ou Cisco Stealthwatch Cloud). Eh bien, dans certains cas, vous vous rendrez compte que le fournisseur de cloud que vous avez choisi (ou que vous avez imposé) n'offre aucune capacité de surveillance de la sécurité des informations. C'est désagréable, mais pas peu non plus, car cela permet d'évaluer adéquatement le niveau de risque associé au travail avec ce cloud.

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

Pour surveiller la sécurité des cloud que vous utilisez, vous n'avez que trois options :

comptez sur les outils fournis par votre fournisseur cloud,
utiliser des solutions tierces qui surveilleront les plateformes IaaS, PaaS ou SaaS que vous utilisez,
créez votre propre infrastructure de surveillance cloud (uniquement pour les plateformes IaaS/PaaS).

Voyons quelles sont les caractéristiques de chacune de ces options. Mais d’abord, nous devons comprendre le cadre général qui sera utilisé lors de la surveillance des plateformes cloud. Je soulignerais 6 composants principaux du processus de surveillance de la sécurité des informations dans le cloud :

Préparation des infrastructures. Déterminer les applications et l'infrastructure nécessaires à la collecte des événements importants pour la sécurité des informations dans le stockage.
Collection. À ce stade, les événements de sécurité sont regroupés à partir de diverses sources pour être ensuite transmis à des fins de traitement, de stockage et d'analyse.
Traitement. A cette étape, les données sont transformées et enrichies pour faciliter les analyses ultérieures.
Stockage. Ce composant est responsable du stockage à court et à long terme des données traitées et brutes collectées.
Analyse. A ce stade, vous avez la possibilité de détecter les incidents et d’y répondre automatiquement ou manuellement.
Rapport. Cette étape permet de formuler des indicateurs clés pour les parties prenantes (direction, auditeurs, fournisseur cloud, clients, etc.) qui nous aident à prendre certaines décisions, par exemple changer de fournisseur ou renforcer la sécurité de l'information.

Comprendre ces éléments vous permettra de décider rapidement à l'avenir ce que vous pouvez demander à votre prestataire et ce que vous devrez faire vous-même ou avec la participation de consultants externes.

Services cloud intégrés

J'ai déjà écrit ci-dessus que de nombreux services cloud ne fournissent aujourd'hui aucune capacité de surveillance de la sécurité des informations. En général, ils ne prêtent pas beaucoup d’attention au thème 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). Toute la section sur la sécurité de ce service tourne autour de l'utilisation du CIPF certifié. La section de sécurité de l'information d'un autre service cloud national pour la gestion électronique des documents n'est pas différente. 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'utilisation de pare-feu, de sauvegardes et même d'audits réguliers de sécurité des informations. Mais il n'y a pas un mot sur la surveillance, ni sur la possibilité d'accéder aux événements de sécurité de l'information qui pourraient intéresser les clients de ce prestataire de services.

En général, la manière dont le fournisseur de cloud décrit les problèmes de sécurité des informations sur son site Web et dans sa documentation vous permet de 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é, mais dans la documentation du produit distinct « My Office. KS3", conçu pour protéger contre les accès non autorisés, il existe une liste habituelle de points du 17ème ordre du FSTEC, que "My Office.KS3" implémente, mais il n'est pas décrit comment il le met en œuvre et, surtout, comment intégrer ces mécanismes à 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 Web « Mon Bureau ». Mais peut-être que je n’ai tout simplement pas accès à ces informations secrètes ?

Pour Bitrix, la situation est bien meilleure. La documentation décrit les formats des journaux d'événements et, fait intéressant, le journal d'intrusion, qui contient les événements liés aux menaces potentielles pour la plateforme cloud. À partir de là, vous pouvez extraire l'adresse IP, le nom de l'utilisateur ou 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 soit à partir du panneau de contrôle du cloud lui-même, soit télécharger des données au format MS Excel. Il est désormais difficile d'automatiser le travail avec les logs Bitrix et vous devrez effectuer une partie du travail manuellement (télécharger le rapport et le charger dans votre SIEM). Mais si l’on se souvient que jusqu’à une date relativement récente, une telle opportunité n’existait pas, il s’agit alors d’un grand progrès. Dans le même temps, je voudrais noter que de nombreux fournisseurs de cloud étrangers proposent des fonctionnalités similaires "pour les débutants" - soit regardez les journaux avec vos yeux via le panneau de contrôle, soit téléchargez les données sur vous-même (cependant, la plupart téléchargent les données au format . csv, pas Excel).

Sans considérer l'option sans journaux, les fournisseurs de cloud vous proposent généralement trois options pour surveiller les événements de sécurité : les tableaux de bord, le téléchargement de données et l'accès aux API. La première semble résoudre de nombreux problèmes pour vous, mais ce n'est pas tout à fait vrai : si vous avez plusieurs magazines, vous devez basculer entre les écrans qui les affichent, perdant ainsi l'image globale. De plus, il est peu probable que le fournisseur de cloud vous offre la possibilité de corréler les événements de sécurité et de les analyser généralement du point de vue de la sécurité (il s'agit généralement de données brutes que vous devez comprendre vous-même). Il existe des exceptions et nous en reparlerons plus loin. Enfin, il convient de se demander quels événements sont enregistrés par votre fournisseur de cloud, dans quel format et comment correspondent-ils à votre processus de surveillance de la sécurité des informations ? Par exemple, l'identification et l'authentification des utilisateurs et des invités. Le même Bitrix vous permet, sur la base de ces événements, d'enregistrer la date et l'heure de l'événement, le nom de l'utilisateur ou de l'invité (si vous disposez du module « Web Analytics »), l'objet consulté et d'autres éléments typiques d'un site Web. . Mais les services de sécurité des informations d'entreprise peuvent avoir besoin d'informations indiquant si l'utilisateur a accédé au cloud à partir d'un appareil de confiance (par exemple, dans un réseau d'entreprise, cette tâche est mise en œuvre par Cisco ISE). Qu'en est-il d'une tâche aussi simple que la fonction géo-IP, qui aidera à déterminer si un compte utilisateur d'un service cloud a été 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 pour cela l'apprentissage automatique et analyse les données historiques de chaque utilisateur et surveille diverses anomalies dans les tentatives d'identification et d'authentification. Seul MS Azure possède des fonctionnalités similaires (si vous disposez de l'abonnement approprié).

Il existe une autre difficulté : puisque pour de nombreux fournisseurs de cloud, la surveillance de la sécurité des informations est un nouveau sujet qu'ils commencent tout juste à aborder, ils changent constamment quelque chose dans leurs solutions. Aujourd'hui, ils ont une version de l'API, demain une autre, après-demain une troisième. Vous devez également vous y préparer. Il en va de même pour les fonctionnalités, qui peuvent changer, et qui doivent être prises en compte dans votre système de surveillance de la sécurité de l'information. Par exemple, Amazon disposait initialement de services distincts de surveillance des événements cloud : AWS CloudTrail et AWS CloudWatch. Ensuite, un service distinct pour surveiller les événements de sécurité des informations est apparu - AWS GuardDuty. Après un certain temps, Amazon a lancé un nouveau système de gestion, Amazon Security Hub, qui inclut l'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. Il a été activement utilisé par de nombreux fournisseurs SIEM, jusqu'à ce qu'en 2018 Microsoft annonce l'arrêt de son développement et de son support, ce qui a confronté de nombreux clients qui utilisaient cet outil à un problème (nous parlerons de la façon dont il a été résolu plus tard).

Par conséquent, surveillez attentivement toutes les fonctionnalités de surveillance que votre fournisseur de cloud vous propose. Ou faites confiance à des fournisseurs de solutions externes qui feront office d’intermédiaires entre votre SOC et le cloud que vous souhaitez superviser. Oui, cela coûtera plus cher (mais pas toujours), mais vous transférerez toute la responsabilité sur les épaules de quelqu'un d'autre. Ou pas tout ?.. Rappelons-nous le concept de sécurité partagée et comprenons que nous ne pouvons rien changer - nous devrons comprendre de manière indépendante comment différents fournisseurs de cloud assurent la surveillance de la sécurité des informations de vos données, applications, machines virtuelles et autres ressources hébergé dans le cloud. Et nous commencerons par ce que propose Amazon dans cette partie.

Exemple : Surveillance de la sécurité des informations dans IaaS basée sur AWS

Oui, oui, je comprends qu'Amazon n'est pas le meilleur exemple car 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 en quoi les différentes plates-formes cloud diffèrent dans leurs capacités de surveillance de la sécurité des informations et à quoi vous devez faire attention lors du transfert de vos processus clés vers les nuages du point de vue de la sécurité. Eh bien, si certains développeurs russes de solutions cloud apprennent quelque chose d'utile par eux-mêmes, ce sera formidable.

La première chose à dire est qu’Amazon n’est pas une forteresse impénétrable. Divers incidents arrivent régulièrement à ses clients. Par exemple, les noms, adresses, dates de naissance et numéros de téléphone de 198 millions d’électeurs ont été volés à Deep Root Analytics. La société israélienne Nice Systems a volé 14 millions de dossiers d'abonnés Verizon. Cependant, les fonctionnalités intégrées d'AWS vous permettent de détecter un large éventail d'incidents. Par exemple:

impact sur les infrastructures (DDoS)
compromission du nœud (injection de commande)
compromission de compte et accès non autorisé
configuration incorrecte et vulnérabilités
interfaces et API non sécurisées.

Cette différence est due au fait que, comme nous l'avons vu ci-dessus, le client est lui-même responsable de la sécurité de ses données. Et s'il n'a pas pris la peine d'activer les mécanismes de protection ni les outils de surveillance, il n'apprendra l'incident que par les médias ou par ses clients.

Pour identifier les incidents, vous pouvez utiliser un large éventail de services de surveillance différents développés par Amazon (même si ceux-ci sont souvent complétés par des outils externes tels qu'osquery). Ainsi, dans AWS, toutes les actions des utilisateurs sont surveillées, quelle que soit la manière dont elles sont effectuées - via la console de gestion, la ligne de commande, le SDK ou d'autres services AWS. Tous les enregistrements de l'activité de chaque compte AWS (y compris le nom d'utilisateur, l'action, le service, les paramètres d'activité et le résultat) et l'utilisation de l'API sont disponibles via AWS CloudTrail. Vous pouvez visualiser ces événements (tels que les connexions à la console AWS IAM) depuis la console CloudTrail, les analyser à l'aide d'Amazon Athena ou les « externaliser » vers des solutions externes telles que Splunk, AlienVault, etc. Les journaux AWS CloudTrail eux-mêmes sont placés dans votre compartiment AWS S3.

Deux autres services AWS offrent un certain nombre d'autres fonctionnalités de surveillance importantes. Premièrement, Amazon CloudWatch est un service de surveillance des ressources et applications AWS qui permet, entre autres, d'identifier 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 de données) et 30 autres services Amazon, utilisent Amazon CloudWatch pour stocker leurs journaux. Les développeurs peuvent utiliser l'API ouverte d'Amazon CloudWatch pour ajouter une fonctionnalité de surveillance des journaux aux applications et services personnalisés, leur permettant ainsi d'étendre la portée de l'analyse des événements dans un contexte de sécurité.

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 microservices. Lorsqu'une de vos ressources AWS VPC interagit avec le réseau, les journaux de flux VPC enregistrent des détails 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 envoyés. scie. Ceux qui sont expérimentés en matière de sécurité des réseaux locaux reconnaîtront que cela est analogue aux threads. NetFlow, qui peuvent être créés par des commutateurs, des routeurs et des pare-feu de niveau entreprise. Ces journaux sont importants à des fins de surveillance de la sécurité des informations car, contrairement aux événements sur les actions des utilisateurs et des applications, ils vous permettent également de ne pas manquer les interactions réseau dans l'environnement de cloud privé virtuel AWS.

En résumé, ces trois services AWS (AWS CloudTrail, Amazon CloudWatch et VPC Flow Logs) fournissent ensemble des informations assez puissantes sur l'utilisation de votre compte, le comportement des utilisateurs, la gestion de l'infrastructure, l'activité des applications et des services et l'activité du réseau. Par exemple, ils peuvent être utilisés pour détecter les anomalies suivantes :

Tentatives d'analyse du site, recherche de portes dérobées, recherche de vulnérabilités à travers des rafales d'« erreurs 404 ».
Attaques par injection (par exemple, injection SQL) par rafales de « 500 erreurs ».
Les outils d'attaque connus sont sqlmap, nikto, w3af, nmap, etc. grâce à l’analyse du champ User Agent.

Amazon Web Services a également développé d'autres services à des fins de cybersécurité qui permettent de résoudre de nombreux autres problèmes. Par exemple, AWS dispose d'un service intégré pour auditer les politiques et les configurations - AWS Config. Ce service fournit un audit continu de vos ressources AWS et de leurs configurations. Prenons un exemple simple : disons que vous souhaitez 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 ne peut le faire que le mardi. " À l'été 2016, le service AWS Config a été étendu pour automatiser la détection des violations des politiques développées. Les règles AWS Config sont essentiellement des demandes de configuration continues pour les services Amazon que vous utilisez, qui génèrent des événements si les politiques correspondantes ne sont pas respectées. Par exemple, au lieu d'exécuter périodiquement des requêtes AWS Config pour vérifier que tous les disques d'un serveur virtuel sont chiffrés, les règles AWS Config peuvent être utilisées pour vérifier en permanence les disques du serveur afin de garantir que cette condition est remplie. Et surtout, dans le cadre de cette publication, toute violation génère des événements qui peuvent être analysés par votre service de sécurité de l'information.

AWS a également son équivalent aux solutions traditionnelles de sécurité des informations 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'informations - AWS Macie
EDR (bien qu'il parle un peu étrangement des points de terminaison dans le cloud) - AWS Cloudwatch + solutions open source osquery ou GRR
Analyse Netflow - AWS Cloudwatch + AWS VPC Flow
Analyse 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écrirai pas en détail tous les services Amazon pouvant être utiles dans le cadre de la sécurité de l'information. L'essentiel est de comprendre que tous peuvent générer des événements que nous pouvons et devons analyser dans le contexte de la sécurité de l'information, en utilisant à cette fin à la fois les capacités intégrées d'Amazon lui-même et des solutions externes, par exemple SIEM, qui peuvent transmettez les événements de sécurité à votre centre de surveillance et analysez-les avec les événements provenant d'autres services cloud ou de l'infrastructure interne, du périmètre ou des appareils mobiles.

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

CloudTrail - Utilisation de l'API et actions utilisateur
Trusted Advisor - contrôle de sécurité par rapport aux meilleures pratiques
Config - inventaire et configuration des comptes et paramètres de service
Journaux de flux VPC - connexions aux interfaces virtuelles
IAM - service d'identification et d'authentification
Journaux d'accès ELB - Équilibreur de charge
Inspecteur - vulnérabilités des applications
S3 - stockage de fichiers
CloudWatch - Activité des applications
SNS est un service de notification.

Amazon, bien qu'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 de manière indépendante les journaux disponibles, à la recherche d'indicateurs pertinents de compromission. AWS Security Hub, récemment lancé par Amazon, vise à résoudre ce problème en devenant un SIEM cloud pour AWS. Mais jusqu’à présent, il n’en est qu’au début de son voyage 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 de la sécurité des informations dans IaaS basé sur Azure

Je ne veux pas me lancer dans un long débat pour savoir lequel des trois fournisseurs de cloud (Amazon, Microsoft ou Google) est le meilleur (d'autant plus que chacun d'eux a encore ses spécificités et est adapté pour résoudre ses propres problèmes) ; Concentrons-nous sur les capacités de surveillance de la sécurité de l'information qu'offrent ces acteurs. Il faut admettre qu'Amazon AWS a été l'un des premiers sur ce segment et a donc le plus avancé en termes de fonctions de sécurité de l'information (même si beaucoup admettent qu'elles sont difficiles à utiliser). Mais cela ne signifie pas que nous ignorerons les opportunités que Microsoft et Google nous offrent.

Les produits Microsoft se sont toujours distingués par leur « ouverture » et dans Azure la situation est similaire. Par exemple, si AWS et GCP partent toujours du concept « ce qui n'est pas autorisé est interdit », alors Azure a l'approche exactement opposée. Par exemple, lors de la création d'un réseau virtuel dans le cloud et d'une machine virtuelle, tous les ports et protocoles sont ouverts et autorisés par défaut. 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. Et cela vous impose également des exigences plus strictes en termes de surveillance de l’activité dans le cloud Azure.

AWS a une particularité liée au fait que lorsque vous surveillez vos ressources virtuelles, si elles sont situées dans des régions différentes, vous avez alors des difficultés à combiner tous les événements et leur analyse unifiée, pour éliminer lesquelles vous devez recourir à diverses astuces, telles que Créez votre propre code pour AWS Lambda qui transportera les événements entre les régions. Azure n'a pas ce problème : son mécanisme de journal d'activité suit toutes les activités dans l'ensemble de l'organisation sans restrictions. Il en va de même pour AWS Security Hub, qui a été récemment développé par Amazon pour regrouper de nombreuses fonctions de sécurité au sein d'un seul centre de sécurité, mais uniquement au sein de sa région, ce qui n'est cependant pas pertinent pour la Russie. Azure dispose 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, il peut fournir aux différentes équipes locales son propre ensemble de capacités de protection et, entre autres, les événements de sécurité qu'elles gèrent. AWS Security Hub est toujours en passe de devenir similaire à Azure Security Center. Mais cela vaut la peine d'ajouter une touche à la pommade - vous pouvez extraire d'Azure une grande partie de ce qui a été décrit précédemment dans AWS, mais cela est plus pratique uniquement pour Azure AD, Azure Monitor et Azure Security Center. Tous les autres mécanismes de sécurité 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. Le problème est en partie résolu par l'API, qui imprègne tous les services Microsoft Azure, mais cela nécessitera des efforts supplémentaires de votre part pour intégrer votre cloud à votre SOC et la présence de spécialistes qualifiés (en fait, comme avec tout autre SIEM qui fonctionne avec API cloud). Certains SIEM, qui seront discutés plus tard, prennent déjà en charge Azure et peuvent automatiser la tâche de surveillance, mais ils ont aussi leurs propres difficultés - tous ne peuvent pas collecter tous les journaux dont dispose 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 métriques, collectées en temps réel et décrivant les indicateurs clés de performance du cloud Azure, et les journaux, contenant des données organisées en enregistrements caractérisant certains aspects de l'activité 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 et auxquelles vous pouvez accéder via le portail Azure, la CLI, PowerShell ou l’API REST (et certaines uniquement via l’API Azure Monitor/Insight) :

Journaux d'activité - ce journal répond aux questions classiques de « qui », « quoi » et « quand » concernant toute opération d'écriture (PUT, POST, DELETE) sur les ressources cloud. Les événements liés à l'accès en lecture (GET) ne sont pas inclus dans ce journal, comme plusieurs autres.
Journaux de diagnostic : contiennent des données sur les opérations avec une ressource particulière incluse dans votre abonnement.
Rapports Azure AD : contiennent à la fois l’activité des utilisateurs et l’activité du système liées à 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.
Métriques : contient des données télémétriques sur les performances et l'état de santé de vos services et ressources cloud. Mesuré toutes les minutes et stocké. dans les 30 jours.
Journaux de flux de 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 de la surveillance des ressources au niveau du réseau.
Journaux de stockage - contiennent les événements liés à l'accès aux installations de stockage.

Pour la surveillance, vous pouvez utiliser des SIEM externes ou Azure Monitor intégré et ses extensions. Nous parlerons plus tard des systèmes de gestion des événements de sécurité de l’information, mais pour l’instant, voyons ce qu’Azure lui-même nous 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 de sécurité et d'audit de Log Analytics (la version gratuite prend en charge une quantité limitée de stockage d'événements pour une semaine seulement). Ce tableau de bord est divisé en 5 zones principales qui visualisent des statistiques récapitulatives de ce qui se passe dans l'environnement cloud que vous utilisez :

Domaines de sécurité - indicateurs quantitatifs clés liés à la sécurité de l'information - 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 de sécurité des informations actifs.
Détections - affiche les modèles d'attaques utilisées contre vous
Threat Intelligence - 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 la sécurité de vos informations.

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 logs du pare-feu cloud), etc. . Ces outils, enrichis de certaines règles de traitement des événements, permettent de visualiser différents aspects de l'activité des services cloud, dont la sécurité, et d'identifier certains écarts de fonctionnement. Mais, comme cela arrive souvent, toute fonctionnalité supplémentaire nécessite un abonnement payant correspondant, ce qui nécessitera de votre part des investissements financiers correspondants, que vous devez planifier à l'avance.

Azure dispose d'un certain nombre de fonctionnalités intégrées de surveillance des menaces 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 la présence d'une intégration avec les services Threat Intelligence de Microsoft), la détection de logiciels malveillants dans l'infrastructure cloud en recevant des alarmes de machines virtuelles hébergées dans le cloud, le mot de passe « deviner les attaques » sur les machines virtuelles, les vulnérabilités dans la configuration du système d'identification des utilisateurs, la connexion au système à partir d'anonymiseurs ou de nœuds infectés, les fuites de comptes, la connexion au système à partir d'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 sécurité et, par conséquent, les événements de sécurité qu'elle génère ne sont pas disponibles de la même manière pour tous les utilisateurs, mais nécessitent un certain abonnement qui inclut la fonctionnalité dont vous avez besoin, qui génère les événements appropriés pour la surveillance de la sécurité des informations. Par exemple, certaines des fonctions décrites dans le paragraphe précédent pour surveiller les anomalies dans les comptes sont disponibles uniquement dans la licence premium P2 du service 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 Azure AD, tous les événements ne seront pas disponibles pour l’analyse.

Sur le portail Azure, vous pouvez gérer à la fois les requêtes de recherche pour les journaux qui vous intéressent et configurer des tableaux de bord pour visualiser les indicateurs clés de sécurité des informations. De plus, vous pouvez y sélectionner des 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 du point de vue de la sécurité.

Si vous avez besoin non seulement de pouvoir travailler avec des journaux, mais également d'un centre de sécurité complet pour votre plate-forme cloud Azure, y compris la gestion des politiques de sécurité des informations, vous pouvez alors parler de la nécessité de travailler avec Azure Security Center, dont la plupart des fonctions utiles sont disponibles moyennant un peu d'argent, par exemple, la détection des menaces, la surveillance en dehors d'Azure, l'évaluation de la conformité, etc. (dans la version gratuite, vous avez uniquement accès à une évaluation de sécurité et à des recommandations pour éliminer 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 que vous offre Azure Monitor, puisque dans ce cas les données collectées dans toute votre usine cloud sont enrichies à l'aide de nombreuses 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), sur lesquels se superposent divers algorithmes sophistiqués d'apprentissage automatique et d'analyse comportementale, qui devraient à terme améliorer l'efficacité de la détection et de la réponse aux menaces. .

Azure possède également son propre SIEM - il est apparu début 2019. Il s'agit d'Azure Sentinel, qui s'appuie sur les données d'Azure Monitor et peut également s'intégrer. solutions de sécurité externes (par exemple, NGFW ou WAF), dont la liste ne cesse de s'allonger. De plus, grâce à l'intégration de l'API Microsoft Graph Security, vous avez la possibilité de connecter vos propres flux Threat Intelligence à 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 » apparu auprès des fournisseurs de cloud (les mêmes Splunk ou ELK, qui peuvent être hébergés dans le cloud, par exemple AWS, ne sont toujours pas développés par les fournisseurs de services cloud traditionnels). Azure Sentinel et Security Center pourraient s'appeler SOC pour le cloud Azure et pourraient s'y limiter (sous certaines réserves) si vous n'aviez plus d'infrastructure et que vous transfériez toutes vos ressources informatiques vers le cloud et ce serait le cloud Microsoft Azure.

Mais comme les capacités intégrées d'Azure (même si vous disposez d'un abonnement à Sentinel) ne suffisent souvent pas pour surveiller la sécurité des informations et intégrer ce processus avec d'autres sources d'événements de sécurité (à la fois cloud et internes), il existe un besoin d'exporter les données collectées vers des systèmes externes, auxquels peuvent inclure SIEM. Cela se fait à la fois à l'aide de l'API et à l'aide d'extensions spéciales, qui ne sont actuellement officiellement disponibles que pour les SIEM suivants - Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight et ELK. Jusqu'à récemment, il y avait davantage de SIEM de ce type, mais à partir du 1er juin 2019, Microsoft a cessé de prendre en charge l'outil d'intégration de journaux Azure (AzLog), qui à l'aube de l'existence d'Azure et en l'absence de standardisation normale du travail avec les journaux (Azure Monitor n'existait même pas encore) a facilité l'intégration d'un SIEM externe au cloud Microsoft. Aujourd’hui, la situation a changé et Microsoft recommande la plateforme Azure Event Hub comme principal outil d’intégration pour les autres SIEM. Beaucoup ont déjà implémenté une telle intégration, mais attention : ils peuvent ne pas capturer tous les journaux Azure, mais seulement certains (regardez dans la documentation de votre SIEM).

Pour conclure une brève excursion dans Azure, je voudrais 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é des informations dans Azure, vous devez les configurer très soigneusement et tester qu'elles fonctionnent comme indiqué dans la documentation et comme vous l'ont dit les consultants Microsoft (et ils peuvent avoir des points de vue différents sur la fonctionnalité des fonctions Azure). Si vous disposez des ressources financières, vous pouvez extraire de nombreuses informations utiles d'Azure en termes de surveillance de la sécurité des informations. Si vos ressources sont limitées, alors, comme dans le cas d'AWS, vous ne devrez compter que sur vos propres forces et sur les données brutes fournies par Azure Monitor. Et rappelez-vous que de nombreuses fonctions de surveillance coûtent de l'argent et qu'il est préférable de se familiariser à l'avance avec la politique tarifaire. Par exemple, vous pouvez stocker gratuitement 31 jours de données jusqu'à un maximum de 5 Go par client - le dépassement de ces valeurs vous obligera à débourser de l'argent supplémentaire (environ 2 $ et plus pour le stockage de chaque Go supplémentaire du client et 0,1 $ pour stockant 1 Go chaque mois supplémentaire). Travailler avec la télémétrie et les métriques des applications peut également nécessiter des fonds supplémentaires, ainsi que travailler avec des alertes et des notifications (une certaine limite est disponible gratuitement, ce qui peut ne pas suffire à vos besoins).

Exemple : Surveillance de la sécurité des informations dans IaaS basée sur Google Cloud Platform

Google Cloud Platform ressemble à un jeune par rapport à AWS et Azure, mais c'est en partie une bonne chose. Contrairement à AWS, qui a progressivement augmenté ses capacités, y compris celles de sécurité, rencontrant des problèmes de centralisation ; GCP, comme Azure, est bien mieux géré de manière centralisée, ce qui réduit les erreurs et le temps de mise en œuvre dans l'ensemble de l'entreprise. D'un point de vue sécurité, GCP se situe, curieusement, entre AWS et Azure. Il dispose également d’une seule inscription à un événement pour l’ensemble de l’organisation, mais elle est incomplète. Certaines fonctions sont encore 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 de journalisation des événements dans GCP est Stackdriver Logging (similaire à Azure Monitor), qui vous permet de collecter des événements sur l'ensemble de votre infrastructure cloud (ainsi que depuis AWS). Du point de vue de la sécurité dans GCP, chaque organisation, projet ou dossier dispose de quatre journaux :

Activité d'administration - contient tous les événements liés à l'accès administratif, par exemple, la création d'une machine virtuelle, la modification des droits d'accès, etc. Ce journal est toujours rédigé, quelle que soit votre envie, 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 par les utilisateurs du cloud (création, modification, lecture, etc.). Par défaut, ce log 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, tout n’est pas écrit dans ce magazine. Par exemple, les événements liés aux ressources accessibles publiquement à tous les utilisateurs ou accessibles sans se connecter à GCP n'y sont pas écrits.
Événement système - contient des événements système non liés aux utilisateurs ou aux actions d'un administrateur qui modifie la configuration des ressources cloud. Il est toujours rédigé et conservé pendant 400 jours.
Access Transparency est un exemple unique de journal qui capture 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 tâches. Ce journal est stocké pendant 400 jours et n'est pas disponible pour tous les clients GCP, mais uniquement si un certain nombre de conditions sont remplies (soit un support de niveau Gold ou Platinum, soit la présence de 4 rôles d'un certain type dans le cadre du support d'entreprise). Une fonction similaire est également disponible, par exemple, dans Office 365 - Lockbox.

Exemple de journal : Access Transparency

{
 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 ce qui a été évoqué précédemment sur Azure et AWS) - via l'interface Log Viewer, via l'API, via le SDK Google Cloud ou via la page Activité de votre projet pour laquelle vous sont intéressés par les événements. De la même manière, ils peuvent être exportés vers des solutions externes pour des analyses complémentaires. Cette dernière opération se fait en exportant les journaux vers le stockage BigQuery ou Cloud Pub/Sub.

En plus de Stackdriver Logging, la plateforme GCP propose également la fonctionnalité Stackdriver Monitoring, qui vous permet de surveiller les métriques clés (performances, MTBF, santé globale, etc.) des services et applications cloud. Les données traitées et visualisées peuvent faciliter la détection des problèmes dans votre infrastructure cloud, y compris dans le contexte de la sécurité. Mais il convient de noter que cette fonctionnalité ne sera pas très riche dans le contexte de la sécurité de l'information, puisqu'aujourd'hui GCP n'a pas d'analogue du même AWS GuardDuty et ne peut pas identifier les mauvais parmi tous les événements enregistrés (Google a développé Event Threat Detection, mais il est encore en développement en version bêta et il est trop tôt pour parler de son utilité). Stackdriver Monitoring pourrait être utilisé comme système de détection d'anomalies, qui feraient ensuite l'objet d'une enquête pour trouver les causes de leur apparition. Mais compte tenu du manque de personnel qualifié dans le domaine de la sécurité des informations GCP sur le marché, cette tâche semble actuellement difficile.

Il convient également de donner une liste de certains modules de sécurité des informations qui peuvent être utilisés dans votre cloud GCP et qui sont similaires à ce que propose AWS :

Cloud Security Command Center est un analogue d'AWS Security Hub et d'Azure Security Center.
Cloud DLP - Découverte et édition automatiques (par exemple masquage) des données hébergées dans le cloud à l'aide de plus de 90 politiques de classification prédéfinies.
Cloud Scanner est un scanner de vulnérabilités connues (XSS, injection Flash, bibliothèques non corrigées, etc.) dans App Engine, Compute Engine et Google Kubernetes.
Cloud IAM – Contrôlez l'accès à toutes les ressources GCP.
Cloud Identity : gérez les comptes d'utilisateurs, d'appareils et d'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.
VPC Service Control - Créez un périmètre sécurisé autour de vos ressources GCP pour les protéger des fuites.
Clé de sécurité Titan - protection contre le phishing.

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

J'ai fait un bref aperçu des capacités de surveillance intégrées dans les plates-formes cloud populaires. Mais avez-vous des spécialistes capables de travailler avec des journaux de fournisseurs IaaS « bruts » (tout le monde n’est pas prêt à acheter les fonctionnalités avancées d’AWS, d’Azure ou de Google) ? De plus, nombreux sont ceux qui connaissent l’adage « faire confiance, mais vérifier », 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 de cloud qui vous envoie des événements de sécurité des informations ? Dans quelle mesure se concentrent-ils sur la sécurité de l’information ?

Parfois, il vaut la peine d'envisager des solutions de surveillance de l'infrastructure cloud superposées qui peuvent compléter la sécurité cloud intégrée, et parfois ces solutions sont la seule option pour avoir un aperçu de la sécurité de vos données et applications hébergé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 de superposition est Cisco Stealthwatch Cloud, qui se concentre sur une seule tâche : surveiller les anomalies de sécurité des informations dans les environnements cloud, notamment Amazon AWS, Microsoft Azure et Google Cloud Platform, mais également les cloud privés.

Exemple : surveillance de la sécurité des informations à l'aide de 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 de sécurité des informations partagées ne fait qu’y contribuer. Exécution de logiciels dans le cloud avec des vulnérabilités inconnues (les vulnérabilités connues peuvent être combattues, par exemple, par AWS Inspector ou GCP Cloud Scanner), des mots de passe faibles, des configurations incorrectes, des initiés, etc. Et tout cela se reflète dans le comportement des ressources cloud, qui peuvent être surveillées par Cisco Stealthwatch Cloud, qui est un système de surveillance de la sécurité des informations et de détection des attaques. Clouds publics et privés.

L'une des fonctionnalités clés de Cisco Stealthwatch Cloud est la possibilité de modéliser des entités. Avec lui, vous pouvez créer un modèle logiciel (c'est-à-dire une simulation en temps quasi réel) de chacune de vos ressources cloud (peu importe qu'il s'agisse d'AWS, d'Azure, de GCP ou autre). Ceux-ci peuvent inclure des serveurs et des utilisateurs, ainsi que des types de ressources spécifiques à votre environnement cloud, tels que des groupes de sécurité et des groupes de mise à l'échelle automatique. Ces modèles utilisent comme entrée des flux de données structurés fournis par les services cloud. Par exemple, pour AWS, il s'agirait des journaux de flux VPC, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda et AWS IAM. La modélisation d'entité découvre automatiquement le rôle et le comportement de chacune de vos ressources (vous pouvez parler de profilage de toutes les activités cloud). Ces rôles incluent les appareils mobiles Android ou Apple, le serveur Citrix PVS, le serveur RDP, la passerelle de messagerie, le client VoIP, le serveur de terminaux, le contrôleur de domaine, etc. Il surveille ensuite en permanence leur comportement pour déterminer quand un comportement à risque ou menaçant la sécurité se produit. Vous pouvez identifier les tentatives de devinette de mot de passe, les attaques DDoS, les fuites de données, les accès à distance illégaux, les activités de 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 pour votre organisation (Corée du Sud) à un cluster Kubernetes via SSH :

Et voici à quoi ressemble la prétendue fuite d'informations de la base de données Postgress vers un pays avec lequel nous n'avons jamais rencontré d'interaction auparavant :

Enfin, voici à quoi ressemblent trop de tentatives SSH échouées en provenance de Chine et d’Indonésie à partir d’un périphérique distant externe :

Ou, supposons que l'instance de serveur dans le VPC ne doive, par politique, jamais être une destination de connexion à distance. Supposons en outre que cet ordinateur ait connu une connexion à distance en raison d'une modification erronée de la stratégie des règles de pare-feu. La fonctionnalité Entity Modeling détectera et signalera cette activité (« Accès à distance inhabituel ») en temps quasi réel et pointera vers l'appel d'API AWS CloudTrail, Azure Monitor ou GCP Stackdriver Logging spécifique (y compris le nom d'utilisateur, la date et l'heure, entre autres détails). ), ce qui a conduit à modifier la règle de l'UIT. Et puis ces informations peuvent être envoyées au SIEM pour analyse.

Des fonctionnalités similaires sont implémentées 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 révéler un problème jusqu'alors inconnu concernant vos collaborateurs, vos processus ou votre technologie. Par exemple, il permet de détecter entre autres des problèmes de sécurité tels que :

Quelqu’un a-t-il découvert une porte dérobée dans le logiciel que nous utilisons ?
Existe-t-il des logiciels ou des appareils tiers dans notre cloud ?
L'utilisateur autorisé abuse-t-il de ses privilèges ?
Y a-t-il eu une erreur de configuration autorisant l’accès à distance ou toute autre utilisation involontaire des ressources ?
Y a-t-il une fuite de données de nos serveurs ?
Quelqu’un a-t-il essayé de nous contacter depuis une situation géographique atypique ?
Notre cloud est-il infecté par un code malveillant ?

Un événement de sécurité des informations détecté peut être envoyé sous la forme d'un ticket correspondant à Slack, Cisco Spark, au système de gestion des incidents PagerDuty, et également envoyé à divers SIEM, dont Splunk ou ELK. Pour résumer, nous pouvons dire que si votre entreprise utilise une stratégie multi-cloud et n'est limitée à aucun fournisseur de cloud, les capacités de surveillance de la sécurité des informations décrites ci-dessus, alors l'utilisation de Cisco Stealthwatch Cloud est une bonne option pour obtenir un ensemble unifié de surveillance. capacités pour les principaux acteurs du cloud : Amazon, Microsoft et Google. La chose la plus intéressante est que si vous comparez les prix de Stealthwatch Cloud avec des licences avancées pour la surveillance de la sécurité des informations dans AWS, Azure ou GCP, il se peut que la solution Cisco soit encore moins chère que les capacités intégrées d'Amazon, Microsoft. et les solutions Google. C'est paradoxal, mais c'est vrai. Et plus vous utilisez de cloud et leurs capacités, plus l’avantage d’une solution consolidée sera évident.

De plus, Stealthwatch Cloud peut surveiller les cloud 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 les équipements réseau (même produits localement), les données AD ou les serveurs DNS, etc. Toutes ces données seront enrichies des informations sur les menaces collectées par Cisco Talos, le plus grand groupe non gouvernemental de chercheurs sur les menaces de cybersécurité au monde.

Cela vous permet de mettre en œuvre un système de surveillance unifié pour les cloud 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 plusieurs autres sont pris en charge par défaut).

Avec cela, nous terminerons la première partie de l'article, dans laquelle j'ai passé en revue les outils intégrés et externes de surveillance de la sécurité des informations des plateformes IaaS/PaaS, qui nous permettent de détecter et de répondre rapidement aux incidents survenant dans les environnements cloud qui notre entreprise a choisi. Dans la deuxième partie, nous continuerons le sujet et examinerons les options de surveillance des plateformes SaaS en utilisant l'exemple de Salesforce et Dropbox, et nous essaierons également de résumer et de tout rassembler en créant un système unifié de surveillance de la sécurité des informations pour différents fournisseurs de cloud.

Source: habr.com

Surveillance de la sécurité du cloud