Tout d’abord, fin septembre 2018 a été publié l’arrêté fixant les règles de sécurité et délais à respecter par les opérateurs de service essentiels (OSE) sur leurs SI essentiels (SIE).

Ensuite, le 9 novembre 2018 les dernières notifications ont été envoyées par l’ANSSI à une première vague d’Opérateurs de Services Essentiels, portant ainsi le nombre d’OSE à 122, chiffre qui sera amené à augmenter dans les mois et années à venir.

C’est donc l’occasion de décrypter la NIS dans sa déclinaison française, d’identifier les principales exigences émises par l’ANSSI et sous quels délais celles-ci devront être respectées par les OSE.

Des règles majoritairement inspirées de la LPM

La directive NIS demande à chaque Etat de définir et d’imposer le respect des bonnes pratiques de sécurité aux OSE et FSN. En France, c’est l’ANSSI qui a été responsable de cette définition, à l’instar de la LPM. Il est donc légitime de se demander dans quelle mesure les règles NIS sont alignées sur les règles LPM.

Des différences de forme sont tout d’abord à noter : les règles NIS sont au nombre de 23 réparties au sein de 4 chapitres (Gouvernance, Protection, Défense, Résilience), contre 20 pour la LPM sans chapitre particulier. Ensuite, ces règles ont été publiées au sein d’un unique arrêté trans-sectoriel, alors que la LPM avait mené à la publication d’un arrêté par secteur d’activité. Autre différence, les délais de mise en application des règles NIS sont communs à tous les secteurs et sont publics, là où les délais pour la LPM varient selon les secteurs et sont en diffusion restreinte.

Néanmoins, les règles NIS restent fortement inspirées (voire pour certaines intégralement reprises) des règles LPM : cartographie, configuration des composants, filtrage, comptes d’administration, SI d’administration, identification, droits d’accès, maintien en conditions de sécurité, journalisation, corrélation et analyse de journaux, réponse aux incidents de sécurité, traitement des alertes et également gestion de crise.

De nouvelles règles font leur apparition ; les règles relatives aux analyses de risques et aux audits de sécurité étaient en fait incorporées dans la règle LPM relative à l’homologation. La règle relative à la sécurité physique et environnementale est quant à elle une réelle nouveauté. De même, certaines règles existantes font l’objet de précisions sans pour autant apporter de modifications structurantes, notamment pour encadrer la façon de traiter certains cas particuliers (SIE exposé sur Internet, etc.).

Finalement, les principales différences portent sur l’assouplissement de certaines règles :

• Indicateurs : les trois thématiques retenues par les règles LPM sont maintenues par les règles NIS (maintien en conditions de sécurité, droits d’accès / authentification et administration des ressources), mais le nombre d’indicateurs total passe de 10 à 6.
• Détection : l’obligation d’utiliser des sondes qualifiées et opérées par un prestataire qualifié PDIS est remplacée par l’utilisation de sondes opérées conformément au référentiel PDIS, sans obligation de qualification
• De manière générale, les règles NIS n’imposent pas le recours à des prestataires dûment qualifiés PASSI (Prestataire d’Audit de la Sécurité des Systèmes d’Information), PDIS (Prestataire de Détection d’Incidents de Sécurité) ou PRIS (Prestataire de Réponse aux Incidents de Sécurité) mais recommandent de s’inspirer des bonnes pratiques que ces référentiels définissent.

Figure 1 : 80% de similarités entre les règles LPM et les règles NIS en France

Les règles NIS, malgré des différences de forme, sont donc globalement similaires à celles de la LPM, ce qui n’est pas surprenant puisqu’elles répondent au même objectif, celui de renforcer le niveau de sécurité des acteurs nationaux clés.

Un planning de mise en conformité ambitieux

Des actions concrètes à réaliser très rapidement

Les délais de mise en application sont publics. Concrètement, les premières actions attendues de chaque OSE après sa désignation sont les suivantes :

• Dans un délai de 2 mois, identification du correspondant auprès de l’ANSSI et communication de ses coordonnées
• Dans un délai de 3 mois, identification des SIE (Systèmes d’Information Essentiels) et transmission de la liste à l’ANSSI. Si le premier réflexe est souvent de vouloir définir le périmètre le plus restreint possible, et ainsi limiter les impacts, il faut garder à l’esprit que l’application partielle de certaines règles peut devenir un véritable casse-tête en raison de l’imbrication des SIE avec le reste du SI.
• Dans un délai de 3 mois, mise en place du processus de traitement des alertes. Objectif : se mettre rapidement en capacité de recevoir les alertes de l’ANSSI et savoir réagir en conséquence.

