Surveillance de la sécurité du cloud. 2e partie

Je vais donc continuer l'article sur la surveillance de la sécurité des fournisseurs de cloud. Dans la première partie, j'ai parlé de l'expérience de Cisco dans le travail avec des services cloud externes, ainsi que des observations Cisco que nous avons rencontrées lors de la création ou de l'audit des SOC de nos clients. Prenant dans la première partie, à titre d'exemple, les trois solutions les plus populaires d'Amazon, Microsoft et Google, qui sont des plates-formes IaaS / PaaS, il est aujourd'hui temps de parler de la surveillance des plates-formes SaaS - Dropbox, Salesforce.com, Slack et Apple Business Manager, et également sur les SIEM les mieux adaptés pour la surveillance des plateformes cloud aujourd'hui.

Exemple: surveillance IS dans SaaS Dropbox

Si, sur la base d'AWS, Azure ou GCP, vous pouvez créer un analogue presque complet de votre infrastructure d'entreprise, uniquement dans le cloud, c'est-à-dire des services cloud qui effectuent une tâche spécifique, par exemple, le stockage de fichiers, comme le fait Dropbox. Ce service a longtemps dépassé le stockage utilisateur habituel, offrant à ses utilisateurs en entreprise tout un ensemble de mécanismes de sécurité:

• identification et authentification des utilisateurs
• contrôle d'accès aux fichiers
• suppression de données à distance
• gestion des appareils de confiance
• intégration avec des solutions externes de sécurité de l'information (DLP, SSO, DRM, eDiscovery, SIEM, etc.)
• journalisation des événements de sécurité.

Les journaux Dropbox Business (qui ne sont pas disponibles dans la version Basic ou Pro) enregistrent les types d'événements de sécurité suivants:

• paramètres de protection par mot de passe
• tentatives réussies et infructueuses pour entrer dans le stockage de fichiers
• contrôler l'accès privilégié et les actions de l'administrateur
• actions sur les fichiers (ajouter, modifier, supprimer, transférer, charger, etc.)
• connexion au stockage de fichiers d'applications tierces
• appareils qui accèdent à Dropbox
• ajouter / supprimer des membres pour accéder aux groupes
• création de dossiers / fichiers accessibles en externe

Vous pouvez analyser les événements de sécurité dans Dropbox soit via la console d'administration Dropbox Business (mais ne vous attendez pas à de grandes révélations), ou en utilisant la solution de surveillance externe qui fonctionne avec l'API Dropbox Business. L'accès aux journaux n'est disponible dans aucun tarif Dropbox Business, mais uniquement à partir d'une licence avancée (n'oubliez pas Office365, qui ne démarre pas non plus l'accès aux journaux avec une licence commerciale de base). Comme pour AWS, il vaut la peine de demander si votre SIEM prend en charge Dropbox? Par exemple, Splunk dispose d'un module distinct pour travailler avec Dropbox, qui, grâce à l'API REST, vous permet de surveiller les événements de sécurité suivants:

• connexion
• activité sur l'ajout / la suppression / les demandes des utilisateurs
• activité des appareils se connectant à Dropbox
• activité de partage de fichiers au sein et en dehors de l'entreprise
• activité d'application
• etc.

Les autres SIEM n'ont pas de support intégré Dropbox - vous devrez écrire votre propre connecteur.

Exemple, surveillance SI en SaaS basée sur Slack et Salesforce.com

