Au sein des SOC européens, une révolution silencieuse est en cours. Face à des volumes d’événements toujours plus importants et une pénurie persistante d’experts, une nouvelle génération d’outils de sécurité, dopés à l’intelligence artificielle, émerge pour identifier des corrélations que les équipes humaines ne peuvent plus traiter seules. L’IA ne remplace pas les analystes, mais elle accélère et optimise leur travail. Entre les ambitions d’hyper-automatisation, les enjeux de transparence des modèles et la volonté croissante d’une souveraineté européenne, le paysage des solutions de détection et réponse à incident évolue à vitesse grand V. 

Pour accompagner au mieux la transformation du marché, l’Agence nationale de la sécurité des systèmes d’information (ANSSI) et le Centre de coordination cyber français (NCC-FR) hébergé par l’ANSSI ont lancé une initiative ambitieuse visant à capturer l’état de l’art du secteur, en menant une étude [1] structurée auprès des principaux acteurs européens spécialisés dans les solutions à destination des SOC

Les objectifs de l’étude étaient doubles : 

1. Recenser les acteurs européens développant des solutions destinées aux SOC intégrant des fonctionnalités basées sur l’IA [2].
2. Construire un panorama le plus exhaustif possible des cas d’usage proposés sur le marché, y compris par les principaux acteurs US présents en Europe. 

Cet article synthétise les enseignements clés tirés de notre étude menée auprès de 48 éditeurs de solutions de détection et de réponse.  

Répartition géographique des éditeurs rencontrés 

Un marché européen bouillonnant en cours de consolidation  

L’étude a porté sur 48 éditeurs. Parmi eux, 34 sont des éditeurs européens (sur un total de 72 acteurs européens initialement identifiés), tandis que les 14 restants sont des éditeurs US, solidement implantés en Europe.  

Le marché montre une consolidation tangible, marquée par de nombreux rachats, le plus souvent d’acteurs européens par des sociétés US. Ces acquisitions visent principalement à renforcer les capacités de détection et de réponse des solutions, à étendre la couverture de protection proposée ou, plus marginalement, à intégrer directement des briques d’IA dédiées à la détection. Les éditeurs convergent ainsi vers une logique de plateforme unifiée capable de répondre à l’ensemble des besoins d’un SOC. 

Certaines initiatives européennes, telles que l’alliance OPEN XDR, visent à proposer une réponse collective aux enjeux de plateformes, sans recourir à des stratégies de rachat entre acteurs. 

Les rencontres avec les éditeurs ont permis de dégager plusieurs constats majeurs. 

Tout d’abord, la GenAI, pour Generative AI (IA capable de générer du contenu original à partir d’instruction), fait son apparition dans les solutions SOC, principalement via des chatbots intégrés aux interfaces d’analyse; leurs fonctionnalités restent toutefois très limitées et hétérogènes. Ces chatbots reposent presque systématiquement sur des technologies externes, en particulier sur des LLMs fournis par un nombre restreint d’acteurs majeurs tels que OpenAI, Google, Meta, Anthropic ou encore Mistral AI, qui concentrent l’essentiel du marché. Cette dépendance à des solutions tierces, impliquant souvent un transfert de données vers les environnements de ces fournisseurs, soulève des questions importantes quant à la protection des données sensibles manipulées au sein des SOC.

Pour réduire cette dépendance, plusieurs éditeurs envisagent désormais d’adopter des LLM open source, déployables directement dans leurs propres environnements, afin de mieux maîtriser leurs données et garder leurs flux en interne. 

Panorama des LLM utilisés par les éditeurs EU rencontrés 

Ensuite, l’usage de la PredAI, pour Predictive AI (IA capable de prédire ou classifier un input grâce à des « connaissances » acquises lors d’une phase d’apprentissage), se révèle nettement plus avancé : certains éditeurs européens s’appuient sur ces approches depuis plus de 15 ans pour traiter des cas d’usage allant de la détection comportementale à la priorisation d’alertes, démontrant une réelle maturité et une expertise éprouvée. La grande majorité de ces usages reste toutefois concentrée sur la phase de détection, où les modèles prédictifs sont aujourd’hui les plus largement exploités, les mieux maîtrisés et les plus pertinents. 

Par ailleurs, plusieurs acteurs commencent à explorer les approches agentiques, avec l’ambition de déléguer progressivement une partie des tâches répétitives ou chronophages, notamment la qualification initiale des alertes et certaines étapes d’investigation.  

Enfin, ces observations doivent être abordées avec prudence : l’échantillon d’éditeurs rencontrés ne reflète qu’une partie du dynamisme technologique actuellement à l’œuvre sur le marché. 

Cartographie des acteurs européens proposant des solutions de détection et de réponse aux incidents intégrant l’IA 

Panorama des cas d’usage de l’IA dans les outils de détection et réponse à incident  

Panorama des cas d’usage de l’IA sur la chaine d’opérations d’un SOC 

L’étude a permis de recenser une cinquantaine de cas d’usage. Au sein des outils de détection et réponse à incident, une distinction claire apparaît entre deux grandes familles de cas d’usage : 

• les cas d’usage fondés sur des modèles de Predictive AI, principalement destinés à la détection d’incidents ; 
• et ceux basés sur la Generative AI, plutôt orientés vers les tâches d’investigation et de réponse à incident. 

Même si les cas d’usage sont nombreux et difficiles à lister de manière exhaustive, on peut néanmoins identifier plusieurs grands ensembles conçus pour répondre à des problématiques similaires et poursuivant le même objectif.  

Pour la détection d’incidents, l’IA est notamment utilisée pour :

• la détection de comportements anormaux d’utilisateurs ou d’assets ; 
• la détection d’anomalies dans le trafic réseau ; 
• la détection d’événements révélateurs d’une attaque ; 
• la détection de tentatives de phishing ; 
• et la détection de fichiers malveillants. 

Si ces ensembles répondent à un même objectif, un autre agrégat de cas d’usage emerge : celui où l’ensemble des usages est adressé par l’IA générative, notamment au travers de chatbot-assistants. Les éditeurs concentrent aujourd’hui une grande partie de leurs efforts sur ces assistants destinés aux analystes, dans lesquels ils intègrent progressivement plusieurs cas d’usage. Leur priorité consiste d’abord à faciliter l’accès à la documentation et à fournir des réponses aux questions opérationnelles, avant d’étendre ces capacités vers des tâches plus avancées de qualification ou d’investigation. 

Pour cela, presque tous adoptent la même approche : 

• l’exploitation d’un modèle tiers de fondation, 
• du prompt engineering pour exploiter au mieux les capacités du modèle en l’orientant vers des sujets précis 
• et l’usage du RAG (Retrieval Augmented Generation), qui personnalise et enrichit les recherches du modèle en lui fournissant une base documentaire prioritaire pour construire ses réponses. 

Enfin, même s’ils restent encore limités, des cas d’usage dits agentic, reposant sur des agents autonomes, commencent à émerger. Ils sont aujourd’hui proposés principalement par les acteurs les plus avancés et les plus matures du secteur, ou par des start-ups cherchant à bousculer le marché. 

Contrairement à la majorité des éditeurs qui intègrent progressivement des cas d’usage IA au sein d’une plateforme cyber existante, ces nouveaux entrants misent sur des solutions d’IA spécialisées, conçues pour répondre à une tâche cyber bien précise. Parmi ces cas d’usage, on trouve par exemple des agents dédiés au threat hunting, à l’analyse malware avancée (type reverse engineering automatisé), ou encore à la qualification initiale des alertes. 

Ces usages restent cependant peu déployés à ce jour.  

Pour aller plus loin…. 

L’ANSSI propose un rapport complet, reprenant tous les résultats de l’étude :  https://cyber.gouv.fr/enjeux-technologiques/intelligence-artificielle/etude-de-marche-lia-au-service-de-la-detection-et-de-la-reponse-a-incident/  

Ce document constitue désormais une référence pour comprendre les tendances, les évolutions futures du rôle de l’IA dans la détection et réponse à incident.  

En définitive, l’étude met en lumière un marché européen de la cybersécurité en pleine structuration, porté par l’essor de l’IA mais également marqué par une dynamique forte de consolidation. Dans ce paysage en mouvement, l’IA poursuit sa montée en maturité au sein des outils pour le SOC : des cas d’usage de détection fondés sur la PredAI, aux assistants analytiques basés sur la GenAI, jusqu’aux approches agentic encore émergentes mais prometteuses. Cette trajectoire confirme que l’automatisation intelligente deviendra un levier majeur pour gagner en efficacité opérationnelle et renforcer la capacité des organisations à se protéger des attaques de demain. 

Références 

[1] Étude réalisée d’octobre 2024 à juillet 2025 – https://cyber.gouv.fr/enjeux-technologiques/intelligence-artificielle/etude-de-marche-lia-au-service-de-la-detection-et-de-la-reponse-a-incident/  

[2] Fonctionnalités basées sur l’Intelligence artificielle :  Ensemble de fonctionnalités utilisant des modèles d’apprentissage automatique (ML, deep learning, LLM) capables d’apprendre à partir de données et de produire des analyses, prédictions ou contenus nouveaux. 

Cet article Intégration de l’IA dans les outils du SOC : Etat de l’art technologique et tendances actuelles sur le marché européen  est apparu en premier sur RiskInsight.

Bien que les principes fondamentaux d’identification des enjeux, des risques et des actions de remédiation demeurent, la méthode s’illustre par son appel à des scénarios d’attaque complexes tirant partie de vulnérabilités multiples, à la manière d’attaques réelles comme celle contre les systèmes de connexion à SWIFT de la Banque Centrale du Bangladesh en 2016 ou contre Sony Pictures en 2014… Autre évolution majeure, l’apparition d’une analyse approfondie des attaquants potentiels, de l’écosystème et des parties prenantes du périmètre étudié.

Ce changement de posture permet à EBIOS RM de répondre spécifiquement aux problématiques posées par des attaquants toujours plus professionnalisés qui étudieront méthodiquement les vulnérabilités d’une cible ainsi que l’ensemble de son écosystème pour parvenir à leurs fins. Elle vient ainsi remplir une zone de vide dans l’espace des méthodologies d’analyse de risques.

Néanmoins, malgré cette approche réellement innovante et comme nous allons l’étayer ci-dessous, EBIOS RM ne doit pas forcément être considérée comme la nouvelle démarche globale d’analyse des risques mais plutôt comme une nouvelle corde à l’arc méthodologique du RSSI pour traiter les scénarios d’attaque les plus complexes.