2 ans pour se mettre en conformité et réaliser l’homologation la 3^ème année.

Pour l’ensemble des autres règles, les délais sont tout aussi précis et ambitieux :

Figure 2 : règles NIS, 2 ans pour se mettre en conformité et une année supplémentaire pour l’homologation

Conclusion

En synthèse, il est important pour les entreprises notifiées d’anticiper dès la phase de cadrage que la mise en conformité NIS va amener des chantiers avec des investissements financiers et humains parfois conséquents. Notamment, les chantiers qui traiteront du « SI Administration », de « l’Homologation », ou encore les chantiers d’urbanisme nécessaires pour le cloisonnement des SIE, etc.

Autant de sujets qui bénéficieront de la maturité du marché impulsée depuis plusieurs années entre autres par la LPM.

Cet article Directive européenne NIS : quelles mesures de sécurité pour les opérateurs de services essentiels en France ? est apparu en premier sur RiskInsight.

La France finalise les textes pour se mettre en conformité avec la directive européenne NIS (Network and Information Security), avec trois textes qui transposent la directive dans le droit national Français, et un quatrième qui sera publié sous peu.

Quels ont été les choix de transposition de la directive NIS dans le droit national Français ? Et quelles seront les entreprises soumises à cette nouvelle législation et les impacts pour celles-ci ?

La transposition dans le droit national français

Pour entrer en vigueur, chaque Etat membre de l’Union européenne doit transposer la directive NIS dans son droit national, avec une date butoir fixée au 09 mai 2018 : spécification des mesures de sécurité à mettre en place, définition des procédures de notification, sanctions applicables…

La France respecte globalement ce calendrier, avec trois textes qui définissent en grande partie les modalités d’application de la directive NIS sur son territoire national :

• La loi n° 2018-133 du 26 février 2018 qui présente les mesures de transposition de la directive NIS dans la législation nationale,
• Le décret n° 2018-384 du 23 mai 2018 qui détaille les modalités d’application des obligations législatives, et liste les secteurs, les types d’opérateur et les services essentiels concernés,
• L’arrêté du 13 juin 2018 qui fixe les modalités de déclarations des incidents de sécurité.

Pour que la transposition de la directive européenne dans la législation Française soit complète, un dernier arrêté fondamental va être publié, et viendra préciser les mesures de sécurité à mettre en œuvre par les opérateurs de services essentiels. Il fera écho à la lettre de mise en demeure par la commission européenne, qui avait jugé la France en retard sur l’exhaustivité de la transposition dans le droit national, tout comme 16 autres Etats membres.

OSE et FSN : deux grandes typologies d’acteurs concernés

La loi française rappelle les deux grandes typologies d’acteurs concernés par la directive européenne : les Opérateurs de Services Essentiels (OSE) et les Fournisseurs de Services Numériques (FSN).

Opérateurs de services essentiels : la France élargit la liste des secteurs concernés

Les OSE sont les entités qui délivrent des services essentiels au fonctionnement de la nation, notamment au travers de leur Système d’Information Essentiel (SIE). Le décret n° 2018-384 complète la liste de la directive, en y ajoutant les secteurs de l’assurance, de la logistique, des produits pharmaceutiques, des services sociaux (partie paiement des prestations), de l’éducation et de la restauration collective dans les environnements sensibles.

Liste des secteurs d’activités concernés pour les OSE

(L’icône  précise les secteurs ajoutés par la législation Française par rapport à la Directive NIS)

La désignation des OSE sera effectuée par arrêtés du Premier Ministre d’ici novembre 2018, en lien avec les OSE, les Ministères concernés et l’ANSSI. La liste des OSE sera par la suite régulièrement actualisée, à minima tous les deux ans.

Fournisseurs de services numériques : la France veille à la bonne désignation des représentants

Les FSN sont les entités qui fournissent directement des services en ligne, de type sites d’e-commerce, moteurs de recherche ou services cloud, notamment utilisés par les OSE. Les Etats membres n’ont pas vocation à dresser la liste des FSN à l’échelle de leur territoire, mais la France pose pour autant un cadre en indiquant que les entreprises qui emploient moins de cinquante salariés et dont le chiffre d’affaire annuel n’excède pas 10 millions d’euros ne sont pas concernées.

Liste des secteurs d’activités concernés pour les FSN

En complément de la directive NIS, la France inscrit dans sa loi n° 2018-133 (Chapitre III, article 11) qu’un FSN établi hors de l’Union Européenne, qui offre ses services sur le territoire national et qui n’a désigné aucun représentant dans un autre Etat membre de l’Union européenne, procède à la désignation d’un représentant établi sur le territoire national auprès de l’ANSSI. La France se positionne ainsi en gardienne de la bonne application de la directive NIS en ce qui concerne les FSN, dans la mesure où un FSN qui tarderait à désigner un représentant en Europe serait donc légalement contraint de le faire en France.

