La sécurisation d’Office 365 passe par de nombreuses thématiques à adresser, dont la nécessité d’être en capacité de tracer les actions, afin de détecter des comportements illicites ou de remonter à la cause d’un incident.

En France, de nombreuses entreprises ont cependant des difficultés pour consolider les logs et définir des cas d’usages de supervision. La maîtrise de la journalisation doit être au cœur de cette démarche.

La supervision des actions d’administration, une nécessité

Pour ce décryptage sur la journalisation, prenons le cas des administrateurs de la plateforme.

Comme pour les autres solutions SaaS (Google Cloud Platform, Salesforce, etc.), l’atteinte à l’intégrité ou à la confidentialité des données à la suite d’une erreur ou d’une action malveillante d’un administrateur de l’entreprise se retrouve parmi les risques majeurs identifiés par nos clients

Par définition, les administrateurs Office 365 possèdent des privilèges élevés :

• Configuration des différents services – ou workloads – et des API ;
• Gestion des permissions sur les OneDrive et les boîtes mails des utilisateurs ;
• Gestion du cycle de vie des espaces de collaboration.

Il est facile d’imaginer les conséquences désastreuses qui pourraient résulter d’une utilisation malveillante ou non maîtrisée de ces privilèges. En effet, des paramètres tels que le partage à l’externe de SharePoint Online, les autorisations des API ou la configuration de la messagerie pourraient introduire des vecteurs de fuite de données significatifs.

Les bonnes pratiques du SI on-premise (cycle de vie, principe de moindre privilège, segmentation des droits, authentification forte, just-in-time access etc.) doivent aussi être appliquées sur le Cloud. Le Cloud aussi doit être maîtrisé et contrôlé.

Cependant, l’implémentation des bonnes pratiques  bien que nécessaire, ne suffisent pas. En effet, elles ne permettent pas de s’assurer qu’un administrateur ne réalise pas des actions diminuant le niveau de sécurité ou des actions illicites. On peut donc naturellement se demander comment il serait possible d’auditer les actions effectuées et de lever des alertes le cas échéant.

Quels sont les moyens fournis par Microsoft ? Comment prévenir qu’une personne malveillante n’efface ses traces (ce qui rendrait une attaque plus difficile à détecter et à reconstituer) ?

Afin d’illustrer les différentes possibilités, nous allons suivre les quatres exemples ci-dessous :

Figure 1 – Exemple d’actes d’administration suspects

Quels journaux sont disponibles ?

Unified Audit Logs : journalisation unifiée des différents services

Pour des raisons historiques et techniques, Office 365 possède nativement plusieurs sources de journaux : Unified Audit Logs, Exchange Logs et Azure Logs. Ces sources sont complémentaires et doivent être analysées conjointement afin d’avoir une vision exhaustive des actions d’administration réalisées.

La source de logs la plus couramment citée et utilisée sont les « Unified Audit Logs ». Ces logs centralisent les traces des utilisateurs et celles des administrateurs, pour l’ensemble des services de la plateforme : SharePoint Online, Azure AD, Exchange Online, Teams, Power Platforms. Microsoft intègre progressivement les différentes sources et continue à rajouter des nouveaux logs.

Pour revenir à nos exemples concrets, les logs intéressants sont :

• Modification de la Politique de partage à l’externe de SharePoint Online : SharingPolicyChanged
• Attribution de droits à un OneDrive : SiteCollectionAdminAdded
• Attribution de droits à une boîte mail : AddMailboxPermission
• Modification d’un rôle d’administration : AddMembertoRole

Ces logs sont accessibles et exportables via les Centres de Conformité et de Sécurité, les API Office 365 Management et PowerShell (via la cmdlet Search-UnifiedAuditLog). Notons que la journalisation doit être activée via le Centre de Conformité ou via PowerShell afin de pouvoir enregistrer des logs et permettre la recherche.

Il est possible de configurer directement des alertes liées à l’occurrence de certains logs dans les Centres de Sécurité et de Conformité.

Exchange Logs : journalisation de l’infrastructure de messagerie

La deuxième source de logs intéressante sont les « Exchange Logs ». Ces logs fournissent des informations quant aux actions d’utilisation et d’administration réalisées sur le service Exchange Online ainsi que sur les boîtes aux lettres personnelles ou partagées. Deux typologies de journaux peuvent être distinguées :

• Administrator Audit Logs: Logs d’administration du service ou d’une boîte aux lettres (ex : modification des permissions d’un utilisateur, modification de la durée de rétention de conservation des journaux d’une boîte aux lettres etc.)
• Mailbox Audit Logs : Logs d’utilisation d’une boîte aux lettres par l’utilisateur principal, un utilisateur délégué ou un administrateur de service (ex : accès à la boîte aux lettres, envoi d’un mail à la place de l’utilisateur principal, déplacement d’un élément dans un dossier, suppression définitive, etc.)

Pour revenir à nos exemples concrets, les logs qui vont nous intéresser ici sont :

• Attribution de droits à une boîte aux lettres : AddMailboxPermission
• Accès à un dossier ou à une boîte aux lettres : FolderBind (non activé par défaut):
• Accès à un mail : MailItemAccessed (uniquement pour les utilisateurs ayant une licence E5)

Pour aller plus loin avec les Administrator Audit Logs

Les Administrator Audit Logs sont générés pour toute action d’administration Exchange pouvant être reliée à une cmdlet PowerShell autre que Get, Search ou Test. Ces logs sont liés aux Unified Logs et peuvent être exploités dans le Centre d’Administration Exchange, les Centres de Sécurité et de Conformité, les API Office 365 Management et PowerShell.

Pour aller plus loin avec les Mailbox Audit Logs

Les Mailbox Audit Logs sont la seule catégorie de logs à être configurable (périmètre et granularité). Ces logs permettent de tracer les actions réalisées par un owner (propriétaire), un delegate (utilisateur ayant des permissions) et d’un admin (accès via les outils eDiscovery).