S’appuyant sur nos premiers retours d’expérience de l’application concrète de cette méthode, nous présenterons en détail les évolutions qu’elle apporte ainsi que leurs implications sur la gouvernance plus générale des risques SSI.

EBIOS RM, une nouvelle méthodologie pour mieux appréhender les risques complexes de cybersécurité

Depuis bientôt 10 ans, EBIOS 2010 propose une méthode centrée sur la notion de menaces unitaires tirant partie de vulnérabilités et de prévention de leurs impacts sur des processus métiers. Cette méthode, qui remettait à l’époque le métier au centre de l’analyse de risques, n’est cependant pas conçue pour identifier et traiter des menaces complexes. Ces menaces, composées de rebonds de l’attaquant d’une vulnérabilité à une autre pour atteindre ses fins, constituent pourtant aujourd’hui une part majeure de l’univers des risques SSI et ont été mises à l’ordre du jour de nombreux comités exécutifs à la suite des dernières attaques majeures comme NotPetya ou WannaCry.

EBIOS RM vise à compléter ce manque par une approche intégrant dans un premier temps de l’étude poussée des intentions des attaquants potentiels, puis la prise en compte formelle de l’écosystème et enfin l’identification de scénarios d’attaque complexes de type kill chain. L’objectif final de cette étude n’est plus l’alignement des mesures de sécurité à des failles unitaires comme pour EBIOS 2010 mais bien la capacité à maîtriser des risques aux facettes multiples.

En préalable, mener un travail préparatoire concernant les vulnérabilités

EBIOS RM propose dans un premier temps la mise place d’une étude structurée du niveau de sécurité du périmètre analysé par une revue de conformité. Cette vérification permet d’identifier un premier panel de vulnérabilités, comme le ferait un attaquant en testant par exemple la version des infrastructures ou les vulnérabilités de l’OWASP.

Contrairement à ce qui est proposé dans la méthode EBIOS 2010, la principale finalité de cette approche n’est pas de remédier à des vulnérabilités unitaires mais bien d’alimenter la définition des scénarios d’attaque complexes en identifiant les potentiels points de rebond de l’attaquant.

Ensuite, mieux prendre en compte l’écosystème et les sources d’attaque

Par ailleurs, afin d’adapter l’analyse des risques à la réalité des SI contemporains et de l’univers de menace, EBIOS RM intègre une innovation majeure sous la forme de la revue systématique de l’écosystème du périmètre étudié, depuis les tiers de confiance connectés à celui-ci jusqu’aux tiers présumés hostiles tels que des concurrents, des états voire des activistes.

L’étude des tiers de confiance met en lumière leurs interactions avec le périmètre étudié, trop souvent acquises comme sûres, qui constituent un vecteur d’attaque idéal pour un attaquant contournant ainsi les défenses périmétriques voire les mesures de gestion des accès internes.

L’étude des tiers hostiles place quant à elle la notion d’intentionnalité de la malveillance au cœur de l’étude. EBIOS RM propose donc de les identifier précisément et d’analyser les objectifs possiblement visés. Ce changement d’angle de vue sert de base au développement de scénarios d’attaque complexes dans la suite de la démarche.

Cette nouvelle approche vise notamment à faire face aux attaques par water-holing ou encore des conséquences de la compromission d’un SI tiers comme les fuites de données de l’enseigne américaine Target en 2013.

Enfin, un travail itératif de construction des scénarios d’attaque

Sur la base de cette connaissance approfondie du contexte, la démarche EBIOS RM vise à réaliser une étude préliminaire et plus fonctionnelle des évènements pouvant survenir sous la forme de scénarios stratégiques, puis un zoom plus technique sous la forme de scénarios opérationnels détaillés. L’objectif est que ces deux visions s’alimentent tout au long de l’étude dans une réflexion itérative.

EBIOS RM demande tout d’abord de définir de 3 à 5 scénarios stratégiques combinant source d’attaque, objectif visé et principaux moyens utilisés pour atteindre cet objectif. Cette vision de haut niveau et aux aspects techniques très limités, atout clef pour présenter les risques cyber aux métiers voire aux instances dirigeantes d’une organisation, permet également de préciser le périmètre de la réflexion plus technique qui sera réalisée au travers de 10 à 15 scénarios opérationnels.

Ces scénarios opérationnels racontent un fil détaillé d’évènements qui, combinés, mènent à un impact majeur. EBIOS RM structure ce cheminement au travers de quatre phases. Tout d’abord, la prise de connaissance par l’attaquant du SI ciblé, de son fonctionnement et de ses acteurs. Ensuite, la phase d’entrée dans ce SI au travers d’actions comme le phishing ou l’exploitation d’une backdoor. Puis vient la phase de recherche des données ou du SI critique que l’attaquant souhaite compromettre. Enfin, c’est la phase d’exploitation de cette cible via par exemple l’exfiltration de données ou l’implantation d’une bombe logique.

Chaque scénario d’attaque opérationnel aura donc sa propre histoire à raconter, sa propre kill chain, dont la vraisemblance sera déterminée. Cette spécificité est une des forces de l’étude, facilitant sa restitution, mais lui permettant également d’alimenter la réflexion d’un SOC concernant la définition de scénarios de corrélation à implémenter dans un SIEM.

Cette hauteur d’analyse en fait d’ailleurs un outil de choix pour l’étude des risques des périmètres les plus critiques d’une entreprise, comme par exemple les SI d’importance vitale.

Un outil ambitieux dont il faut cadrer l’utilisation

EBIOS RM présente des atouts séduisants par la prise en compte des motivations et méthodes des attaquants, de l’étude approfondie des tiers de confiance comme potentiels vecteurs d’attaque ou encore par sa capacité à produire des scénarios d’attaques complexes mais capables de convaincre des publics non-initiés.

L’une des principales qualités d’EBIOS RM, imposer réflexion et créativité pour définir les scénarios stratégiques et opérationnels pertinents, a néanmoins un revers notable : EBIOS RM ne pourra ainsi pas, exception faite de l’étude du socle et des acteurs menaçants, faire l’objet d’une industrialisation poussée des outils associés sans craindre une perte de créativité et donc une perte de qualité dans ses résultats. Cette logique s’écarte donc de celle en vigueur pour EBIOS 2010 qui rendait par exemple possible une revue exhaustive des menaces, permise par la complexité très souvent limitée de celles-ci.

En l’absence de cadre largement outillé et afin d’éviter que la subjectivité des participants n’y fasse son lit, EBIOS RM va ainsi exiger de son pilote un éventail de compétences qui reste rare sur le marché : des connaissances techniques pointues et orientées test d’intrusion pour déterminer ce que serait capable de réaliser un attaquant selon son niveau d’expertise, de la créativité, une capacité au story telling, à la synthèse et à la pédagogie, afin de définir des scénarios d’attaques qui auront à la fois suffisamment d’impact et de pertinence pour convaincre à la fois les équipes métiers et techniques tout en illustrant avec justesse et moins de quinze scénarios opérationnels toutes les facettes remarquables de la situation étudiée.

Ces différentes qualités renforceront par ailleurs la légitimité du pilote de l’étude, indispensable pour animer et recadrer efficacement les différents groupes de travail demandés par la méthodologie, afin d’éviter les discussions sans fin qu’elle peut risquer d’entraîner par ses aspects subjectifs. Il faut en outre garder à l’esprit que par son aspect itératif et les nombreux groupes de travail qu’elle implique, EBIOS RM sera une démarche significativement plus coûteuse en temps qu’EBIOS 2010. De plus, ses résultats seront difficilement réutilisables d’une étude à l’autre, en cela qu’elle se concentre justement sur les spécificités des périmètres étudiés.

Les sources accidentelles écartées

Dernier point d’attention, EBIOS RM, en plaçant l’intentionnalité au cœur de sa démarche, écarte les sources accidentelles. Pourtant, celles-ci se produisent régulièrement, qu’il s’agisse d’un coup de pelleteuse, d’une corruption d’une base de données ou de l’erreur d’un administrateur. Par ailleurs, le cœur de la démarche EBIOS RM, en générant un nombre limité de scénarios opérationnels, ne vise pas à l’exhaustivité qui était une des forces d’EBIOS 2010. La réponse de la démarche à ce biais méthodologique est l’étape d’étude du socle, mais celle-ci n’est qu’une revue de conformité. Si on imagine appliquer la démarche à un périmètre existant présentant de nombreux axes d’améliorations et qu’on utilise un référentiel de conformité suffisamment exhaustif (les 42 règles de l’ANSSI ou ISO27002), on pourra se retrouver avec une liste à la Prévert des mesures correctives à mettre en œuvre, sans moyen rigoureux de les prioriser, sauf à faire appel à EBIOS 2010 qu’EBIOS RM visait à remplacer…

Vers une refonte de la gouvernance de la gestion des risques

EBIOS RM est donc une démarche qui nécessite un temps de mise en œuvre certain ainsi que des expertises à la disponibilité souvent déjà limitée, et dont les résultats seront difficiles à réutiliser. En tenant également compte de ses priorités méthodologiques, nous pensons préférable de concentrer l’application de cette démarche aux systèmes présentant des enjeux forts et dont le niveau de sécurité a déjà un certain niveau de maturité, par exemple parce qu’ils seront passés par l’étape EBIOS 2010. Il nous semble également préférable d’utiliser EBIOS RM pour des ensembles cohérents de SI (exemple : une voiture ou les activités marketing) afin de conserver un périmètre d’étude suffisamment important pour permettre des attaques avancées. Enfin, sur des ensembles cohérents de SI appartenant à des acteurs différents, il est possible d’appliquer la méthode jusqu’aux scénarios stratégiques afin de fixer des priorités d’étude pour les analyse de risques plus détaillées qui seront mises en œuvre par chaque entité sur ses périmètres propres. EBIOS RM sera dans ces cas d’autant plus pertinente qu’elle se concentrera uniquement sur des scénarios au plus proche des pratiques métiers.

EBIOS RM, une brique dans l’offre de services d’analyse de risque

L’arrivée d’EBIOS RM, démarche novatrice quoique à utiliser avec mesure, et qui finalement complète plus qu’elle ne remplace EBIOS 2010, participe donc à créer ce qu’on pourrait appeler une offre de service EBIOS. Les ressources et les compétences nombreuses qu’elle nécessite pour être mise en œuvre la réserveront ainsi à des périmètres spécifiques, fortement exposés ou porteurs d’enjeux majeurs comme par exemples les SI d’importance vitale, ayant déjà fait l’objet d’un socle de mesures d’hygiène SSI.