Les exclusions : ne pas cumuler les exigences légales

Afin de ne pas surcharger de législations les acteurs déjà soumis à des règlementations plus contraignantes, la loi mentionne dans ses articles 2 et 5 la liste d’exclusions suivante :

• Les OSE ou les FSN soumis à des exigences sectorielles au moins aussi contraignantes que la présente législation, en particulier les OIV (Opérateurs d’Importance Vitale) sur leur SIIV (Système d’Information d’Importance Vitale) car déjà soumis aux exigences apportées par la Loi de Programmation Militaire,
• Les opérateurs de réseaux ou de services de communications électroniques, notamment car déjà soumis aux exigences du code des postes et des communications électroniques,
• Les prestataires de services de confiance soumis aux exigences du règlement eIDAS sur l’identification électroniques et les transactions électroniques.

Une législation plus stricte pour les OSE que pour les FSN

Le droit national Français traite des mêmes thématiques pour les OSE et les FSN, mais dans une approche différente : même si une base commune est définie, les OSE devront respecter une liste précise de mesures de sécurité, tandis que les FSN seront sur une approche par les risques (précisée par le règlement UE- 2018/151 du 30 janvier 2018), restant libres de prendre les mesures techniques et organisationnelles qu’ils jugent appropriées et proportionnées, et seront plutôt gérés à l’échelle européenne.

Une base commune d’obligations à respecter…

En premier lieu, l’identification d’un représentant de l’entreprise, qui sera le point de contact unique de l’ANSSI pour traiter les réceptions et les transmissions d’information,

Ensuite, la déclaration des réseaux et des systèmes d’information nécessaires à la fourniture du services essentiels / numériques, y compris ceux dont l’exploitation est confiée à des tiers. Au-delà d’un simple inventaire ou cartographie des actifs, les enjeux seront :

• De lister les éléments nécessaires à la délivrance des services essentiels / numériques, afin de ne pas imposer les mesures de sécurité sur un périmètre trop étendu de l’entreprise,
• D’exiger la mise en application de la règlementation sur les systèmes opérés par les tiers, en leur communiquant les mesures à implémenter, en révisant les contrats de sous-traitance, voir en auditant leur conformité.

Puis la déclaration des incidents de sécurité sans délai auprès de l’ANSSI (qu’il est conseillé de formaliser dans un processus), lorsqu’ils sont susceptibles d’avoir un impact significatif sur le service, en terme du nombre d’utilisateur impactés, de la zone géographique touchée, de la durée de l’incident… L’ANSSI pourra alors épauler l’entreprise sur le traitement de l’incident, notamment en activant le réseau des CSIRT.

Et enfin, l’obligation de se soumettre à des contrôles du respect des obligations ci-dessus, et qui devront faire l’objet de conventions et de rapports formalisés. Le 1^er ministre indiquera si ces contrôles seront effectués par l’ANSSI ou l’un des prestataires de services qualifiés PASSI (dans ce dernier cas, l’entreprise choisira le prestataire sur la liste qui lui sera communiquée).

… Mais des obligations complémentaires structurantes pour les OSE.

Contrairement à la liberté laissée aux FSN sur la manière de sécuriser leur services numériques, les OSE devront mettre en œuvre une démarche de sécurisation de leur SIE selon 4 grands principes imposés, qui seront bientôt détaillés par le futur arrêté :

• Gouvernance de la sécurité, via l’élaboration de politique de sécurité et d’homologation du SIE,
• Protection des SIE, avec la sécurité de l’architecture, de l’administration et des accès au SI,
• Défense des SIE, avec la détection et le traitement des incidents de sécurité,
• Résilience des SIE, notamment au travers de la gestion de crise.

Les opérations de contrôle pourront être déclenchées sans condition par le 1^er ministre pour les OSE, alors qu’elles ne seront menées chez les FSN que si le 1^er ministre est informé du non-respect d’une des obligations qui leur incombent.

Quels impacts financiers associés cette législation ?

Tout d’abord, la législation précise clairement que les OSE et les FSN devront financer leurs différentes actions de mise en conformité, mais également les contrôles demandés par l’ANSSI.

Ensuite, en cas de manquement à leurs obligations, les dirigeants des OSE et des FSN pourront écoper d’amendes, avec des montants supérieurs pour les OSE par rapport aux FSN :

L’ordre de grandeur et le principe des amendes sont quant à eux plus proches de ceux apportés par la Loi de Programmation Militaire que ceux du Règlement Général sur la Protection des Données (RGPD).

