Dans cet exemple, nous supposerons que vous êtes un fabricant de machine à café. Votre projet actuel est de développer une machine à café connectée pour vos entreprises clientes. Vous avez identifié plusieurs cas d’utilisation pour cette machine IoT. Par exemple, elle permet de commander automatiquement de nouvelles capsules de café lorsque le stock atteint un certain seuil. Un deuxième cas consiste à ce qu’elle envoie des alertes automatiques à vos serveurs lorsque des actions de maintenance telle que le nettoyage et les réparations sont nécessaires. Enfin, elle offre également des fonctionnalités de suivi des consommations.

Comment choisir le réseau qui répond le mieux à vos besoins ? Quelles questions devriez-vous vous poser ? Comment faire le bon choix tout en considérant la sécurité globale de votre système ?

Première étape – Définir les besoins de votre entreprise et effectuer une analyse des risques

Tout d’abord, vous devez identifier les exigences de votre réseau IoT, qui sont doubles : les exigences fonctionnelles et de sécurité. Nous caractérisons ces exigences par des niveaux de 0 à 3, 0 étant le niveau le plus bas et 3 le plus élevé.

En ce qui concerne les exigences fonctionnelles, vous devez répondre à des questions telles que :

1. Quelle distance le signal de l’objet doit-il atteindre ?
2. De quelle largeur de bande avez-vous besoin ?
3. Quelle est l’autonomie de votre objet ?

Dans notre exemple, nous supposons que vos machines à café connectées seront distribuées à des entreprises clientes opérant sur une vaste zone géographique (c’est-à-dire dans un rayon de plus de 100 km). Par conséquent, vous aurez besoin d’une large couverture pour permettre aux différentes machines répandues de vos clients de communiquer avec votre système d’information.

Deux cas de figure sont présentés ici. Si votre client accepte de connecter votre machine à son réseau local existant, vous n’aurez alors qu’à utiliser un réseau sans fil à courte portée entre la machine et la passerelle internet. S’il refuse de le faire, vous devrez alors mettre en place un réseau longue portée car vous déploierez votre service et vos machines sur une vaste zone.

En ce qui concerne la bande passante, une petite quantité sera nécessaire, car il suffit de pouvoir envoyer de petits paquets de données quelques fois par jour au maximum (commandes de capsules, alertes, état général, …).

En ce qui concerne la consommation d’énergie, une machine à café est traditionnellement connectée à une prise électrique pour accomplir ses tâches ; ainsi, la machine IoT est constamment alimentée en électricité, et par conséquent l’autonomie de l’objet n’est donc pas une contrainte. En résumé, il n’y a pas d’exigence de consommation d’énergie en soi car elle est déjà couverte par le raccordement de la machine à café au réseau électrique.

Nous résumons les niveaux des exigences fonctionnelles comme suit :

• Portée (P) = 3 ou 1
• Bande passante (B) = 1
• Consommation énergétique (E) = 0

Après la définition des exigences fonctionnelles, une analyse des risques doit être effectuée pour formuler les exigences de sécurité de votre projet en termes de disponibilité, d’intégrité, de confidentialité et de traçabilité.

Une perte de disponibilité se produirait en cas de dysfonctionnement de la machine à café connectée, qui la rendrait inutilisable pour un client. Une perte d’accès au réseau ou l’indisponibilité des serveurs backend ne doit jamais entraîner l’indisponibilité de la machine : elle doit continuer à fonctionner hors réseau. Toutefois, si un dysfonctionnement de la machine se produit, il faudrait qu’il soit signalé le plus rapidement possible par le réseau afin que des actions de maintenance soient déclenchées.

En combien de temps cela devrait-il être fait ? La réponse est plusieurs heures plutôt que plusieurs jours, car nous ne voudrions pas priver les employés de leur pause-café ! Par conséquent, 4 à 24 heures est une fenêtre d’indisponibilité acceptable qui correspond à un niveau d’exigence de disponibilité égal à 2.

Une perte d’intégrité entraînerait une corruption des données. Par exemple, un excès potentiel dans une commande de capsules de café peut se produire en modifiant les messages envoyés par la machine à café ou en rejouant plusieurs fois la même commande. Dans les deux cas, cela entraînerait une perte financière pour votre client. En effet, ces données doivent être communiquées par le réseau de manière rigoureuse et exacte. Nous pouvons donc conclure qu’il s’agit d’une exigence d’intégrité de niveau 3.