Tout ceci plaide en faveur de la mise en œuvre, en amont des projets, d’une démarche de gouvernance des risques, transverse à l’entité, qui permettra de déterminer rapidement les enjeux, l’exposition et la maturité sécurité de ses périmètres fonctionnels et applicatifs, puis de décider en fonction quelle méthodologie de sécurisation mettre en place : simple revue de conformité à un socle minimal de règles de sécurité, étude EBIOS 2010 plus ou moins approfondie ou enfin, sur les périmètres à la fois sensibles et matures, étude EBIOS RM.

Cet article EBIOS (2010) est mort, vive EBIOS (RM) ? est apparu en premier sur RiskInsight.

Affirmation des grandes orientations sécurité, précisions importantes et nouvelles préconisations : cet article propose une synthèse objective des changements apportés dans cette récente version, afin d’en faciliter l’appropriation par les acteurs du SI et de sa sécurité, et guider de potentielles évolutions dans la pratique de l’administration.

Une nouvelle version reposant sur les retours terrains

L’administration d’un SI est, en raison des missions qui lui sont associées (installation et paramétrage des systèmes, mises à jour, supervision…) et des capacités qu’elle délivre à ses exécutants (capacités d’action étendues sur les biens, accès direct aux données sensibles…), une composante fondamentale de la stratégie de sécurisation d’un système.

Un premier guide sur le sujet fut diffusé par l’ANSSI en 2015, et a servi de cadre de référence pour des entreprises et administrations afin d’appuyer leurs chantiers de mise en conformité, par exemple dans le cadre des homologations de sécurité de leur système. Depuis, l’ANSSI a échangé avec les différents acteurs du monde du SI et de sa sécurité, bénéficié de retours d’expérience concernant l’interprétation et l’adoption de ce guide et constaté sur le terrain (à travers audits, entretiens et études documentaires notamment) son implémentation effective.

Si elle ne bouleverse pas la ligne directrice, cette nouvelle version apporte de nombreuses clarifications et précisions d’importance sur les orientations fondamentales de l’ANSSI et couvre certains non-dits, le tout dans une approche plus didactique et claire permettant une meilleure appropriation par les publics visés : les sections sont réorganisées, parfois épurées, et souvent accompagnées de schémas de principe facilitant la compréhension concrète des attendus. Elle propose également quelques compléments sur l’état de l’art et la maturité de certaines solutions spécifiques.

Des orientations fondamentales confirmées

Au global, les niveaux d’exigence sont conformes à ceux de la première version et les objectifs fondamentaux y sont confirmés : maximiser la protection du SI d’administration et la protection du SI administré en cas de compromission du SI d’administration, suivant le principe régulièrement mis en exergue de « défense en profondeur ».

Entre autres, l’ANSSI réaffirme la nécessité :

• D’employer des postes dédiés à l’administration (ou, si une dégradation importante du niveau de sécurité peut être accepté, des contextes dédiés sur un même support physique), durcis, cloisonnés de tout autre système, et dont le disque est chiffré (R9-R14)
• De privilégier le principe de précaution prévalant en matière de virtualisation. La complexité des solutions de virtualisation et la difficulté à évaluer ou maîtriser leurs mécanismes de cloisonnement engendrent des réserves importantes sur leur utilisation en contexte sensible (R7)
• D’une authentification forte, ne se limitant pas à un simple mot de passe, de comptes dédiés pour les administrateurs et de l’application stricte du principe de moindre privilège pour leurs activités (R27, R29, R36, R39)
• D’un Maintien en Conditions de Sécurité (MCS) / Patch management rigoureux sur tous les systèmes, et tout particulièrement sur les composants d’administration (R42)
• D’un chiffrement de l’intégralité des flux d’administration, selon les recommandations du RGS (R24).

Des précisions importantes apportées

Plus que des nouvelles mesures, l’ANSSI détaille plusieurs d’entre elles pour éviter les erreurs d’interprétation et assurer une mise en phase avec l’état de l’art :

• La réalisation d’une analyse de risques et sa révision régulière sont recommandées dès le début du guide (R4), preuve supplémentaire que celui-ci est construit dans une approche plus globale de la SSI
• La notion de zones de confiance est définie très explicitement, et la relation par défaut « une zone de confiance métier = une zone d’administration dédiée » est avancée sans ambiguïté (R5, R22)
• Si le cloisonnement SI métier / SI d’administration apparaissait déjà dans la première version, le nouveau guide insiste à de nombreuses reprises, schémas à l’appui, sur toutes les dimensions à prendre en compte, certaines étant potentiellement négligées : réseau physique, infrastructures serveur et stockage et leurs interfaces physiques, annuaires…doivent être dédiés au réseau d’administration (R15, R18, R19, R28, R29). Aucune mutualisation ne peut être mise en œuvre.
• Les outils d’administration installés localement sur les postes sont à éviter, en ce qu’ils diminuent potentiellement leur maîtrise (R22)
• L’utilisation de produits qualifiés par l’ANSSI fait l’objet d’un rappel important : pour chacun, il est nécessaire de prendre garde à la version de produit qualifiée, et à la cible de sécurité définie lors de cette démarche, possiblement en déphasage avec l’usage réalisé (R6)
• Les pratiques liées au nomadisme sont l’objet d’une position plus appuyée, insistant sur l’importance de maîtriser entièrement les postes concernés (R48 à R50). De plus, la notion d’évaluation du « niveau de confiance » des différentes populations d’administration est explicitement avancée dans ce cadre (R51), généralisant la distinction internes/prestataires du précédent guide.
• Considérant le besoin de connexion du poste d’administration vers le poste bureautique, l’ANSSI émet un avis relatif aux logiciels de connexion répondant à cet usage : aujourd’hui, aucun produit du marché ne répond aux exigences de sécurité associées, et ne peut être considéré « de confiance » (section 4.2)
• De la même façon, l’ANSSI exprime des réticences quant aux solutions désignées comme « bastions » par différents éditeurs aujourd’hui, et qui n’offrent a priori pas de gages de sécurité suffisants, ou mènent à des usages non conformes aux profils de sécurité qu’ils sont en mesure de fournir (section 12.1). L’usage de simples « rebonds » peut alors être à privilégier.

La place plus importante et appuyée de ces mesures montre l’importance qu’elles revêtent aujourd’hui aux yeux de l’ANSSI, et indique que d’importants efforts peuvent encore être nécessaires pour leur adoption sur de nombreux systèmes.

Quelques « nouveautés », prévenant les écueils parfois rencontrés

S’il n’apporte pas de changement majeur, ce nouvel opus apporte quelques nouveautés sur des points précis. Certaines relèvent de l’explicitation de mesures qui n’étaient pas clairement exposées dans le guide précédent :

• La restriction, pour l’administration du SI, à l’utilisation d’équipements entièrement maîtrisés (R8), excluant les dispositifs personnels (BYOD)
• L’importance de disposer de documentation et cartographie exhaustives des systèmes (R3), bien que le rôle des administrateurs dans sa constitution et son maintien ne soit pas précisé.
• La nécessité de changer les mots de passe par défaut des équipements (R34)
• Le besoin de sauvegarder, au même titre que sur le périmètre métier, les données et composants du SI d’administration, et de réaliser des tests de restauration (R45)
• La notion « d’administration du SI d’administration » à prendre en compte, avec des standards à minima aussi exigeants, comprenant notamment des postes et serveurs dédiés (section 12.4)

D’autres préconisations nouvelles reposent sur un socle déjà présent dans la première version du guide, mais font l’objet de compléments importants, menant potentiellement à de nouveaux chantiers :

• L’importance de la gestion des habilitations spécifique des administrateurs est rappelée, et l’utilisation de groupes et de référentiels d’habilitations est désormais clairement recommandée (R40), afin d’apporter clarification et allègement considérable de ce processus
• Les comptes, s’ils doivent être dédiés à l’administration, doivent également être distincts entre les différents domaines techniques (section 7.1)
• Le rôle des administrateurs fait toujours d’eux des plaques tournantes de la sécurité des SI, mais le guide indique désormais que « pour toute question relative à la sécurité des systèmes d’information (SSI), un administrateur doit pouvoir s’adresser à des référents internes de l’entité » (section 2.2). Dans la précédente version, ce soutien à l’administrateur n’apparaissait pas et pouvait le laisser apparaître comme seul responsable de la sécurisation
• Des moyens d’échanges (mail, messagerie instantanée…) entre administrateurs au sein même du SI d’administration sont recommandés (R53), afin d’éviter les contournements et fuites de données potentielles parfois envisagés lorsque ces fonctionnalités sont absentes : passage par un serveur non prévu à cet effet ou, pire, détour par l’environnement bureautique

Enfin, un seul point discuté dans la première version disparaît : Le dispositif de diode n’est plus évoqué, au profit d’un système d’échanges hors SI d’administration répondant mieux aux besoins fonctionnels de l’administration, en ce qu’il permet des échanges bidirectionnels, et assurant un certain niveau de sécurité (au niveau réseau et logiciel, et non plus matériel).

Les mesures de sécurité associées restent cependant pertinentes dans certains contextes, où des risques spécifiques doivent être couverts.

Une mise à jour bienvenue

Sans provoquer de changement fondamental sur les principes de l’administration sécurisée, ce guide oriente bien plus clairement les acteurs concernés du SI. La précision de la pensée de l’ANSSI sur de tels sujets est en particulier primordiale pour les entreprises et administrations gestionnaires de systèmes sensibles : les principes exposés guideront une partie importante des interactions avec ces entités, et in fine les décisions d’homologation.

En plein compte-à-rebours règlementaire, notamment en ce qui concerne les OIV et la LPM, la diffusion de ce nouveau guide est l’occasion de conforter son interprétation des recommandations et les orientations prises pour la sécurité de chaque SI, ou à défaut de (re)considérer des chantiers fondamentaux non encore menés et répondre au contexte sécurité actuel.

Cet article Administration sécurisée : que dit le nouveau guide ANSSI ? est apparu en premier sur RiskInsight.

Dans le contexte de la Loi de Programmation Militaire (LPM), l’homologation est une procédure obligatoire qui s’applique aux Opérateurs d’Importance Vitale (OIV). Elle permet de maîtriser les enjeux et le niveau de sécurité de chaque Système d’Information d’Importance Vitale (SIIV).