Quelles sont les prochaines étapes ?

La publication de l’arrêté qui précisera les règles de sécurité pour les OSE, indispensable pour compléter la transposition de la directive NIS dans le droit national Français. Il permettra de jauger le niveau de sécurisation souhaité par l’état Français, et d’en déduire l’effort de mise en conformité des SIE.

D’ici au mois de novembre, la désignation progressive des OSE, qui auront alors :

• Deux mois pour communiquer les coordonnées de leur représentant à l’ANSSI,
• Trois mois pour formaliser et transmettre la liste et la description des réseaux et systèmes d’information pour lesquels l’existence d’incidents pourrait gravement affecter la continuité des services essentiels au fonctionnement de la société ou de l’économie.

Pour les FSN, la désignation d’un représentant, avec deux cas possibles :

• Si le siège se situe en Union Européenne, déclaration auprès de l’autorité de l’Etat où se situe le siège,
• Si le siège se situe hors de l’Union Européenne, déclaration auprès d’une autorité d’un Etat membre où le FSN exerce son activité.

Les acteurs concernés par la directive NIS sont consultés en France et en Europe depuis plus d’un an et sont informés de leur potentielle désignation. Ils ne seront donc pas surpris le moment venu. Ces derniers peuvent d’ores et déjà lancer les premières actions de mise en conformité : identification du périmètre concerné, inventaire des réseaux et système d’information qui le composent, formalisation du processus de déclaration des incidents de sécurité aux autorités.

Des modalités de mise en œuvre qui restent à préciser aux niveaux national et local

Une fois que le dernier arrêté concernant les mesures de sécurité pour les OSE sera publié, le cadre législatif et règlementaire Français posera des bases claires d’application de la directive NIS, par ailleurs cohérentes avec les différentes règlementations déjà en place sur le sujet.

En revanche, des questions restent à trancher au niveau européen pour faciliter la gestion des acteurs transfrontaliers : rattachement d’un OSE à plusieurs Etats membres ? Désignation d’une autorité de référence ? Communications et hiérarchie entre autorités nationales ?… Autant d’enjeux à adresser rapidement par le groupe de coopération dédié à NIS, en place depuis février 2017.

Cet article Directive européenne NIS : quelle transposition dans le droit français et quel impact pour les entreprises ? 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.

La directive NIS : un texte majeur

Au niveau national, la directive requiert notamment l’établissement d’une stratégie cybersécurité et la mise en place d’un CSIRT ainsi que d’une autorité en charge de ces sujets. Pour les entreprises, elle introduit deux volets d’obligation pour deux types d’acteurs :

• Les Opérateurs de Services Essentiels doivent mettre en œuvre des mesures techniques et organisationnelles pour gérer les risques menaçant la sécurité des réseaux et et des systèmes d’information
• Les Fournisseurs de Services Numériques sont tenus de notifier les incidents de sécurité à l’autorité compétente

La nécessité d’orientations fortes et communes

La directive NIS est le pendant sécurité de la stratégie européenne du Marché Unique Numérique, lancée en 2015, qui vise à faire du numérique un moteur de la croissance : la confiance des entreprises et des consommateurs est indispensable pour ce projet, car sans confiance, pas de croissance !

Les pays européens sont de plus en plus dépendants du numérique et des systèmes d’information, et leurs réseaux sont de plus en plus reliés. Et cette interconnectivité fait leur force comme leur faiblesse, puisque le niveau de sécurité d’un système d’information est équivalent à celui de son point le plus faible.

Or, on observe une très forte hétérogénéité entre les Etats Membres au regard de ces enjeux, étant donné que la prise en charge de la cybersécurité se faisait jusqu’ici au niveau national.

C’est à ce risque systémique que l’Europe cherche à remédier avec la directive NIS. Il s’agit de la première législation européenne régissant les pratiques cybersécurité de façon cross-sectorielle.

Elle se démarque des textes spécifiques à une problématique particulière, tels que le GDPR. Souvent associé à la directive NIS, il n’a pourtant pas les mêmes objectifs puisqu’il se concentre sur le seul périmètre de la protection des données personnelles tandis que la directive vise à assurer un certain niveau de cybersécurité via la définition de standards de sécurité et la notification des incidents (qu’ils touchent à des données personnelles ou non). Reste qu’une cyber-attaque mettra souvent en jeu les deux domaines, et qu’il fait donc sens de ne pas considérer ces deux textes séparément lors de la mise en conformité.

Un processus de transposition déjà engagé

Le texte étant une directive et non un règlement, il est nécessaire que chaque Etat Membre transpose ces orientations dans son cadre législatif national.