Depuis Janvier 2019, la journalisation des Mailbox Audit Logs est activée par défaut pour l’ensemble des locataires Office 365. A date, si la journalisation est activée par défaut, l’ensemble des boîtes aux lettres sont auditées (même si le paramètre « -AuditDisabled » est à « True »). La seule façon de ne pas journaliser les actions d’une boîte mail est d’implémenter une règle de by-pass avec « Set-MailboxAuditBypassAssociation ».

Il faut toutefois noter que certaines actions ne sont pas auditées par défaut, comme par exemple l’accès d’un delegate ou d’un admin à une boite mail d’un utilisateur. Il est par conséquence primordial d’analyser les journaux à activer, lors de la configuration initiale du service.

Selon le niveau de licences et la configuration, ces logs peuvent être liés aux Unified Logs et être exploités dans le Centre d’Administration Exchange, les API Office 365 Management et PowerShell ou les Centres de Sécurité et de Conformité.

Azure Logs et Rapports : journalisation d’Azure Active Directory

La dernière source de logs, mais pas la moins importante, sont les « Azure AD logs ». Ces logs permettent de fournir des traces complètes pour la brique d’identité d’Office 365 ainsi que sur les actions d’administration associées. Plusieurs catégories de journaux et de rapports sont disponibles :

• Azure Audit Logs: Logs d’administration de la brique d’identification ou de modification des éléments (ex : attribution du rôle « SharePoint Administrator », création d’un utilisateur ou d’un groupe de sécurité, autorisation d’une API, configuration des utilisateurs invités, etc.)
• Azure Sign-in Logs: Logs de connexion à un service Office 365 (ou à des applications / ) avec des informations sur la chaîne de connexion (ex : protocole, adresse IP, terminal, etc.)
• Risky Sign-in: Rapports de connexion avec des indicateurs liés à des connexions suspectes.

Ces logs et rapports sont accessibles et exportables via le portal Azure, les API Graph ou Azure Management et PowerShell. Certains des logs directement liés à Office 365 se retrouvent aussi dans les Unified Audit Logs.

Pour revenir à nos exemples concrets, les logs intéressants sont :

• Modification d’un rôle d’administration : AddMembertoRole
• Ajout d’une application : CoreDirectory – ApplicationManagement – Add service principal / Add application
• Consentement à une application : Core Directory – ApplicationManagement / Add delegated permission grant / Consent to application (ConsentContext.IsAdminConsent)

Figure 2 – Récapitulatif des caractéristiques des logs d’Office 365

En résumé, les Unified Audit Logs apportent une vision consolidée des différents services d’Office 365, mais certaines informations peuvent être manquantes. Il sera nécessaire de s’assurer que les journaux requis soient bien présents, et ensuite d’approfondir une investigation dans les logs et les rapports d’Exchange ou Azure.

Quelle rétention pour les différents journaux d’Office 365 ?

Une fois les logs adéquats identifiés, se pose le défi de la rétention. Comment être sûr que les journaux sont bien conservés sans être altérés, pendant toute la durée requise par la politique de sécurité de l’entreprise et les différentes réglementations, comme la loi anti-terroriste ou le RGPD ?

Par construction, et contrairement aux solutions Exchange and SharePoint on-premise, tous les logs cités précédemment sont inaltérables – c’est-à-dire non modifiables ni supprimables par les administrateurs de l’entreprise. Par ailleurs, les durées de conservation définies par défaut ne peuvent être modifiées (à savoir 90 jours pour les logs Office 365 et 7 ou 30 jours pour les logs Azure avec des licences standards). Ceci à une exception près, un administrateur Exchange a la possibilité d’effacer les journaux des boîtes aux lettres, en modifiant la durée de rétention associée.

Si on reprend nos exemples, on pourrait tout à fait imaginer un administrateur malveillant se donnant des droits pour accéder à une boîte mail, puis regarder les mails et effacer les logs d’accès en fixant une durée de rétention nulle. Dans ce cas, ne serait conservée que l’élévation de privilège réalisée dans les Administrator Audit Logs.

Afin de se mettre en conformité avec les exigences de sécurité ou la réglementation, il pourra de plus être nécessaire de s’assurer que les journaux des différents services soient conservés plus de 7, 30 ou 90 jours.

Quelques étapes pour implémenter une journalisation pertinente au sein d’Office 365

1. Définition et activation des logs nécessaires: les Unified Audit Logs peuvent ne pas être suffisants (suivi des API Office 365 et Azure AD, journalisation des accès des administrateurs aux boîtes aux lettres, etc.)
2. Configuration d’un export automatique des journaux identifiés vers un stockage externe  (via PowerShell ou les API Management) ;
3. Suivi de l’état du tenant : implémentation d’un tableau de bord des paramètres du tenant configuration d’alertes liées à un changement de la configuration des journaux (via le Centre de Sécurité ou Conformité, les API Office 365 Management ou PowerShell), comme la désactivation des Unified logs ou à une modification de la rétention des logs d’une boîte aux lettres ;

Figure 3 – Bonnes pratiques pour la journalisation du tenant

Après avoir réalisés ces trois actions, l’entreprise aura les informations nécessaires pour auditer les actions d’utilisation et d’administration du tenant. Cependant, elles ne répondent pas encore au besoin plus large de supervision des administrateurs. Il pourra être utile de mettre en place des alertes (via le Centre de Sécurité ou de Conformité ou des outils tierces spécialisés).

1. (Pour aller plus loin) Mise en place d’une supervision basique : définition de scénarii de détection sécurité généralistes, identification des logs concernés, activation de l’alerte associée dans les Centres de Sécurité ou de Conformité ;
2. (Pour aller encore plus loin) Mise en place d’une supervision avancée : identification de scénarii liés à un contexte métier, implémentation, définition de la gouvernance associée, amélioration continue.

Quels outils utiliser pour analyser les journaux ? Quels scénarios de détection prioriser ? Quelle gouvernance mettre en place pour définir, implémenter et suivre des alertes ? Autant de questions qui doivent être traitées dans l’implémentation de la supervision de la plateforme de collaboration.