L’homologation est au cœur de la stratégie de mise en conformité LPM, car elle permet de décliner de manière concrète et opérationnelle les règles de la LPM tout en réduisant les risques de sécurité.

L’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI) a décrit dans un guide les grandes étapes de l’homologation. Ainsi les étapes majeures d’une homologation sont :

• La définition de la stratégie d’homologation (document de cadrage décrivant les détails de réalisation de l’homologation)
• La réalisation d’une analyse de risques sur le SIIV
• La conduite d’un audit d’homologation
• La décision d’homologation
• Le suivi a posteriori de l’homologation

Cette décision doit être prise par l’autorité d’homologation (AH), personne morale portant la responsabilité de l’homologation pour un SIIV. Elle est aidée par la commission d’homologation, groupe d’experts internes chargé de préparer la décision d’homologation.

Les informations nécessaires à la prise de décision sont regroupées dans le dossier d’homologation. Cela permet à la commission d’homologation d’attester la connaissance du niveau de sécurité et d’accepter les risques résiduels. In fine, la commission d’homologation atteste que le niveau de risque est maîtrisé.

Une démarche à éprouver au plus vite sur les SIIV existants

Rétro-homologation : comment homologuer les SIIV déjà en service ?

Dans le cadre d’un SIIV déjà existant, le paradigme de l’homologation est différent, même si les objectifs restent les mêmes. L’analyse de l’existant constitue le point de départ de l’homologation, et la réalisation d’un audit à blanc (ou l’utilisation d’un rapport d’audit précédent) sert d’accélérateur dans la collecte d’information et dans l’identification des risques.

A l’inverse, les mesures de sécurité devront être appliquées sur un historique parfois lourd à transformer. Des mesures compensatoires doivent dès lors être identifiées, priorisées et mises en œuvre

Cette homologation a posteriori, ou rétro-homologation, doit permettre au métier d’assurer une prise en compte exhaustive des risques, et de prioriser les actions pour réduire les risques à un niveau acceptable, en mobilisant les budgets adéquats.

Même s’il est important de définir une procédure d’homologation en capacité de traiter les nouveaux SIIV à venir, ce sont surtout les SIIV existants qui occupent les OIV à l’heure actuelle, et la rétro-homologation est prioritaire.

Adopter une approche projet test & learn

Afin de définir et déployer une procédure d’homologation sur son périmètre LPM, l’OIV peut définir un pilote initial, pour roder et perfectionner le processus, avant de l’industrialiser sur l’ensemble des SIIV.

L’objectif de cette phase pilote est de confronter la méthodologie à la réalité terrain, dans une optique de validation de la démarche et des étapes définies (procédures, interlocuteurs à solliciter, etc.). Cette approche fait ressortir les points de difficultés (SI d’administration, cloisonnement, patch management, …), et permet d’apporter un plan de remédiation concret et réalisable.

Le choix du SIIV pilote est primordial pour pouvoir anticiper les problématiques qui vont être rencontrées. Ainsi, il est préférable de choisir un SIIV pilote représentatif de l’ensemble des autres SIIV (taille moyenne, interactions limitées, etc.).

Démontrer la sécurité apportée par la LPM

Au sein des différents chantiers et projets engendrés par la LPM, celui de l’homologation permet de concrétiser le renforcement effectif de la sécurité. Non seulement en mettant en visibilité la sécurité de manière interne à un haut niveau (DG, autorité d’homologation) et de manière externe (ANSSI, État), mais également en mesurant la réduction des risques exigée (analyse de risques) et réalisée (audit).

La réalisation de l’homologation permet de communiquer sur les risques réels, d’identifier, de sensibiliser et de responsabiliser les acteurs concernés (en particulier la Direction au travers du rôle de l’autorité d’homologation).

L’ensemble des actions de mise en conformité LPM est regroupé dans le dossier d’homologation, et porte une réalité pratique. On y retrouve notamment les constats de sécurité, les points bloquants et un aperçu du degré de complexité de la mise en conformité.

Le dossier d’homologation doit être à la disposition de l’ANSSI. À ce titre, il constitue la vitrine de l’OIV vis-à-vis de la l’ANSSI pour la LPM, et gagne à ne pas être bâclé ! Il doit démontrer les acquis de sécurité et la validation concrète des réponses théoriques de mise en conformité.

Assurer le maintien de la sécurité dans le temps

Créer une dynamique d’homologation

Une homologation ne s’arrête pas lorsque la décision d’homologation est prononcée et le système mis en production. Cette étape ne marque que le commencement du management des risques. Il s’agit par la suite d’animer, de mettre en visibilité et d’assurer un contrôle permanent de la sécurité. L’arrêté précise que l’homologation doit être renouvelée au minimum tous les 3 ans, où lors d’évolutions majeures sur le SIIV, qui remettent en cause le contexte sécurité du SIIV tel que décrit dans l’analyse de risques.

Pour les SIIV existants, il est donc nécessaire de mettre en place un processus pour contrôler et détecter les évolutions du contexte de sécurité du SIIV. Cela doit notamment s’appuyer sur une organisation, par exemple avec un acteur en charge de détecter et d’évaluer ces évolutions de contexte. Il peut notamment établir une liste d’événements déclencheurs (par exemple : changement d’exposition du SIIV, arrivée de prestataires, évolution fonctionnelle du SIIV, modification d’infrastructure ou de gestion opérationnelle) qui servira de base à l’évaluation du besoin de renouvellement.

La mise en place du comité de gouvernance de l’homologation permet d’assurer une animation du processus d’homologation. La mise à jour de la méthodologie d’Intégration de la Sécurité dans les Projets permet de capter les nouveaux projets, d’y appliquer le management des risques dès le début du projet et d’anticiper la mise en conformité d’un SIIV.

Poser un cadre clair et compréhensible pour les propriétaires applicatifs

Les propriétaires applicatifs représentent des acteurs clés dans le maintien de la sécurité et de l’homologation dans le temps. Non seulement car ils possèdent une bonne vision de leur SIIV, mais également car ils en perçoivent les évolutions. S’ils ont « peur » de la LPM, cela peut amener à une mauvaise implémentation de la sécurité. Au contraire, une bonne compréhension des enjeux de la LPM, de l’homologation et de l’amélioration continue est bénéfique pour la sécurité du SIIV.

Il est recommandé de prêter une attention particulière sur l’accompagnement et la sensibilisation des propriétaires applicatifs à la sécurité en général, et à l’homologation en particulier. Dans une démarche gagnant-gagnant, il faut embarquer et fédérer les propriétaires applicatifs pour bonifier la sécurité dans le temps.

L’homologation de sécurité, une démarche permettant d’approfondir la maîtrise des risques dans la durée

Au-delà de la contrainte réglementaire pure, la LPM doit être considérée comme un formidable accélérateur permettant d’approfondir la maitrise des risques au sein de l’Opérateur d’Importance Vitale, depuis les équipes opérationnelles, les propriétaires applicatifs et jusqu’à la Direction.

Après une première étape de mise à niveau et de mesures de réduction des risques sur les SIIV existants, l’enjeu de l’homologation est d’assurer le maintien dans le temps du niveau de sécurité sur le périmètre des SIIV. A ce titre, il est nécessaire d’animer dans le temps les différentes instances, afin de conserver la dynamique initiale.

Cet article L’homologation de sécurité, clé de voute de la mise en conformité LPM est apparu en premier sur RiskInsight.

En particulier, le chapitre IV de la LPM donne plus de pouvoirs au Premier ministre et à l’ANSSI en matière de sécurité et de défense des systèmes d’information. Ce texte responsabilise pour la première fois les OIV quant à la sécurisation de leurs systèmes d’information d’importance vitale (SIIV).

Depuis mi-2016, les OIV se voient préciser secteur par secteur ce que l’État attend officiellement d’eux, via la publication d’arrêtés sectoriels. Les secteurs « produits de santé », « gestion de l’eau » et « alimentation » ont ainsi ouvert le bal le 23 juin dernier pour une entrée en vigueur le 1er juillet 2016, suivis le 11 août par le « transport terrestre », le « transport maritime et fluvial », le « transport aérien », l’ « énergie électrique », le « gaz naturel » et les « hydrocarbures pétroliers », pour une entrée en vigueur au 1er octobre. Le 28 novembre 2016, les secteurs « finances », « industrie », « communications électroniques » et « audiovisuel et information »ont clôturé l’année pour une entrée en vigueur au 1er janvier 2017. En six mois 13 arrêtés ont décliné la LPM, ne laissant plus que quelques secteurs et sous-secteurs à couvrir dans les mois à venir.

Cet article vise, en respectant le secret de la défense nationale, à partager nos retours d’expérience liés aux projets de mise en conformité qui ont marqué l’actualité ces derniers mois.

Cinq idées clés pour une mise en conformité à la LPM réussie

L’entrée en application de la LPM mène nécessairement à un investissement conséquent de la part des OIV, ne serait-ce que pour décliner la notion de SIIV sur leur périmètre, démontrer leur conformité à chacune des règles et aligner leurs processus et corpus documentaire sur le formalisme imposé par la LPM.

De par ses relations privilégiées avec l’ANSSI et son rôle sur la SSI au sein de son entreprise, le RSSI est l’acteur légitime pour piloter et animer cette mise en conformité. De la mobilisation des acteurs à la généralisation des principes de sécurité, en passant par le cadencement des chantiers et la construction de cibles acceptées par tous, quels sont les facteurs clés de réussite ?

1. Par où commencer ? Dresser la liste des SIIV

Tous les OIV doivent déclarer leurs SIIV à l’ANSSI dans un délai de 3 mois à compter de l’entrée en vigueur de l’arrêté les concernant. Il est important de noter que les exigences portent uniquement sur les SIIV, et non sur l’ensemble du SI de l’OIV. L’identification des SIIV doit par conséquent être un chantier réalisé avec le plus grand soin pour être conforme à la loi tout en limitant les impacts au maximum.

Au-delà des typologies de SI éligibles (proposées en annexe III de chaque arrêté), l’analyse doit partir des missions d’importance vitale (MIV) confiées par l’État à l’OIV. Elles sont listées dans les Directives Nationales de Sécurité (DNS), en possession de l’Officier de Sécurité de l’OIV puisque c’est un document classifié Confidentiel Défense. Des rencontres avec les métiers permettront ensuite d’affiner la compréhension des processus et de leur transcription sur le SI en termes d’applications.