De nombreux pays ont déjà annoncé des premières mesures s’inscrivant dans le cadre de la directive :

• Le Royaume-Uni a confirmé son intention de transposer le texte malgré le Brexit ; le montant des pénalités prévues dans le texte vient d’être communiqué et celles-ci sont particulièrement importantes
• La Pologne a annoncé l’ouverture d’un nouveau centre national dédié à la cybersécurité (NC Cyber) ;
• La Belgique a présenté six mesures phares pour renforcer la cybersécurité, à la suite de WannaCry, cyberattaque mondiale qui a paralysé de nombreuses entreprises le mois dernier ;
• La République Tchèque a amendé sa loi cybersécurité pour prendre un compte plus de secteurs critiques et se conformer aux exigences de la directive ;
• L’Italie a révisé son Plan National pour la Cyber Protection et la Sécurité Digital, en accord avec les orientations données par la directive ;
• La Croatie a mis en place un groupe de travail pour préciser les modalités de transposition de la directive ;
• La Suède a d’ores et déjà fourni des détails sur la transposition, tels que l’ordre de grandeur des pénalités applicables, ou encore les entités responsables de la mise en œuvre.

Sur un certain nombre d’aspects, le texte est très peu directif et fixe des objectifs sans imposer de moyens. Il est du ressort de chaque pays de travailler à l’interprétation et de définir des mesures plus concrètes permettant l’atteinte de ces objectifs.

L’enjeu est donc d’atténuer l’hétérogénéité entre les pays européens et de parvenir à lisser le niveau de cybersécurité en limitant les écarts trop importants, afin de réduire la complexité de mise en conformité pour les acteurs présents dans plusieurs pays.

Pour ce faire, une collaboration structurée s’organise à l’échelle de l’UE :

• Une révision du mandat de l’ENISA, l’agence européenne en charge de la sécurité des réseaux et de l’information, est à l’étude, avec entre autres l’objectif de lui donner la latitude nécessaire à l’accomplissement des missions relatives à la directive ;
• Un Groupe de Coopération, composé de représentants nationaux ainsi que de l’ENISA et la Commission Européenne, donnera des orientations stratégiques ;
• Un réseau de CSIRT s’organise aussi, et sera en mesure d’assurer la communication et l’échange de bonnes pratiques, ainsi que d’appuyer les Etats Membres pour les sujets relatifs à la directive.

Comment se préparer à l’arrivée de la directive ?

Concrètement, comment anticiper dès maintenant ce nouveau texte et quel plan d’actions déployer ? Cela dépend en pratique du type de structure (OSE ou FSN).

Concernant les fournisseurs de service numériques (FSN), une approche harmonisée est requise : les Etats Membres ne peuvent pas imposer d’autres exigences liées à la sécurité ou aux notifications, et en ce sens, la directive se rapproche d’un règlement pour ce type d’acteur. Cette singularité par rapport aux OSE provient du caractère transfrontalier de leurs activités et du fait que beaucoup sont des entreprises étrangères non implantées sur le territoire européen, qui devront désigner un représentant basé dans un Etat Membre pour être l’interlocuteur attitré concernant les questions liées à NIS (Article 18 de la directive). Il est donc essentiel que chaque pays impose les mêmes obligations, dans l’objectif d’éviter que le choix du pays d’implantation ne soit orienté par ce critère.

Les obligations pour les FSN sont d’ailleurs un peu moins contraignantes : par exemple, ils ne sont dans l’obligation de notifier un incident que s’ils ont accès aux informations nécessaires pour évaluer son impact au regard des critères définis dans la directive (Article 16).

D’ici le 9 août prochain, la Commission Européenne publiera les actes d’exécution et il sera alors possible de commencer le processus de mise en conformité.

Pour les Opérateurs de Services Essentiels (OSE), en France, il y a deux principaux cas de figure.

D’abord, les opérateurs déjà identifiés comme OIV, opérateurs d’importance vitale, dans le cadre de la Loi de programmation militaire française (LPM). Pour eux, l’enjeu de mise en conformité est moins significatif, puisque la LPM introduit déjà de nombreuses obligations ; la directive n’en introduira probablement pas de plus exigeantes. Quelques éléments tels que le reporting pourraient être à adapter, mais il n’y a pas de changement majeur à prévoir.

Toutefois le périmètre de la directive est susceptible d’être plus large que celui de la LPM, et certains opérateurs des secteurs critiques définis par chaque Etat devront alors commencer leur mise en conformité. Les Etats Membres ont jusqu’à novembre 2018 pour désigner les OSEà partir des critères définis dans le texte. La liste des opérateurs désignés sera ensuite passée en revue par la Commission Européenne en mai 2019.