Une perte de confidentialité entraînerait la divulgation des données ; les quantités des commandes sont des données plutôt sensibles qui ne devraient pas être partagées avec des tiers. Il faut s’assurer que les données soient communiquées de manière sécurisée sur le réseau et qu’elles ne sont pas accessibles par des parties externes.  Par conséquent, nous concluons que la confidentialité a un niveau d’exigence de 2.

Concernant la traçabilité, pour des raisons de simplification, nous choisissons de laisser cet aspect de côté en considérant qu’il est déjà pris en compte par l’étude des 3 premiers critères.

En résumé, l’analyse de risque conclut aux exigences de sécurité suivantes :

• Disponibilité (D) = 2
• Intégrité (I) = 3
• Confidentialité (C) = 2

Pour plus de détails sur la méthodologie d’analyse de risque pour les objets intelligents, nous vous invitons à consulter cet article.

A la fin de cette analyse, vous obtenez pour vos deux cas d’usage un diagramme radar représentant les niveaux de vos exigences opérationnelles, comprenant les exigences fonctionnelles et de sécurité.

Cas n°1 : votre client connecte la machine à café à son réseau local

Cas n° 2 : votre client ne connecte pas la machine à café à son réseau local

Bien qu’ils ne soient pas abordés dans cet article, les aspects financiers sont également importants et dépendent de divers facteurs tels que le modèle de tarification des opérateurs de réseau. Il en va de même pour les contraintes géographiques, car certains réseaux IoT peuvent ne pas être disponibles dans certaines régions.

Enfin, la facilité de configuration du réseau peut être incluse dans vos exigences fonctionnelles, surtout si votre objet connecté vise un public B2C.

Deuxième étape – Choisir votre réseau IoT

Sur la base des exigences fonctionnelles et de sécurité, nous avons élaboré une méthodologie qui permet de choisir le réseau optimal afin de répondre à vos besoins fonctionnels et de sécurité : portée, bande passante, consommation d’énergie, disponibilité, intégrité, confidentialité.

Les trois exigences fonctionnelles sont obligatoires, c’est-à-dire que le réseau que vous choisissez doit absolument les satisfaire, autrement, il sera écarté.

Pour les exigences de sécurité, l’évaluation nécessite une analyse préemptive. Entre deux réseaux qui couvrent les mêmes exigences fonctionnelles, vous devez choisir celui qui offre le meilleur niveau de sécurité avec le coût minimum.

Si un réseau ne répond pas à l’une des exigences de sécurité, vous devrez mettre en place un dispositif de sécurité supplémentaire dans le cadre de votre projet, ce qui augmentera vos coûts.

Vous devez également veiller à ce que la mise en œuvre supplémentaire n’affecte pas les performances du système. Par exemple, si vous mettez en œuvre le chiffrement des données au niveau de la couche applicative, l’augmentation des temps de traitement aurait un impact négatif sur votre débit de données maximum ou pourrait être limitée par les capacités matérielles du dispositif, avec un impact financier potentiel en cas de mise à niveau du matériel. Par conséquent, l’une de vos exigences fonctionnelles pourrait ne plus être satisfaite.

Si une haute disponibilité est requise (A=3), vous devriez choisir un réseau robuste de par sa conception qui répondra à vos besoins de temps réel.

En effet, les protocoles à spectre étalé (comme Bluetooth ou ZigBee) ou modulés par saut de fréquence (comme Sigfox ou Bluetooth) sont plus résistants au brouillage radioélectrique ou aux interférences radio.

Ces types de réseaux sont particulièrement recommandés lorsque la disponibilité est une exigence importante, comme sur une chaîne de production industrielle.

En outre, les protocoles maillés sont connus pour être plus fiables et plus évolutifs que les protocoles point à point. Toutefois, pour qu’ils soient efficaces, ils doivent être utilisés dans un contexte où plusieurs dispositifs connectés sont reliés entre eux. Les protocoles maillés comme WirelessHART peuvent également garantir des communications en temps réel. Leur utilisation est particulièrement adaptée à un contexte industriel.

Une méthodologie simple pour choisir le bon réseau consiste à confronter les exigences opérationnelles de votre entreprise aux caractéristiques fonctionnelles et de sécurité du réseau.

Dans les diagrammes radar suivants, nous présentons différents types de réseaux IoT offrant différents niveaux fonctionnels et de sécurité, et nous comparons chacun d’entre eux à vos exigences opérationnelles.