L’enjeu est ici de définir une méthode systématique et une justification rigoureuse sur les critères d’inclusion et d’exclusion des applications potentiellement éligibles.

D’autre part, nos retours d’expérience sur l’identification des SIIV montrent que la logique « d’importance vitale » diffère entre une vision de l’entreprise (qui vise à assurer sa propre survie) et celle de l’État (qui vise à assurer la sécurité des citoyens). Concrètement, les systèmes commerciaux assurant les ventes ou la facturation, ne sont souvent pas répertoriés dans la liste des SIIV.

Les applications d’importance vitale représentent aujourd’hui au maximum 3% du parc applicatif de nos clients grands comptes sur le volet SI de gestion. Les SIIV sont quant à eux constitués de l’ensemble des applications concourant à un même processus d’importance vitale.

2. Recenser les écarts et dessiner des premières cibles

L’analyse d’écart doit elle aussi débuter au plus vite, sans attendre la stabilisation de la liste des SIIV.

Certes des subtilités techniques seront présentes, mais des tendances devraient rapidement apparaître sur les nombreux thèmes transverses tels que la supervision SSI, les cartographies, les principes d’authentification voire la gestion des correctifs de sécurité. Cela, en particulier sur les SI industriels, n’est pas sans poser des interrogations assez importantes.

Ici, l’enjeu est double : anticiper le macro-budget qui sera nécessaire à la mise en conformité et l’inscrire dans l’exercice de prévision budgétaire pluriannuel. Expliquer la LPM aux futurs porteurs d’actions et les mobiliser autour de l’identification de cibles qui pourraient répondre aux différentes exigences.

Il est crucial de ne pas traiter la mise en conformité règle par règle : selon les cas, certaines cibles d’apparence plus complexe permettent de couvrir plusieurs règles à la fois, diminuant ainsi l’investissement nécessaire au global. Ce constat est d’autant plus fort sur la protection des systèmes, où les principes de cloisonnement, les pratiques d’administration et les mécanismes d’authentification sont très liés.

3. Favoriser la pratique à la théorie

Les situations où il est difficile de faire converger les différentes approches sont légions dans ce type de programme. Aussi, le passage à la pratique est souvent le meilleur des alliés :

• La réalisation d’un audit à blanc technique et organisationnel permettra d’obtenir des réponses factuelles et détaillées et ainsi de débloquer les éventuelles analyses d’écart fastidieuses ;
• De même, la réalisation d’une homologation sur un SIIV pilote permettra à la fois de préciser le processus d’homologation et le contenu du dossier et fluidifiera d’autant les autres homologations ;
• Enfin, la mise en œuvre sur un SIIV pilote des principes de sécurisation retenus permettra de concrétiser les modalités d’implémentation spécifiques et transverses et d’affiner les modèles initialement retenus, avant généralisation. Il permettra en particulier d’identifier précisément les besoins relatifs aux systèmes transverses (administration, surveillance, contrôle d’accès…).

4. Paralléliser les chantiers

Les délais associés aux différentes règles sont très ambitieux. Aussi, il est indispensable de traiter en parallèle tous les sujets qui peuvent l’être.

C’est notamment le cas de la formalisation des guides de durcissement, des évolutions de la PSSI, des processus d’intégration de la sécurité dans les projets, des modifications au niveau des clauses contractuelles et des processus de sélection des fournisseurs, etc.

5. Tirer parti de la complémentarité des équipes

La LPM aborde le sujet de la cybersécurité au travers d’une loi et en l’inscrivant dans le dispositif SAIV. Les interlocuteurs sont donc tout aussi nombreux que variés : les dirigeants dans la mesure où la responsabilité pénale de l’OIV est engagée, les responsables de la sûreté garants du bon maintien du dispositif SAIV, les RSSI interlocuteurs habituels de l’ANSSI, les responsables de la conformité, les métiers en regard des missions d’importances vitales qu’ils peuvent porter, les DSI au vu des impacts potentiels sur le SI, les achats sur la gestion des fournisseurs, les équipes techniques opérant le SI au quotidien, etc.

Face à cette multitude d’interlocuteurs et d’approches parfois radicalement opposées, il est impératif de voir au-delà de la complexité apparente : cette situation est surtout l’occasion de mobiliser un nombre inédit d’acteurs autour de la cybersécurité et d’ainsi actionner des leviers jusque-là souvent inaccessibles. Il est notamment plus facile d’obtenir les ressources nécessaires à la bonne réussite du programme lorsqu’autant d’enjeux sont réunis.

Un paysage cybersécurité modelé en profondeur

Les cadrages menés jusqu’à présent par les OIV démontrent une forte volonté de prendre en compte la LPM le plus en amont possible, avec au sein des grands comptes que nous accompagnons, plusieurs dizaines de millions d’euros budgétés pour les années à venir.

Par ailleurs, la LPM a démontré l’intérêt de la cybersécurité à des décideurs historiquement peu mobilisés sur ce sujet, que ce soit au sein des OIV ou de leurs fournisseurs. Gageons que cette prise de conscience annonce une sécurisation pérenne des SIIV et des SI plus largement.

Un autre aspect structurant et positif de la LPM est à noter : afin de répondre aux besoins des OIV, le marché est incité à se structurer autour des thématiques cybersécurité. Il sera donc plus facile, pour les OIV mais aussi les autres entreprises d’avoir recours à des fournisseurs respectant les bonnes pratiques de sécurité.

Dans tous les cas, l’enjeu à venir pour les OIV est de ne surtout pas réduire la cybersécurité aux programmes LPM mais bien au contraire de les utiliser comme accélérateur pour leurs autres projets, sous peine de délaisser leurs SI critiques non considérés comme vitaux pour la survie de la nation (et ils sont nombreux). Cet équilibre est crucial pour assurer une cybersécurité servant à la fois l’État mais aussi les entreprises concernées.

Consultez notre synthèse LPM via le site officiel du cabinet, www.wavestone.com.

Cet article Réussir sa mise en conformité à la loi de programmation militaire est apparu en premier sur RiskInsight.

Clés de voute du cadre règlementaire posé en décembre 2013, que faut-il retenir de ces arrêtés émis par le Premier ministre, en coordination avec les ministères concernés et l’ANSSI ?

Des arrêtés très similaires et sans surprise

Ces arrêtés ne réservent aucune surprise à quiconque a participé aux réflexions sur la LPM ces derniers mois : planning, structure, règles, tout y est. Par ailleurs, c’est désormais officiel, le contenu des arrêtés est quasiment identique d’un secteur à l’autre.

Dès l’entrée en vigueur des arrêtés, tous les OIV seront tenus de déclarer à l’ANSSI leurs incidents de sécurité[1].

Dans un délai de 3 mois à compter de l’entrée en vigueur des arrêtés, tous les OIV devront déclarer leur SIIV à l’ANSSI[2] et communiquer les coordonnées de leur service de permanence SSI.

Enfin, tout OIV devra être conforme à 20 règles de sécurité, selon des délais variables d’une règle à l’autre et d’un secteur à l’autre. Ces règles sont les mêmes pour tous les secteurs à deux exceptions près, concernant les modalités d’accès à distance aux SIIV (authentification simple autorisée pour le sous-secteur des produits de santé et le secteur de l’alimentation) et la supervision SSI (pas de supervision obligatoire des systèmes assurant la sécurité physique et la gestion technique des bâtiments des point d’importance vitale pour le sous-secteur produits de santé).

Si les 20 règles détaillées en Annexe I de chaque arrêté sont publiques, ce n’est pas le cas des Annexes II, III et IV, marquées Diffusion Restreinte et notifiées par l’ANSSI aux seules personnes ayant besoin d’en connaître. Ces annexes précisent respectivement les délais dans lesquels les opérateurs sont tenus d’appliquer les règles de sécurité, les types de système d’information potentiellement SIIV, et les types d’incidents de sécurité à notifier à l’ANSSI.

20 règles pour promouvoir les bonnes pratiques et référentiels ANSSI

Les 20 règles couvertes par les arrêtés peuvent être regroupées de la manière suivante :

• Gouvernance (règles 1 et 20) : être doté d’une Politique de Sécurité du SI (PSSI) intégrant la notion de SIIV et posant notamment des exigences en termes de sensibilisation, de formation et de reporting à la Direction de l’OIV. Certains indicateurs SSI doivent également être générés (suivi des comptes, patch management, etc.).Ce volet correspond généralement à un chantier mineur de mise à jour du corpus documentaire et des processus déjà existants.

• Maîtrise des risques (règle 2) : l’OIV doit mener une homologation formelle de chacun de ses SIIV, afin d’identifier les risques portés et les mesures de sécurité à mettre en œuvre. La décision d’homologation est prise par une commission interne à l’OIV, en capacité de représenter l’OIV sur le plan pénal. Tout acte d’homologation sera précédé d’un audit SSI.Concrètement, les OIV doivent prévoir un audit d’homologation par SIIV, qui sera réalisé conformément au référentiel PASSI LPM[3], soit par un prestataire qualifié soit par une équipe interne de l’OIV. Le renouvellement de l’homologation est à prévoir à minima tous les 3 ans, pour prendre en compte l’évolution du contexte et des menaces.

• Maîtrise des SI (règles 3 et 4) : il est attendu de l’OIV qu’il connaisse à tout moment les composants constituant chacun de ses SIIV (cartographies à disposition de l’ANSSI sur demande) et qu’il sache y déployer tous les correctifs de sécurité nécessaires ou mettre en œuvre des mesures compensatoires appropriées.Si des inventaires et processus de veille et patch management sont déjà en place, l’enjeu est ici de les décliner concrètement sur chacun des SIIV fraîchement identifiés et surtout de s’assurer de leur pertinence et efficacité dans le temps.

• Gestion des incidents de sécurité (règles 5 à 10) : au niveau de la détection des incidents, les journaux d’événements clés doivent être activés, centralisés et archivés, puis corrélés et analysés sur une infrastructure dédiée et conformément au référentiel PDIS[4]. Des sondes réseaux qualifiées doivent être mise en place entre les SIIV et les réseaux tiers à ceux de l’OIV. Le traitement des incidents doit respecter le référentiel PRIS[5] et l’OIV doit posséder un service de permanence, communément appeler astreinte, pour assurer le traitement des alertes en 24/7. Enfin, une procédure de gestion de crise doit pouvoir être déclenchée sur demande du Premier Ministre afin d’assurer la cyber-résilience des SIIV et du SI de l’OIV.Bien que la détection et le traitement des incidents de sécurité soient pris au sérieux par les OIV, c’est un volet de la SSI qui reste assez récent et continue de se structurer. Aussi, la difficulté principale sera d’aligner les initiatives déjà en place sur les référentiels PDIS et PRIS et de les étendre aux SIIV. Les OIV les moins avancés sur le sujet auront l’avantage de pouvoir partir d’une feuille blanche.