Les structures concernées devront ensuite mettre en place une veille juridique pour suivre l’évolution du processus de transposition, puisque pour les OSE, les Etats Membres sont en droit d’imposer des mesures allant au-delà du socle commun défini par la directive.

Beaucoup de chantiers restent maintenant à mener par les Etats Membres : spécification des mesures de sécurité à mettre en place, définition des procédures de notification, sanctions applicables, sans oublier la désignation des secteurs critiques et des OES par chaque pays.

On assiste ainsi à un véritable renouveau du paysage législatif de la cybersécurité en Europe visant avant tout à homogénéiser le niveau de sécurité des SI entre états membres, dont il sera intéressant de suivre l’évolution.

Cet article Directive NIS : quels enjeux et comment s’y préparer ? 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.

La directive NIS fixe un cap

Comme l’indique son nom, la directive NIS n’est ni une loi, ni un règlement. Elle donne un objectif à atteindre, mais laisse le choix des moyens pour y arriver. Comme pour toute directive, elle doit être transposée par chacun des pays membres en lois qui fixeront les moyens pour y arriver. La LPM française ou le IT Security Act allemand en sont des exemples. L’ANSSI a récemment annoncé être en charge du pilotage de la déclinaison en France.

Il est possible de diviser les obligations données par la directive en trois catégories :

• Définition d’un modèle de gouvernance national (articles 5,6,7) : chaque État membre doit adopter une stratégie nationale, en définissant des objectifs et une législation appropriée dans le but d’atteindre un haut niveau de sécurité national.
  Pour cela chaque pays doit se doter au moins d’une autorité compétente, chargée de la transposition de la directive en loi. Cette autorité peut être unique, comme c’est le cas en France avec l’ANSSI, ou peut être divisée selon les différents secteurs essentiels. Les dites-autorités sont invitées à se rapprocher de l’ENISA (Agence européenne chargée de la sécurité des réseaux et de l’information) pour obtenir de l’aide.
  De même, un CSIRT (Computer Security Incident Response Team) national doit être désigné. En charge de la gestion d’incident nationaux, il a pour mission d’alerter et de partager sur les risques et les incidents, et de reporter les notifications d’incidents aux entités adéquates. Enfin, un point de contact unique doit être désigné pour participer à la coopération transfrontalière sur les objectifs stratégiques et les moyens mis en place.

• Mise en place de mesures de sécurité et de systèmes de notification d’incident pour les opérateurs de services essentiels (article 14 et 15a) : les entités identifiées par les pays comme indispensables à la pérennité d’activités critiques (économiques ou sociales) doivent mettre en place des mesures pour appréhender les risques ainsi que leurs impacts. Ces opérateurs ont également l’obligation de notifier immédiatement à l’autorité compétente tout incident dont la nature pourrait impacter significativement la continuité du service. La notion d’impact,laissée à la libre évaluation de l’entité, dépend du nombre d’utilisateurs touchés, de la durée de l’incident et de la portée géographique.
  La directive impose des actions similaires aux « fournisseurs de services numériques ». Ces fournisseurs correspondent aux les places de marchés en ligne, les moteurs de recherches, les services cloud, à l’exception des TPE et des microentreprises (2003/361/EC). Leurs obligations sont légèrement moindres (règles spécifiques au niveau des États et obligation de notifications plus restreintes), comme leurs activités ne nuiront pas directement à la vie des personnes, mais plutôt à l’économie.

• Participation aux initiatives de partage d’information et collaboration (article 8) : Lors de la présentation de la directive, le vice-président de la Commission Européenne en charge du Marché unique numérique, Adrus Ansip, et le Commissaire européen à l’Économie et à la Société numérique, Günther H. Oettinger, ont insisté sur la nécessité d’une coopération entre les institutions publiques européennes et nationales avec les acteurs privés. Ils ont également rappelé l’importance de la standardisation pour faciliter les échanges inter-frontaliers. Une réponse à ces besoins se traduit par la création d’un réseau de CSIRT et d’un groupe de coopération stratégique composé de représentants des pays membres de la Commission Européenne et de l’ENISA.

La directive NIS en renfort de la LPM

En France, la directive NIS vient accroître la légitimité de la Loi de programmation militaire dont certains arrêtés ont été publiés le 23 juin dernier.

Plusieurs différences sont toutefois notables entre le texte européen et la loi française, notamment dans la partie concernant les obligations des entreprises.

