Lorsque le CERT-Wavestone est engagé, trois priorités guident chaque action et chaque décision : endiguer la menace, comprendre l’attaque et éradiquer l’attaquant. Pour atteindre ces objectifs, établir une visibilité sur le périmètre impacté est la première étape indispensable.

Dans ces contextes où vitesse et efficacité sont non négociables, le CERT-Wavestone s’appuie sur de nombreux outils : solutions de cybersécurité (EDR, SIEM, etc.), collecteurs et parseurs open-source, et ses propres outils développés en interne.

Parmi ceux-ci, StormCell se distingue comme un outil open-source développé par le CERT-Wavestone pour automatiser le traitement des collectes forensiques Windows et libérer le temps des analystes afin qu’ils se concentrent sur ce qui compte vraiment : l’investigation elle-même.

Endiguer. Comprendre. Éradiquer. Chaque heure compte.

Des attaquants de plus en plus efficaces

Plusieurs acteurs de la réponse à incident s’accordent à dire que certains types de cyberattaques, comme les rançongiciels et les attaques par exfiltration de données, sont de plus en plus rapides. Les données publiées par Zero Day Clock (https://zerodayclock.com) illustrent cette tendance :

• Une part croissante des vulnérabilités zero day est activement exploitée chaque année, passant de 16 % en 2018 à 71 % en 2026,
• Un délai d’exploitation (Time to Exploit) en constante diminution est noté, tombant de plusieurs années en 2018 à moins d’une journée en 2026.

C’est également un constat partagé par l’équipe de réponse à incident de Wavestone (CERT-Wavestone) dans son dernier rapport annuel (voir : rapport annuel du CERT-Wavestone) basé sur une vingtaine d’incidents majeurs rencontrés par des clients de Wavestone au cours de l’année 2025 :

Dès lors, afin d’endiguer et de remédier aux incidents au plus tôt, notre équipe de réponse à incident se doit d’être la plus efficace possible dans ses analyses et prises de décision. Cela nécessite notamment une compréhension rapide du contexte et de l’incident.

L’anatomie d’une investigation du CERT-Wavestone

Chaque investigation CERT-Wavestone débute généralement sur un périmètre restreint avant de s’étendre rapidement à des dizaines de systèmes au fil de l’évolution de la situation :

• Étape 1 — Analyse initiale : Une fois le périmètre sécurisé et les premières mesures de confinement en place, le CERT-Wavestone évalue la situation sur un périmètre initial de machines suspectes ou compromises. Si le client dispose d’un SOC ou d’un CERT, la télémétrie et les outils de détection existants constituent un point de départ immédiat. Dans le cas contraire, CERT-Wavestone s’appuie sur les ressources disponibles pour réaliser des premières collectes forensiques et établir un premier état des lieux de l’attaque.
• Étape 2 — Investigation élargie : A mesure que la killchain se précise, l’investigation s’étend à des dizaines de machines compromises. Lorsque l’infrastructure du client ne permet pas de supporter des acquisitions à grande échelle, le CERT-Wavestone déploie son propre outil de collecte forensique pour recueillir les données de triage efficacement.
• Étape 3 — Recherche d’IoC sur l’ensemble du SI : Les indicateurs de compromission sont établis et la recherche s’étend à l’ensemble du système d’information. Si ce n’est pas déjà le cas, un EDR ou des outils alternatifs peuvent être déployés par le CERT-Wavestone. Les recherches d’IoC à grande échelle s’appuient sur les capacités natives de l’EDR, du SIEM ou des plateformes de collecte de logs.

Que ce soit durant l’étape 1 ou l’étape 2, chaque collecte nécessite le même pipeline standardisé : récupération, parsing, ingestion, identification des indicateurs de compromission (IoC) et corrélation entre les collectes. En conséquence, le traitement forensique manuel mobilise un temps et des ressources précieux, contraignant les analystes à gérer des opérations de traitement de données routinières plutôt que de se concentrer sur l’investigation.

Traiter chaque collecte individuellement et manuellement est un travail lent, source d’erreurs et d’incohérences, et s’adapte mal au nombre de machines à investiguer comme au nombre d’analystes mobilisés sur l’incident.

C’est précisément ce problème que StormCell, outil développé par le CERT-W, a été conçu pour résoudre.

StormCell : C’est quoi ?

StormCell est un outil développé par le CERT-Wavestone pour répondre à un besoin de longue date : un orchestrateur d’analyse forensique Windows qui s’adapte à de multiples contextes d’investigation, automatise le traitement de bout en bout des données de triage, de l’extraction des artefacts jusqu’à leur ingestion centralisée dans une plateforme SIEM, et libère les analystes pour qu’ils se concentrent sur l’investigation, et non sur le pipeline.

Développé en python afin de le rendre facile d’utilisation, l’outil a récemment été publié sur GitHub afin d’être accessible en source ouverte par l’ensemble de la communauté de réponse à incidents : https://github.com/CERT-W/StormCell. Le CERT-Wavestone souhaite que cet outil puisse être utilisé, confronté et amélioré directement par la communauté.

Bien que d’autres outils similaires aient été développés et publiés depuis le début de son développement, StormCell se démarque par sa modularité ainsi que ses choix technologiques, pensés pour garantir à la fois rapidité d’exécution et grande adaptabilité.

Les trois étapes clés : ingestion, traitement et centralisation

Le fonctionnement de StormCell repose sur trois étapes clés :

Afin de les mener à bien, StormCell repose sur un ensemble d’outils tiers : que ce soit pour la collecte et le traitement des artéfacts avec Kape, l’enrichissement et l’envoi des journaux dans un SIEM avec Vector ou bien les fonctionnalités de recherche d’un SIEM avec Splunk ou ELK.

Malgré ces dépendances, l’outil n’a besoin d’être installé et configuré qu’une seule fois sur un unique poste d’investigation avant d’être utilisé tout au long de la réponse à incident par l’ensemble des analystes.

Extraction et ingestion de données

StormCell est développé afin de fonctionner avec deux types de collectes : les copies de disque et les extractions ZIP d’artéfact réalisées avec Kape.

Lorsque StormCell est exécuté sur une copie de disque, il va directement utiliser Kape afin d’en extraire les artéfacts pertinents.

Des archives ZIP compatibles peuvent quant à elles également être générées avec l’outil du CERT-Wavestone CollectRaptor, reposant sur Velociraptor, ou toute autre collecte réalisée avec le module KapeTarget de Velociraptor.

Traitement et enrichissement des artéfacts

Une fois les artéfacts bruts à disposition, le cœur de la chaîne de traitement entre en jeu : les artefacts sont traités avec Kape.

Kape est utilisé car c’est un outil dédié au traitement d’artéfacts Windows. Il permet, au moyen de modules, d’exécuter automatiquement de multiples outils tels que la suite de Zimmermann, Hayabusa ou bien encore Chainsaw. De plus, les journaux traités par Kape sont directement organisés par catégorie d’artéfact (exécutions, système de fichier, registres, etc.), permettant une analyse locale manuelle efficace en cas de besoin.

Au total, StormCell utilise Kape pour exécuter plus d’une trentaine d’outils de traitements des artéfacts, chacun couvrant un spectre d’analyse complémentaire, assurant une exhaustivité des éléments à disposition des analystes.

L’ensemble de ces outils peut facilement être téléchargé avec à la commande d’installation de StormCell, décrite dans son Readme. La configuration modulaire de StormCell permet par ailleurs de facilement intégrer de nouveaux outils de traitement des journaux.

Centralisation dans un SIEM

Une fois que les artéfacts ont été traités par Kape, les journaux générés sont normalisés, enrichis et envoyés vers une plateforme SIEM par Vector, un outil open source notamment adapté à l’envoi d’une volumétrie importante de données.

Afin d’identifier quels artéfacts envoyer, ainsi que les normalisations et enrichissements à appliquer, Vector repose sur ses fichiers de configuration TOML qui intègrent des parsers qui structurent les données brutes en champs exploitables et des sinks (destinations de sortie) qui acheminent les événements vers l’environnement ciblé,  instance ELK ou Splunk de nos clients, ou sur une instance ELK interne dédiée du CERT-Wavestone.

Pour récupérer ces configurations, StormCell utilise les configurations du répertoire Github Vector4IR dont le CERT-Wavestone est contributeur.

Un gain de temps majeur pour les analystes

Par l’enchaînement de ces trois étapes, chaque collecte forensique n’a besoin d’être traitée qu’une unique fois avant d’être rendue accessible dans un SIEM à l’ensemble des analystes. Ainsi, il est possible de réaliser des investigations globales en exploitant au maximum les fonctionnalités inhérentes aux technologies SIEM : langages de recherches, tableaux de bord et requêtes enregistrées, lookups et tableaux de données, fonctionnalités de corrélation, etc.

La récupération des collectes et l’exécution dans StormCell peut être portée par un unique analyste pendant que les autres peuvent déjà investiguer en temps réel au fur et à mesure de l’arrivée des journaux.

Les modes d’exécution de StormCell

Conformément aux détails sur l’installation et la configuration de StormCell à disposition dans le Readme du répertoire Github, une commande setup peut être utilisée afin de télécharger l’ensemble des outils nécessaires au fonctionnement intégral de StormCell. Par ailleurs, de nombreuses options, détaillées dans le fichier de configuration par défaut ainsi que la commande d’aide sont disponibles afin de convenir aux différents besoins d’exécution.

Il est par exemple possible de préciser quels modules Kape exécute ou bien de forcer un nouveau traitement et envoi des journaux. StormCell utilisant un fichier de base de données locale pour assurer une persistance entre plusieurs exécutions successives, il est possible d’entièrement réinitialiser son comportement en supprimant cette base.

Enfin, StormCell propose trois modes d’exécution complémentaires, pensés pour s’adapter à chaque contexte d’investigation, du périmètre restreint à la crise de grande ampleur, et permettre aux analystes d’être opérationnels le plus rapidement possible, quel que soient le type de ressources à leurs dispositions.

Mode Once : Petits périmètres et besoin d’investigation rapide

Conçu spécifiquement pour des investigations ciblées, au périmètre plus restreint, ce mode permet de traiter en une seule exécution un ensemble de collectes d’ores et déjà disponibles.

Après configuration spécifique par les analystes, l’outil s’exécute et permet l’analyse des collectes sans étape supplémentaire.

Mode Mountpoint : collecte locale et analyse, en une seule commande

Mountpoint constitue le mode d’exécution de bout en bout de StormCell : Il va de la collecte des artefacts sur un disque ou copie forensique monté localement à l’envoi dans le SIEM.

Ce mode est privilégié lors de l’analyse de disques complets mis à disposition pour l’investigation pour des raisons opérationnelles, et inclus nativement l’extraction d’artefacts grâce aux fonctionnalités intégrées de Kape.

Une fois l’extraction réalisée, son fonctionnement est similaire au mode Once.

Mode Loop : Traitement en continu pour les investigations de grande ampleur

Privilégié par le CERT-Wavestone, ce mode de fonctionnement est pensé pour les crises de plus grande ampleur et a pour but de permettre l’exécution de StormCell en continu, tout au long de l’incident. Après configuration, l’outil surveille un dossier et traite toutes les collectes déposées par les analystes.

Ce point de dépôt centralisé devient le cœur logistique de l’investigation : une fois en place, les analystes n’ont plus à se soucier du traitement des collectes, que l’incident dure quelques jours ou plusieurs semaines, et peuvent ensuite accéder aux données traitées dans la solution SIEM utilisée.

Enfin, deux niveaux de traitement des artefacts sont configurables pour répondre au mieux au besoin des analystes lorsque les investigations sont menées sur de nouvelles machines :

• Short : un traitement allégé privilégiant la rapidité, adapté aux analyses de surface pour qualifier rapidement une machine et prioriser les investigations.
• Long : un traitement exhaustif activant des modules d’analyse en profondeur, conçu pour les investigations approfondies nécessitant une vision complète de l’activité de la machine.

Les modules à exécuter sur chacun de ces modes est librement configurable par les analystes utilisant StormCell. Ces deux modes de fonctionnement complémentaires permettent notamment de déposer dans un premier temps les archives dans le dossier Short pour obtenir une liste rapide mais non exhaustive d’artéfacts, puis dans un second temps les déposer dans le dossier Long pour obtenir une liste exhaustive d’artéfacts.

StormCell : Quoi de plus ?

StormCell est aujourd’hui un outil clé fréquemment utilisé au sein du CERT-Wavestone afin d’accélérer le traitement des artefacts Windows lors de ses investigations.

Il est prévu d’étendre les capacités d’orchestration de l’outil aux investigations sur des environnements Cloud (notamment M365), Linux et macOS, tout en étudiant l’apparition de nouvelles sources forensics et des technologies avancées comme l’utilisation de l’IA.

C’est pourquoi le CERT-Wavestone vous invite à contribuer à son évolution : fork, pull requests et retours d’expérience sont les bienvenus pour faire de StormCell un outil le plus adapté possible aux besoins de réponse à incidents.

Cet article StormCell : Quand la Blue Team passe à l’échelle en réponse à incident est apparu en premier sur RiskInsight.

S’il y a 10 ans, construire son SOC revenait à se demander quels scénarios superviser, quelles sources de logs collecter et quel SIEM choisir, les évolutions récentes du SI proposent de nouveaux défis : comment mettre en place la supervision dans un environnement partiellement on-premise et/ou multicloud ? En effet, en 2021, avoir un SI hébergé chez plusieurs fournisseurs IaaS est plus proche de la règle que de l’exception ; et si AWS reste l’acteur le plus rencontré, les offres d’Azure et de GCP intéressent de plus en plus d’équipes IT.

Comment construire sa stratégie de détection ? Où positionner le ou les SIEM ? Comment centraliser les logs, les alertes ? D’ailleurs, faut-il des logs ou des alertes ? Et comment tirer parti des solutions managées proposées par les fournisseurs cloud ?

Dans cet article, nous discuterons de bonnes pratiques : utilisation d’une stratégie de détection bottom-up, optimisation via le choix des services natifs cloud les plus pertinents, simplification de l’architecture de collecte ; toujours basées sur des retours d’expérience de construction de stratégies de supervision multicloud.

(Re)penser sa stratégie de détection pour le multicloud

La première question que devrait se poser l’équipe en charge du SOC est celle de la stratégie de détection. Autrement dit, quels scénarios va-t-on superviser ?

Un bon réflexe cyber consiste à utiliser une approche dite « top-down » : partir d’une analyse de risques pour identifier les alertes à prioriser, les formaliser puis les traduire techniquement dans le SIEM. En pratique, trois facteurs démontrent que cette approche est insuffisante :

• Peu d’équipes disposent d’analyses de risques qui soient suffisamment exhaustives, à jour et pragmatiques pour permettre une déclinaison des scénarios de menaces en scénarios supervisables, en particulier pour des périmètres complexes comme le cloud public,
• Rien ne garantit que les scénarios obtenus par cette méthode puissent concrètement être mis sous supervision, que les limites soient liées aux solutions déployées ou à la nécessité pour les équipes SOC de disposer de connaissances métier.
• Cette approche définit quelques chemins d’attaques selon la criticité des actifs, mais ne couvre pas tous les chemins d’attaques qu’un attaquant pourrait emprunter.

De ce fait, une stratégie de détection multicloud efficace sera obtenue en complétant l’approche par les risques par une approche « bottom-up » : en partant des capacités de journalisation des solutions dont on dispose pour identifier les alertes que le SIEM devra remonter, pour enfin prioriser en se basant sur leur intérêt en termes de couverture des risques. Partir de l’existant garantit le pragmatisme et l’efficacité de la démarche.

Chez Wavestone, nous sommes de plus en plus sollicités par des clients souhaitant être accompagnés sur cette nouvelle approche. Le périmètre concerne les principales solutions utilisées en multicloud : Microsoft 365 (SaaS) et les solutions managées des offres IaaS des 3 principaux acteurs du marché : Amazon Web Services, Microsoft Azure et Google Cloud Platform.

Mettre en place la supervision de l’infrastructure Microsoft 365

Sur le papier, l’équipe SOC a toutes les clés en main pour monitorer son infrastructure cloud :

• Des logs bruts pour les services d’Office 365 (Teams, SharePoint Online, Exchange Online, etc.)
• Des logs bruts, rapports de sécurité, alertes et Identity Secure Score pour Azure AD
• Des logs bruts, alertes, Microsoft Secure Score et recommandations Azure pour les outils de sécurité comme ATP, AAD Identity Protection, Intune, AIP, etc.

En pratique, naviguer entre les logs et tous les outils mis à disposition (et leurs consoles) peut vite devenir un casse-tête. Et si nous entendons régulièrement qu’il y a trop de logs ou d’interfaces d’administration à maîtriser, sur le terrain les difficultés sont accentuées :

• Par les faibles capacités de personnalisation des outils natifs proposés,
• Par le manque de scénarios disponibles avec la licence achetée,
• Par la durée de rétention de 90 jours des logs,
• Par le manque général de compétences Office 365 ou AzureAD dans les équipes SOC.

Pour éviter de se perdre, nous conseillons de simplifier le terrain de jeu autant que possible. Les bonnes pratiques consistent à penser alertes, et pas collecte de logs, puis à centraliser leur gestion dans le SIEM en utilisant des connecteurs comme ceux de Security Graph API. A titre d’exemple, il est possible d’arriver à un modèle comme celui donné ci-dessous :

Une fois l’architecture identifiée, configurer une durée de rétention de logs adaptée aux besoins (au sein d’Azure ou à l’extérieur) et entreprendre l’adaptation des processus SOC aux spécificités de M365 selon les choix réalisés lors de l’étape précédente.

Mettre en place la supervision des autres cloud en IaaS

Afin de dessiner l’architecture de collecte sur ces clouds, il convient de distinguer les différents types de logs mis à disposition par les CSP.

Logs système

Le cas des logs système générés par les VM et les flux réseau peut être traité en premier ; il est possible de les collecter de la même manière qu’on-premise, avec des agents syslog, par exemple. Les infrastructures des CSP mettent à disposition des briques comme Log Analytics chez Azure pour faciliter la remontée.

Logs d’administration de l’infrastructure

On peut aussi envisager la supervision des opérations d’administration des composants « sensibles » de l’infrastructure (VPN, FW, scanner de vulnérabilités, etc.) comme on le ferait on-premise. En effet, la plupart de ces solutions disposent de leur pendant IaaS chez les fournisseurs cloud : elles s’obtiennent via la Marketplace et disposent de console d’administration web ou s’interfacent directement à la console de management du CSP (c’est par exemple le cas de l’appliance du scanner Qualys).

Logs des appels d’API

Enfin, les appels d’API réalisés par les processus/comptes sur l’infrastructure cloud et par les opérations d’administration génèrent des logs qui sont facilement récupérables via les services managés suivants :

• CloudTrail chez AWS
• Activity Log & Monitor chez Azure
• Audit Logging chez GCP

Pour éviter de se perdre, retenons la leçon suivante : « Utilisons et abusons des services natifs du cloud ». En effet, qui de mieux placé que le fournisseur pour proposer des services adaptés et intégrés au mieux à l’environnement ? En pratique, nous constatons qu’implémenter la gestion des logs et des alertes cloud dans un SIEM on-premise coûte cher (même en cherchant à limiter les coûts de stockage dans la solution de supervision) et est chronophage.

L’utilisation du cloud implique de passer à la philosophie du cloud : adoptons ses codes et domptons ses services et outils. L’occasion de renforcer les synergies entre les équipes cloud et le SOC !

En synthèse, un exemple d’architecture de monitoring sur AWS est proposé ci-dessous. Il présente plusieurs façons de réaliser la supervision, en s’appuyant sur des services natifs pour les logs et pour les alertes (NB : tous les flux vers S3 et d’autres services n’ont pas été représentés pour des raisons de lisibilité).

Définir l’architecture de centralisation des alertes multicloud

C’est l’une des questions qui nous est la plus posée : quelle architecture SIEM faut-il envisager en multicloud ? Si chaque contexte est différent, parce que chaque infrastructure IT dispose de legacy et d’un historique qui lui est propre, la présence d’autant de ressources et d’outils doit amener une équipe SOC à considérer l’adoption d’un SIEM dans le cloud central (comme Azure Sentinel, Splunk SaaS, etc. ; AWS et Chronicle de Google ne proposant pas à date de solution équivalente).

Pour aider les équipes SOC à choisir le scénario adapté, nos recommandations sont les suivantes :

• Privilégier le scénario à un seul SIEM central
• Limiter autant que possible le nombre de consoles de supervision cloud
• Remonter au maximum des alertes déjà préanalysées par les services natifs mis à disposition étudiés précédemment
• Tirer profit des synergies éventuelles entre produits du même fournisseur : Azure Sentinel pour monitorer l’infrastructure Microsoft 365 par exemple
• Tirer profit des nombreux connecteurs mis à disposition par les fournisseurs de SIEM cloud
• Etudier les impacts de chaque scénario sur l’organisation du SOC (taille des équipes, compétences technologiques, etc.) et les coûts associés (développements nécessaires, volumétrie et coûts d’ingestion, etc.)

Un exemple d’architecture reprenant l’ensemble des recommandations de cet article est proposé ci-dessous, il utilise Azure Sentinel comme SIEM cloud central.

Synthèse : les principes clés à adopter pour garder la tête au-dessus des nuages

En résumé, l’équipe SOC souhaitant adapter sa stratégie de détection au multicloud devrait :

• Compléter son approche classique top-down par l’approche bottom-up, particulièrement adaptée au contexte complexe du multicloud,
• Utiliser dès que c’est possible les services natifs mis à disposition par les fournisseurs afin de tirer pleinement parti des avantages du cloud,
• Simplifier l’architecture de collecte et centraliser au maximum des alertes préanalysées par les services natifs cloud,

Une fois la tête sortie du nuage, la stratégie formalisée et l’architecture de collecte déployée, le SOC retrouve bien sa place de tour de contrôle du SI : la prolifération des services dans le cloud ne lui fait plus peur !

Les prochaines étapes peuvent consister à étudier les possibilités d’automatisation, avec la mise en place d’un SOAR, par exemple. Nous ne manquerons pas de discuter du sujet dans un prochain article.

Cet article Adapter sa stratégie de détection au multicloud sans se perdre dans les nuages est apparu en premier sur RiskInsight.

L’année dernière, j’ai eu la chance de travailler avec différentes organisations dans leur transformation du Cloud, et chacune d’elles a fourni à notre équipe de consultants Wavestone des idées et des leçons clés sur ce que les systèmes de détection basés sur le Cloud peuvent et ne peuvent pas apporter à une organisation.

Au cours de cette année, j’ai eu la chance de travailler avec différentes organisations dans leur transformation Cloud, et chacune d’entre elles a fourni à notre équipe de consultants Wavestone des retours d’expériences et des leçons clés sur ce que les systèmes de détection basés sur le Cloud peuvent et ne peuvent pas apporter à une organisation.

Pour cet article, gardez à l’esprit que nous considérerons tout changement de configuration conduisant à une dégradation du niveau de sécurité comme un incident. Bien qu’il ne corresponde peut-être pas à la définition exacte et habituelle d’un incident de sécurité, la mauvaise configuration d’un service public cloud (où les ressources et les données peuvent être directement accessibles par Internet) est un problème trop grave pour ne pas donner lieu à une alerte immédiate sur la sécurité du système d’information.

Embrassez les victoires rapides

Lorsque vous utilisez le Public Cloud des principaux fournisseurs (Amazon Web Services, Microsoft Azure et Google Cloud Platform), il est assez facile d’activer les fonctionnalités de détection natives et de d’obtenir une capacité de détection basique mais efficace. La plupart des éditeurs fournissent une plateforme de sécurité centrale qui vous permettra de détecter les erreurs de configuration  sur l’infrastructure que vous avez déployée, d’évaluer votre niveau de conformité par rapport à une norme donnée et de lever certaines alertes lorsque les incidents les plus typiques se produiront (voir plus loin). Il n’y a pratiquement aucune raison de passer sur ces fonctionnalités, qui sont parfois gratuites à activer (que ce soit pour un essai ou de manière permanente).

En outre, la journalisation est quasiment un non-problème dans votre feuille de route de sécurité. Les fournisseurs de cloud vous permettent généralement de diffuser les journaux de vos machines virtuelles (par l’intermédiaire d’agents), de vos composants PaaS (via une poignée de clics, ou de quelques paramètres dans vos modèles d’Infrastructure as Code) et du plan de gestion (management plane) de votre abonnement (souvent activé par défaut). Cela permet à votre équipe de sécurité de comprendre rapidement l’activité en cours sur la plate-forme et de commencer à construire sur la base des journaux pour obtenir quelques alertes. En outre, certains fournisseurs de cloud possèdent des systèmes SIEM (tels que Azure Sentinel) prêts à être branchés via des connecteurs pour les appliances et les sources de données externes. Ces systèmes SIEM analysent les journaux et retire  une partie du travail lourd nécessaire lors de la mise en place de la journalisation.

Saisissez l’occasion d’améliorer la sécurité dès maintenant

Une fois que vous avez appris les bases des outils natifs de détection Cloud, il est temps de construire votre propre expertise pour pouvoir compter sur vos propres outils ! Vous pouvez également vous appuyer sur des solutions tierces telles que les solutions de gestion de la posture de sécurité dans les Cloud (CSPM) et les configurer de manière à couvrir vos besoins.

Comme indiqué ci-dessus, les fonctionnalités natives des fournisseurs de services Cloud offrent quelques alertes de base qui peuvent aller loin. Avec AWS Guard Duty, vous pouvez détecter la compromission des jetons d’accès AWS EC2 ou un accès anormal aux seaux S3. Azure Security Center vous avertira lorsqu’une activité potentiellement malveillante est détectée sur une machine virtuelle, ou lorsque les comptes Azure AD sont susceptibles d’être pris en charge… Si vous devez être capable de détecter rapidement des attaques, il existe un moyen d’exploiter les alertes natives et prêtes à l’emploi disponibles (bien que certaines d’entre elles puissent nécessiter la licence premium après un essai gratuit).

L’un des principaux avantages de la détection du Cloud est que vous pouvez agir immédiatement en y remédiant automatiquement ! Par exemple, les erreurs de configuration sont une réelle source de préoccupation pour les équipes de sécurité, comme en témoignent les téraoctets de données qui ont fui par des seaux S3 accidentellement exposés. Alors pourquoi ne pas reconfigurer tout seau exposé, à moins qu’il n’ait été spécifiquement défini dans une « liste d’autorisation » ? L’automatisation vous permettra de détecter le modèle d’exposition, de lancer une fonction sans serveur qui corrigera la mauvaise configuration et pourrait même avertir le propriétaire de la ressource ou l’équipe de sécurité.

Cela peut être fait pour une mauvaise configuration, mais aussi pour une activité malveillante : si vous détectez qu’un jeton EC2 est volé dans les métadonnées d’une instance, vous pouvez temporairement lui retirer ses droits d’accès. Si vous constatez que la journalisation est désactivée, réactivez-la et verrouillez les comptes d’utilisateurs responsables. Cela vous permettra de réagir plus rapidement aux incidents de sécurité.

Bien entendu, vous devez encore travailler sur le processus global de gestion des incidents : à la fois sur la manière d’éviter la mauvaise configuration des services (par la formation des développeurs et les contrôles dans les canaux CICD s’ils existent) et sur la manière de les gérer une fois qu’ils se produisent (le modèle de fonctionnement est abordé plus loin).

Se rapprocher de l’entreprise et de l’amélioration continue

Le passage au Cloud est généralement un moment où les applications et les charges de travail devront à nouveau passer par un examen de sécurité pour s’assurer que l’architecture et la conception sont solides et sûres. Mais c’est aussi l’occasion de rendre la détection de sécurité plus pertinente pour l’application.

Pour que cela compte, mon conseil serait le suivant:

• Passer par le processus de « Service Enablement » pour les nouveaux services : comme le passage au cloud permet aux équipes commerciales et informatiques d’utiliser des centaines de nouvelles fonctionnalités et de nouveaux composants, il est important de réunir les architectes et les équipes de sécurité pour évaluer les principaux risques pour chaque nouvelle technologie, trouver des contre-mesures pour limiter ces risques et commencer à réfléchir aux alertes qui devront être mises en œuvre dans le SIEM ;
• Construire un catalogue d’alerte pour chaque scénario et composant de risque typique, la logique de l’alerte étant déjà prédéfinie et seules les spécificités de l’entreprise devant être personnalisées. Le « time to market » de la supervision devrait également diminuer, car une bonne partie des composants utilisés pour les opérations dans le Cloud est commune à la plupart des applications (machines virtuelles, bases de données, applications et fonctions sans serveur, systèmes de découplage) ;
• Tenez-vous au courant des attaques liées au Cloud afin de comprendre les dernières vulnérabilités et les chemins empruntés par les attaquants, et intégrez-les dans vos systèmes de détection.

Toutes ces spécificités applicatives doivent s’ajouter aux alertes transversales couvrant les fonctions essentielles de votre Cloud (IAM, mise en réseau, zones d’atterrissage, etc.). Pour vous aider à mettre en place cette capacité de détection du noyau, vous pouvez évidemment compter sur notre équipe, mais je vous recommande également de vous renseigner sur la communauté CloudSec, qui ne cesse de s’agrandir et qui partage son expertise en permanence grâce à des outils open-source (comme cette vue consolidée ) ou sur des plateformes en direct et en ligne (comme le Forum sur la sécurité dans le Cloud et son premier Fwd:CloudSec conférence cette année).

Mais tout n’est pas facile !

D’après tout ce qui précède, il peut sembler facile d’obtenir une compétence de détection et de réaction d’un Cloud solide. Cependant, certains défis restent à relever.

Le premier qui vient à l’esprit est la tarification. Souvent proposé comme argument de vente pour les programmes Move to Cloud, il n’est pas aussi facile qu’il y paraît d’estimer avec précision le prix que votre fournisseur vous fera payer pour les détections Cloud. Au fil des ans, de nombreuses solutions de sécurité des CSP sont passées à une tarification basée sur les composants pour les IaaS et à une tarification basée sur les transactions pour les composants PaaS. Le stockage des journaux et les alertes sont parfois encore plus complexes, car certaines solutions vous factureront en fonction du transit et de l’agrégation des journaux, tandis que d’autres vous factureront le nombre d’évaluations par rapport aux alertes que vous avez lancées. Un travail important est nécessaire pour déterminer un budget réel et ne pas faire faillite.

Le deuxième point essentiel est de comprendre ce que votre fournisseur offre et ce qu’il n’offre pas en termes de détection. Si la plupart des solutions prétendront résoudre tous vos problèmes d’un seul coup, c’est malheureusement loin d’être le cas. Et pour chaque cas d’utilisation de la sécurité, il faut savoir si l’option gratuite, si elle existe, vous convient, si l’option premium est nécessaire ou si vos équipes de sécurité peuvent se débrouiller seules. De manière réaliste, vous devrez commencer par l’option native, jusqu’à ce que votre équipe de sécurité soit suffisamment mature, en termes de Cloud, pour passer à un processus fait maison.

En outre, et c’est peut-être l’aspect le plus important, vous devez concevoir un modèle d’exploitation qui vous permettra de travailler avec plusieurs abonnements, plusieurs équipes/entreprises et éventuellement plusieurs fournisseurs de Cloud. De plus en plus d’organisations parallélisent leurs opérations en choisissant différents CSP pour différents cas d’utilisation, ce qui entraîne une complexité accrue pour les équipes de sécurité – car elles doivent gérer des incidents sur différentes plateformes, les responsabilités étant réparties entre les DevOps, les SecOps et les équipes sur site. Cela sera d’autant plus difficile qu’une mauvaise configuration entraînera des risques de sécurité immédiats et qu’il faudra choisir entre les opérations et la sécurité. En l’absence d’une division solide des tâches entre tous les fournisseurs et toutes les équipes, il y a de fortes chances qu’une petite erreur de configuration se transforme en une fuite de données importante.

Enfin, n’oubliez pas que la surveillance de vos applications dans le Cloud peut également créer des risques. Outre le verrouillage des fournisseurs, vous pouvez perdre toutes les fonctions de sécurité ainsi que vos applications si tout se trouve sous le même plan de gestion. Si les droits d’administration globale du locataire SIEM sont repris par un attaquant, il aura toute liberté d’affecter les ressources sous-jacentes (c’est-à-dire d’effacer les journaux, de désactiver les alertes ou de supprimer les capacités de correction). Il vaut la peine d’y réfléchir avant d’empiler votre SIEM et vos applications critiques sous le même toit.

Pour résumer, en fin de compte :

• Attrapez les fruits qui pendent : votre fournisseur de Cloud vous aidera à collecter et à consolider les bûches facilement. Il n’y a pratiquement plus d’obstacles techniques pour ne plus utiliser les bûches. En outre, activez les fonctions de sécurité de base fournies par votre fournisseur de services dans le Cloud pour détecter les attaques les plus évidentes.
• Développez votre maturité en matière de Cloud avec des équipes de Cloud : Le mouvement Cloud a poussé les équipes commerciales et informatiques (SecDevOps) à travailler plus étroitement que jamais. Adoptez cette philosophie en comprenant mieux les besoins des entreprises en termes de sécurité, en personnalisant les alertes et en automatisant votre réponse pour permettre à votre capacité d’évoluer.

• Optimiser les coûts et les modèles de fonctionnement pour exceller : La virtualisation a facilité de nombreux aspects techniques pour les équipes, mais les processus peuvent être difficiles à adapter. Veillez à concevoir avec soin votre modèle d’exploitation de détection/réponse aux incidents pour vous assurer que toutes vos applications et tous vos fournisseurs de services dans le Cloud sont couverts. Enfin, pensez à l’optimisation des coûts lorsqu’il s’agit de la gestion des logs !

Cet article Comment améliorer votre detection cyber en migrant dans le Cloud est apparu en premier sur RiskInsight.

À quelles difficultés font face ces équipes au quotidien ? Comment rester efficace alors que les attaques des cybercriminels deviennent extrêmement élaborées ?

Le SIEM : un pilier du SOC… à condition d’être bien implémenté !

L’apparition d’outils comme le SIEM (Security Information and Event Management), il y a environ 10 ans, a permis aux équipes de sécurité opérationnelle d’industrialiser la surveillance en simplifiant l’analyse de multiples sources d’événements de sécurité (console antivirus, proxy, Web Application Firewall…). Cet outil a également rendu possible la corrélation de nombreux événements provenant d’équipements ou d’applications hétérogènes pour détecter des scenarii de menace avancés.

Cependant, la mise en place d’un SIEM doit être le résultat d’un projet ayant un investissement proportionnel à la complexité du système d’information surveillé. En effet, la pertinence d’un SIEM repose à la fois sur :

• La présence de contrôles contextualisés au système d’information (notamment au travers de l’exploitation de la sensibilité des assets surveillés).
• L’étude et l’implémentation de scénarii de menaces avancés et adaptés aux enjeux du métier de l’entreprise.

Concernant le périmètre de surveillance, les premiers équipements habituellement intégrés sont les équipements de sécurité car ils sont nativement configurés pour laisser des traces exploitables pour les équipes opérationnelles. Il est néanmoins souvent constaté que leur intégration se limite à une simple retranscription des contrôles déjà existants ; ce qui ne permet pas de tirer parti de la corrélation d’évènements proposé par un SIEM.

En revanche, l’intégration d’applications métiers est plus délicate en raison notamment des besoins différents entre les équipes métiers et sécurité : la principale préoccupation pour le métier se résume généralement à l’indisponibilité de son application (ou de certaines de ses fonctionnalités), alors que la sécurité adresse un éventail de risques plus complet, que ce soit de l’indisponibilité, de la compromission de l’intégrité de données ou encore de la fuite d’informations confidentielles.

Il s’avère donc primordial de sensibiliser les métiers aux enjeux sécurité dans leur ensemble pour pouvoir déterminer des scenarii de menace réalistes et propres à chaque périmètre. De plus, ces applications n’ont traditionnellement pas de fonctionnalités avancées en termes de sécurité. Par conséquent, il est difficile de disposer d’un système de surveillance efficace (configuration d’envoi de logs complexe, fichiers de logs très peu verbeux…).

De manière générale, l’implémentation trop simpliste de contrôles dans un SIEM rend l’activité du SOC inefficace. Les équipes de surveillance se voient alors noyées de « faux positifs » et les évènements de sécurité sont traités unitairement au lieu d’être analysés dans leur ensemble afin de détecter de réels scenarii de menace (par exemple : une authentification non autorisée sur un serveur puis la désactivation de son antivirus devra être traité comme un seul incident à investiguer).

Des équipes pas assez intégrées dans l’organisation de la sécurité

Outre les problématiques liées à une mauvaise implémentation du SIEM évoquées ci-dessus, on constate également des problématiques d’ordre organisationnel.

En effet, le SIEM est souvent perçu comme une « boîte noire » par les analystes de niveau 1 et 2 au sein des équipes du SOC. Cela est généralement dû à la méconnaissance des problématiques réelles de production (identification des assets critiques, des interactions entre les différents systèmes…). Les incidents détectés par le SIEM se retrouvent alors tous traités au même niveau sans aucune priorisation et identification en amont des éléments les plus sensibles.

Pour maintenir un niveau de compétence suffisant au sein des équipes de sécurité opérationnelle, de la veille technologique doit être réalisée par les investigateurs niveau 3 pour ensuite être communiquée aux analystes niveau 1 et 2. Des sujets tels que la présentation de nouveaux IOC (Indicator Of Compromise) venant compléter des règles de détection permettront aux équipes de gagner en efficacité dans leur manière d’appréhender les incidents. Ces types d’initiatives contribueront à l’amélioration continue du service en évitant sa dégradation dans le temps.

De plus, les équipes doivent participer en continu aux nombreuses initiatives sécurités initiées par la DSI tels que des projets de sécurisation des infrastructures ou applications. Par ailleurs, des exercices de gestion de crises doivent être organisés afin d’éprouver les différents processus et outils mis en place et de permettre aux interlocuteurs métiers et sécurité de pouvoir échanger sur leurs rôles respectifs en cas de crise.

Dans un contexte où la cybercriminalité ne cesse de se réinventer (comme le démontre l’attaque sur les systèmes Swift récente), les équipes opérationnelles sont de plus en plus sollicitées pour intégrer de nouveaux périmètres. Cette pression constante exercée notamment par les décideurs accentue les phénomènes de mauvaise implémentation des contrôles et de méconnaissance des scénarii de menace réels. Une bonne surveillance nécessite plus qu’un simple envoi de logs dans un SIEM ; les équipes projet doivent s’efforcer de respecter et faire respecter le processus complet d’intégration de nouveaux périmètres : identification des scénarii d’attaques, mise en place des mécanismes de collecte, création des règles de détection, tests et mise en production. L’oubli d’une de ces étapes risque de rendre la collecte des logs du périmètre inutile.

Quel avenir pour les SOC ?

De nombreux facteurs vont venir bouleverser l’écosystème des prestataires de la sécurité opérationnelle.

En effet, la LPM (Loi de Programmation Militaire) va exiger de tous les OIV (Opérateur d’Importance Vitale) de choisir des prestataires certifiés PDIS (Prestataires de Détection des Incidents de Sécurité), pour ceux qui font appel à de telles prestations externes. De nombreux prérequis seront nécessaires afin de pouvoir être certifié, tels que le cloisonnement des données des clients ou la mise en place de zones d’administrations (enclaves), uniquement accessible par le prestataire, par lesquelles les logs seront récupérés pour ensuite être transmis au SIEM. Ces facteurs vont entraîner de nombreux changements au sein des organisations et infrastructures mises en place actuellement.

Par ailleurs, la part grandissante du cloud dans les systèmes d’information des entreprises amène une nouvelle complexité : celle de la collecte des logs auprès des fournisseurs. De nouveaux acteurs sont donc apparus dans le marché de la sécurité : les CASB (Cloud Access Security Brokers). Leur promesse : répondre aux problématiques de sécurité pour le cloud. Ces entités se situent entre les utilisateurs et les divers services cloud et proposent de nouvelles briques de sécurité telles que l’utilisation d’API pour détecter directement des scenarii de menaces (création de fichiers de journalisation des accès aux applications, implémentation de ces données dans un SIEM…).

L’objectif de demain : gagner en maturité

La sécurité opérationnelle a encore de nombreux défis à relever. La plupart des entités assurent actuellement l’hygiène minimum du système d’information et la maturité des équipes leur permet de se prémunir des menaces diffuses (virus, spam…). Cependant, le dispositif actuel doit se renouveler afin de répondre aux nouveaux enjeux liés à la cybersécurité pour pouvoir lutter contre les menaces opportunistes (hacker isolé) et ciblées (cyber-mafia, gouvernement), plus complexes à détecter.

Dans ce contexte et face aux obligations légales, les SOC ont (et auront) un rôle très important à jouer nécessitant une expertise technique approfondie ainsi qu’une intégration avec la sécurité dans les projets.

Cet article Cybersécurité : l’heure du bilan pour les SOC 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.

 Quelle est la nature des annonces récentes dans le domaine du Big Data et de la sécurité ?

 Le buzzword « big data » a fait son entrée en force cette semaine dans le monde de la sécurité de l’information. Deux acteurs majeurs ont pris position sur le marché. D’un côté, RSA a annoncé son outil « Analytics ». Son objectif : détecter les fameux « signaux faibles » dans le volume des journaux de sécurité générés dans le système d’information. De l’autre, Cisco annonce le rachat de la société « Cognitive Security », une start-up tchèque spécialisée dans l’analyse analytique des mêmes journaux. Cisco envisage un rapprochement effectif au 3^ème trimestre de cette année et l’inclusion des technologies dans ces services cloud de sécurité.

Est-ce que cela représente une avancée significative pour la sécurité ? 

Dans un sens oui, l’adoption de ces technologies par de grands acteurs valide l’intérêt des méthodes statistiques afin de détecter des attaques ciblées. Nous savons qu’il y a une attente forte sur ce point. Les statistiques le montrent clairement, aujourd’hui il faut en moyenne 412 jours pour détecter une attaque ciblée. Plus frappant encore,cette détection provient dans 94% des cas  de tiers externes à l’entreprise (Rapport Mandiant 2012) tandis que les premières exfiltrations de données ont lieu 24h après le début de l’attaque ! Il y a donc clairement un problème à résoudre. D’ailleurs nous disposons de retours d’expérience positifs avec des outils existants déjà sur le marché. Je pense en particulier à la solution de la société française PicViz. Elle est déjà en place dans plusieurs sociétés où elle a permis des avancées significatives.

Comment une entreprise peut-elle tirer parti de ces innovations ?

Ces outils n’ont rien de magique, les acheter et les déployer ne résoudra pas tout. Ils vont requérir d’une part d’être alimentés par des données – les journaux de sécurité – et d’autre part de disposer de compétences pour analyser les résultats. Et ces deux points sont aujourd’hui des points faibles dans beaucoup d’entreprises ! En premier lieu, il faut augmenter le volume de journaux générés à tous les niveaux du SI pour pouvoir « nourrir » correctement l’outil. L’avantage, c’est que ces solutions, contrairement au SIEM (Security Information and Event Management) historique, font de l’analyse sans chercher des scénarios particuliers qu’il faut définir au préalable. Ils sont donc plus efficaces pour détecter les attaques ciblées.

Parallèlement, les équipes dédiées à l’analyse de ces journaux doivent être renforcées (en effectifs et en formations) afin d’être en mesure de comprendre les analyses et d’y réagir de manière appropriée. Notre expérience le montre, nous n’échappons pas aux faux positifs… L’externalisation d’une partie de l’équipe en charge  de  surveiller les SI est  une solution possible. De récents appels d’offres que nous avons conduits ont montré que les acteurs du marché se sont multipliés et qu’ils proposent de nouvelles solutions aux problèmes rencontrés au quotidien par les entreprises dans le domaine de la sécurité.

Cet article Outillage sécurité : la ruée vers le Big Data est en cours est apparu en premier sur RiskInsight.

Force est de constater que la sécurité n’est plus un frein à sa propre externalisation. Les principaux risques que craignaient les RSSI il y a encore quelques années peuvent désormais être maîtrisés.  À condition bien entendu de respecter quelques règles d’or acceptées par la plupart des fournisseurs : engagement de réversibilité, clauses d’audit, mécanismes de suivi des SLA et certifications des fournisseurs …

Le RSSI n’a que l’embarras du choix : il est aujourd’hui possible d’externaliser quasiment tous les services imaginables en termes de sécurité opérationnelle. Mais alors que doit-on externaliser, et pourquoi ?

Externaliser pour rationaliser

Depuis des années, les entreprises font appel aux MSSP (Managed Security Service Providers) pour gérer leurs infrastructures sécurité : management du parc de firewalls, surveillance des consoles anti-virus et des IDS…

Ces fournisseurs, tirant partie de leurs nombreux retours d’expérience, proposent aujourd’hui des offres totalement packagées et industrialisées. La mutualisation de leurs ressources et processus permet d’optimiser les coûts, à tel point qu’aujourd’hui les business case penchent quasi-systématiquement en faveur de l’externalisation !

Et l’industrialisation pourrait encore aller plus loin… avec le marché des SecAAS (Security-as-a-Service). Ces « nouveaux entrants » ne se limitent pas à la gestion des infrastructures, mais fournissent directement des mesures de protection dans le Cloud (filtrage web, messagerie sécurisée, authentification forte…). Leurs clients peuvent ainsi bénéficier de tous les avantages hérités du Cloud (mutualisation, optimisation, flexibilité…) tout en réduisant le coût de l’exploitation de leur infrastructure.

Externaliser pour mieux se protéger

Paradoxalement, l’externalisation peut même avoir comme objectif premier d’augmenter le niveau de sécurité… en tirant partie de la vision globale, inter-clients, des MSSP.

Il s’agit de confier à un MSSP la surveillance de l’infrastructure sécurité, qui lui-même dispose d’une vue sans pareille sur l’actualité du monde de la cybercriminalité. En effet, les grandes entreprises doivent désormais connaître les nouvelles menaces en temps réel et être en capacité de réagir en cas d’attaque. Une conséquence évidente de l’évolution des attaques constatée ces dernières années.

Les MSSP leaders du marché ont compris l’importance de ce changement et ont structuré leurs offres autour de leurs connaissances du monde de la cybercriminalité (affiliation aux réseaux de CERT, présence sur les forums underground, déploiement de réseaux de sondes dans le monde…).

La surveillance des infrastructures de leurs clients ne se limite plus à l’administration d’outils SIEM (Security Information and Events Management) : les filtres de surveillance sont mis à jour au fil de l’actualité, sans se limiter aux comportements définis préalablement avec leur client. De même, les activités historiques de veille et de tests de vulnérabilités sont largement complétées : les vulnérabilités des clients sont désormais analysées en connaissance des menaces réelles et la surveillance peut être adaptée tant que la vulnérabilité n’est pas corrigée.

La valeur ajoutée sécurité est évidente : les clients bénéficient d’une mise à jour constante de leur niveau de sécurité. Bien entendu, plus le nombre de clients du MSSP est élevé, plus le service devient pertinent. Il n’est donc pas surprenant que le marché soit aujourd’hui dominé par les grands fournisseurs anglo-saxons. Mais peut-être pas pour longtemps, ces derniers étant bousculés depuis quelques temps par les groupes Indiens qui tendent aujourd’hui vers des services performants avec des prix plus compétitifs.

Externaliser pour encore plus de valeur ajoutée

Les services proposés par les MSSP tendent à s’homogénéiser… voire même à se standardiser. Il est de plus en plus complexe de négocier des SLA particuliers, ou d’exiger des ressources spécifiques ou dédiées.

Cette approche mutualisée est très efficace tant que les services portent sur la sécurité des infrastructures, cependant elle est fortement limitée lorsqu’il s’agit de protéger les besoins métiers spécifiques. Le « sur-mesure » est indispensable pour lutter contre les menaces les plus avancées et pour protéger de manière fine les applications critiques de l’entreprise.

Aujourd’hui il n’existe pas d’acteurs majeurs capables de surveiller les applications ou de détecter les fuites d’information avec une vision métier. Peut-être ce marché est-il à la portée des MSSP français qui restent assez proches de leurs clients, avec des offres encore adaptables ?

Il est donc à la fois possible d’optimiser ses coûts et d’augmenter son niveau de sécurité en externalisant la sécurité des infrastructures. En revanche, sur le terrain de la sécurité applicative… les clients devront encore attendre ! Les fournisseurs externes sont en effet encore trop loin des enjeux métiers de leurs clients.

Cet article Externaliser la sécurité, oui mais dans quel objectif ? est apparu en premier sur RiskInsight.