• Protection des systèmes (règles 11 à 19) : chaque SIIV devra respecter les bonnes pratiques de sécurité sur l’authentification et l’habilitation des utilisateurs des SIIV, sur les principes et infrastructures d’administration, sur le cloisonnement des SIIV et la gestion des flux ainsi, sur les principes d’accès à distance, ainsi que sur le durcissement des composants à leur installation.Selon la taille et les typologies de SIIV, l’enjeu est ici de placer le curseur au bon endroit entre cloisonnement des SIIV et fluidité des opérations au quotidien. Des SIIV trop isolés vont entrainer un coût d’exploitation très élevé voire des dysfonctionnements métiers, tandis qu’une gestion trop centralisée maximisera les impacts d’une attaque réussie. Fort heureusement, des solutions permettant d’atteindre le bon compromis existent et sont déjà éprouvés chez certains OIV.

Finalement, cet ensemble de règles rappelle les bonnes pratiques de sécurité et exige qu’elles soient respectées à minima sur le périmètre des SIIV.

Ces arrêtés sont aussi l’occasion pour l’État de promouvoir les documents produits ces dernières années en lien avec la cybersécurité et la Sécurité des Activités d’Importance Vitale (SAIV) : référentiels PASSI / PDIS / PRIS, guides de sécurisation, stratégie d’homologation, méthodologie d’analyse de risques EBIOS, IGI 6600 sur les SAIV, IGI 1300 sur la protection du secret de la défense nationale, II 901 sur la protection des SI sensibles, etc. Les différents guides de bonnes pratique de l’ANSSI seront aussi à considérer pour construire ou faire évoluer les systèmes.

Des publications salutaires, mais encore de nombreuses incertitudes à lever de manière officielle

Après la phase d’identification des SIIV et de gap analysis d’ores et déjà amorcée et en cours de finalisation par la plupart des OIV, la publication des premiers arrêtés sectoriels va enfin permettre une diffusion plus large des règles. Au-delà des OIV et de ceux qui les accompagnent auourd’hui, l’ensemble du marché va ainsi pouvoir s’approprier ces règles et se structurer en conséquence (éditeurs, infogérants, fournisseurs, etc.) en pouvant échanger clairement et de manière plus ouverte sur ces sujets.

En parallèle, il est indispensable que l’ANSSI continue de lever officiellement les questions restantes en publiant le maximum d’éléments : listes de prestataires et produits qualifiés pour l’ensemble des référentiels, exemples d’architectures et configuration conformes, etc. Sur ce point, la récente création de la rubrique « OIV » sur le site de l’ANSSI va dans le bon sens.

D’ici-là, les OIV doivent continuer de mobiliser leurs dirigeants et leurs équipes sur cette mise en conformité, l’identification de cibles envisageables, leur chiffrage et leurs porteurs, sous peine de prendre un retard qui sera difficile à rattraper.

[1] Formulaire de déclaration fourni par l’ANSSI : http://www.ssi.gouv.fr/uploads/2016/04/declaration-incident-lpm-np1.pdf ; couvert par le secret de la défense nationale (Confidentiel Défense) une fois rempli, selon l’incident

[2] Formulaire de déclaration des SIIV fourni par l’ANSSI : http://www.ssi.gouv.fr/uploads/2016/04/declaration-siiv-lpm-np1.pdf ; liste et informations couverts par le secret de la défense nationale (Confidentiel Défense)