• Alors que la France a identifié 12 secteurs d’importance vitale (SIV), la directive NIS n’en reconnait que 6 (énergie, transport, banques, distribution et provision d’eau potable, infrastructures financières, santé) auxquels s’ajoutent les fournisseurs de services numériques non couverts par la LPM actuelle. Ces fournisseurs ont été estimés à près de 1400 pour l’ensemble du territoire européen. De plus, certains secteurs comme l’industrie ne sont pas inclus dans la démarche, et ne profiteront pas de l’impulsion donnée au sommet de l’Europe.
• Au sein d’un même secteur, les opérateurs concernés ne seront pas forcément identiques. En effet, la directive NIS ne considère que ceux dont l’activité dépend fondamentalement des réseaux et des systèmes d’information.
• Bien que les obligations pour les entités considérées comme sensibles soient similaires, la LPM va un cran plus loin et requière que les organisations identifiées dans le secteur d’importance vitale soient auditées par des prestataires qualifiés, alors que cela n’est pas rendu obligatoire par le texte européen. Chaque pays sera libre d’adapté le texte.

En définitive, les opérateurs des secteurs d’importance vitale français ayant initié un processus de mise en conformité à LPM seront globalement en accord avec les objectifs fixés par la directive. En revanche, certaines organisations devront mettre en place des mesures pour identifier et réduire les risques, en particulier celles du secteur de fournisseurs de services numériques car non concernées par la LPM.

21 mois pour s’aligner à la directive

La directive NIS entrera en vigueur 20 jours après publication au Journal Officiel de l’Union Européenne, c’est-à-dire en août 2016. Suite à cela, les différents États membres disposeront de 21 mois pour transposer cette directive en lois nationales. Une période de 6 mois supplémentaire sera donnée pour identifier les opérateurs de services essentiels correspondants aux secteurs identifiés.

Afin d’aligner la gouvernance nationale avec le cap fixé par la directive NIS, il restera un certain nombre d’interrogations auxquelles devra répondre chacun des pays de l’UE : Qui va prendre en charge cette transposition ? Combien d’autorités compétentes ou de CSIRT désigner à l’échelle nationale ? Quels moyens faut-il mettre à disposition ? Est-il nécessaire d’écrire de nouvelles lois ou simplement faire des amendements d’anciennes lois ?

La directive NIS est un pas important pour obtenir une cybersécurité unifiée à l’échelle européenne et c’est devenu une nécessité, car les cybercriminels eux, ne connaissent pas les frontières.

Cet article Directive NIS : Une confiance accrue dans le cyberespace européen 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.

Le cyberespace, talon d’Achille de l’Europe

En l’absence de sécurité suffisante, cette dépendance des États comme des entreprises peut rapidement se transformer en talon d’Achille. Elle peut en effet offrir à des individus, des organisations ou des États la possibilité de voler des secrets industriels ou des données en grande quantité, de détourner des fonds ou, pire, de détruire le potentiel économique ou de survie d’un État.

À titre d’exemple, en 2015 au Royaume-Uni, 90% des grandes entreprises et 74% des petites entreprises ont subi une cyberattaque. Par ailleurs – en guise d’illustration des conséquences financières atteignables – la cyberattaque subie par Talk Talk lui a couté au total plus de 75 millions d’euros. Enfin, la cyberattaque contre la centrale électrique ukrainienne démontre parfaitement le caractère potentiellement destructeur pour les États des cyberattaques contre leurs infrastructures critiques.

Face à un cyberespace qui est autant créateur de richesses que source de menaces, comment l’Union européenne prépare-t-elle sa cyber protection ?

Entre hétérogénéité, volonté d’harmonisation et désir de coopération

Aujourd’hui, l’Europe de la cybersécurité repose essentiellement sur des États européens qui avancent en ordre dispersé lorsqu’il s’agit de se prémunir contre les cybermenaces ; il existe en effet une forte hétérogénéité entre les pays membres dans leur sensibilité et leur niveau de préparation en matière de cybersécurité, et peu d’initiatives associant deux ou plusieurs États sont mises en œuvre.

Sans surprise, la question de la cybersécurité se pose avec plus d’acuité aux principales puissances économiques et militaires européennes, qui ont le plus d’intérêt et le plus de capacités financières et technologiques pour se prémunir contre les menaces venues du cyberespace.

Avec le Royaume-Uni et l’Allemagne, la France fait partie de ces États, créant dès 2008 l’ANSSI , l’autorité étatique dédiée à la cybersécurité, et se dotant dès 2013 d’un cadre juridique imposant aux Opérateurs d’Importance Vitale de protéger leurs systèmes d’importance vitale (article 22 de la loi de programmation militaire). À cela s’ajoute la mise en œuvre de moyens civils et militaires dédiés à la protection contre les cybermenaces.