Cas n°1 : votre client connecte la machine à café à son réseau local

Cas n° 2 : votre client ne connecte pas la machine à café à son réseau local

Appliquons la méthodologie évoquée précédemment dans les 2 cas de figure. Tout d’abord, nous utilisons les diagrammes radar ci-dessus pour voir quels réseaux sont conformes à vos exigences fonctionnelles.

Cas n°1 : votre client connecte la machine à café à son réseau local

Dans ce cas, Bluetooth et Wi-Fi sont deux options viables à courte portée si votre client connecte la machine à son réseau local. D’une part, Bluetooth répond à toutes les exigences de sécurité, mais il est moins simple à mettre en œuvre que le Wi-Fi. D’autre part, le Wi-Fi répond à toutes les exigences, à l’exception de la disponibilité, mais nous pouvons y remédier grâce à des accords de niveau de service (SLA).

Cas n°2 : votre client ne connecte pas la machine à café à son réseau local

Dans ce cas, Zigbee, BLE et Wi-Fi sont clairement hors de l’équation car ils ne répondent pas aux exigences de portée. Cependant, LoRa, LTE-M et Sigfox sont des candidats potentiels.

Nous utilisons à nouveau les diagrammes radar, cette fois pour évaluer la conformité de ces trois candidats aux exigences de sécurité.

Sigfox ne répond pas à l’une de vos exigences de sécurité (confidentialité) alors que LoRa répond à toutes les exigences de sécurité. LTE-M est la meilleure offre car elle répond à toutes vos exigences, mais c’est aussi la plus chère. Nous en concluons que la LoRa est un candidat relativement bon.

En conclusion, vous disposez d’une part une option adéquate qui est LoRa et qui nécessitera le déploiement d’un nouveau réseau, et d’autre part d’une option alternative utilisant un réseau Wi-Fi préexistant. Il est à noter que votre client peut refuser de connecter la machine à café à son réseau Wi-Fi pour des raisons de sécurité.

Nous allons envisager un nouveau scénario dans un prochain article : une entreprise cliente achète la machine et discute de quelle option utiliser LoRa ou Wi-Fi.

Cet article Brancher sa cafetière connectée: oui, mais comment? est apparu en premier sur RiskInsight.

QU’EST-CE QU’UNE ANALYSE DE RISQUE CYBER?

Vous êtes-vous déjà demandé ce qui se passerait si un appareil que votre entreprise a mis au point et qu’elle vend divulguait les données qu’elle recueille ? Ou si ces données étaient corrompues ou soudainement rendues indisponibles ? Qu’est-ce qui serait le plus préjudiciable ? Et si votre solution était vulnérable à une cyberattaque ? Les conséquences pourraient-elles être une prise de contrôle d’un ou de plusieurs appareils qui entraînerait un risque pour la sécurité, comme un bâtiment qui prendrait feu ou même une victime humaine ? Ou peut-être s’agirait-il « seulement » d’une attaque pivot sur le réseau de votre client qui entraînerait une incapacité totale de fonctionnement de votre entreprise et de celle de votre client.

Si vous êtes en train de développer une solution IoT et que vous ne faites pas de dépression nerveuse en envisageant de telles possibilités, vous vous demandez probablement pourquoi votre RSSI (Responsable de la Sécurité des Systèmes d’Information) n’en fait pas une.

C’est probablement parce que votre RSSI a une méthode : il considère chaque risque d’un point de vue impartial et de manière comparable. La première étape importante consiste à s’assurer que chaque risque est correctement évalué (c’est-à-dire qu’il n’est ni surestimé, ni sous-estimé) et à partager les résultats de cette évaluation avec toutes les parties prenantes du projet. Une fois que toutes les parties prenantes se sont mises d’accord sur chaque risque, votre entreprise dispose d’une base adéquate pour décider des mesures de contrôle à implémenter.

Cette approche ne signifie pas que vous devez traiter tous les risques au point que votre solution soit pratiquement impossible à mettre en œuvre. D’ailleurs, c’est techniquement impossible, et votre budget disparaîtrait bien avant d’avoir atteint une solution dite de risque zéro. Chaque mesure de contrôle doit être hiérarchisée et proportionnelle à la probabilité et à la gravité du risque.