[3] PASSI LPM – extension du référentiel public PASSI encadrant la réalisation d’audits SSI (http://www.ssi.gouv.fr/uploads/2014/12/PASSI_referentiel-exigences_v2.1.pdf) ; PASSI LPM est en Diffusion Restreinte aux seules personnes ayant besoin d’en connaître

[4] PDIS – Prestataire de Détection des Incidents de Sécurité : http://www.ssi.gouv.fr/uploads/2014/12/PDIS_referentiel-d%E2%80%99exigences-v1.0.pdf

[5] PRIS – Prestataire de Réponse aux Incidents de Sécurité : http://www.ssi.gouv.fr/uploads/2014/12/PRIS_Referentiel-d%E2%80%99exigences-v1.0.pdf

Cet article Cybersécurité et Loi de Programmation Militaire : les premiers arrêtés sectoriels enfin publiés est apparu en premier sur RiskInsight.

Ce premier article vise, en respectant le secret de la défense nationale, à résumer le cadre législatif et réglementaire de la LPM : quel est le périmètre d’application de la loi ? Quels sont les principes à mettre en œuvre ? Quid de sa compatibilité avec les directives européennes ?

Un contexte réglementaire historique

Des LPM sont régulièrement votées en France depuis 1960. Elles permettent à l’État d’inscrire le financement de sa stratégie de défense militaire dans une logique pluriannuelle. La dernière LPM a notamment servi de véhicule législatif pour adresser le sujet de la cybersécurité des OIV. Elle traduit les orientations du livre blanc sur la défense et la sécurité nationale, publié en avril 2013. En particulier, son chapitre IV donne plus de pouvoirs au Premier ministre et à l’ANSSI en matière de sécurité et de défense des systèmes d’information. Ce texte responsabilise pour la première fois les OIV quant à la sécurisation de leurs systèmes d’information d’importance vitale (SIIV).

La notion d’opérateur d’importance vitale apparaît dans l’ordonnance n°58-1371 du 29 décembre 1958, tendant à renforcer la protection des installations d’importances vitales : « Les entreprises exploitant des établissements ou utilisant des installations et ouvrages, dont l’indisponibilité risquerait de diminuer d’une façon importante le potentiel de guerre ou économique, la sécurité ou la capacité de survie de la nation, sont tenues de coopérer à leurs frais dans les conditions fixées à la présente ordonnance, à la protection desdits établissements, installations et ouvrages contre toute tentative de sabotage ». La liste des opérateurs est confidentielle.

Jusqu’à la LPM, les exigences portaient exclusivement sur la protection physique des points d’importance vitale (PIV) vis-à-vis des actes de sabotage. Depuis, les principes de sécurisation de ces PIV et les interlocuteurs mobilisés (ministres, préfets, responsables de la sûreté, etc.) sont globalement restés les mêmes, tandis qu’en 2006 les OIV se sont vus structurés en douze secteurs d’activité, via le décret n° 2006-212 du 23 février 2006. Tout cela est résumé dans l’instruction générale interministérielle relative à la sécurité des activités d’importance vitale (SAIV), l’IGI n°6600 du 7 janvier 2014.

On peut donc retenir que la LPM vient compléter le dispositif SAIV existant et déployé chez les OIV par un volet cybersécurité. Elle apporte par la même occasion son lot de nouveaux interlocuteurs, avec en tête l’ANSSI et les RSSI des OIV, et nécessite de faire évoluer un existant en place souvent depuis plusieurs dizaines d’années.

De nombreuses exigences visant les SI d’importance vitale

Les OIV ne sont directement impactés que par l’article 22 de la LPM, et plus précisément par les sections du code de la défense qu’il vient créer et mettre à jour : les articles L. 1332-6-1 à L. 1332-7 traitant de la protection des installations d’importance vitale et dispositions spécifiques à la sécurité des systèmes d’information.

Le premier objectif est de sécuriser les SI d’importance vitale, les SIIV, dont la définition reprend celle des OIV : « systèmes pour lesquels l’atteinte à la sécurité ou au fonctionnement risquerait de diminuer d’une façon importante le potentiel de guerre ou économique, la sécurité ou la capacité de survie de la Nation ou pourrait présenter un danger grave pour la population ».

Plusieurs exigences sont imposées : respect de règles de sécurité spécifiques, recours à du matériel et des prestataires qualifiés pour la détection des événements de sécurité, notification obligatoire des incidents de sécurité, contrôles de sécurité réguliers commandités par l’ANSSI. Les sanctions pénales applicables aux OIV lorsqu’ils ne satisfont pas aux obligations prévues s’élèvent à 150 000 € pour le dirigeant de l’OIV et à 750 000 € pour la personne morale.

Il est important de noter que les exigences portent uniquement sur les SIIV, et non sur l’ensemble du SI de l’OIV. D’autre part, nos retours d’expérience sur l’identification des SIIV montrent que la logique « d’importance vitale » diffère entre une vision de l’entreprise (qui vise à assurer sa propre survie) et celle de l’État (qui vise à assurer la sécurité des citoyens). Concrètement, les systèmes commerciaux assurant les ventes ou la facturation, ne sont souvent pas répertoriés dans la liste des SIIV.

Décrets : répartition des responsabilités, classification et qualifications

Deux décrets ont précisé les conditions de mise en œuvre de la LPM. Le premier (Décret n° 2015-351 du 27 mars 2015) vient préciser les modalités pour chaque thème abordé par l’article 22 de la LPM et définit la répartition des responsabilités entre les acteurs (Premier Ministre, Ministres coordinateurs, ANSSI, OIV et prestataires), la classification des documents produits et les qualifications exigées.

En complément, le deuxième (Décret n° 2015-350 du 27 mars 2015) concerne la qualification des produits de sécurité et des prestataires de service de confiance pour les besoins de la sécurité nationale. L’objectif de ce décret est de donner aux OIV les moyens de mettre en œuvre la LPM en s’appuyant potentiellement sur des prestataires et produits de confiance, évalués de manière impartiale dans le cadre de processus de qualification formels. On peut notamment citer PASSI[1] (audit), PDIS[2] (détection d’incident) et PRIS[3] (réaction aux incidents).

Et l’Europe dans tout ça ?

L’Europe, à travers la directive Network and Information Security (NIS), s’inscrit dans la même logique de protection de ses opérateurs essentiels. Elle pose un cadre européen, compatible avec la LPM, que chaque pays aura la responsabilité de décliner sur son territoire. A ce stade et pour les OIV, il suffit donc de retenir que la LPM est finalement une transposition avant l’heure de la directive européenne NIS.

Prochaine étape : publication des règles / arrêtés sectoriels

En définitive, les exigences qui devront concrètement s’appliquer aux SIIV sont celles rédigées par l’ANSSI en concertation avec les OIV depuis plus d’un an maintenant. Elles verront le jour sous la forme d’arrêtés sectoriels, applicables à compter du 1er juillet 2016. Les actions en cours actuellement chez les OIV visent à identifier les écarts de conformités et à budgéter les chantiers requis.

Suite à ce premier volet, un article analysant les arrêtés sectoriels a été publié.

[1] PASSI – Prestataire d’Audit de la Sécurité des Systèmes d’Information : http://www.ssi.gouv.fr/administration/qualifications/prestataires-de-services-de-confiance-qualifies/prestataires-daudit-de-la-securite-des-systemes-dinformation-passi-qualifies/

[2] PDIS – Prestataire de Détection d’Incidents de Sécurité : http://www.ssi.gouv.fr/administration/qualifications/prestataires-de-services-de-confiance-qualifies/prestataires-de-detection-dincidents-de-securite-pdis/

[3] PRIS – Prestataire de Réponse aux Incident de Sécurité : http://www.ssi.gouv.fr/administration/qualifications/prestataires-de-services-de-confiancequalifies/prestataires-de-reponse-aux-incidents-de-securite-pris/

Cet article Cybersécurité et Loi de programmation militaire : quel cadre réglementaire pour quelles exigences ? est apparu en premier sur RiskInsight.

Après ces révélations, 2014 devra être une année de progression pour la communauté dans son ensemble. Les directions sont connues et les principes partagés. Néanmoins, leur promotion et leur application se feront sur  2014 !

2013 aura fait avancer la prise de conscience… Que peut –on souhaiter à la sécurité de l’information 2014 ?

Une sécurité plus transparente

C’est possible ! L’exemple de l’intégration de la reconnaissance biométrique à l’iPhone 5S le montre. Même si la solution n’est pas parfaite, elle a permis d’augmenter significativement le niveau de sécurité des personnes  qui n’utilisent pas de code de verrouillage en raison de la gêne qu’il représente. Au premier rang desquelles on peut citer la PDG de Yahoo, Marisa Meyer…

 Une sécurité plus ancrée dans le quotidien de la DSI

Un chemin important reste à parcourir pour maintenir une hygiène de base dans le SI. La question de l’application des correctifs et des mises à jour en est un exemple frappant. L’ANSSI pousse dans ce sens avec ses 40 règles d’hygiène. Le vote de la loi de Programmation militaire ne fera que renforcer cette orientation pour les structures concernées. Et rappelons que même les structures les plus visés par des attaques ne sont pas encore toutes au point sur ces sujets !

Une sécurité mieux appropriée par les métiers

Nous avons assisté en 2013 à une multiplication des attaques informatiques visant des activités métiers – comme les fraudes dans les agences Santander ou RBS, le premier malware visant SAP ou encore les attaques ciblées sur les systèmes gérant les plafonds de paiements de carte bancaire. Elles montrent aux métiers que lorsqu’un incident survient, certes le SI est touché, mais les cibles finales sont bien les données des métiers ! Ces cas entraînent des prises de conscience fortes. Nous ne pouvons évidemment pas souhaiter d’en voir plus, mais espérer que ces incidents auront été des aiguillons suffisamment forts pour montrer aux métiers, au-delà même des entreprises touchées, l’importance de leur implication au quotidien.

Une sécurité plus à même de détecter et de réagir en cas d’incidents

2013 aura connu son lots d’incidents. Toutes les menaces ont été mises sur le devant de la scène. États avec le rapport APT1 et les révélations sur la NSA, cybercriminels avec l’arrestation du plusieurs profils de haut niveau (Paunch par exemple) et des attaques destructrices (Corée du Sud) ou paralysantes (Cryptolocker). Tout ceci montre clairement que les incidents peuvent se produire et qu’il n’est pas toujours possible de les éviter. Il faut donc se préparer à réagir efficacement !

Une sécurité qui anticipe les innovations

Les évolutions se succèdent dans la société et la sécurité doit les accompagner si elle n’arrive pas à les devancer. Les objets connectés sont aujourd’hui au cœur de toutes les attentions, et 2013 nous a montré leurs vulnérabilités. Lunettes Google Glass, voiture Ford ou Toyota, ampoules Philips Hue, drone Parrot, tous ces systèmes ont été piratés. Et sur ce volet, les efforts de sécurité doivent être réalisé en amont, en effet, il sera très complexe de les mettre à jour une fois distribués sur le terrain !

La plupart des membres de la communauté de la sécurité de l’information partagent déjà ces orientations, mais il est bon de les rappeler et de les confirmer afin qu’elles guident nos actions sur 2014 !

Cet article Que souhaiter pour la sécurité de l’information en 2014 ? est apparu en premier sur RiskInsight.

Des craintes à relativiser …

Disponibilité du Cloud

Chaque incident touchant l’un des grands acteurs du Cloud fait la « Une » de l’actualité, mettant sur le devant de la scène la question de sa disponibilité.

Il s’agit pourtant d’un faux problème : les taux de disponibilité des services Cloud sont souvent  supérieurs à ceux des systèmes internes des entreprises. La situation, d’un point de vue médiatique, est comparable à celle des accidents aériens : bien que rares, ils choquent l’opinion et intéressent les journalistes beaucoup plus que les accidents de voiture, qui font pourtant annuellement plus de victimes. La disponibilité n’est donc pas un risque inhérent au Cloud. Il reste néanmoins une spécificité à laquelle il faut prêter attention : la connectivité avec le fournisseur Cloud. Si celui-ci utilise internet comme unique moyen d’accès à ses datacenters, le risque d’indisponibilité de cet accès et d’internet en tant que tel doit être pris en compte.

 Confidentialité des données

Mes données sont-elles isolées de celles des autres clients ? Les administrateurs peuvent-ils y accéder ? Il est important de remettre ces craintes en perspective. D’une part, toutes les données de l’entreprise ne sont pas critiques en termes de confidentialité. D’autre part, si ces questions se justifient dans certains cas, elles ne sont pas nouvelles et ont trouvé leurs réponses il y a déjà plusieurs années, à l’heure des premiers contrats d’externalisation IT ou de l’emploi d’administrateurs prestataires. Les principales différences résident dans l’éloignement potentiel et le degré de contrôle possible du fournisseur.

La confidentialité des données vis-à-vis des Etats reste un sujet plus complexe à adresser. Ces derniers disposent en effet de textes leur permettant d’accéder aux données présentes dans les systèmes hébergés sur leur sol. Les USA font souvent figure d’épouvantail, leurs textes ayant en plus une portée extraterritoriale (Patriot Act, FISAA). Ces textes permettent à la justice et aux forces de l’ordre américaines d’accéder aux données manipulées par des sociétés de droit américain quel que soit le client et la localisation des données. Le risque est donc que des Etats aient accès aux données dans un objectif d’espionnage économique. Ce risque est réel comme l’illustrent les révélations sur les moyens dont dispose la NSA. Mais là encore, la portée du risque est à mesurer. Seules quelques données ont un niveau de sensibilité élevé : étatiques (administrations, défense, etc.), stratégiques pour l’entreprise dans un environnement à forts enjeux concurrentiels, géopolitiques, etc.

 Conformité réglementaire

La conformité réglementaire (PCI-DSS, LIL…) des offres Cloud, notamment en matière de protection des données à caractère personnel est également un sujet d’inquiétude. La situation reste très variable en fonction des acteurs, même si des réponses techniques (localisation des données, chiffrement…) ou juridiques (Safe Harbour, contrat type de la commission européenne…) existent aujourd’hui chez la plupart d’entre eux.

… car la sécurité est au cœur de la préoccupation des fournisseurs

Très visibles et régulièrement attaqués, les fournisseurs majeurs de Cloud mettent souvent en place des équipes dédiées pour assurer la sécurité de leurs services. La sécurité est même devenue pour certains d’entre eux l’un  des principaux arguments de vente.

Attention cependant : tous n’assurent pas le même niveau de sécurité. Il reste donc important de préciser avec le fournisseur les mesures incluses dès la signature du contrat, d’autant qu’il est difficile de faire évoluer les mécanismes de sécurité d’un fournisseur quand ceux-ci ne sont pas prévus initialement. Certains fournisseurs de solutions « SaaS métier » de taille petite et intermédiaire négligent parfois la sécurité : les audits et tests d’intrusion ont pour ce type d’offres une importance accrue.

Vers une coresponsabilité fournisseur / entreprise

Analyse de risque : passer de l’intention à l’action

Suivre une démarche d’analyse de risque est impératif pour lever les freins relatifs à l’adoption du Cloud. La finalité de l’analyse n’est pas d’interdire le Cloud par défaut mais plutôt d’identifier les données sensibles afin d’accompagner les projets de la manière la plus sûre et la plus pertinente. L’implication des responsables sécurité dès le démarrage des projets est donc essentielle. Ils doivent identifier les risques que l’on peut réduire par des moyens techniques et organisationnels, et ceux résiduels impossibles à couvrir. Aux Métiers et à la Direction de décider ensuite si ceux-ci sont acceptables ou non pour l’entreprise. Et de revoir si besoin le périmètre de la démarche Cloud.

Des contrôles à ne pas négliger…

Durant le projet ou en amont lors de la phase de choix des fournisseurs, il est recommandé de poser des questions précises sur les mesures de sécurité pour ne pas laisser place à des réponses ambiguës. Par exemple, beaucoup de fournisseurs mettent en avant leurs certifications.

Il convient de vérifier le type de certification et le périmètre concerné. Un certain nombre d’acteurs du Cloud acceptent d’ailleurs de fournir des détails sur l’architecture de leur solution, après signature d’un accord de non-divulgation. La capacité à répondre rapidement et de manière détaillée aux questions permet de se forger un avis sur la maturité de l’offre proposée.

En outre, la possibilité d’auditer le prestataire Cloud est un bonus à ne pas négliger. Accepter un audit est une preuve de transparence du fournisseur et de confiance en son niveau de sécurité. Même si les plus grands acteurs anglo-saxons s’y refusent, il est toujours utile de poser la question, notamment pour des acteurs de taille intermédiaire.

Des référentiels émergents

Un outillage commence à voir le jour pour aider les entreprises à évaluer les risques et le niveau de sécurité inhérent. En France, l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information) a publié un guide pour accompagner les démarches de type Cloud computing. Au niveau européen, l’ENISA (European Network and Information Security Agency) fournit une analyse générique mais complète des risques liés au Cloud. Enfin, outre- Atlantique, l’association Cloud Security Alliance, qui regroupe les acteurs majeurs, a mis au point la Cloud Controls Matrix. Cette matrice permet de comparer de nombreux fournisseurs sur des critères de sécurité précis. Bien que fondée sur les seules déclarations desdits fournisseurs, elle peut s’avérer utile pour comparer les offres.