Il faudra également prendre en compte les changements réguliers apportés par Microsoft sur ces services, ainsi que sur la structure des logs et des API. D’autant plus que cohabitent les fonctionnalités en Preview et celles en General Availability.

Cet article Journalisation d’Office 365 : un cas concret avec les administrateurs est apparu en premier sur RiskInsight.

Améliorer la connaissances des menaces et des attaquants : plateformes CTI (-Cyber-Threat Intelligence)

La Cyber Threat Intelligence (CTI ou Threat Intel’) est une discipline regroupant la récolte, la consolidation et l’exploitation de toutes les informations sur les cyber-menaces. “Connais ton ennemi” indique Sun Tzu dans l’Art de la Guerre. Bien que cette citation fasse référence aux guerres « physique », le principe reste vrai… et l’est sans doute même davantage pour les luttes « cyber ».

En effet, aujourd’hui, un nombre important de dispositifs de sécurité s’appuient sur une connaissance des attaques : approche par signature des anti-virus et IDS, scénarios de détection ciblés… Même si la tendance s’inverse (notamment avec la détection d’anomalies), la grande majorité des produits de sécurité s’appuient toujours -et continueront de s’appuyer- sur des principes de Threat Intelligence.

Les besoins des entreprises étant de plus en plus spécifiques, et les attaquants de plus en plus spécialisés, les solutions de Threat Intel’ se démocratisent et proposent directement leurs services aux entreprises. En complément des offres commerciales, de plus en plus de plateformes d’échanges et de partenariats permettent de collaborer directement avec d’autres entreprises (de même secteur, zone géographique…).

Les services rendus par la Threat Intel’ sont multiples. D’une part la Threat Intel’ « stratégique » aide les SOC à mieux connaître le contexte et les menaces spécifiques à leur entreprise. Pour cela, les risques pesant sur chaque écosystème sont étudiés : aspects géographique, politique, idéologique, sectorielle… Ces informations permettent aux équipes sécurités de mieux connaître les menaces les concernant, et d’orienter leurs décisions pour définir leur stratégie « long terme » (solutions à déployer…).

D’autre part, la Threat Intel’ « tactique » donne des informations plus précises sur les méthodes des attaquants et permet notamment au SOC de faciliter la détection et d’adapter les mesures existantes : nouveaux scénarios de menaces à surveiller, ports à bloquer….

En complément de ces approches, la Threat Intel’ « technique » participe grandement à l’analyse des évènements de sécurité en fournissant, sur demande (depuis un SOAR notamment, voir partie suivante), des éléments permettant de juger de la véracité d’une alerte : appartenance d’une IP à un botnet, hash de fichier correspondant à un virus connu…

Les dispositifs de Threat Intelligence figurent donc parmi les outils les plus polyvalents du SOC, en permettant de tirer parti au mieux des dispositifs existant, en restant à jour et priorisant les menaces à détecter, et en orientant vers les prochains outils et mesures à déployer.

Exemples d’éditeurs Threat Intelligence :

Industrialiser et automatiser le processus de réaction : SOAR

Les SOAR (pour Security Orchestration, Automation & Response) sont issus de la combinaison de trois outils du SOC : les SIRP (Security Incident Response Plateform, plus de détails ici), les SOA (Security Orchestration & Automation, les solutions d’industrialisation et d’automatisation) et une partie des fonctionnalités de plateformes de Threat Intelligence. Pour résumer, ce sont des plateformes d’aide et d’automatisation de la réaction aux incidents de sécurité. Ces solutions se rapprochent d’outils de ticketing (ITSM) classiques, mais embarquent des fonctionnalités spécifiques aux problématiques de cybersécurité. Les SOAR offrent principalement trois capacités, chacune liée à l’un des trois types d’outils à leur origine.

Premièrement, comme les SIRP, ils permettent la définition de processus de réaction adaptés à chaque évènement de sécurité. Ceux-ci sont basés sur des playbooks prédéfinis par l’éditeur, publiés par la communauté de la solution, ou créés manuellement pour une meilleure adaptation aux besoins de l’entreprise. Cette tâche impose notamment aux équipes de réaction d’établir un processus clairement défini, les aidant ainsi à se poser les bonnes questions lors de la création de procédures de réaction, et à capitaliser et stocker ces connaissances.

Le gain des SOAR repose cependant davantage sur l’automatisation des différentes étapes suivant la détection. Lors de la phase d’analyse, l’outil va automatiquement enrichir l’évènement de sécurité en allant récupérer des informations de contexte sur le SI (identité dans l’AD, criticité d’une ressource…), et en interrogeant des services de Threat Intelligence externes (via des API) ou proposés avec la solution. Outre l’automatisation de l’enrichissement et des étapes d’analyse, les SOAR facilitent aussi le travail des analystes -investigation de postes, interrogation de VirusTotal… en un clic-  lorsque leur intervention est nécessaire.

Mais l’automatisation ne s’arrête pas là ! Bien que polémique, l’automatisation de la réaction (via la connexion aux équipements de sécurité, héritage du SOA) peut représenter un gain important pour les équipes de sécurité : blocage d’URL, génération de signature de fichier et propagation aux antivirus, blacklisting d’IP…

L’objectif des SOAR est donc clair : faciliter la tâche des équipes en charge de l’analyse et de la réaction, en les aidant à définir des processus et en automatisant les tâches au maximum. Même si les SOAR sont très adaptables, et peuvent donc aider à répondre à toute type d’attaque, ils brillent tout particulièrement pour automatiser le traitement des attaques courantes (ransomware, phishing…), très répétitives et mobilisant les efforts des équipes de réaction.

Une fois ces tâches automatisées, les équipes sécurité en charge de la réaction peuvent se concentrer sur les alertes plus complexes, où leurs connaissances apportent une véritable valeur ajoutée.

À conditions d’être prêt à fournir l’effort initial (formalisation des processus…), les gains en réactivité et en charge attendus sont donc conséquents. Les SOAR sont amenés à changer le mode de travail des équipes SOC, en particulier pour les analystes de premier niveau. Même si ces solutions sont encore peu déployées en France, ils devraient devenir l’un des indispensables du SOC dans les années qui viennent.