Outre-Rhin nous pourrions par exemple citer une loi adoptée en 2015 visant à accroître la cybersécurité des OIV allemands, ainsi que la coopération étroite qui lie l’ANSSI et son homologue allemand, le BSI (Bundesamt für Sicherheit in der Informationstechnik), depuis plus de cinq ans.

Outre-Manche le gouvernement britannique a annoncé en 2015, 1,9 milliards de livres sur cinq ans pour renforcer la cybersécurité du pays.
Depuis quelques années, et face aux enjeux économiques que représente la cybersécurité pour la communauté européenne, les autorités de l’Union entendent participer davantage à la protection contre les cybermenaces, notamment en harmonisant la législation.

Depuis 2005, la Convention de Budapest , conçue par le Conseil de l’Europe, fournit par ratification à tout pays une trame et des outils juridiques leur permettant de mieux se prémunir contre la cybercriminalité.

Par ailleurs, la directive Network and Information Systems (NIS), prochainement adoptée, harmonisera automatiquement à l’échelle européenne les obligations des opérateurs de services essentiels (dénomination issue de la directive NIS) pour la protection de leurs systèmes d’information. Dans le même temps le futur règlement européen sur la protection des données personnelles devrait accroître la maîtrise des organisations sur les données qu’elles collectent, traitent et stockent, et donc limiter les conséquences des cyberattaques en terme de fuite.

Enfin, il a été annoncé par la Commission européenne lors du FIC 2016 que la cybersécurité fera, dans un avenir proche, de plus en plus partie des textes européens à portée sectorielle.

La directive NIS définit en outre une gouvernance européenne de la cybersécurité, inédite et résolument tournée vers la coopération entre les instances européennes (Commission européenne, ENISA – Agence Européenne chargée de la sécurité des réseaux et de l’information -, CERT-EU – Computer Emergency Response Team -)  et entre les États membres.

Deux nouveaux organes seront donc créés :

• Un groupe de coopération chargé de soutenir et de faciliter la coopération stratégique entre les États membres, notamment à travers l’échange d’informations et de bonnes pratiques. Ce groupe réunira la Commission européenne, l’ENISA et les représentants des États membres.
• Un réseau de CSIRTs (Computer Security Incident Response Team), regroupant le CERT-EU et le CSIRT de chaque État membre dont l’existence est rendue obligatoire par la directive. Il est chargé de promouvoir la coopération opérationnelle entre les États membres. L’ENISA assurera le secrétariat de ce réseau et la Commission européenne aura un statut d’observateur.

Des défis qui appellent une volonté politique commune

Ces initiatives européennes – complémentaires des initiatives des États les plus avancés en matière de cybersécurité – sont évidemment salutaires, mais ne doivent pas faire oublier les défis, politiques et économiques, que l’Europe devra dépasser afin de disposer d’une cybersécurité efficace et assurant sa cyber résilience.

Au défi que pose la coopération de 28 États membres s’ajoute la question des moyens qui permettront sa mise en œuvre effective, tant au niveau stratégique qu’opérationnel. Nul doute que les États déjà en avance pérenniseront leurs efforts. Mais quid des autres États, les plus nombreux : mobiliseront-ils les moyens suffisants pour se protéger ? La problématique des moyens se pose aussi au niveau de la gouvernance européenne : à titre d’exemple le budget de l’ENISA est de seulement 10,1 millions d’euros. Ce budget est-il réellement à la hauteur des enjeux ?

Par ailleurs, comment envisager une Europe de la cybersécurité sans une véritable industrie européenne de la cybersécurité ? De l’aveu de la Commission européenne, l’offre européenne est encore trop fragmentée et portée par des acteurs qui n’ont pas encore atteint une taille suffisante, portant préjudice à leur compétitivité face aux multinationales, américaines notamment. Mais une industrie suffisamment puissante économiquement, sachant produire des produits et services européens, est aussi un enjeu de souveraineté. À l’heure de la compétition économique mondiale, peut-on bâtir une Europe de la cybersécurité avec du matériel et des services chinois ou américains ?

On ne peut que saluer les efforts que compte produire l’Europe en matière de cybersécurité dans les prochaines années. Stimulé par des cybermenaces toujours plus nombreuses, ce projet pourra-t-il s’appuyer sur une volonté politique et des actions communes et durables ? Ou bien la dynamique européenne lancée s’essoufflera-t-elle faute d’une volonté politique commune suffisante, laissant les États membres en ordre dispersé au sujet de la cybersécurité, à l’image de l’Europe de la sécurité ou de la défense ?

Cet article L’Europe de la cybersécurité : peut-on y croire ? 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.