Le chiffrement : graal de la sécurité Cloud ?

Parmi les solutions techniques permettant de réduire les risques du Cloud, le chiffrement se positionne en tête. Et si aujourd’hui son utilisation nécessite souvent de donner les clés de déchiffrement au fournisseur, des innovations technologiques se profilent. Elles permettront de transférer et de traiter des données à distance sans jamais donner au fournisseur d’accès direct. Bien qu’encore expérimentales, ces techniques, rassemblées sous la bannière du chiffrement homomorphique, méritent qu’on les suive avec attention.

Ne pas mettre ses responsabilités dans les nuages

Contrairement à ce que trop d’entreprises pensent, leur responsabilité ne s’arrête pas une fois la solution Cloud mise en production. Si le fournisseur est tenu de respecter un certain nombre

de règles de sécurité, le maintien du niveau de protection dans le temps relève aussi de la  responsabilité de l’entreprise. Pour cela, les bonnes pratiques appliquées au SI d’entreprise doivent être transposées au Cloud : gouvernance de la sécurité (processus, sensibilisation des utilisateurs), administration fonctionnelle de la sécurité, configuration des options de sécurité avancées, restriction des droits requis par les utilisateurs, formation des administrateurs, revue régulière des paramètres de configuration… Ceci est particulièrement vrai pour la gestion des identités et des accès, élément clé pour garantir la confidentialité des données dans le Cloud.

Cet article Sécurité et Cloud, un mariage de raison est apparu en premier sur RiskInsight.

Il met en particulier l’ANSSI au cœur de la future stratégie de la France dans ce domaine en renforçant ses pouvoirs et sa capacité d’action. La majorité de ces points étaient connus ou envisagés depuis la publication du livre blanc Défense et sécurité nationale 2013. Mais ce document donne plus de détails sur les moyens déployés et les orientations à venir.

Les opérateurs d’importance vitale (OIV), sous le contrôle rapproché de l’ANSSI

Le texte prévoit que le Premier ministre, avec l’aide de l’ANSSI, puisse imposer aux OIV, sur leurs périmètres sensibles, la mise en place de mesures de sécurité, la qualification des systèmes de détection et la réalisation d’audit par l’ANSSI. Comme prévu, la notification des incidents est intégrée au texte. Elle se définit par l’obligation de fournir « des informations sur les attaques qu’ils peuvent subir ».

Au delà du guide d’hygiène informatique qui pourrait être la base des mesures imposées, l’ANSSI travaille actuellement sur d’autres référentiels, par exemple sur les systèmes industriels ou sur le cloud.

En cas de non-respect de ces obligations, des sanctions pénales sont prévues. Il se posera alors la difficile question des moyens à disposition pour respecter ces obligations. Aujourd’hui, même si la sécurité est souvent préservée des coupes budgétaires, les budgets alloués sont souvent trop faibles au regard des enjeux et des risques. Espérons que cette réglementation, au-delà de paraître « intrusive », aura des vertus pédagogiques et fera prendre conscience aux dirigeants des OIV des réels enjeux de sécurité et permettra le déblocage de ressources.

 La lutte informatique défensive dans le champ d’action de l’ANSSI

Le récent rapprochement « géographique » entre le CALID (centre d’analyse en lutte informatique défensive) du Ministère de la Défense et le COSSI (centre opérationnel en sécurité SI) de l’ANSSI le laissait présager. Il y a aujourd’hui une volonté de renforcer les capacités de lutte informatique défensive au sein de l’Etat. L’ANSSI sera ainsi en mesure « d’accéder à un serveur informatique à l’origine d’une attaque afin d’en neutraliser les effets ». C’est une première dans ce domaine. Des dispositifs juridiques sont prévus pour que ces actions ne rentrent pas dans le champ des articles 323-1,2 et 3 du code pénal qui répriment des actions de ce type.

 Le volet militaire n’est pas en reste : recrutements et investissements sont prévus

De nombreuses autres évolutions sont prévues, en particulier dans le domaine du développement des capacités de cyberdéfense militaire avec la mise en place d’une chaîne opérationnelle unifiée, centralisée et spécialisée. Le projet de loi prévoit la mise en place des capacités défensives mais aussi offensives pour préparer ou accompagner les opérations militaires. Les moyens humains seront renforcés et des investissements sont également prévus en particulier pour mieux surveiller les systèmes critiques. La DGA sera en charge de la composante technique de cette organisation.

 L’Etat investit dans la cybersécurité… mais les entreprises restent à convaincre

Nous ne sommes qu’au début du processus législatif et les débats au parlement et au sénat amèneront certainement des modifications. Cependant, l’orientation est claire et tout cela va dans la bonne direction pour renforcer nos capacités de défense face à des attaquants de plus en plus virulents et pointus.

Enfin, ce projet de loi démontre que l’État a compris les enjeux de la cybersécurité et investit fortement dans ce domaine. Espérons que cela sera un électrochoc pour les organisations privées, aujourd’hui en retrait face aux évolutions de la cybercriminalité.

Cet article Loi de programmation militaire 2013 : de réelles avancées pour la cybersécurité est apparu en premier sur RiskInsight.

En particulier, la question de la protection des données transmises, traitées et sauvegardées apparaît comme cruciale. Ces points préoccupent aujourd’hui les experts techniques, les managers d’information, et parfois même les directions des entreprises.

Le Cloud est-il sûr ? Que risque-t-on en l’adoptant ? Comment y assurer la sécurité de ses données ?

Un service moins cher n’est pas forcément moins sécurisé

Il faut voir les risques liés au Cloud comme proches de ceux existants sur l’externalisation et la virtualisation avec en particulier la perte de contrôle de ses données et les risques liés aux technologies utilisées (virtualisation des systèmes et des réseaux, automatisation d’un certain nombre de tâches, etc.).

Pourtant, de manière générale, nous constatons en France que le niveau moyen de sécurité des services Cloud est au-dessus du niveau moyen de sécurité des entreprises. Plusieurs facteurs expliquent cela.

Le fait de fournir un service informatique à l’état de l’art (et donc sécurisé) est le métier des acteurs du Cloud. Chez la plupart d’entre eux, la mise en place et le respect des procédures de sécurité fait l’objet d’une attention particulière. Par ailleurs, ils proposent un service industrialisé à de nombreux clients : les bonnes pratiques exigées par l’un peuvent souvent être appliquées à tous.

Ces fournisseurs sont, enfin, plus exposés que la moyenne des entreprises, et ont de vrais enjeux en termes d’image : la découverte de faiblesses de sécurité amène en général à une correction rapide.

Inversement, si un mécanisme de sécurité n’est pas offert par un fournisseur (de base ou en option), il sera malheureusement difficile de l’obtenir : en sécurité comme pour les autres fonctionnalités, les offres Cloud manquent souvent de souplesse.

Attention cependant, contrairement à une idée répandue, toutes les offres Cloud ne se valent pas : de véritables différences peuvent exister d’un fournisseur à un autre.

Des outils dédiés existent pour évaluer ses risques de sécurité

D’un point de vue sécurité, la démarche est celle – classique – de l’analyse de risque. Le but est ici d’accompagner les projets de mise en œuvre ou de migration vers le Cloud, et pas de les interdire.

Dans le cas du Cloud, un outillage spécifique commence à apparaître pour réaliser cette analyse. En France, l’ANSSI (Agence Nationale de  la Sécurité des Systèmes d’Information) a publié  un guide¹ pour accompagner les démarches de type Cloud computing. Au niveau européen, l’ENISA (European Network and Information Security Agency) fournit une analyse² générique mais complète des risques liés au Cloud.

Outre-Atlantique, l’association Cloud Security Alliance regroupant les acteurs majeurs du Cloud a mis au point son outil Cloud Controls Matrix³, qui permet de comparer de nombreux fournisseurs sur des critères de sécurité très précis. Si elle est basée sur les seules déclarations desdits fournisseurs, cette matrice peut néanmoins s’avérer utile.

Les comparaisons théoriques  ne suffisent pas

Il est parfois difficile de distinguer ce qui est présenté de ce qui est fait en réalité en termes de sécurité. Plusieurs critères permettent d’évaluer les fournisseurs.

Ils peuvent tout d’abord se prévaloir de différentes certifications : ISO 27001 (très adoptée et quasiment obligatoire aujourd’hui) et ISAE 3402/SAE 16 (très adoptées également, requises pour les groupes cotés aux États-Unis, dans la ligne de SOX). Des démarches spécifiques existent aussi dans certains domaines, comme pour les données de santé en France, ou PCI-DSS pour les données de cartes bancaires.

Pour autant, ces certifications ne sont pas toujours une assurance d’un niveau de sécurité adapté. Lors de la phase de choix des fournisseurs ou durant le projet, il apparaît nécessaire de poser des questions très précises, sans laisser de place à des réponses trop larges ou ambiguës.

Un certain nombre d’acteurs du Cloud accepteront d’ailleurs de fournir des détails sur le fonctionnement de leur solution, après signature d’un accord de non-divulgation. Des visites de datacenters sont aussi toujours très instructives, et permettent parfois de se forger un avis sur la maturité du niveau de sécurité de l’offre proposée.

Certains fournisseurs sont réticents à fournir des informations très précises préalablement à la signature du contrat, ils peuvent alors proposer l’ajout d’une clause permettant de dénoncer le contrat ultérieurement. Mais attention à ce mécanisme, une fois la mise en œuvre démarrée, faire marche arrière est presque impossible…

Enfin, la possibilité de contrôler le prestataire Cloud est un critère intéressant. Sa capacité à accepter un audit diligenté par ses clients est en effet une preuve de transparence, voire de confiance en son propre niveau de sécurité.

¹ : ANSSI – Externalisation, Cloud Computing : maîtriser les risques pour les systèmes d’information (http://www.ssi.gouv.fr/externalisation/)  

² : ENISA  – Cloud Computing Security Risk Assessment (http://www.enisa.europa.eu/activities/risk-management/)

³ : Cloud Security Alliance – Cloud Controls Matrix (https://cloudsecurityalliance.org/research/ccm/)

Cet article Cloud et sécurité : mythes et réalités (partie 1) est apparu en premier sur RiskInsight.