Exemples d’éditeurs SOAR :

Même si l’outillage n’est qu’une partie du SOC, chacune de ces solutions présente des avantages certains qui aideront les équipes de détection à rester d’actualité face à l’évolution du SI et des menaces.

Tous ces outils sont prometteurs, et certains arrivent à maturité. Cependant, il est important de garder à l’esprit que l’outillage actuel lève déjà de nombreuses alertes, difficiles à prendre en compte. Il est donc conseillé de finir de déployer et d’industrialiser l’existant (en utilisant un SOAR par exemple), avant de se tourner vers de nouvelles solutions.

Et, comme pour tout produit innovant, il faut savoir garder la tête froide : le déploiement d’une nouvelle solution doit être motivé par des besoins bien définis.

Cet article SOAR, UEBA, CASB, EDR et autres acronymes… suivez la saga de l’été pour comprendre et choisir parmi les nouveaux outils du SOC (3/3) est apparu en premier sur RiskInsight.

Compléter la détection avec de nouvelles approches

Raisonner identité pour détecter les comportements suspects : UEBA

Les technologies UEBA (pour User and Entity Behavioral Analysis), précédemment appelées UBA, sont parmi les derniers nés des outils venant compléter l’arsenal de détection des SOC. Comme leur nom l’indique, leur approche est claire : faire abstraction des considérations techniques des solutions actuelles (SIEM…) en analysant le comportement des utilisateurs et des entités (comprendre terminaux, applications, réseaux, serveurs, objets connectés…).

Le principe est simple, mais son implémentation l’est beaucoup moins. En effet, pour être efficace, les dispositifs UEBA ont besoin de sources nombreuses, avec des formats de données variés. Les sources traditionnelles, telles que le SIEM et le(s) gestionnaire(s) de logs, mais aussi directement certaines ressources (AD, proxy, BDD…) sont souvent utilisées.

Mais afin de parfaire la détection, les solutions UEBA interrogent aussi de nouvelles sources : informations sur les utilisateurs (applications RH, gestion des badges…), échanges entre employés (chats, échanges vidéo, emails…), ou toute autre contribution pertinente (applications métiers à surveiller…).

À partir de toutes ces informations, les solutions UEBA analysent les comportements des utilisateurs (et entités) pour identifier de potentielles menaces. Elles peuvent utiliser des règles statiques, sous forme de signatures à détecter (souvent déjà implémentées dans les solutions SIEM) : connexions simultanées depuis deux endroits différents ou hors des plages horaires classiques…

Mais la véritable force des UEBA réside dans l’utilisation d’algorithmes de Machine Learning pour détecter des modifications du comportement d’utilisateurs ou services : opération métier suspecte, accès à des applications critiques jamais utilisées auparavant lors de congés, transferts de données inhabituels…

Si, à l’origine, les UEBA étaient pensés pour lutter contre les fraudes, leur rôle s’est cependant peu à peu élargi pour couvrir certains périmètres posant habituellement des problèmes aux SIEM : vols de données, compromission -ou prêt- de comptes applicatifs, infection de terminaux ou serveurs, abus de privilèges…

Ainsi, les UEBA se positionnent aujourd’hui en compléments des SIEM, en complétant l’approche « technique » par une vision « utilisateur », et en ajoutant une couche d’intelligence supplémentaire dans l’analyse.

Au vu du marché, il probable que les solutions UEBA cessent d’exister en tant que telles dans les années à venir et s’intègrent à des solutions existantes (SIEM, EDR…), passant de produits à fonctionnalités.

Exemples d’éditeurs UEBA :

Piéger les attaquants : Deceptive Security

La Deceptive Security peut être considérée comme un passage au niveau supérieur des Honey Pots. Des leurres, sous formes de données, d’agents ou d’environnements dédiés, sont répartis à grande échelle dans tout ou partie du SI.

Selon les solutions et les besoins, les outils de Deceptive Security peuvent poursuivre deux buts. En détournant l’attention des attaquants des vraies ressources et en les dirigeants vers de fausses pistes, ils peuvent agir comme moyens de protection.

Mais surtout, la surveillance de ces leurres peut permettre de détecter des menaces se propageant au sein du SI. En effet, ces leurres n’ayant d’autres utilités que d’appâter de potentiels attaquants ou de divulguer de fausses informations, toute communication avec l’un d’entre eux est nécessairement suspecte.

Ce type de solution ne remplace par les solutions existantes, mais répond à des cas d’usage bien spécifiques, pour lesquels les dispositifs de détection classiques sont peu efficaces : les APT, spécialement conçus pour les contourner, et plus largement les mouvements horizontaux au sein du SI.

Pour plus de détails sur les solutions de Deceptive Security, vous pouvez consulter notre article dédié au sujet ici !

Exemples d’éditeurs Deceptive Security :

Détecter les signaux faibles sur le réseau : sondes « Machine Learning »

Les sondes de détection classiques (IDPS), basées sur l’analyse de trafic et la comparaison avec des signatures d’attaques connues, sont peu efficaces lorsqu’il s’agit de détecter des menaces subtiles (APT…) ou inconnues (0 days…). Pour pallier ce problème, les IDPS nouvelles générations intègrent des capacités de Machine Learning (parfois présenté comme de l’Intelligence Artificielle) dans leur arsenal de détection.

Selon les solutions, deux types d’usage du Machine Learning sont à distinguer. D’une part, l’utilisation de ces algorithmes en mode supervisé, pour apprendre à reconnaître le comportement de certaines attaques ou phases d’attaque lors de leur phase active : commande & contrôle, scans, mouvements latéraux, fuite de données…

Une fois la sonde déployée, l’ajustement des seuils de détection au contexte client est lui aussi basé sur des algorithmes de Machine Learning (comme le font déjà bon nombre de solutions IDPS classiques).

Ce mode de fonctionnement permet un déploiement rapide (solution utilisable out-of-the-box et phase d’apprentissage écourtée), et une meilleure capacité à détecter les attaques caractérisées précédemment. En contrepartie, la détection des attaques non couvertes par l’apprentissage ou complètement inconnues restent difficiles.