Ce que nous avons décrit ci-dessus est connu sous le nom de méthodologie d’analyse des risques. Les professionnels de la cybersécurité utilisent cette méthodologie comme base de référence pour les initiatives de leur entreprise en matière de cybersécurité. Les professionnels évaluent les scénarios de risque (souvent liés à la disponibilité des services, à l’intégrité des données, à la confidentialité et/ou à la traçabilité des actions) et les impacts sur l’image de marque de leur entreprise, les responsabilités légales, les conséquences sur la sécurité et bien sûr les résultats financiers. Plus le risque est évalué, plus la priorité est accordée à la réduction de la probabilité que le risque se produise (par exemple, ajouter des barrières à une attaque, réduire la surface d’attaque, etc.) ou à la gravité des résultats si le risque se produit (par exemple, appliquer une segmentation pour réduire la propagation d’une attaque).

Si vous voulez en savoir plus sur les méthodes d’analyse des risques existantes, vous devriez commencer par la norme ISO27005, qui a un large champ d’application et de compréhension dans divers secteurs.

Soyez rassuré sur le fait que parler des risques n’augmentera pas la probabilité que le problème se produise (si jamais vous le craigniez), mais ne pas en parler fait courir un grand risque au projet.

EN QUOI L’ANALYSE DES RISQUES D’UN PROJET IOT EST-ELLE DIFFÉRENTE ?

Nous espérons vous avoir convaincu de l’importance de l’analyse des risques de votre projet ; nous verrons comment vous pouvez vous y prendre rapidement dans le prochain chapitre. Avant d’en arriver là, nous allons détailler ce qui rend l’exercice spécifique à un projet IoT: quelles sont les caractéristiques de tels projets et qu’est-ce qui rend l’analyse des risques plus difficile ou plus simple ?

Commençons par les caractéristiques communes qui doivent être prises en compte pour une analyse des risques. Tout d’abord, une initiative IoT repose souvent sur un réseau de matériel très décentralisé (capteurs, passerelles, serveurs, etc.). Ces dispositifs peuvent être répartis sur une vaste zone géographique, parfois dans le monde entier, et sont destinés à rester longtemps sur le terrain avec peu ou pas de maintenance sur place. Il est courant de voir des dispositifs IoT B2B dont la durée de vie dépasse 10 ans (par exemple, un projet de mesure de l’eau pour les entreprises de services publics). Les dispositifs B2C peuvent également viser de telles durées de vie – pensez par exemple aux véhicules connectés. Il convient également de noter que les dispositifs IoT ont généralement des interfaces utilisateur limitées, telles qu’un écran et un clavier. Malgré cela, les boutons, les LED et les applications mobiles permettent les interactions ou les personnalisations nécessaires à l’appareil IoT pour que vous puissiez collecter des données sur le terrain. N’oubliez pas que les données collectées à partir des appareils connectés sont en fait là où réside toute la valeur de tels objets. Ainsi, le fait que ces données soient ou non critiques est essentiel dans l’évaluation des risques. Enfin, nous devons nous rappeler qu’un projet IoT est toujours un projet informatique. Si les dispositifs ne sont pas des ordinateurs portables typiques, les serveurs d’application et le stockage restent centraux dans la plupart des cas. C’est là qu’une grande partie du risque demeure, mais heureusement, il existe de nombreuses bonnes pratiques pour cette partie de la solution également.

Du point de vue de la cybersécurité, ces caractéristiques peuvent rendre les projets IoT plus risqués. Par exemple :

• La sécurité physique d’un réseau décentralisé est très difficile à implémenter. Où sont situés les appareils ? Sont-ils accessibles au public ? Quelqu’un peut-il facilement les voler, les endommager ou les altérer ? Par exemple, un tracker installé sur une palette se déplace à l’extérieur des locaux de confiance et peut être endommagé ou retiré – intentionnellement ou non. Bien entendu, ce risque est amplifié par une empreinte géographique plus large.
• Étant donné les interactions limitées des utilisateurs et la durée de vie plus longue des appareils, leur maintenance peut devenir très coûteuse et longue, surtout si vous devez dépêcher physiquement des techniciens. Une intervention manuelle peut être tout simplement irréaliste, mais même les mises à jour de microprogrammes ont un taux d’échec. Pour toutes ces raisons, les contrôles doivent être pertinents à long terme
• Dans tout projet IoT, la sensibilité des données est un facteur qui doit être pris en compte. Est-ce un facteur critique pour votre entreprise ? Pour les projets de consommation, la sensibilité des données peut être perçue comme très élevée car les appareils collectent des données du monde « réel ».
• Les solutions IoT sont constituées de nombreuses technologies et de nombreux fournisseurs différents. Cela constitue un réel défi : quelles sont les pratiques de sécurité suivies par chacun de ces fournisseurs et ces pratiques couvrent-elles suffisamment les risques identifiés ?
• Enfin, les contrôles de sécurité qui peuvent être appliqués dépendent des capacités des appareils et des logiciels. Par exemple, de nombreux capteurs fonctionnent sur des MCU 8 bits et ne peuvent donc pas exécuter des algorithmes de chiffrement compliqués.