Nous comprenons qu'il existe aujourd'hui un grand nombre de plates-formes cloud qui peuvent être utilisées par les entreprises pour résoudre leurs problèmes et que nous aimerions surveiller du point de vue de leur sécurité. Nous ne plongerons pas dans chacune de ces plates-formes (et je n'ai pas défini une telle tâche, je voulais juste prêter attention aux spécificités des tâches de surveillance de la sécurité des informations de la plate-forme cloud), mais nous essaierons de terminer la discussion avec l'exemple de plates-formes spécifiques par deux solutions commerciales plus courantes - Slack et Salesforce.com .

Slack s'intègre à plus de 50 outils de sécurité (de la protection du contenu et de la confidentialité à la surveillance des certificats et au contrôle d'accès), mais du point de vue de la surveillance d'un large éventail d'événements de sécurité, Slack a peu d'intégrations prêtes à l'emploi - sur le site, cette liste est limitée au peu connu Symantec CloudSOC, Cisco CloudLock (plus d'informations ci-dessous) et Chronicle. C’est probablement tout. Mais ayant la certification ISO 27001, SOC2 / 3, Fed-RAMP et un certain nombre d'autres, Slack n'a pas pu s'empêcher de mettre en œuvre les fonctionnalités avancées de surveillance de son infrastructure, dont certaines sont disponibles pour les clients. En particulier, en utilisant l'API Audit Logs (disponible uniquement pour les utilisateurs de Slack Enterprise Grid et non disponible dans les plans Free, Standard, Plus), vous pouvez «extraire» un large éventail de données de votre infrastructure Slack et les charger dans votre SIEM en rapport avec l'activité des utilisateurs, mais pas avec surveillance du contenu (pour ces tâches, il est nécessaire d'utiliser des solutions DLP ou eDiscovery spécialisées). Dans le même temps, Slack n'a pas de mécanisme similaire à AWS GuardDuty - il envoie les événements «tels quels» et ne vous dit pas s'ils sont mauvais ou bons, vous seul pouvez le déterminer en écrivant vos propres règles de corrélation dans votre SIEM ou en utilisant des solutions externes qui ont un ensemble de modèles prédéfinis d'activité non autorisée dans Slack (comme, par exemple, dans Cisco CloudLock).

Chaque événement du journal de bord Slack comprend 4 éléments clés: une action, l'utilisateur qui l'a généré (acteur), l'entité associée à l'événement (espace de travail, application, utilisateur, canal, fichier) et l'emplacement (contexte) dans lequel cette action s'est produite (un espace de travail séparé ou toute l'organisation). Au total, Slack capture environ 70 actions différentes. Par exemple, voici à quoi ressemble un événement d'enregistrement d'utilisateur dans Slack:

{ "entries":[ { "id":"0123a45b-6c7d-8900-e12f-3456789gh0i1", "date_create":1521214343, "action":"user_login", "actor":{ "type":"user", "user":{ "id":"W123AB456", "name":"Charlie Parker", "email":"bird@slack.com" } }, "entity":{ "type":"user", "user":{ "id":"W123AB456", "name":"Charlie Parker", "email":"bird@slack.com" } }, "context":{ "location":{ "type":"enterprise", "id":"E1701NCCA", "name":"Birdland", "domain":"birdland" }, "ua":"Mozilla\/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.186 Safari\/537.36", "ip_address":"1.23.45.678" } } ] } 

Avec Salesforce, la situation est similaire - en utilisant l'API, vous pouvez accéder à toutes les activités des utilisateurs dans ce cloud CRM, et en particulier aux événements suivants:

• connexion
• déconnexion
• téléchargement de rapport
• Appels API
• URI (clics Web dans Salesforce Classic)
• Lightning (clics sur le Web dans l'application mobile Lightning Experience et Salesforce)
• Téléchargements de pages Visualforce
• Exécution Apex
• Et d'autres

De plus, vous pouvez surveiller la sécurité de votre instance Salesforce et utiliser les journaux des événements dans la console d'administration Salesforce. Vous avez 4 options:

• Surveillance de toutes les tentatives d'accès au portail SFDC. La page Historique de connexion affiche 20 000 entrées sur l'accès au portail au cours des 6 derniers mois (indiquant la méthode de connexion HTTP - GET, POST ou autres). Si vous avez besoin d'une histoire plus longue, le journal correspondant peut être téléchargé au format .csv ou .gzip.
• Suivi des travaux sur le terrain dans CRM. Grâce à la console d'administration, vous pouvez suivre l'historique de l'utilisation des champs CRM cloud standard et personnalisés au cours des 18 derniers mois, et grâce à l'API, accédez à un historique de deux ans des modifications des champs. Vous pouvez également archiver cette histoire jusqu'à 10 ans et, si nécessaire, y accéder.
• Suivi des changements administratifs. En utilisant la fonction Setup Audit Trail, vous pouvez surveiller plus de 100 actions de tous vos administrateurs (surtout s'il y en a plusieurs) au cours des 180 derniers jours.
• Surveillance des transactions À l'aide du service Transaction Security, vous pouvez capturer les événements Salesforce en temps réel et leur appliquer des notifications et des alarmes avec la logique de traitement appropriée.

Récemment, Salesforce a développé une solution spécialisée de surveillance de la sécurité pour sa plateforme - Salesforce Shield. Il comprend trois composants: la gestion du chiffrement de toutes les informations stockées, la surveillance de la sécurité et de l'utilisation des données et la gestion des politiques de sécurité. Dans le cas de la surveillance de la sécurité des informations, cette fonctionnalité dans Salesforce Shield s'apparente aux extensions Azure Monitor, qui non seulement vous montrent les événements, mais aussi, en raison de leur traitement et de leur visualisation, vous indiquent ce qu'il faut rechercher. Par exemple, pouvez-vous savoir à partir de quels appareils et plates-formes les utilisateurs accèdent le plus souvent à SFDC? Ou quand, le plus souvent, et d'où les utilisateurs entrent-ils leur copie de Salesforce (cela peut-il aider à identifier les points d'entrée atypiques)? Qui consulte les informations confidentielles? Qui télécharge le plus souvent des rapports sur son ordinateur? Les réponses à ces questions peuvent être obtenues à l'aide de 16 panneaux préinstallés, dont l'entrée est analysée par le sous-système Einstein Event Monitoring Analytics sous licence séparée (joli nom, n'est-ce pas). Avec son aide, vous pouvez également modéliser vos tableaux de bord, télécharger des données vers des systèmes de BI externes, etc.

Exemple: surveillance de la sécurité des informations sur iPhone et iPad

Oups ... Et d'où vient la surveillance de l'iPhone et du cloud, demandez-vous. Ici, tout est simple. Par exemple, aucun des SIEM au moment de la rédaction de cet article n'avait de connecteur vers la plate-forme Apple Business Manager (ou Apple School Manager, qui est mieux connue dans les universités américaines), ce qui vous permet de gérer les appareils d'entreprise Apple - iPhone, iPad, Mac. Pour cette tâche, vous pouvez utiliser n'importe laquelle des solutions MDM ou utiliser Apple Business Manager (si vous participez au programme d'inscription d'appareil Apple ou au programme d'achat en volume, qui ne sont pas valables en Russie). Les solutions MDM peuvent être installées localement et les intégrer à votre SIEM est fondamentalement facile, tout comme les MDM cloud (par exemple, Cisco Meraki), mais l'histoire avec Apple Business Manager a une couleur de cloud prononcée et dans le contexte de cet article est intéressante découvrez comment l'un des plus grands fabricants informatiques résout le problème de la possibilité de surveiller la sécurité de leurs solutions.

En général, c’est de ce point de vue que les décisions d’Apple en Russie ne sont pas très connues (bien qu’en Occident nous les affrontions dans les projets SOC). D'où l'opinion dominante selon laquelle Apple est une entreprise purement grand public qui ne s'est pas tournée vers les entreprises clientes en termes d'intégration dans leurs SOC. Ce n'est pas le cas en même temps. Le fait est qu'ayant un système de protection suffisamment puissant pour iOS et MacOS, Apple continue de rester une co-entreprise fermée et ne permet pas très activement à des tiers de s'informer sur la sécurité de ses produits. Bien que l'image change progressivement. Par exemple, Apple Business Manager vous permet de voir des informations sur l'activité sur les appareils Apple d'entreprise, qui sont combinées en trois blocs d'informations - l'événement, l'état et la date de début de l'événement (avec la date de fin, hélas, les problèmes). Les événements contrôlés (Apple School Manager en a un peu plus, mais ils sont liés aux étudiants / étudiants) comprennent:

• Envoyer de nouvelles connexions par e-mail
• Créer de nouvelles connexions
• Envoyer par e-mail de nouveaux codes de vérification
• Attribuer des rôles
• Supprimer des comptes
• Désactiver les comptes
• Comptes réactifs
• Attribuer des appareils
• Désaffecter des appareils
• Libérer les appareils
• Annuler l'attribution et la suppression du serveur
• Réaffectez et supprimez le serveur.

Pour être honnête, il n'y a pas beaucoup d'informations. Vous pouvez l'utiliser avec le panneau de configuration d'Apple Business Manager ou en le téléchargeant en tant que fichier .csv sur votre ordinateur pour une analyse plus approfondie. Je dois admettre que l'orientation principale de cette fonctionnalité dans Apple est toujours axée sur la recherche de problèmes dans le plan informatique, plutôt que sur les problèmes de sécurité - Apple n'a pas de collecte ou d'analyse automatisée des journaux. Vous pouvez obtenir beaucoup plus d'informations si vous intégrez Apple Business Manager à n'importe quelle solution MDM - vous pouvez alors obtenir des informations sur les utilisateurs actifs, les ID utilisateur et les appareils, y compris l'adresse Wi-Fi, les données sur les applications installées et leurs versions, présence de mises à jour désinstallées, opérateur de télécommunications, point d'accès personnel, fonction «Rechercher iPhone» activée, cryptage des données, jailbreak, certificats installés, disponibilité et paramètres d'un ITU personnel, paramètres PIN-when, télécommande phénomènes, etc. Cela suffit pour les tâches de surveillance du SI, mais cela nécessitera certains gestes pour intégrer vos appareils Apple d'entreprise dans votre SOC.

SIEM pour la surveillance du cloud

Il convient de noter qu'Amazon, comme de nombreux autres clouds publics, accordant une grande attention à sa sécurité, se concentre néanmoins principalement sur les mécanismes de détection et de prévention des menaces assez simples dans son infrastructure, ainsi que sur l'accès aux événements qui peuvent être analysés à l'aide de décisions externes. Microsoft est le plus proche de la création d'un système de surveillance et d'analyse des événements de sécurité dans le cloud, mais l'utilisation de sa solution nécessitera des investissements financiers supplémentaires. Si vous utilisez uniquement les clouds de cette entreprise, vous pouvez peut-être vous limiter à Azure Security Center avec des extensions. Mais si vous avez un environnement multi-cloud, alors il vaut la peine d'envisager l'utilisation de solutions indépendantes - SIEM, que vous utilisez peut-être déjà pour surveiller la sécurité des informations de votre infrastructure interne. Et ici, vous devez comprendre comment sélectionné ou choisi par vous SIEM prend en charge le cloud que vous utilisez (et ses différents services) comme source de données. Par exemple, Splunk, QRadar, ArcSight, ELK prennent en charge AWS et cela est directement indiqué dans la documentation de ces systèmes de surveillance, mais le même RuSIEM ou PT SIEM ne prend pas en charge.

Il convient de garder à l'esprit que différents SIEM peuvent prendre des données de différents services cloud de différentes manières. Prenons par exemple ELK et Amazon. De nombreux services et applications cloud peuvent transférer leurs événements vers le compartiment S3, et Logstash peut ensuite les récupérer sur demande. L'AWS CloudWatch mentionné précédemment peut également envoyer des données à S3 et les diffuser vers AWS Lambda (et Logstash les prend pour analyse) ou hébergées dans le cloud ElasticSearch. Bien sûr, il existe des applications qui peuvent envoyer directement des données à ELK, en contournant S3, Lambda ou CloudWatch. IBM QRadar collecte les données du même AWS GuardDuty via AWS CloudWatch, les journaux Amazon VPC Flow Logs en les publiant dans le panier S3 suivi de captures dans QRadar et les données d'AWS CloudTrail via le panier S3 ou via AWS CloudWatch. Selon les données dont vous avez besoin pour la surveillance, ces connaissances peuvent vous aider à ne pas commettre d'erreur fatale en choisissant SIEM, qui, après la mise en œuvre, ne pourra pas travailler avec les applications et services cloud dont vous avez besoin.

Malgré la popularité d'AWS ou d'Azure, un certain nombre de SIEM n'ont pas de connecteurs intégrés pour travailler avec les clouds Amazon et Microsoft, mais il est possible de créer le vôtre - soit indépendamment, soit avec l'aide du fabricant, comme, par exemple, dans le cas de PT SIEM avec connecteur personnalisé. Il convient de noter qu'AWS n'est pas le bon exemple pour avoir une idée du fonctionnement de SIEM avec les nuages. AWS est la plate-forme commerciale cloud la plus populaire au monde et, par conséquent, de nombreux fabricants, y compris dans le domaine des technologies de l'information, essaient d'intégrer leurs produits avec elle. Mais même dans ce cas, il faut néanmoins admettre qu'en général, SIEM aujourd'hui ne permet pas si souvent de surveiller des plateformes cloud. Par exemple, IBM QRadar fonctionne uniquement avec les services cloud suivants (à l'exclusion des services cloud IB tels que Cisco Umbrella, Cisco Meraki, Cisco Threat Grid, etc.):

• AWS GuardDuty et AWS CloudTrail (autres services AWS non encore pris en charge)
• Boîte
• Cloudera
• Ms azur
• Salesforce

La liste n'est pas très longue. La même base de modules Splunk pour travailler avec des nuages ​​est beaucoup plus large. En plus de ce qui précède pour IBM Qradar, la solution de Splunk prend également en charge:

• Office365
• ServiceNow
• Amazon kinésis
• Mou
• Jira
• Google Drive
• Google cloud
• Nagios
• Application G Suite
• Docker
• Kubernetes
• et autres

Veuillez noter que personne ne prend en charge GCP pour le moment.

En utilisant l'application Splunk pour l'extension AWS (l'idée sera similaire pour ArcSight ou QRadar), vous pouvez implémenter, par exemple, les scénarios de surveillance de cas d'utilisation suivants qui vous permettront de répondre à des questions importantes du point de vue de la sécurité des informations:

• Qui a ajouté la règle au groupe de sécurité qui protège nos serveurs d'applications?
• D'où vient le trafic bloqué vers le VPC?
• Quelle était l'activité d'un utilisateur particulier avant et après l'incident?
• M'avertir lorsqu'un groupe de sécurité autorise l'accès à partir de tous les ports
• Quels groupes de sécurité sont définis mais ne sont associés à aucune ressource?
• M'avertir lorsque la console sera accessible à partir d'une adresse IP externe
• M'avertir lorsqu'un agent utilisateur typique des attaques Web est commis
• Quand les ressources d'instance sont-elles dépassées de X%?

Certains SIEM spécialement conçus pour le réseau d'entreprise peuvent avoir des problèmes d'architecture avec les nuages. Au minimum, vous devrez ouvrir une série de règles pour tous vos systèmes cloud qui envoient des journaux à votre SIEM sur le périmètre ITU. Un autre problème, et plus grave, est le fait que le fait d'avoir des connecteurs pour travailler avec les nuages ​​ne signifie pas que SIEM est prêt à être utilisé dans ce rôle. Si nous prêtons attention aux composants du système de surveillance mentionnés au début de 6, il s'avère que le connecteur vers SIEM vous aide à résoudre deux tâches nécessaires, mais clairement insuffisantes - la collecte et le traitement des événements de sécurité des informations. Le stockage est fourni par SIEM lui-même, mais avec l'analyse, nous avons encore une grande question. Si un SIEM d'entreprise typique a un ratio de règles de corrélation vraiment utiles et fonctionnelles par rapport au nombre total d'entre elles, il est de 20 à 80, tandis que pour surveiller la sécurité des informations dans le cloud, ce ratio sera de l'ordre de 5 à 95, voire moins. Par conséquent, n'oubliez pas que la présence de SIEM travaillant avec des nuages ​​n'est pas tout ce qui est nécessaire pour surveiller leur réelle sécurité. Vous aurez besoin de beaucoup plus d'efforts (sans parler du personnel qualifié) pour écrire des règles de corrélation des événements pour votre cloud, pour vos clouds, ainsi que pour les clouds et l'environnement de l'entreprise (car vous voudrez probablement corréler les données de localisation de l'utilisateur connecté à la plateforme cloud avec fonctions de sécurité d’entreprise).

Si la situation avec la surveillance IaaS / PaaS est plus ou moins bonne - le nombre de sources, le volume de journaux créés et les types d'événements sont suffisants pour leur analyse, alors pour de nombreux SaaS, cela pose toujours des difficultés. Par conséquent, je veux prêter attention aux activités / événements suivants qui sont disponibles pour les joueurs SaaS les plus sérieux et qui doivent être analysés dans votre SIEM lors de la surveillance SaaS:

• Accès utilisateur et administrateur
  
  • Tentatives de connexion réussies et infructueuses
  • Heure et lieu d'entrée
  • Type et attributs du périphérique d'entrée
  • Tentatives de connexion infructueuses suivies d'un succès
  • Activité SSO
  • Activité AD
• Comportement des utilisateurs
  
  • Activité du fichier utilisateur (téléchargement, suppression, copie, impression, transfert, envoi)
  • «Partager» des fichiers avec des utilisateurs externes et internes
  • Création de liens ouverts / partagés
  • Activité à partir d'appareils mobiles non autorisés / non approuvés
  • Activité réseau
• Accès API tiers
  
  • Modifications des privilèges API
  • Activité liée au certificat OAuth
  • Activité associée au jeton OAuth.

Au minimum, une analyse de ces événements, que vous donnera par exemple Salesforce.com, Box ou Dropbox, vous permettra d'identifier un grand nombre d'incidents avec vos données cloud et vos utilisateurs.

Comment expliquer une telle lacune dans la capacité de surveiller les environnements d'entreprise et cloud avec SIEM? Faible prévalence des nuages? Nous comprenons que ce n'est pas le cas. La question est plutôt la maturité des clients qui sont déjà prêts pour le cloud, mais pas prêts à surveiller leur sécurité, dont j'ai parlé au tout début de l'article. Et sans cela, le nombre requis d'analyses de rentabilisation n'est pas recruté et les développeurs SIEM ne sont pas pressés de leur propre initiative de mettre en œuvre la prise en charge du cloud dans leurs produits; en particulier dans le contexte des changements réguliers des mécanismes de travail et du retour des événements de sécurité des fournisseurs de cloud (rappelons l'histoire d'AzLog avec Azure).

Que faire lorsque votre fournisseur ne dispose pas d'outils de surveillance

Mais que se passe-t-il si votre fournisseur de cloud possède des journaux, mais n'a pas ses propres outils pour les analyser et les surveiller, votre SIEM ne prend pas en charge le cloud que vous avez choisi et il n'y a aucun moyen d'y écrire un connecteur? Il existe une option qui vous permet d'utiliser des intermédiaires spécialisés qui, à l'aide de l'API cloud existante (elle devrait l'être), accèdent à votre fournisseur de cloud puis en extraient des journaux, leur appliquent divers outils analytiques, identifiant divers incidents et autres irrégularités, dont les données peut ensuite être remis à votre SIEM.

Des exemples de tels intermédiaires sont soit Cloud Access Security Broker, les solutions CASB (par exemple, Cisco CloudLock), ou certaines solutions d'authentification multifacteur, MFA avec des capacités de contrôle d'accès avancées (par exemple, Cisco Duo). Vrai, CASB ou MFA, résoudre un problème, en ajouter un autre - obtenir une autre console de gestion, qui doit être intégrée dans votre SOC. Mais résoudre ce problème est généralement plus simple. SIEM, souvent sans connecteur cloud, peut travailler avec des outils de sécurité de l'information, y compris CASB et MFA (après tout, c'est leur tâche principale). Dans ce cas, les API de l'aide CASB et MFA vous permettent d'envoyer des événements de sécurité collectés et analysés aux SIEM d'entreprise et de les intégrer dans vos SOC. Il en résulte un système à trois niveaux dans lequel SIEM, qui n'a pas à s'intégrer directement au cloud, utilise pour cela CASB / MFA (dans le cas ci-dessus avec Cisco Stealthwatch Cloud la même histoire).



Certes, le CASB n'est pas non plus une panacée. Tous les fournisseurs de cloud n'ont pas d'API dans leurs plates-formes qui permettent d'envoyer des données au SOC d'entreprise et au SIEM. C'est généralement cet attribut qui distingue les décisions d'entreprise. Parfois, même les solutions cloud populaires ne disposent pas de telles API, comme vous pouvez le voir au tout début, lorsque j'ai mentionné les solutions Bitrix, «My Office» ou SKB Kontur.

Exemple: surveillance de la sécurité avec Cisco CloudLock

Cisco CloudLock est une solution basée sur l'API qui s'intègre à un large éventail de plates-formes SaaS cloud populaires existantes, telles que G Suite, Salesforce, Office 365, Dropbox, Box, ServiceNow, Slack, Okta, etc., ainsi qu'avec IaaS / PaaS des plateformes comme Salesforce et AWS. Contrairement au proxy CASB, la solution basée sur l'API vous permet de travailler avec des données déjà chargées dans le cloud, d'analyser le trafic inter-cloud et de contrôler l'accès à partir d'appareils mobiles et non gérés d'entreprise et personnels. Dans le même temps, Cisco CloudLock, qui devient progressivement une partie intégrante de Cisco Umbrella , n'interfère pas avec le travail de l'utilisateur et se connecte à des clouds contrôlés en raison de son API, ce qui vous permet de surveiller les violations telles que:

• deviner le mot de passe
• se connecter depuis un lieu atypique (vol de compte)
  
  
• violation des règles de travail avec des informations confidentielles (stockage dans le cloud d'informations qui ne devraient pas y être)
  
  
• malware dans le cloud
• fuite de données
  
  
• violation des exigences réglementaires
• Accès à partir d'applications interdites ou expirées.
  
  

L'accès à ces incidents est possible à la fois à partir du service Cisco CloudLock lui-même et via SIEM, auquel CloudLock fournit les informations nécessaires via l'API existante. Actuellement, Cisco CloudLock peut s'intégrer à Splunk, QRadar et Arcsight.

SOC

Nous avons donc eu une idée du fonctionnement de la surveillance de la sécurité des informations dans les environnements cloud populaires en Russie. Vous comprenez maintenant quelles données et comment télécharger sur votre SIEM. Mais cela signifie-t-il que vous pouvez parler d'un système intégré de surveillance du cloud IS? Bien sûr que non. Il suffit de rappeler que selon le concept populaire, mais pas tout à fait juste, le SOC est une combinaison de personnes, de processus et de technologies. Nous avons parlé ci-dessus uniquement de la technologie. Le moment est venu de parler un peu des autres composants.

Pour commencer, le monde du cloud n'a pas de favori ni de leader clair. Les entreprises utilisent différents nuages ​​pour différentes tâches. Ci-dessus, j'ai donné un exemple de Cisco, qui utilise environ 700 fournisseurs de cloud dans le monde dans ses activités.Et ils sont tous différents, avec des approches différentes pour assurer la sécurité de l'information et son suivi. Afin de les intégrer tous dans notre centre de surveillance SI, il est nécessaire d'aller au-delà des moyens de chargement des données dans SIEM et de construire une stratégie de surveillance multi-cloud à part entière, qui comprend nécessairement les étapes suivantes:

1. , ( use case). use case Splunk. , . , , - “”. , ? use case . — , .
   
   
2. playbook' runbook', .
3. , use case, . , , . Amazon — ( , , ..), ( , , Amazon EC2 VPC) (, , ). , , .
4. , , , , .
5. , . , , Threat Intelligence, , , ( Cisco Stealthwatch Cloud), (, Amazon Web Services ), , - . .
6. , .
7. , , , - . , - osquery.
8. , (, WORM — Write Once, Read Many), (, AWS Key Management System) (, Amazon S3 Glacier).
9. , , Threat Intelligence, (, GCP Azure), . , . , , .
10. (SIEM), CASB NTA (, Cisco Stealthwatch Cloud).
    
    
11. Threat Hunting, , . , , — . .
12. .

Il convient de garder à l'esprit que certains de ces composants chevaucheront d'autres tâches de surveillance auxquelles votre organisation peut être confrontée - surveillance SLA, surveillance de la disponibilité, surveillance des performances des applications, surveillance de l'utilisation pour la facturation ultérieure, etc. Par conséquent, lors de la création du système de surveillance de la sécurité des informations de votre cloud, spécifiez d'abord ce qui a déjà été fait et ce qui est prévu d'être fait par vos collègues d'autres départements - vous pourrez peut-être utiliser les réalisations ou les outils déjà réalisés ou partager un certain nombre de tâches avec d'autres.

Il semble que je n'ai rien écrit de spécial et de nouveau. Si votre SOC est correctement conçu au départ, l'ajout de toute nouvelle entité contrôlée (que ce soit le cloud, l'ICS ou les appareils mobiles) ne devrait pas entraîner une forte altération des documents et processus développés précédemment. Lorsque nous concevons ou réalisons un audit SOC, nous essayons dans un premier temps de prendre en compte tous ces aspects dans notre travail.

Conclusion

En résumé, il convient de répéter à nouveau que la surveillance de la sécurité des informations dans les environnements cloud est un sujet relativement nouveau, même pour les «anciens» du marché du cloud. Par conséquent, des changements sont constamment en cours dans ce segment, et quelque chose qui n'était pas possible jusqu'à récemment apparaît dans le portefeuille du fournisseur de cloud. Il en va de même pour les fonctions de surveillance du SI. Quel que soit le fournisseur dont nous parlons, ils peuvent vous fournir l'une des nombreuses options de surveillance:

• — .
• SIEM . , “” /.
• API, “” . .
• .
• Accès par des intermédiaires qui collectent les données du cloud qui vous intéressent, les enrichissent d'informations supplémentaires et appliquent divers outils et algorithmes analytiques, après quoi ils transfèrent le résultat de l'analyse vers votre SIEM ou système d'analyse d'événements de sécurité de l'information.

Ces cinq options diffèrent par la complexité de leur collaboration, le prix et la rapidité de la surveillance et de la réponse. Je ne peux pas dire lequel choisir, car cela dépend beaucoup non seulement du cloud avec lequel vous travaillez, mais également de votre stratégie de surveillance. IB. Je ne peux que vous aider avec une liste de questions à vous poser et à votre fournisseur de cloud, avec qui vous décidez de «connecter votre vie»:

• Travaillez-vous / prévoyez-vous de travailler avec un cloud ou avec plusieurs?
• Quels mécanismes de protection votre fournisseur de cloud offre-t-il? Cela dépend de ce que vous pouvez surveiller ou non.
• ISO 27001, Fed-RAMP, SOC2/3? , - - .
• ? .
• ? ( )?
• / ? , , .
• ? ? ? threat hunting? - Threat Intelligence?
• ? / ?
• API ?
• SIEM ? /API ( )?
• “” SIEM? use case ?
• SIEM ? — SIEM?
• SIEM CASB?
• SIEM TI- ?

Voici une courte liste de questions, dont les réponses vous permettront de commencer à construire le processus de surveillance de la sécurité des informations dans les environnements cloud que vous ou votre entreprise avez décidé d'utiliser. Plus tôt vous vous intéressez à répondre à ces questions, moins il vous en coûtera pour construire un système de surveillance et moins d'incidents se produiront avec vos ressources données à des fournisseurs de cloud externes. Comme le montre l'expérience de Cisco dans la création ou l'audit de SOC, même les centres de surveillance des SI les plus performants qui traitent efficacement les incidents au sein du réseau d'entreprise n'améliorent pas toujours les capacités de surveillance du cloud dans leur architecture, ce qui nécessite sa restructuration. J'espère que les observations et recommandations décrites dans ces deux parties contribueront à garantir la cybersécurité.