A l’opposé de cette approche, des solutions misent sur l’apprentissage non-supervisé pour détecter les attaques. Pour cela, lors du déploiement, les sondes sont positionnées sur le réseau pour observer le trafic, et apprendre à reconnaître le trafic légitime.

Une fois la phase d’apprentissage terminée, les sondes sont capables de détecter des anomalies, et donc de lever des alertes en cas de comportement suspect. Cette approche permet de détecter des attaques inconnues, mais nécessitent généralement une phase d’apprentissage plus longue pour être efficace et atteindre un taux de fausses alertes acceptables.

Dans les deux cas, les sondes « Machine Learning » permettent de compléter l’arsenal des SOC, aujourd’hui majoritairement destiné à détecter des attaques connues, par des capacités de détection capables de distinguer des attaques complexes, méconnues, ou créés pour contourner les dispositifs de sécurité classiques.

Nos premiers retours terrains montrent que ces technologies peuvent en effet détecter des menaces passant au travers des dispositifs de sécurité classiques. Les faux positifs sont cependant très fréquents (la courbe d’apprentissage variant grandement selon les solutions et les contextes), et il reste difficile de juger de l’exhaustivité des menaces détectées.

Les sondes « Machine Learning » ont donc un avenir certain parmi les outils du SOC, même si un gain en maturité reste à réaliser pour qu’elles atteignent leur plein potentiel.

Exemples d’éditeurs de sondes ML :

Pour retrouver notre troisième et dernier article sur cette saga, c’est par ici.

Cet article SOAR, UEBA, CASB, EDR et autres acronymes… suivez la saga de l’été pour comprendre et choisir parmi les nouveaux outils du SOC (2/3) est apparu en premier sur RiskInsight.

Dans un contexte où l’on assiste à une véritable pénurie de compétences cybersécurités, ces problématiques ne peuvent être adressées uniquement par le renforcement des effectifs du SOC. L’utilisation de nouveaux outils, basée sur 4 axes stratégiques, est indispensable pour permettre au SOC d’avoir de l’avance sur les nouvelles menaces.

Ainsi, l’extension de la détection à de nouveaux périmètres permet de protéger de nouvelles parties du SI, aujourd’hui insuffisamment sécurisées (Cloud) ; et des ressources de plus en plus prises pour cibles (attaques ransomware sur les terminaux, attaques ciblées utilisant les AD…).

Dans le même temps, l’adoption de nouvelles approches devient une nécessité pour détecter les attaques ciblées (0days, « low signal » …), dont la subtilité croissante met à mal les dispositifs de sécurité existants.

En complément de nouveaux outils de détection, une connaissance avancée des menaces et des attaquants peut venir améliorer les capacités de détection existantes, aider à la priorisation des incidents à traiter et faire gagner en efficacité lors de la réaction.

Mais les équipes SOC éprouvent déjà des difficultés à traiter les évènements générés par les outils existants. Il est donc primordial d’industrialiser et d’automatiser les interactions entre équipes et systèmes, et, lorsque c’est possible, les étapes d’analyse et de réaction !

Pendant l’été, suivez les épisodes de notre saga pour découvrir les moyens d’outiller ces 4 axes stratégiques !

Étendre la détection à de nouveaux périmètres

Une solution unique pour sécuriser tous les Cloud : CASB

Les CASB (pour Cloud Access Security Broker) adressent un périmètre du SI aujourd’hui mal desservi par les mesures de sécurité classiques : le Cloud. Par sa nature, sa protection nécessite en effet des adaptations par rapport aux SI classiques : pas ou peu de maîtrise des ressources (infrastructures, OS ou applications, selon le type d’offre), localisation à l’extérieur du SI…

Les CASB visent à centraliser et à faire appliquer les politiques de sécurité aux services situés dans le Cloud. Certains fournisseurs Cloud proposent leurs propres services de sécurisation CASB (par exemple Microsoft avec Microsoft Cloud App Security) ; mais, selon les besoins, il est parfois préférable d’utiliser des solutions tierces, même si l’ajout d’un acteur supplémentaire a un coût. En effet, le CASB visant à s’assurer du niveau de sécurité du Cloud, confier ce rôle aux fournisseurs du service à surveiller peut être contre-productif, et l’utilisation d’un « tiers de confiance » est à privilégier.

Dans tous les cas, les CASB sont des solutions variées, pouvant regrouper de très nombreux services, leurs maturités variant selon les éditeurs de solution, les fournisseurs Cloud et le type d’hébergement (IaaS, PaaS, SaaS…).

D’une part, les solutions CASB permettent d’adresser les enjeux spécifiques aux Cloud, en palliant le manque de visibilité sur ces environnements (détection du Shadow IT, statistiques d’utilisation…), et en s’assurant de leur conformité (vérification des configurations…).

D’autre part, elles participent au déploiement des mesures de sécurités classiques sur ce périmètre. En particulier, les enjeux de sécurité de la donnée (DLP et mesures de chiffrement, particulièrement appréciées par les régulateurs) et de détection des menaces (centralisation des logs Cloud pour transmission au SIEM, détection de comportements anormaux -UEBA !, voir partie dédiée-…) font parties des capacités classiques proposées par les éditeurs. En complément, certaines problématiques d’IAM peuvent aussi être adressées par ces solutions (SSO, contextualisation des accès…).

Il existe deux principaux modes de déploiement pour la mise en place de ces fonctionnalités, chacun possédant ses avantages (et inconvénients). Les solutions types proxy sont placées en coupure entre les utilisateurs et le service Cloud.

A l’opposé, dans le cas des solutions de type API, parfois appelées out-of-band, les consommateurs du service Cloud communiquent directement avec celui-ci. Pour chaque accès, le service interroge les API du CASB afin de d’évaluer les risques, et d’autoriser ou non la consommation du service. Les solutions API s’appuient cependant sur les interfaces proposées par le fournisseur Cloud pour fonctionner, ce qui peut limiter certaines possibilités.