ALORS MAINTENANT, COMMENT PUIS-JE COMMENCER ?

Prenez une grande respiration et impliquez votre RSSI.

Le RSSI doit identifier et évaluer les réglementations applicables, décider du niveau de risque acceptable, fournir des politiques à suivre et des outils pour mettre en œuvre les mesures de sécurité. Peut-être devriez-vous nommer un responsable de la sécurité des produits pour s’occuper spécifiquement de la sécurité de l’IoT dans votre entreprise ou même de la sécurité d’un produit IoT spécifique si les enjeux l’exigent.

Pour atteindre un niveau de sécurité acceptable, il faudra disposer d’une expertise dans les différents domaines de l’IoT. Si vous êtes cet expert, vous devriez probablement être prêt à vous impliquer. Cela amènera toute l’équipe à envisager:

• La sécurité de bout en bout sur la pile technologique : du matériel au cloud, y compris les logiciels intégrés, la connectivité réseau, les applications mobiles, etc.
• La sécurité de bout en bout du point de vue du cycle de vie des appareils. Lorsque vous concevez votre appareil, pensez à toutes les phases : de la fabrication à la distribution ; de la première utilisation à l’utilisation normale ; revente, remise à neuf, recyclage ou mise à la poubelle.
• L’implication des partenaires : veillez à ne pas les oublier et évaluez leur maturité. Vous devrez peut-être prendre des mesures pour les soutenir ou les perfectionner (conseil : demandez à votre RSSI ou à votre responsable de la sécurité des produits).
• L’audit de votre appareil et de toute la pile technologique. Faites-le régulièrement car il se peut que votre logiciel n’ait pas changé mais que les menaces et les vulnérabilités connues aient évolué.
• Les mises à jour et la maintenance de la sécurité à long terme : définissez pendant combien de temps vous allez mettre à jour et déployer vos appareils.
• L’organisation de la réponse aux incidents : définissez comment vous pouvez être informé des vulnérabilités ou des brèches et comment vous pouvez prévoir d’y répondre (d’un point de vue technique et de communication).

La cybersécurité de l’IoT n’est pas impossible. Elle fournit en fait des méthodologies et des outils pour aider à créer un environnement sûr.

Les acteurs du projet et les clients recherchent des produits sûrs et font pression pour qu’ils le soient. La réglementation visant à faire respecter la sécurité est imminente et les cadres de référence permettant d’aider chaque acteur à s’aligner sur ses devoirs continueront d’être appliqués. Il est temps d’aller de l’avant dès maintenant si vous cherchez à faire de la cybersécurité un atout pour votre produit sur votre marché !

Cet article Analyse des risques et IoT: un mariage d’amour ou de raison ? 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.

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 effet, le processus de souscription constitue le pilier fondateur d’un transfert de risques réussi. Il est donc primordial pour toute entreprise désirant franchir le pas de la cyber-assurance de connaître toutes les caractéristiques d’une telle opération.

Quels sont les acteurs majeurs de ce processus ?

Les acteurs du processus de souscription sont peu nombreux et bien définis. Participent aux négociations :

• Le client : il s’agit d’une organisation ou d’une entreprise souhaitant disposer d’une prestation (généralement financière) en cas de survenance d’un incident. C’est lui qui exprime le besoin, que ce soit par ses Risk Manager, ses RSSI, sa Direction Générale ou encore ses acteurs métiers.
• Le courtier : il est l’intermédiaire entre le souscripteur et l’assureur, et joue de ce fait un rôle central tout au long du processus. Il base son travail sur une excellente connaissance du marché et du besoin remonté par son client.
• L’assureur : il crée les polices d’assurances, en définissant leurs périmètres de couverture, leurs plafonds de garanties ainsi que leurs primes ou franchises. Ces paramètres sont toutefois largement négociés et fortement corrélés avec la maturité du client.