Aujourd’hui jeunes et peu matures, les CASB restent peu déployés. Au vu de la démocratisation (déjà bien avancée) des services Cloud, les CASB ont cependant un bel avenir devant eux, et permettront aux équipes SOC d’étendre leur surveillance sur ce périmètre, voué à représenter une partie importante du SI.

Exemples d’éditeurs CASB :

Détection et réaction, le nouveau couteau suisse pour sécuriser les terminaux : EDR (Endpoint Detection and Response)

Les solutions EDR (pour Endpoint Detection and Response) viennent compléter les capacités de détection et de réaction des SOC sur les terminaux (PC, serveurs…).

Comme leur nom l’indique, les EDR participent à la détection d’attaques. Ceux-ci viennent en effet combler les faiblesses des anti-virus (et autres HIPS) s’appuyant sur des signatures d’attaques précises, et donc inadaptées pour détecter certains types d’attaques, notamment les attaques avancées (APT). Les EDR se basent donc sur d’autres méthodes de détection, les éditeurs proposant généralement une combinaison de techniques habituellement utilisées sur d’autres périmètres.

Parmi ces techniques, la détection d’exploitation de vulnérabilités connues ou de patterns d’attaque (ouverture de port suspects vers des adresses douteuses…), l’analyse de fichiers par une sandbox (émulation locale, soumission dans le Cloud…), et des approches comportementales basées sur du Machine Learning (en particulier les solutions UEBA, cf. partie dédiée) sont utilisées par bon nombre de solutions. Selon les besoins du SOC, les alertes remontées peuvent être intégrées comme sources du SIEM, ou disponibles directement depuis la console de management de la solution.

En plus de ces capacités de détection avancées, les solutions EDR apportent aussi un important gain en visibilité sur les terminaux : liste des processus et services lancés, liste de fichiers dans certains répertoires systèmes… et toute autre information permettant de faciliter l’investigation en cas d’alerte. Certaines solutions ne se limitent pas à récupérer l’état du terminal au moment de la demande, mais permettent aussi de récupérer son historique : génération de logs, récupération de fichiers supprimés…

Mais les fonctionnalités des EDR ne s’arrêtent pas aux étapes de détection et d’analyse. En effet, ces solutions permettent d’effectuer des actions de remédiation à distance, dont la complexité dépend des éditeurs : suppression ou mise en quarantaine de fichiers, arrêt de processus, mise en quarantaine réseau de postes, modification de clés de registre…

Les EDR sont donc des solutions très complètes intervenant à toutes les étapes du processus : de la détection, à l’analyse, jusqu’à la réaction. Elles n’ont cependant pas vocation à remplacer les solutions anti-virus, toujours plus efficaces pour bloquer les attaques connues ; même si l’on observe de plus en plus d’éditeurs proposant des solutions unissant les deux types de fonctionnalités.

Pour plus de détails sur les solutions EDR, vous pouvez consulter notre article dédié au sujet ici !

Exemples d’éditeurs EDR :

Protection des clés du royaume : supervision Active Directory

Les annuaires comptent parmi les composants les plus critiques du SI. En effet, ceux-ci fournissent les fonctionnalités d’authentification et d’habilitation pour la quasi-totalité des ressources du SI, aussi bien techniques que métiers, y compris les plus critiques. Il n’est donc pas étonnant que la compromission d’AD figure parmi les méthodes d’attaque les plus utilisées, car ouvrant de nombreuses portes aux attaquants.

Malgré cette criticité, et bien que les architectures AD soient bien connues et aient peu évolué depuis plusieurs années, leur sécurisation reste perfectible. Cela est en particulier dû à leur mode de fonctionnement spécifique (OU, domaines, arbres, forêts, utilisateurs…), rendant les moyens de protection et de surveillance classiques peu efficaces, en particulier lorsque toute vulnérabilité peut représenter un risque majeur pour le reste du SI.

Les solutions de surveillance AD visent à pallier ce problème en supervisant (en temps réel, ou lors d’audit) les spécificités des annuaires (configuration, état des comptes…), et en y détectant des vulnérabilités susceptibles de causer leur compromission. Pour cela, les solutions de supervision AD possèdent une connaissance très pointue du fonctionnement des AD, et tout particulièrement des enjeux de sécurité liés.

Lorsqu’une vulnérabilité est détectée, une alerte est remontée (par le biais du SIEM, ou directement dans la solution) et des conseils de remédiation peuvent être fournis afin de faciliter le travail des équipes en charge de la correction.

Les outils de supervision AD permettent par ailleurs au SOC de détecter toute modification de configuration (légitime, accidentelle ou malveillante) et de s’assurer en continu du niveau de sécurité de ces composants critiques, compliquant d’autant la tâche de nombreux attaquants.

En complément du renforcement direct du niveau de sécurité de l’AD, ces solutions peuvent aussi être utilisés pour s’assurer de la compliance vis-à-vis de normes ou de contraintes réglementaires (LPM, PCI DSS…).

Ces solutions restent assez peu répandues aujourd’hui, et leur utilisation généralement limitée à des audits ponctuels. Cependant, au vu des importants gains de sécurité associés (détection et conseils de remédiation) et de leur simplicité d’utilisation, ces solutions sont prometteuses et devraient réussir à se faire une place parmi les outils du SOC.

Exemples d’éditeurs de supervision AD :

Pour retrouver notre second article de la saga, c’est par ici.

Cet article SOAR, UEBA, CASB, EDR et autres acronymes… suivez la saga de l’été pour comprendre et choisir parmi les nouveaux outils du SOC (1/3) est apparu en premier sur RiskInsight.

Cependant, de nouvelles réglementations le soumettent à des contraintes de plus en plus fortes telles que le GDPR (General Data Protection Regulation) visant toutes les données à caractère personnel, ou les différentes lois sur la protection des infrastructures critiques des pays. La France est particulièrement en avance aujourd’hui avec la LPM (Loi de Programmation Militaire [lien EN / lien FR ]) qui s’applique aux organisations les plus critiques pour le fonctionnement de l’Etat.