Comment se déroule le processus de souscription à une cyber-assurance?

En premier lieu, le client doit faire le point sur son besoin et confronter les risques résiduels identifiés comme nécessaires à couvrir avec ceux déjà couverts par une assurance. Pour ce faire, une analyse de risques récurrente et un bilan assurantiel (évaluation de la couverture actuelle et des manques) impliquant toutes les parties de l’entreprise sont nécessaires.

Dans un second temps, il convient de choisir le courtier le mieux à même de répondre aux attentes du client. Dans le contexte de grandes entreprises, il sera jugé sur son expertise sur le sujet cyber, sa capacité à offrir une couverture multi-assureurs et des modalités de son accompagnement au cours des différentes étapes, du choix à la vie du contrat.

Courtier et client échangent alors sur la nature même des risques à traiter, ainsi que sur la maturité de ce dernier. Le courtier identifie ensuite, grâce à sa connaissance poussée du marché, les assureurs les plus à même de répondre au besoin.

Le client et le courtier présentent ensuite à l’assureur leurs exigences en termes de périmètre de couverture et de plafond de garantie. Dans le cas de montants très élevés, le courtier peut mettre en place des montages d’assurances qui permettent d’atteindre des plafonds plus élevés que ceux proposés dans les offres standards. En réponse, l’assureur évalue la maturité du client, par l’intermédiaire de questionnaires ou par une analyse de risques. L’assureur propose alors un montant de prime d’assurance en fonction de la maturité observée chez le client. Ce montant, qui varie généralement entre 1 et 5% du plafond de la garantie, est ensuite négocié entre les différents partis.

Le périmètre de couverture, le plafond de garantie et le montant de la prime constituent la police d’assurance.

Comment faire vivre le contrat ?

Le contrat reposant essentiellement sur le code des assurances français, le client est tenu à certaines obligations vis-à-vis de l’assureur, notamment sur le devoir d’information en cas de modification significative des risques sur son système d’information. Cette obligation se concrétise généralement par des réunions annuelles entre l’assureur, l’assuré et le courtier dans le but d’établir un bilan de l’évolution de la maturité du client et d’adapter le contrat en conséquence.

La souplesse dans l’évolution du contrat a deux principaux intérêts. Pour le client, il est de faire baisser le montant des primes en améliorant sa sécurité. Pour l’assureur, il est d’adapter le montant des primes en fonction de l’évolution du risque. Cette démarche encourage et valorise donc les travaux effectués en faveur de la sécurité du SI.

Comment déclencher les garanties ?

Les délais de notification en cas d’attaque constituent l’élément central du déclenchement. Le code des assurances rappelle : «L’assuré est obligé de donner avis à l’assureur, dès qu’il en a eu connaissance et au plus tard dans le délai fixé par le contrat, de tout sinistre de nature à entraîner la garantie de l’assureur. Ce délai ne peut être inférieur à cinq jours ouvrés » (Article L113-2). En cas de faute vis-à-vis de cette règle, le client peut se voir refuser ses garanties. L’enjeu est donc d’alerter au plus tôt l’assureur, même s’il n’y a que suspicion d’intrusion, mais aussi de cadrer les preuves à recueillir pour l’indemnisation – et ce dès l’établissement du contrat. Le déclenchement des garanties et le déblocage des fonds ne peuvent se faire que si  l’assureur a été notifié dans les délais, et l’évaluation du sinistre réalisée.

En fonction des assureurs, la mise à disposition d’experts peut relever d’une option ou ne pas être proposée. Le souscripteur doit par ailleurs veiller à bien préciser les modalités d’intervention de ces experts (obligation d’utiliser les prestataires de l’assureur, …).

Le processus de souscription est donc bien identifié et cadré. La connaissance la plus fine possible du marché ainsi que de ses propres risques sont des atouts indispensables pour bien choisir sa cyber-assurance. Cette dernière gagne considérablement en souplesse de négociation (périmètre, plafond, prime) de par la nouveauté de son marché, de son évolution rapide et de la concurrence naissante.

Retrouvez tous nos articles sur le secteur de l’assurance sur Insurance speaker, le blog assurance des consultants Solucom

Cet article Souscrire une cyber-assurance : mode d’emploi est apparu en premier sur RiskInsight.