Comment mettre en place un système de détection de plus en plus fin, tout en s’inscrivant dans un cadre réglementaire toujours plus strict ?

Une standardisation des SOC à l’échelle européenne (et mondiale)

Au milieu des années 2000, la mise en place des premiers SOC consistait, dans la plupart des cas, à déployer un collecteur de logs par plaque géographique et à mettre en place une gestion des alertes en central. Cependant, des évolutions réglementaires récentes peuvent imposer des changements d’architecture. En particulier en France dans le cadre de la LPM, l’obligation de mise en place d’un « système de corrélation et d’analyses de journaux » (autrement dit : SOC outillé par un SIEM) s’est accompagnée d’une structuration règlementaire stricte décrite dans le référentiel d’exigences PDIS (Prestataires de Détection des Incidents de Sécurité [lien FR]).

Trois points sont traités en particulier pour la standardisation :

• D’abord, l’organisation de la surveillance : il existe dorénavant une obligation de détection de certains types d’attaques communes et d’implémentation de contrôles faisant suite à des recommandations réalisées via des audits qualifiés suivant le référentiel PASSI (Prestataires d’Audit de la Sécurité de Systèmes d’information [lien EN / lien FR]). L’entreprise doit également mettre en place une cellule de veille permettant de notifier l’ANSSI en cas de compromission du SI d’importance vitale.
• Le second point concerne la sécurisation des actifs du SOC : de nouvelles mesures de sécurisation décrites dans le référentiel de qualification PDIS imposent notamment un durcissement des postes des opérateurs et des administrateurs du SOC (authentification à deux facteurs, limitations des accès à internet…). Ces mesures de sécurité seront vérifiées par l’ANSSI via des audits ou rétroactivement suite à la notification de compromission du SI.
• L’architecture enfin, avec une complexification de celle-ci : un découpage en zones de confiance cloisonnées ainsi qu’un élargissement du périmètre du réseau surveillé sont imposés (outre les « classiques » équipements de sécurité, les serveurs métiers et les terminaux mobiles doivent maintenant aussi être surveillés). Les informations liées à un incident de sécurité (événements, rapports d’analyses et les notifications associées) doivent également être conservées pendant toute la durée de la prestation.

Sécurisation forte et respect des données personnelles : 2 enjeux incompatibles ?

Afin de pouvoir assurer des analyses a posteriori et notamment d’être capable de déterminer l’origine des cyberattaques, de nombreuses données personnelles et critiques doivent être collectées, conservées et exploitées. Pourtant, ces données sont soumises au GDPR qui tend à l’inverse à limiter leur collecte et leurs usages.

La récente amende de l’AGPD (l’autorité de protection des données à caractère personnel en Espagne) à Google met en lumière des problématiques que pourrait rencontrer le SOC concernant le traitement des données à caractère personnel :

• Le droit à la manipulation des données personnelles et le droit à l’oubli des utilisateurs a été la première cause de condamnation de Google. En effet, le GDPR compte offrir aux citoyens européens la possibilité d’accéder, de modifier ou de supprimer leurs données où qu’elles soient stockées (y compris dans le Cloud). Cela signifie, en pratique, que l’entreprise doit connaître exactement la teneur des données collectées par son SOC pour pouvoir en informer les clients, ses employés… Cela signifie également que ceux-ci devraient pouvoir exiger leur suppression à tout moment. Cependant, le GDPR semble indiquer qu’il est possible de conserver certaines données si celles-ci sont nécessaires à la protection des entreprises. Cette définition est appelée à être discutée dans les années à venir.
• L’obligation de transparence quant à l’exploitation des données est la seconde problématique soulevée par l’AGPD. Cependant, dans le cadre de PDIS, l’obligation de monitorer une grande variété d’équipements va engendrer la récupération d’un grand nombre de données de natures différentes. Un travail sur le contenu des logs collectés va donc être nécessaire afin de s’assurer que seules les données nécessaires à l’activité de surveillance sécurité sont récupérées.
• Enfin, le GDPR impose la justification de la conservation de la donnée. Or PDIS impose de conserver les données sur au moins six mois afin de pouvoir effectuer des analyses sur du long terme ou rétroactivement créant ainsi un flou législatif : jusqu’où peut-on aller pour assurer la protection de son SI ?

Au-delà du cas Espagnol, il est intéressant de noter les approches des différents textes sur la notification des incidents. Ceux dédiés à la protection des données à caractère personnel ciblent une notification rapide pour limiter les impacts sur la vie des citoyens, quand les textes sur la protection des infrastructures critiques eux imposent des notifications limitées et très confidentielles pour prendre le temps de gérer correctement l’incident sans révéler à l’attaquant le fait qu’il a été découvert. GDPR a finalement prévu ce cas de figure mais d’autres textes pourraient également être contradictoires.

Un cadre réglementaire strict mais bénéfique

Le durcissement du cadre réglementaire pour le SOC, que ce soit direct (PDIS) ou indirect (GDPR), va engendrer une transformation de l’écosystème. De nouveaux profils pourraient ainsi s’intégrer aux équipes comme le DPO (Data Privacy Officer) que le SOC pourrait considérer comme un acteur clé pour maintenir sa conformité dans la durée.

De plus, ces réglementations vont tirer vers le haut les niveaux de maturité des acteurs soumis à ces référentiels ainsi que de ceux s’en inspirant. D’ores et déjà on observe de nombreux chantiers de mise en conformité touchant tant à l’architecture du SOC qu’à ses processus et sa gouvernance.

Pour satisfaire aux réglementations, l’outillage compte également, et il faut jouer avec les innovations telle que la surveillance orientée sur les données (avec de l’outillage de type Data Leakage Prevention – DLP), qui peut aider à la mise en conformité sur la protection des données sensibles.

Vers des réglementations plus réalistes…

L’apport des référentiels est indéniable, en tant que standard et en tant que cible à atteindre pour nombre d’organisations.

Si la barre peut sembler haute, ou que l’on trouve encore quelques incohérences entre les différents textes, on peut gager que les prochaines révisions apporteront un cadre solide pour la conception et l’amélioration des SOC.

Cet article Le SOC, un service en pleine mutation réglementaire est apparu en premier sur RiskInsight.

Beaucoup ont donc entamé au cours des 18 derniers mois un projet visant à exploiter les logs (ou journaux d’évènements) afin d’anticiper, détecter et diagnostiquer des actes malveillants.

L’objectif est ambitieux : on parle d’abord de log management, puis de corrélation des logs à l’aide d’un SIEM (security information and event management) . Quelle réalité derrière ces principes ? Comment les mettre en place ?

Étape 1 : centraliser les journaux

Une grande majorité de machines (équipements réseau, serveurs, postes de travail), bases de données ou applications d’un SI peuvent aujourd’hui générer des logs. Ces fichiers contiennent, pour chaque machine, la liste de tous évènements qui se sont déroulés : réussite ou échec d’une connexion utilisateur, redémarrage, saturation de la mémoire…

Pour les exploiter, il est possible de se connecter unitairement à chacun des équipements afin d’y observer l’historique. Cette tâche fastidieuse, encore souvent observée sur le terrain, est irréaliste sur des systèmes d’information complexes. Elle est par ailleurs inefficace pour prévenir un incident ou détecter les impacts en temps réel.

La construction d’un « puits de log » est une première brique de réponse : il s’agit de collecter, à l’aide d’un outil automatisé du marché, l’ensemble des journaux d’équipements dans un espace de stockage unique. L’un des critères de sélection de cet outil est justement sa capacité à reconnaître différents formats de logs (syslog, traps SNMP, formats propriétaires…).

Le volume d’information centralisée peut vite exploser : il est important d’éviter la collecte de données inutiles. Par ailleurs, le système peut également être gourmand en puissance de calcul en fonction des périmètres de recherches effectuées.

On parle de log management à partir du moment où les données contenues dans ce puits sont traitées et exploitées, par exemple pour retrouver un élément dangereux (virus, problème de sécurité…), ou un comportement malveillant (fuite d’information, suppression de données…). Il est nécessaire de cadrer en amont les finalités du projet,  qui peuvent être multiples :

• Vérifier que les règles du SI sont appliquées
• Détecter les attaques ou les utilisations frauduleuses du SI
• Permettre les analyses post-incidents (forensics)
• Répondre aux contraintes légales ou de conformité avec la capacité de fournir des éléments de preuve

Pour démarrer, une bonne pratique consiste à s’orienter principalement vers des logs de sécurité et réseau. Certaines applications métiers sensibles pourront ensuite être ajoutées.

Une fois l’espace de stockage cadré, l’archivage amène son lot de contraintes :

• D’un point de vue légal et réglementaire, il faut s’assurer de la licéité des traitements en fonction des informations archivées et de leurs durées de rétention. Une déclaration à la CNIL est à prévoir dans de nombreux cas.  En fonction de leur origine (e-mail, proxy, applications), les périodes de rétention ne sont pas soumises aux mêmes règles. À titre d’exemple, on considère aujourd’hui qu’une durée raisonnable pour l’historique des accès des utilisateurs à internet est de 12 mois.
• En fonction des traitements et du cadre juridique existant dans l’entreprise (par exemple charte incluant la surveillance…), les collaborateurs doivent potentiellement être informés des mesures mises en place. Dans ce cadre la mobilisation des ressources humaines et des instances représentatives du personnel sont à prévoir.
• La gestion des identités et des accès au puits de logs  est, enfin, un sujet crucial. Le volume et la sensibilité des informations qui y sont stockées nécessite d’identifier précisément les personnes habilitées à en faire usage, et de limiter strictement leurs droits au périmètre qui leur incombe. Toute modification des traces doit être interdite (même aux administrateurs),  afin que celles-ci puissent avoir une valeur probante le cas échéant.

Étape 2 : faciliter l’analyse, du SIEM au Big Data

Si des recherches manuelles sont toujours possibles dans un puits de logs, elles ne répondent qu’à un besoin précis et ponctuel.

Pour obtenir une analyse en temps réel avec des remontées d’alertes automatiques, il est nécessaire de passer à l’étape supérieure : le SIEM. Il s’agit à la fois d’une extension et d’une industrialisation de la première étape, souvent offerte par le même outil du marché.

Il s’agit ici de rechercher, à travers les traces, des liens entre des évènements unitaires ayant lieu sur différents éléments du SI, afin d’anticiper, bloquer (en temps réel) ou comprendre une action malveillante.  On parle alors de corrélation de logs.

Pour cela, il est important de définir les types de comportement anormaux à identifier. C’est la principale difficulté : un niveau de sensibilité trop élevé génèrera beaucoup d’alertes sans intérêt, tandis qu’un niveau trop faible ne permettra pas de lever les alertes pertinentes. Cette étape comporte donc une phase d’ajustement et apprentissage qui peut durer plusieurs mois.

Aujourd’hui le marché des SIEM se renouvelle : les solutions sont de plus en plus performantes, utilisent de nouvelles techniques de détection d’attaque, et exploitent de plus en plus la puissance de calcul du Cloud pour la corrélation d’évènements.

Le marché voit également arriver des outils utilisant les principes du Big Data. Plutôt que de rechercher des scénarios connus, l’idée est alors de détecter des anomalies statistiques dans la masse d’information. Cette approche séduisante doit encore être mise à l’épreuve du terrain.

 Ne pas négliger les aspects organisationnels

Enfin, il est nécessaire de s’assurer que les alertes seront traitées par les équipes compétentes. Les procédures et l’organisation associées doivent donc embarquer les équipes sécurité (SOC/CERT), réseau et système et le RSSI. Des réflexions autour de l’externalisation ou de l’internalisation de ces fonctions de surveillance et des liens avec les entités en charge de la gestion des incidents de sécurité sont également essentielles.

Cet article Surveillance sécurité : passer du puits de logs au SIEM (security information and event management) est apparu en premier sur RiskInsight.