guide_homologation_de_securite_en_9_etapes

L’HOMOLOGATION DE SÉCURITÉen neuf étapes simples

Pourquoi l’homologation de sécurité ?Lorsqu’un responsable (autorité administrative, élu, dirigeant d’entreprise)décide de faire déménager ses équipes dans de nouveaux locaux ou d’ouvrirun établissement recevant du public, il s’assure que les lieux sont conformes àla réglementation et que les bâtiments sont solides, afin que l’ensemble puissefonctionner en toute sécurité pour les personnes et les biens. Il doit s’en assurermême s’il n’est pas un spécialiste de la construction et il s’appuie pour celasur des garanties et des arguments portés à sa connaissance par des experts dudomaine.En matière d’informatique, l’homologation de sécurité joue le même rôle. Ellepermet à un responsable, en s’appuyant sur l’avis des experts, de s’informer etd’attester aux utilisateurs d’un système d’information que les risques qui pèsentsur eux, sur les informations qu’ils manipulent et sur les services rendus, sontconnus et maîtrisés. L’homologation est d’autant plus nécessaire, aujourd’hui,que les systèmes d’information sont de plus en plus complexes et que les impactspotentiels d’un incident sont de plus en plus graves.La démarche d’homologation, recommandée depuis plusieurs années parl’Agence nationale de la sécurité des systèmes d’information (ANSSI), est doncun préalable à l’instauration de la confiance dans les systèmes d’information etdans leur exploitation.Pour un certain nombre de systèmes, cette recommandation est rendue obligatoirepar des textes, tels que l’instruction générale interministérielle n° 1300,le référentiel général de sécurité (RGS) et la politique de sécurité des systèmesd’information de l’État (PSSIE).1

Qu’est-ce qu’une homologation de sécurité ?En informatique, comme dans les autres domaines, le risque zéro n’existe pas.La démarche d’homologation de sécurité est destinée à faire connaître et fairecomprendre aux responsables les risques liés à l’exploitation d’un système d’information.Il s’agit d’un processus d’information et de responsabilisation qui aboutit à unedécision, prise par le responsable de l’organisation. Cette décision constitue unacte formel par lequel il :••atteste de sa connaissance du système d’information et des mesures desécurité (techniques, organisationnelles ou juridiques) mises en œuvre ;••accepte les risques qui demeurent, qu’on appelle risques résiduels.La décision s’appuie sur l’ensemble des documents que le responsable estimenécessaire et suffisant à sa prise de décision.La démarche d’homologation doit être adaptée aux enjeux de sécurité du système,notamment au contexte d’emploi, à la nature des données contenues, ainsiqu’aux utilisateurs :• • dans les cas de systèmes complexes ou à fort enjeu de sécurité, il est souhaitableque le responsable s’entoure d’experts techniques et fonctionnels(la commission d’homologation). Il peut déléguer la prise de décision àl’un de ses représentants qui présidera ce comité d’experts ;• • dans le cas de systèmes simples, le responsable peut mettre en place desprocédures simplifiées associant un nombre plus limité d’acteurs.2

Comment homologuer un système d’information ?La démarche d’homologation peut être décomposée en neuf étapes, dont lamise en œuvre est directement liée à la complexité du système à homologuer.Les questions posées lors de ces neuf étapes permettent de constituer un dossier,sur lequel l’autorité d’homologation s’appuie pour prendre sa décision.Définition de la stratégie d’homologationÉtape n° 1 : Quel système d’information dois-je homologuer et pourquoi ?Définir le référentiel réglementaire applicable et délimiter le périmètre du système àhomologuer.Étape n° 2 : Quel type de démarche dois-je mettre en œuvre ?Estimer les enjeux de sécurité du système et en déduire la profondeur nécessaire de ladémarche à mettre en œuvre.Étape n° 3 : Qui contribue à la démarche ?Identifier les acteurs de l’homologation et leur rôle (décisionnaire, assistance, expertisetechnique, etc.).Étape n° 4 : Comment s’organise-t-on pour recueillir et présenter les informations?Détailler le contenu du dossier d’homologation et définir le planning.Maîtrise des risquesÉtape n° 5 : Quels sont les risques pesant sur le système ?Analyser les risques pesant sur le système en fonction du contexte et de la nature del’organisme et fixer les objectifs de sécurité.3

Étape n° 6 : La réalité correspond-elle à l’analyse ?Mesurer l’écart entre les objectifs et la réalité.Étape n° 7 : Quelles sont les mesures de sécurité supplémentaires à mettre enœuvre pour couvrir ces risques ?Analyser et mettre en œuvre les mesures nécessaires à la réduction des risques pesant surle système d’information. Identifier les risques résiduels.Prise de décisionÉtape n° 8 : Comment réaliser la décision d’homologation ?Accepter les risques résiduels : l’autorité d’homologation signe une attestation formelleautorisant la mise en service du système d’information, du point de vue de la sécurité.Suivi a posterioriÉtape n° 9 : Qu’est-il prévu pour maintenir la sécurité et continuer de l’améliorer?Mettre en place une procédure de révision périodique de l’homologation et un pland’action pour traiter les risques résiduels et les nouveaux risques qui apparaîtraient.4

Table des matièresObjectifs de l’homologation de sécuritéÉtape n° 1 : Quel système d’information dois-je faire homologueret pourquoi ?Étape n° 2 : Quel type de démarche dois-je mettre en œuvre ?Étape n° 3 : Qui contribue à la démarche ?Étape n° 4 : Comment s’organise-t-on pour recueillir et présenterles informations ?Étape n° 5 : Quels sont les risques pesant sur le système ?Étape n° 6 : La réalité correspond-elle à l’analyse ?Étape n° 7 : Quelles sont les mesures de sécurité supplémentairespour couvrir ces risques ?Étape n° 8 : Comment réaliser la décision d’homologation ?Étape n° 9 : Qu’est-il prévu pour continuer d’améliorer la sécurité ?Conseils pratiquesAnnexe 1 : Estimation rapide du besoin de sécurité d’un systèmed’informationAnnexe 2 : Estimation rapide du niveau de maturité de l’organismeAnnexe 3 : Liste des documents pouvant être contenus dans un dossierd’homologationAnnexe 4 : Liste de menaces, issue de la base de connaissanceEBIOS79131723293337414548525961715

Objectifs de l’homologation de sécuritéEn informatique, comme dans les autres domaines, le risque zéro n’existe pas.L’objectif de la démarche d’homologation d’un système d’information (SI) est detrouver un équilibre entre le risque acceptable et les coûts de sécurisation, puisde faire arbitrer cet équilibre, de manière formelle, par un responsable qui aautorité pour le faire.Cette démarche permet d’améliorer la sécurité pour un coût optimal, enévitant la « sur-sécurité », mais en prenant également en compte le coût d’unéventuel incident de sécurité. Elle permet de s’assurer que les risques pesantsur le SI, dans son contexte d’utilisation, sont connus et maîtrisés de manièreactive, préventive et continue.La démarche d’homologation doit s’intégrer dans le cycle de vie du systèmed’information. Elle comprend plusieurs étapes clés, détaillées au sein duprésent document. Il est nécessaire de les suivre en même temps que les phasesde développement du système : opportunité, faisabilité, conception, réalisation,validation, exploitation, maintenance et fin de vie. En outre cette démarchedoit être lancée suffisamment tôt, afin de pouvoir déterminer les exigences desécurité qui seront intégrées dans les cahiers des charges de développement oud’acquisition.La décision d’homologation est le résultat du processus. Son objet est devérifier que le responsable a analysé les risques de sécurité et a mis en œuvre lesdispositifs adaptés à la menace.Le terme « homologation » recouvre donc deux notions distinctes :••la démarche d’homologation, avant tout destinée à faire connaître etfaire comprendre aux responsables les risques liés à l’exploitation d’unsystème d’information. Elle se conclut par une décision, soutenue par laconstitution et l’analyse d’un dossier de sécurité ;••la décision formelle d’homologation (également appelée attestation formelle).7

Se lancer dans une démarche d’homologation est relativement simple : il s’agitde vérifier que la sécurité n’a pas été oubliée avant la mise en place du systèmed’information et d’appliquer les mesures de sécurité nécessaires et proportionnées.Les neuf étapes simples présentées dans ce document permettront à unchef de projet ou à un comité de pilotage SSI de préparer un dossier d’homologationet de le présenter au responsable, désigné autorité d’homologation.L’autorité d’homologation pourra alors prendre une décision éclairée surla base de ce dossier, qui doit apporter des réponses pertinentes à l’ensemble desquestions qu’elle se pose.8

1étape n°Quel système d’information dois-jefaire homologuer et pourquoi ?

QUEL SYSTÈME D’INFORMATION DOIS-JE FAIRE HOMOLOGUER ET POURQUOI ?Durant la première étape, vous allez préciser le référentiel réglementaireapplicable et délimiter le périmètre du système à homologuer.1 . Préciser le référentiel réglementaireLa démarche d’homologation est recommandée depuis plusieurs années parl’Agence nationale de la sécurité des systèmes d’information (ANSSI). Pour uncertain nombre de systèmes, cette recommandation est rendue obligatoire par :••l’instruction générale interministérielle n° 1300 (IGI 1300), pour lessystèmes traitant d’informations classifiées de défense ;••le référentiel général de sécurité (RGS), pour les systèmes permettantdes échanges entre une autorité administrative et les usagers ou entreautorités administratives ;••la politique de sécurité des systèmes d’information de l’État (PSSIE),pour les systèmes des administrations de l’État.Il est indispensable de déterminer à quel titre le système d’information doit êtrehomologué. En effet, même si la démarche d’homologation reste identique danstous les cas, le référentiel réglementaire constitue un élément crucial pour ladélimitation du périmètre et la constitution du dossier d’homologation.2 . Délimiter le périmètre du systèmeLe périmètre du système d’information à homologuer doit comporter tous leséléments indispensables au fonctionnement du système. La délimitation du périmètrene doit comporter aucune ambiguïté, car elle permet de déterminer etde caractériser précisément les systèmes qui seront homologués. La descriptionde ce périmètre comprend :••des éléments fonctionnels et d’organisation : fonctionnalités du sys-10

QUEL SYSTÈME D’INFORMATION DOIS-JE FAIRE HOMOLOGUER ET POURQUOI ?tème, type d’utilisateurs, contexte et règles d’emploi, procédures formalisées,conditions d’emploi des produits de sécurité, gestion des droits,dispositifs de détection et de gestion des incidents ;••des éléments techniques : architecture du système (en précisant notammentles interconnexions avec d’autres systèmes), possibilité d’utilisationde supports amovibles, d’accès à distance ou de cloisonnement, mécanismesde maintenance, d’exploitation ou de télégestion du système,notamment lorsque ces opérations sont effectuées par des prestatairesexternes ;••le périmètre géographique et physique : localisations géographiques etcaractéristiques des locaux.Le périmètre peut évoluer au cours de la démarche d’homologation, mais ilest recommandé d’aboutir rapidement à une délimitation stable de celui-ci. Ilest également recommandé d’appliquer une démarche d’homologation pourchaque service applicatif ou système d’information.Les questions qui se posent à la première étapeLe système d’information est (ou sera) composé de certainesbriques matérielles et logicielles que je ne maîtrise pas, car je lesachète à un industriel, un éditeur ou un intégrateur. Commentgarantir leur niveau de sécurité ?Lorsque ces briques sont des composants essentiels de sécurité, elles doivent de préférencefaire l’objet d’une labellisation de sécurité (qualification ou à défaut certification).Lorsque ces briques sont des composants essentiels de la fonction applicative, il faut11

QUEL SYSTÈME D’INFORMATION DOIS-JE FAIRE HOMOLOGUER ET POURQUOI ?exiger auprès du fournisseur un cahier de sécurité, qui offre des garanties, préciseles conditions d’emploi et définit des règles de sécurité. Le cas échéant, des audits decode peuvent être réalisés (cf. étapes suivantes).Ces documents sont versés au dossier d’homologation du système.Plusieurs services applicatifs, nécessitant chacun une homologation,sont hébergés sur une même plate-forme technique avec desressources mutualisées. Dois-je inclure la plate-forme dans toutesles homologations ?Dans ce cas, il est recommandé d’homologuer séparément la plate-forme technique,en étudiant les risques qui lui sont propres et qui impactent potentiellement tous lesservices applicatifs qu’elle héberge.J’aurais dû faire homologuer le système d’information avant samise en service, mais je ne l’ai pas fait et le service est opérationnel.Est-il trop tard ?Non. La démarche d’homologation doit s’inscrire dans un processus itératif d’améliorationcontinue de la sécurité. Il est préférable et plus efficace de la démarreravant les phases de développement et d’intégration, mais si le service est déjà opérationnel,les objectifs de l’homologation restent les mêmes.Le contenu du dossier d’homologation sera légèrement différent et certaines mesuresde sécurité ne pourront être mises en œuvre que lors des prochaines évolutions dusystème.Si les risques identifiés sont trop importants et que les mesures de sécurité sontimpossibles à mettre en œuvre, il faut envisager l’arrêt du service.12

2étape n°Quel type de démarche dois-jemettre en œuvre ?

QUEL TYPE DE DÉMARCHE DOIS-JE METTRE EN ŒUVRE ?Durant la deuxième étape, vous allez définir le niveau de profondeurde la démarche d’homologation, afin que celle-ci soit adaptée aux enjeuxde sécurité du système, d’une part, et aux capacités de votre organismeà la mener, d’autre part.La démarche la plus adaptée à l’homologation du système doit être définie enfonction du contexte, du niveau de complexité et de criticité du système, duniveau de sensibilité des données hébergées et du niveau de maturité en matièrede SSI de l’organisme qui met en œuvre l’homologation.1 . Autodiagnostiquer les besoins de sécurité dusystème et le niveau de maturité SSI de l’organismeDeux outils d’autodiagnostic vous sont proposés. Ils sont détaillés en annexe duprésent document.L’annexe 1 permet d’évaluer les besoins de sécurité du système d’informationà homologuer, en estimant la gravité des conséquences potentielles d’unedéfaillance du SI, la sensibilité des données, le degré d’exposition aux menaceset l’importance des vulnérabilités potentielles du système.Un questionnaire simple et rapide vous permet de déterminer si le besoinde sécurité du système est nul, faible, moyen ou fort.L’annexe 2 permet de déterminer le niveau de maturité SSI de l’organisme,c’est-à-dire le niveau de maîtrise et de rigueur atteint par l’organisme,dans la gestion de la sécurité des systèmes d’information.Un questionnaire simple et rapide vous permet de déterminer si la maturitéSSI de votre organisme est élémentaire, moyenne ou avancée.14

QUEL TYPE DE DÉMARCHE DOIS-JE METTRE EN ŒUVRE ?2 . En déduire la démarche appropriéeEn fonction des résultats de l’autodiagnostic des besoins de sécurité et du niveaude maturité, vous pouvez déterminer, à l’aide du tableau infra, le type dedémarche d’homologation à mettre en œuvre dans le cadre de votre projet.Les autodiagnostics doivent être réalisés avec sérieux et objectivité.L’adoption d’une démarche inadaptée aux enjeux ou aux capacités de l’organismehypothéquerait les chances de réussite du projet d’homologation.Les démarches possibles sont les suivantes :••Pianissimo : démarche autonome a minima, que l’autorité d’homologationpeut mener sans recours à une assistance conseil externe, par l’applicationdes outils et des indications donnés dans le présent guide.••Mezzo-Piano : démarche autonome approfondie, que l’autorité d’homologationpeut mener sans recours à une assistance conseil externe, parl’application des outils et des indications donnés dans le présent guide etses ressources internes.••Mezzo-Forte : démarche assistée approfondie, que l’autorité d’homologationmène avec l’aide d’une assistance conseil externe, en plus des outilset des indications données dans le présent guide.• • Forte : le niveau de maturité de l’organisme en matière de sécurité dessystèmes d’information dispense l’autorité d’homologation de la lecturedu présent guide qui apporte des outils qu’elle maîtrise déjà. Cette démarchen’est donc pas traitée dans ce guide.15

QUEL TYPE DE DÉMARCHE DOIS-JE METTRE EN ŒUVRE ?Besoin de sécurité du SystèmeFaible Moyen FortélémentairePianissimo :démarcheautonomea minimaMezzo-Forte :démarcheassistéeapprofondieMezzo-Forte :démarcheassistéeapprofondieNiveau SSIde l’organismemoyenPianissimo :démarcheautonomea minimaMezzo-Piano :démarcheautonomeapprofondieMezzo-Forte :démarcheassistéeapprofondieavancéPianissimo :démarcheautonomea minimaForte :hors champde ce guideForte :hors champde ce guide16

3étape n°Qui contribue à la démarche ?

QUI CONTRIBUE À LA DÉMARCHE ?Durant la troisième étape, vous allez identifier l’ensemble des acteursde l’homologation et bien définir leur rôle (décision, assistance ouexpertise technique notamment).Une homologation s’appuie sur plusieurs acteurs distincts auxquels sont associésdifférents rôles et niveaux de responsabilité.1 . L’autorité d’homologation (AH)L’autorité d’homologation est la personne physique qui, après instruction dudossier d’homologation, prononce l’homologation de sécurité du système d’information,c’est-à-dire prend la décision d’accepter les risques résiduels identifiéssur le système.L’autorité d’homologation doit être désignée à un niveau hiérarchique suffisantpour assumer toutes les responsabilités. Il est donc nécessaire que l’autoritéd’homologation se situe à un niveau de direction dans l’organisme.L’autorité d’homologation désigne un responsable du processus d’homologation,qui mènera le projet d’homologation en son nom.Lorsque cela est nécessaire, elle peut rédiger une lettre de mission à l’attentionde la personne chargée d’organiser les tâches du processus d’homologation,en lui indiquant de quelle manière la synthèse des résultats de chaqueétape de la démarche d’homologation lui sera communiquée.Lorsque le système est sous la responsabilité de plusieurs autorités, l’autoritéd’homologation est désignée conjointement par les autorités concernées2 . La commission d’homologationLa commission d’homologation assiste l’autorité d’homologation pour l’instructionde l’homologation et est chargée de préparer la décision d’homologation.La taille et la composition de cette commission doivent être adaptées à18

QUI CONTRIBUE À LA DÉMARCHE ?la nature du système et proportionnées à ses enjeux. Cette commission, réunitles responsables métier concernés par le service à homologuer et des expertstechniques. Elle peut donc être de taille très réduite dans des cas très simples.La commission d’homologation est chargée du suivi des plannings, del’analyse de l’ensemble des documents versés au dossier d’homologation. Ellese prononce sur la pertinence des livrables et peut les valider dans certains cas.3 . Les acteurs de l’homologationLa maîtrise d’ouvrageLa maîtrise d’ouvrage représente les acteurs métier et assure la bonne prise encompte des contraintes liées à l’utilisation du système d’information. Elle joueun rôle-clé dans plusieurs étapes de la maîtrise des risques, y compris dans lesarbitrages sur le traitement des risques.Le RSSILorsque l’entité dispose d’un responsable de la sécurité des systèmes d’information,celui-ci est impliqué dans la démarche d’homologation. Selon les cas,il peut être désigné responsable du processus d’homologation, chargé du secrétariatde la commission d’homologation ou être membre de droit de cette commission.Le responsable d’exploitation du systèmeLe responsable d’exploitation du système, ou autorité d’emploi, remplit le rôleopérationnel. Il s’agit de l’entité exploitant le système d’information destiné àêtre homologué.Les prestatairesEn fonction de leur statut (interne ou externe), de leur implication dans le projetet de leurs relations avec l’autorité d’homologation, les prestataires peuvent êtreintégrés dans la commission d’homologation, ou simplement consultés en casde besoin.19

QUI CONTRIBUE À LA DÉMARCHE ?Ils remplissent un rôle d’assistance et produisent des livrables qui seront versésau dossier d’homologation ainsi que des réponses aux interrogations de la commissiond’homologation.Les systèmes interconnectésLes autorités d’homologation des systèmes interconnectés au système concernépeuvent jouer un rôle dans l’homologation et être associés à la démarche lorsque :••le système à homologuer a un impact sur leurs propres systèmes ;••ils émettent des avis ou des certificats qui peuvent concerner le système.Les questions qui se posent à la troisième étapeQui doit être désigné autorité d’homologation ?L’autorité d’homologation doit être choisie au niveau hiérarchique suffisant pourassumer toutes les responsabilités, y compris éventuellement pénale, afférentes àcette décision d’homologation.L’autorité d’homologation doit-elle être unique ?C’est très largement préférable, car il s’agit d’une prise de responsabilité individuelle.Lorsque le système est sous la responsabilité de plusieurs autorités qualifiées, uneautorité d’homologation multiple peut toutefois être envisagée, mais le partage desresponsabilités doit demeurer absolument limpide.L’autorité d’homologation peut-elle être déléguée ?Parfois, une autorité d’homologation est désignée pour un système complexe ouensemble de systèmes. Dans certains cas, elle souhaite déléguer la prise de décision20

QUI CONTRIBUE À LA DÉMARCHE ?pour un système particulier ou un sous-système. C’est possible, mais avec beaucoupde précautions et dès le début du projet :••la délégation doit être donnée en accord avec l’autorité qui a désigné l’autoritéd’homologation initiale ;••l’autorité d’homologation doit rester à un niveau hiérarchique suffisant pourassumer toutes les responsabilités qui lui incombent ;••il ne doit pas exister de mélange des genres et l’autorité d’homologation doitgarder l’objectivité nécessaire ;••le délégataire doit conserver une vue sur les systèmes déployés, les programmesen cours et les travaux de maintien en condition de sécurité.Au sein d’un organisme, les membres de la commission d’homologationsont-ils désignés une fois pour toutes ?Cela dépend beaucoup du nombre et de la nature des systèmes d’information àhomologuer au sein de l’organisme. La composition de la commission d’homologationpeut être définie :••par projet, s’ils sont différents les uns des autres ;••pour l’ensemble des projets de la direction, s’ils sont similaires les uns auxautres ;• • de manière mixte avec un noyau stable et des intervenants spécifiques auprojet.21

4étape n°Comment s’organise-t-onpour recueillir et présenterles informations ?

COMMENT S’ORGANISE-T-ON POUR RECUEILLIR ET PRÉSENTER LES INFORMATIONS ?Durant la quatrième étape, vous allez inventorier le contenu du dossierd’homologation et définir le planning de la démarche qui permettrade le constituer et de l’instruire.1 . Le contenu du dossier d’homologationLe dossier d’homologation est alimenté pendant toutes les phases de la démarche,essentiellement avec des documents nécessaires à la conception, à laréalisation, à la validation du projet ou à la maintenance du SI après sa mise enservice, ainsi que des documents produits spécifiquement pour l’homologation.L’annexe 3 propose une liste complète des documents qui peuvent être intégrésdans un dossier d’homologation.Le contenu du dossier pourra varier selon la démarche choisie. Le tableauci-dessous synthétise les éléments constitutifs du dossier d’homologation enfonction de la démarche adoptée. L’annexe 3 établit la liste plus complète desdocuments pouvant être contenus dans un dossier d’homologation et en proposeune description détaillée.Pianissimo Mezzo-Piano Mezzo ForteStratégie d’homologationRéférentiel de sécuritéIndispensableSi existantDocument présentant lesrisques identifiés etles objectifs de sécuritéIndispensablePolitique de sécurité dessystèmes d’informationRecommandéFortement recommandéProcédures d’exploitationsécurisée du systèmeIndispensable24

COMMENT S’ORGANISE-T-ON POUR RECUEILLIR ET PRÉSENTER LES INFORMATIONS ?Journal de bordde l’homologationRecommandéFortement recommandéCertificats de qualification desproduits ou prestatairesSi existantRésultats d’audits Si existant RecommandéFortementrecommandéListe des risques résiduelsDécision d’homologationIndispensableIndispensableSpécifiquement pour les systèmes déjà en service :Tableau de bord des incidentset de leur résolutionRecommandéFortementrecommandéIndispensableRésultats d’auditsintermédiairesSi existantRecommandéJournal des évolutionsdu systèmeSi existantDémarche Pianissimo :Tous les documents décrivant les procédures de sécurité en vigueur au sein del’organisme peuvent être intégrés au dossier, par exemple :••la charte d’utilisation des postes informatiques ;••les règles de contrôle d’accès physique et logique au système ;••les clauses de sécurité des contrats de sous-traitance informatique.Démarche Mezzo-Piano et Mezzo Forte :Les documents constitutifs du référentiel de sécurité de l’organisme peuventêtre intégrés au dossier. En particulier :••la politique de sécurité des systèmes d’information (PSSI) de l’organisme ;25

COMMENT S’ORGANISE-T-ON POUR RECUEILLIR ET PRÉSENTER LES INFORMATIONS ?••la législation ou la réglementation particulière au contexte de l’organisme ;••le dossier de sécurité des systèmes interconnectés au système à homologuer.La PSSI, quand elle existe, est un document de référence pour l’homologation,car elle contient des éléments stratégiques (périmètre du système, principauxbesoins de sécurité et origine des menaces), ainsi que les règles en vigueur ausein de l’organisme.L’homologation peut aussi être l’occasion de compléter (ou de rédiger) laPSSI, par exemple pour généraliser des règles indispensables au SI homologué.2 . PlanningL’homologation doit être prononcée préalablement à la mise en service opérationnelledu système d’information.La démarche visant à l’homologation doit donc être lancée en amont puisêtre totalement intégrée au projet dès les phases d’étude préalable et de conception,afin d’éviter tout risque calendaire.Le calendrier de l’homologation est directement dépendant du calendrierdu projet dont il doit tenir compte en permanence. Les principales étapes del’homologation sont fixées dans la stratégie d’homologation.Il est indispensable de déterminer les tâches de chacun des acteurs del’homologation et les formaliser dans un planning associé, reprenant les principalesétapes. Au besoin, en fonction de l’évolution du projet, ces échéancespeuvent être révisées, avec l’accord de l’autorité d’homologation.Ainsi, une homologation est rythmée par deux temps forts :• • la construction du référentiel documentaire et l’analyse de risque (dont lamise en œuvre peut être longue) ;• • le déploiement, l’audit, l’homologation et la mise en service opérationnel(a contrario, il s’agit d’une étape courte et très rapide).26

COMMENT S’ORGANISE-T-ON POUR RECUEILLIR ET PRÉSENTER LES INFORMATIONS ?Les échéances prévues pour les différentes étapes de la démarche d’homologationdoivent figurer dans le planning :1. lancement de la procédure d’homologation (par exemple date de formalisationde la stratégie d’homologation) ;2. début et de fin de l’analyse des risques (dates des entretiens avec l’autorité) ;3. remise des différents documents du dossier d’homologation (cf. sectionsuivante) ;4. engagements liés à d’éventuels contrats avec des prestataires impliquésdans le système (hébergeurs, fournisseurs de sous-systèmes, d’applications…);5. réunions de la commission d’homologation ;6. audits éventuels sur les composants du système (techniques ou organisationnels),logiciels plates-formes matérielles, interfaces réseaux ;7. homologation du système ;8. mise en service du système.Les questions qui se posent à la quatrième étapeUn audit sera-t-il nécessaire au cours de la démarche d’homologation ?Un contrôle sera systématiquement effectué à la sixième étape, mais ce contrôlene prendra la forme d’un audit technique formel que si les enjeux de sécurité lejustifient.Quelle que soit la démarche adoptée, c’est à l’autorité d’homologation dedécider s’il est nécessaire d’effectuer un audit sur le système d’information, et àquel niveau. Cet audit permettra de mettre en évidence d’éventuelles failles sur lesystème, et d’identifier rapidement les risques encourus par l’organisme en conséquence.27

5étape n°Quels sont les risquespesant sur le système ?

QUELS SONT LES RISQUES PESANT SUR LE SYSTÈME ?Durant la cinquième étape, vous allez identifier et ordonner lesrisques qui pèsent sur le système d’information à homologuer.1 . L’analyse de risqueUn risque est la combinaison d’un événement redouté (susceptible d’avoir unimpact négatif sur la mission de l’entité) et d’un scénario de menaces. On mesurele niveau du risque en fonction de sa gravité (hauteur des impacts) et de savraisemblance (possibilité qu’il se réalise).Il s’agit d’identifier les risques pesant sur la sécurité des systèmes d’information,de les hiérarchiser et de déterminer des objectifs généraux qui permettrontde diminuer certains d’entre eux et, à terme, de les amener à un niveauacceptable.La durée et le coût de la réalisation d’une analyse de risques sont fonctionde la complexité du système d’information et de la sensibilité des données(données propres ou données de tiers, telles que celles des usagers ou des partenaires).L’analyse des risques pesant sur le système peut être simplifiée dans lecadre d’une démarche Pianissimo. Dans le cas d’une démarche Mezzo-Pianoou Mezzo-Forte, on privilégiera l’utilisation d’une méthode éprouvée d’analysede risque.Démarche PianissimoLe tableau d’autodiagnostic de l’annexe 1 vous a permis d’identifier, lors de ladeuxième étape, que les enjeux de sécurité du système d’information étaientlimités et que les besoins de sécurité étaient faibles.Pour une analyse de risque simplifiée, vous pouvez alors procéder de la manièresuivante :1. Partez de la liste des menaces courantes présente dans l’annexe 4. Cesmenaces sont d’ordre volontaire ou accidentel (inondation, panne de climatisationentraînant une panne des équipements informatiques, erreurde saisie), de nature physique (intrusion sur le système) ou logique (intru-30

QUELS SONT LES RISQUES PESANT SUR LE SYSTÈME ?sion réseau, défiguration de site, etc.).2. Écartez celles qui ne sont pas pertinentes dans le contexte du systèmed’information étudié ;3. Pour chaque menace conservée, déterminez un ou plusieurs biens essentielsqui pourraient être affectés. Les biens essentiels sont les informationstraitées au sein du système, ainsi que leurs processus de traitement. Ilsconstituent la valeur ajoutée du système d’information pour l’organisme.4. Pour chaque lien identifié entre une menace et un bien essentiel, décrivezl’impact négatif sur la disponibilité, l’intégrité ou la confidentialité de cebien essentiel. Vous obtenez un scénario de risque.5. Hiérarchisez les scénarios de risque obtenus, en identifiant les plus probableset ceux dont l’impact est le plus pénalisant.6. Si un scénario de risque plausible aboutit à un impact très fort, cela signifieque le besoin de sécurité évalué lors de la deuxième étape a été sous-évalué.Envisagez alors une démarche plus complète, de type Mezzo-Pianoou Mezzo Forte.Démarche Mezzo-Piano ou Mezzo-forteDans le cadre de la mise en œuvre d’une démarche Mezzo-Piano ou Mezzo-Forte, la mise en œuvre d’une méthode d’analyse de risque éprouvée est trèsfortement recommandée. La méthode EBIOS 2010 est une méthode d’analysede risque développée par l’ANSSI.La méthode EBIOS 2010 présente les risques et les objectifs de sécuritéidentifiés dans une Fiche d’Expression Rationnelle des Objectifs de Sécurité(FEROS).Dans le cadre d’une démarche Mezzo-Piano, l’analyse est effectuée parl’autorité d’homologation, avec ou sans l’assistance d’un consultant ayant uneexpérience confirmée de la méthode. Elle nécessite la participation des acteursclés du système à homologuer, qui sont interrogés sur leurs besoins, leurcontexte d’emploi du système et les événements qu’ils redoutent. C’est la directionde l’entreprise ou l’autorité administrative, par exemple, qui fournissent lesinformations sur les besoins de disponibilité ou de confidentialité du système,ce qui permet d’identifier les objectifs de sécurité du système.31

QUELS SONT LES RISQUES PESANT SUR LE SYSTÈME ?Pour la démarche Mezzo-Piano, le résultat de l’analyse (la FEROS) peut ensuiteconstituer un élément du cahier des clauses techniques particulières d’unappel d’offres pour la réalisation ou la mise en conformité du système à homologuer.Les soumissionnaires doivent y répondre en indiquant de quelle manièreils proposent d’atteindre les objectifs de sécurité identifiés par l’autorité d’homologation.2 . Identifier les mesures de sécuritéÀ l’issue de l’analyse de risque, il convient de définir les mesures de sécuritépermettant de couvrir les risques identifiés. Ceux qui demeurent après l’applicationdes mesures sont considérés comme des risques résiduels qui doivent êtreacceptés dans le cadre de l’homologation.Démarche PianissimoPour déterminer les mécanismes de sécurité à mettre en œuvre, vous pouvezégalement vous référer à plusieurs documents publiés par l’ANSSI (surhttp://www.ssi.gouv.fr) :••le guide des 40 règles d’hygiène informatique ;••le guide d’externalisation pour les systèmes d’information ;••le guide sur la virtualisation ;••les notes techniques, notamment celle sur la sécurité web.Démarche Mezzo-Piano et Mezzo-ForteDans le cadre d’une démarche Mezzo-Piano et Mezzo Forte, les objectifs desécurité identifiés au cours de l’analyse de risque selon la méthode EBIOS permettrontde définir les mesures de sécurité destinées à couvrir les risques considéréscomme inacceptables.Outre les documents présentés dans le paragraphe précédent, de nombreuxréférentiels de sécurité proposent des catalogues de mesures.32

6étape n°La réalité correspond-elle à l’analyse ?

LA RÉALITÉ CORRESPOND-ELLE À L’ANALYSE ?Durant la sixième étape, vous devez mesurer l’écart entre les résultats de l’étudede risque et la réalité, en réalisant un contrôle plus ou moins formalisé du système.Ce contrôle peut intervenir à tout moment du cycle de vie du système : enamont, avant la mise en service voir au cours de la conception, mais égalementen aval, si le système est déjà opérationnel.Le degré de formalisation du contrôle dépend de la démarche entreprise.Vous avez déterminé lors de la quatrième étape quel type d’audit était adapté.Certains systèmes n’appellent qu’une vérification peu formelle. En revanche, unaudit complet et indépendant se justifie dans le cas de systèmes à fort enjeu desécurité.1 . Réalisation du contrôleDémarche PianissimoPour la démarche Pianissimo, un audit technique est optionnel.Démarche PianoPour la démarche Piano, il est recommandé de procéder à un audit formalisé surles segments les moins maîtrisés du système.Démarche Mezzo-fortePour la démarche Mezzo-Forte, il est fortement recommandé d’effectuer unaudit technique du système d’information. Cet audit permettra de mettre enévidence d’éventuelles failles et d’identifier rapidement les risques encourus parl’organisme.Les audits doivent être menés dans les formes prévues par le référentield’exigences relatif aux prestataires d’audit de la sécurité des systèmes d’information,disponible sur le site de l’ANSSI .34

LA RÉALITÉ CORRESPOND-ELLE À L’ANALYSE ?2 . Définition du périmètre du contrôleLe contrôle effectué, qui peut prendre la forme d’un audit formalisé, porte surun système dont le périmètre doit être soigneusement délimité par l’autoritéd’homologation. Les éléments à contrôler peuvent être de différente nature(code source, configuration des équipements, architecture du système, organisationmise en place, etc.).Dans certains cas, des tests d’intrusions peuvent être effectués.3 . Conséquences de l’audit sur le dossierd’homologationLe contrôle de sécurité doit faire l’objet d’une trace écrite. A fortiori, s’il s’agitd’un audit de sécurité, celui-ci doit faire l’objet d’un rapport, qui doit faire apparaître:••une évolution des menaces sur le système ;••la découverte éventuelle de nouvelles vulnérabilités ;••la préconisation de mesures correctrices, le cas échéant.Le rapport d’audit est intégré au dossier d’homologation, qui doit être complétéen tenant compte des nouveaux risques mis en lumière.35

7étape n°Quelles sont les mesures de sécuritésupplémentaires pour couvrirles risques ?

QUELLES SONT LES MESURES DE SÉCURITÉ SUPPLÉMENTAIRES POUR COUVRIR CES RISQUES ?Durant la septième étape, vous devez définir un plan d’action pouramener le risque identifié à un niveau acceptable.1 . Le traitement du risqueAu vu des résultats de l’analyse de risques et du contrôle de sécurité, l’autoritéd’homologation se prononce sur l’ensemble des risques qui ne sont pas, à cestade, complètement couverts par des mesures de sécurité. Il convient ainsi,pour tout ou partie de chaque risque de choisir parmi les options suivantes :••l’éviter : changer le contexte de telle sorte qu’on n’y soit plus exposé ;••le réduire : prendre des mesures de sécurité pour diminuer l’impact et/oula vraisemblance ;••l’assumer : en supporter les conséquences éventuelles sans prendre demesure de sécurité supplémentaire ;••le transférer : partager les pertes occasionnées par un sinistre ou faireassumer la responsabilité à un tiers.On peut choisir plusieurs options pour chaque risque. Par exemple, un risquepeut être partiellement réduit par la mise en œuvre de mesures de sécurité,partiellement transféré par le recours à une assurance et partiellement assumépour ce qui subsiste.2 . La mise en œuvre de mesures de sécuritéLes mesures de sécurité peuvent être de nature technique, organisationnelle oujuridique. Elles sont décidées par l’autorité d’homologation sur proposition dela commission d’homologation.En cas de recours à un prestataire externe (hébergement de site ou deservices par exemple), les mesures de sécurité peuvent être intégralement misesen œuvre à travers un contrat garantissant, par exemple, que les processus etles données sont protégés et accessibles uniquement aux utilisateurs légitimes.38

QUELLES SONT LES MESURES DE SÉCURITÉ SUPPLÉMENTAIRES POUR COUVRIR CES RISQUES ?3 . Définition du plan d’actionLes risques résiduels identifiés lors du contrôle et de l’analyse de risques et quine peuvent pas être couverts par des mesures techniques ou organisationnellessont identifiés dans un plan d’action. Ce dernier indique les vulnérabilités éventuelles,leur degré (critique, majeure, mineure…), l’action correctrice envisagée,le pilote désigné, ainsi que l’échéance associée.39

8étape n°Comment réaliser la décisiond’homologation ?

COMMENT RÉALISER LA DÉCISION D’HOMOLOGATION ?Durant la huitième étape, vous devez concrétiser la décision d’homologationpar une attestation formelle autorisant, du point de vue de lasécurité, l’exploitation du système d’information.La décision d’homologation est l’acte par lequel le responsable de l’autoritéadministrative atteste de l’existence d’une analyse de sécurité et de sa prise encompte. La décision d’homologation doit nécessairement comprendre un certainnombre d’éléments, référencés ci-dessous.1 . Le périmètre de l’homologationIl doit, au minimum, tenir compte des éléments suivants :••référentiel réglementaire ;••références des pièces du dossier d’homologation ;••périmètre géographique et physique (localisations géographiques, locaux,etc.) ;••périmètre fonctionnel et organisationnel (fonctionnalités, types d’informationstraitées par le système et sensibilité, types d’utilisateurs, règlesd’emploi, procédures, conditions d’emploi des produits de sécurité, etc.) ;••périmètre technique (cartographie, architecture détaillée du système, produitsagréés, prestataires qualifiés, etc.).2 . Les conditions accompagnant l’homologationL’autorité d’homologation peut, en fonction des risques résiduels identifiés, assortirl’homologation de conditions d’exploitation ainsi que d’un plan d’actionvisant à maintenir et à améliorer le niveau de sécurité du système dans le temps.À chaque action, ce plan associe une personne pilote ainsi qu’une échéance.42

COMMENT RÉALISER LA DÉCISION D’HOMOLOGATION ?3 . La durée de l’homologationL’homologation doit être décidée pour une durée maximale.Cette durée doit prendre en compte l’exposition du système d’information auxnouvelles menaces, ainsi que les enjeux de sécurité du système, c’est-à-dire ledegré de criticité des informations et des processus du système.Pour un système bien maîtrisé, avec peu de risques résiduels et ne présentantpas de difficultés particulières, il est recommandé de prononcer unehomologation d’une durée maximale de cinq (5) ans, avec revue annuelle. Cettedurée maximale doit être réduite à trois (3) ans pour un système avec de nombreuxrisques résiduels ou à un an (1) pour un système présentant de nombreuxrisques résiduels.4 . Conditions de suspension ou de retrait del’homologationL’homologation de sécurité ne demeure valide que tant que le système d’informationest exploité dans le contexte décrit dans le dossier d’homologation.Les changements suivants doivent impliquer un réexamen du dossier, pouvantconduire à une nouvelle décision d’homologation ou à un retrait de la décision :••raccordement d’un nouveau site sur le système d’information ;••ajout d’une fonctionnalité majeure ;••succession de modifications mineures ;••réduction de l’effectif affecté à une tâche impactant la sécurité ;••changement d’un ou de plusieurs prestataires ;••prise de fonction d’une nouvelle autorité d’homologation ;••non-respect d’au moins une des conditions de l’homologation ;••changement du niveau de sensibilité des informations traitées et, plusgénéralement, du niveau du risque ;••évolution du statut de l’homologation des systèmes interconnectés ;43

COMMENT RÉALISER LA DÉCISION D’HOMOLOGATION ?••publication d’incidents de nature à remettre en cause les garanties recueilliesdans le dossier de sécurité ;••décision de l’autorité d’homologation.À ce titre, il est recommandé que la commission d’homologation soit réunieannuellement par l’autorité d’homologation, afin de procéder à une revue durespect des conditions de l’homologation.Les questions qui se posent à la huitième étapeLa démarche d’homologation a mis en évidence que les risquesrésiduels restent trop élevés pour une homologation, mais descontraintes d’ordre supérieur imposent une mise en service opérationnelledu système. Comment faire ?Si l’autorité d’homologation considère que les conditions ne sont pas réunies pourune homologation, la meilleure solution est de refuser l’homologation. Si cette possibilitén’est pas envisageable, il est toujours possible de prononcer une autorisationprovisoire d’emploi (APE) pour une durée courte (3 ou 6 mois), assortie de conditionsstrictes et d’un plan d’action précis, destiné à supprimer ces risques trop élevéset qui doit être réalisé durant le temps de l’APE.Certaines mesures de sécurité ne pourront être mises en place quedans deux ans pour une homologation de 3 ans. Est-ce trop long ?Il est impératif de spécifier dans la décision d’homologation que la mise en placedes mesures est progressive, planifiée et suivie. Elle doit commencer dès la date depublication de la décision.44

9étape n°Qu’est-il prévu pour continuerd’améliorer la sécurité ?

QU’EST-IL PRÉVU POUR CONTINUER D’AMÉLIORER LA SÉCURITÉ ?Durant cette dernière étape, qui intervient après la décision d’homologationproprement dite, vous devez mettre en œuvre une procédure derévision périodique de l’homologation, ainsi que le plan d’action pourtraiter les risques résiduels et les nouveaux risques dans le cycle de vie dusystème.1 . Suivi de l’homologationÀ la suite de la décision proprement dite, l’autorité d’homologation doit veillerau maintien du niveau de sécurité du système. La commission d’homologationréalise annuellement un suivi de l’homologation. Cette étape n’est pas une nouvelleinstruction. Elle doit donc rester simple et se limiter à une mise à jour dudossier et à une analyse succincte des évolutions et des incidents intervenus aucours de l’année, afin de juger de l’opportunité d’une révision plus approfondiede l’homologation.En préparation du renouvellement de l’homologation, le dossier d’homologationest régulièrement complété par les éventuelles analyses de vulnérabilités,les comptes rendus de contrôle et les rapports d’audits complémentaires.La version consolidée est transmise aux membres de la commission d’homologationIl est recommandé de réunir périodiquement la commission d’homologationpour reprendre la liste des critères et vérifier que les conditions d’homologationsont toujours respectées. Cela permet également d’éviter de reprendrel’homologation à zéro au terme de sa durée de validité.2 . Maintien en conditions de sécuritéIl est nécessaire que les conditions de l’homologation soient respectées dans letemps. À ce titre, l’entité en charge du maintien du dossier d’homologation doitégalement assurer une veille technologique. Celle-ci permet d’identifier les vul-46

QU’EST-IL PRÉVU POUR CONTINUER D’AMÉLIORER LA SÉCURITÉ ?nérabilités qui apparaîtraient sur le système et s’assurer qu’elles soient corrigées,notamment les plus sérieuses.Il est également nécessaire de vérifier :••les clauses de sécurité et de maintien en conditions de sécurité du système,le cas échéant en se référant au guide d’externalisation publié par l’ANSSI ;••les capacités d’évolution et d’interopérabilité de son système, notammentau regard de ses capacités de développement ou de ses contrats de prestationsde service.Les questions qui se posent à la neuvième étapeSi une nouvelle vulnérabilité est découverte, dois-je relancer leprocessus d’homologation ?Cela dépend de l’impact de la vulnérabilité sur le système. S’il est fort, ilfaudrait effectivement relancer le processus d’homologation sans attendrel’issue de la durée d’homologation en cours.47

XXXXXCONSEILS PRATIQUESLa démarche d’homologation est un projet en soi, qui doit s’intégrer complètementau projet global et au cycle de vie du système d’information. C’est unedémarche qui peut se révéler complexe et qui se heurte parfois à des difficultésorganisationnelles, techniques ou calendaires. Les conseils contenus dans cettefiche vous permettront d’aboutir plus facilement à un résultat satisfaisant.Conseils d’ordre généralLes conseils d’ordre général listés ci-dessous doivent, dans la mesure du possible,être suivis pour maximiser les chances de réussite d’une démarched’homologation :••débuter suffisamment tôt la démarche d’homologation ;••prévoir une validation formelle des décisions au niveau hiérarchiqueadéquat ;••désigner un véritable chef de projet, qui sera disponible tout au long duprojet ;••maîtriser le calendrier et ne pas être trop contraint par des nécessitésopérationnelles ;••bien définir le périmètre et disposer d’une architecture précise du système ;••bien prendre en compte les interconnexions éventuelles ;••s’appuyer sur des documents écrits, explicites, sans ambiguïté, afind’éviter les quiproquos entre les parties prenantes au projet.48

XXXXXAvant l’étudeUne réflexion menée en amont permet de bien préparer la démarche d’homologationet d’assurer sa réussite de façon optimale.Au préalable, il faut que la démarche soit portée à haut niveau par l’autoritéd’homologation et que l’ensemble des acteurs concernés soit impliqué etmotivée.Il faut également désigner un chef de projet, qui disposera des moyenspour mener à bien sa mission et rapporter toute difficulté à l’autorité d’homologation.Enfin, dès que les acteurs de l’homologation sont identifiés, il est indispensablede les sensibiliser sur la démarche, les concepts et le vocabulaire quiseront utilisés.Pendant l’étudePour chaque activité à réaliser, il est conseillé de s’organiser en mode projet, enidentifiant un responsable de l’activité, en constituant un groupe de travail et enlui confiant une mission précise, associée à une date de réalisation.Certaines missions sont essentielles pour la réussite du projet :> la sensibilisation des acteurs••rappeler l’objectif de l’activité••présenter les concepts, le vocabulaire••s’assurer que l’ensemble des acteurs ait une vision commune de laproblématique> la collecte des informations••réaliser des entretiens••rassembler les documents existants sur l’organisme, le projet49

XXXXX> le suivi du projet••présenter des exemples pour lancer les discussions••synthétiser les informations récoltées pour validation par le groupe detravail••nommer des responsables et fixer des échéances••se rencontrer périodiquementIl est également nécessaire d’adapter les livrables aux destinataires en ce quiconcerne :••la forme : tableaux, textes, schémas, etc. ;••le niveau d’information : recherche d’exhaustivité ou forme synthétique ;••l’intégration aux documents existants ;••l’adaptation au vocabulaire habituel de l’organisme,••leur nomenclature, qui doit être explicite,••leur libellé, qui doit être court et descriptif.Enfin, il est recommandé de faire valider chaque étape par la commissiond’homologation. Cela permet d’éviter les retours en arrière improductifs, touten impliquant les autorités tout au long de la réalisation du dossier de sécurité.50

ANNEXES

ANNEXE 1Annexe 1Estimation rapide du besoin de sécurité d’un système d’informationLe tableau suivant permet d’évaluer les besoins de sécurité du système d’information(SI) à homologuer, en estimant la gravité des conséquences potentielles d’unedéfaillance du SI, la sensibilité des données, le potentiel des attaquants, le degréd’exposition aux menaces et l’importance des vulnérabilités intrinsèques du SI.Si vous répondez « Je ne sais pas » à plus de deux questions, faites-vousaider par la maîtrise d’ouvrage, qui connaît les enjeux du système.Question n° 1 : Votre système est-il important pour remplir vosmissions ?1 2 3 4NoteNon, le systèmeest accessoireà l’accomplissementdesmissionsOui, les missionsseraient fortementperturbéespar un dysfonctionnementduSI.Oui, les missionsdépendenttotalement du SIJe ne sais pasQuestion n° 2 : Si un sinistre atteint votre SI, causant un dysfonctionnementou une perte de données, les conséquences en interne (pour vos services)seraient-elles graves ?Exemple : une panne électrique ne permet pas d’utiliser le système, le contenud’une base de données a été supprimé, etc.52

ANNEXE 1Note1 2 3 4Non, lesconséquencesinternes d’unsinistre seraientnégligeablesOui, lesconséquencesinternes d’unsinistre seraientsignificativesOui, lesconséquencesinternes d’unsinistre seraientgraves, voirefatalesJe ne sais pasQuestion n° 3 : Si un sinistre touche la sécurité de votre système (il nefonctionne plus ou pas bien, vol d’informations…), les conséquences pourl’extérieur (pour vos usagers, administrés…) seraient-elles graves ?1 2 3 4Non, lesconséquencesd’un sinistrepour l’extérieurseraientnégligeablesOui, lesconséquencesd’un sinistrepour l’extérieurseraientsignificativesOui, lesconséquencesd’un sinistrepour l’extérieurseraient graves,voire fatalesJe ne sais pasGravité des conséquences potentielles (reportez ici la valeur maximaledes réponses aux questions 1 à 3)Question n° 4 : Le fait que les données de votre système soient inaccessiblesest-il grave ?Exemple : vous ne pouvez pas accéder aux données en raison d’une pannematérielle.1 2 3 4Non, le faitqu’il ne soit pasaccessible negêne quasimentpas l’activitéOui, le faitqu’il ne soitpas accessibleperturberal’activitéde manièresignificativeOui, le faitqu’il ne soit pasaccessible peutêtre fatal pourl’activitéJe ne sais pas53

ANNEXE 1NoteQuestion n° 5 : Le fait que les données de votre système soient altéréesest-il grave ?Exemple : un virus a modifié des valeurs dans une base de données, les remettanttoutes à 0.1 2 3 4Non, le fait queles donnéessoient altérées negêne quasimentpas l’activitéOui, le fait queles donnéessoient altéréesperturberal’activitéde manièresignificativeOui, le fait queles donnéessoient altéréespeut être fatalpour l’activitéJe ne sais pasQuestion n° 6 : Le fait que les données de votre système ne soient pas ouplus confidentielles est-il grave ?Exemple : la liste des bénéficiaires du service social est dévoilée.1 2 3 4Non, le défaut deconfidentialiténe gênequasiment pasl’activitéOui, le défaut deconfidentialitéperturberal’activitéde manièresignificativeOui, le défaut deconfidentialitépeut être fatalpour l’activitéJe ne sais pasSensibilité des données du système (reportez ici la valeur maximale desréponses aux questions 4 à 6)Question n° 7 : Quel est le niveau de compétence maximal présumé del’attaquant ou du groupe d’attaquants susceptibles de porter atteinte au système?54

ANNEXE 1Note1 2 3 4Individu isoléde niveau decompétenceélémentaireIndividu isoléde niveau decompétenceavancéGroupe d’individusorganisés,de niveauxindividuels decompétencefaibles à moyens,ou individu isoléaux compétencesexpertesGrouped’individusexperts,organisés, auxmoyens quasiillimitésQuestion n° 8 : Quelle est la précision des attaques potentielles enversle SI ?1 2 3 4Attaques « auhasard » sur lecyberespaceAttaquesorientées versle continenteuropéen ou laFranceAttaques ciblantun groupede victimesprésentant descaractéristiquescommunesAttaques visantprécisément lesystèmeQuestion n° 9 : Quel est le niveau de sophistication des attaques potentiellescontre le SI ?1 2 3 4Outils d’attaquetriviaux (logicielde scan de ports,virus connus,etc.)Outils élaborésgénériquesprêts à l’emploi(réseaux debotnet loués,faille connue,etc.)Outilssophistiqués,adaptés pour leSI (zéro-day,etc.)Boîte à outilstrès hautementsophistiquée.55

ANNEXE 1NoteQuestion n° 10 : Quelle est la visibilité des attaques potentielles contrele SI ?1 2 3 4Attaqueannoncée(revendications« d’hacktivistes »,rançon, etc.)Attaqueconstatéeimmédiatementpar ses effets surle SIAttaque discrète,qui laisse destraces dans lesjournaux d’événements,mais neperturbe pas lefonctionnementdu SIAttaqueinvisible, réaliséeen laissant leminimum detracesQuestion n° 11 : Quelles sont la fréquence et la persistance des attaquespotentielles contre le SI ?1 2 3 4Unique :l’attaque ne seproduit sur lacible qu’uneseule foisPonctuelle :l’attaque survientplusieurs foissans régularitédans safréquence (ellepeut être liée àl’actualité).Récurrente :attaquepar vaguessuccessivesimportantesPermanente.Base d’estimation des potentiels d’attaques cyber (reportez ici la valeurmaximale des réponses aux questions 7 à 11)Question n° 12 : Quel est le niveau d’hétérogénéité du système ?Exemple : plusieurs logiciels, matériels ou réseaux différents pour un mêmesystème.56

ANNEXE 2Note1 2 3 4Le système estjugé commehomogèneLe système estjugé commefaiblementhétérogèneLe système estjugé commefortementhétérogèneJe ne sais pasQuestion n° 13 : Quel est le degré d’ouverture/interconnexion du système?Exemple : Internet, un autre système interne ou externe (celui d’un prestataire,d’une autre autorité administrative…)…1 2 3 4Le SI n’est pasouvertLe SI n’estouvert qu’à dessystèmes internesmaîtrisésLe système estouvert à dessystèmes internesnon maîtrisés ouexternesJe ne sais pasQuestion n° 14 : Le contexte dans lequel se trouve le SI et ses composants(matériels, logiciels, réseaux) évolue-t-il régulièrement ?1 2 3 4Le SI et soncontexte sontjugés stablesLe SI et soncontextechangentsouventLe SI et soncontexteévoluent enpermanenceJe ne sais pasQuestion n° 15 : Les composants du SI sont-ils mis régulièrement à jour ?1 2 3 4Les composantsdu SI sont toustenus à jour enpermanenceUne partie descomposantsdu SI estrégulièrementmise à jourLes mises à joursont effectuéesde manièreirrégulièreJe ne sais pas57

ANNEXE 1Exposition et vulnérabilités (reportez ici la valeur maximale des réponsesaux questions 12 à 15)Additionner les valeurs maximales des réponses aux questionsTOTALAvec ces résultats que l’on additionne, on estime ainsi le besoin de sécurité deson système :Somme des quatre valeursDe 4 à 6De 7 à 9De 10 à 16Besoin de sécurité du système1 - Faible2 - Moyen3 - Fort58

ANNEXE 2Annexe 2Estimation rapide du niveau de maturité de l’organismeLe tableau suivant permet d’évaluer le niveau de maturité en sécurité de votreorganisme.Le niveau de maturité en sécurité ne correspond pas au niveau réel desécurité, mais à la capacité de l’organisme à gérer les risques, pour chaque systèmed’information.QuestionsOui / NonLes activités de sécurité sont-elles réalisées en utilisant des pratiquesde base (bonnes pratiques de sécurité, référentiels de mesures…) ?Si la case précédente est à Oui, alors votre organisme a un niveaude maturité élémentaire en sécurité, sinon, une démarche assistée estindispensable.Les activités de sécurité sont-elles planifiées ?Les acteurs affectés à des activités de sécurité sont-ils formés (eninterne ou par un organisme de formation) à la SSI (niveau de compétenceen sécurité jugé suffisant) ?Certaines pratiques de sécurité sont-elles formalisées dans desdocuments spécifiques (procédures) ?Des mesures de sécurité sont-elles en place ?59

ANNEXE 2Les autorités compétentes sont-elles informées des mesures effectuées?Si toutes les cases précédentes sont à Oui, alors votre organisme aun niveau de maturité moyen en sécurité.Les processus de sécurité sont-ils définis, standardisés et formalisés(définir la stratégie, gérer les risques, gérer les règles, superviser…) ?Des acteurs spécifiques sont-ils affectés à la gestion des processus desécurité et sont formés en conséquence ?L’organisme dans sa globalité soutient-il les processus de sécurité(les différents niveaux hiérarchiques…) ?Les processus de sécurité sont-ils coordonnés dans tout le périmètrechoisi ?L’efficacité des mesures de sécurité en place est-elle mesurée ?Des audits sont-ils effectués pour vérifier la suffisance des mesuresen place ? (Les mesures de sécurité effectuées sont-elles contrôlées[auditées] ?)Les processus de sécurité sont-ils améliorés en fonction des mesuresde sécurité effectuées ?Si toutes les cases précédentes sont à Oui, alors votre organisme aun niveau de maturité avancé en sécurité.60

ANNEXE 3Annexe 3Liste des documents pouvant être contenus dans un dossier d’homologationLe dossier d’homologation peut contenir, en fonction de leur pertinence auregard du contexte et de la complexité du système, les éléments suivants.1 . La stratégie d’homologationL’autorité d’homologation, ou son représentant, formalise l’organisation del’homologation dans un document de synthèse. Cette stratégie d’homologationdécrit les modalités de réalisation du processus d’homologation. Elle rappellel’ensemble des parties prenantes à l’homologation et précise :••le cadre réglementaire applicable (règles de protection des informationsconfidentielles, règles sectorielles, etc.) ;••l’organisation (acteurs, missions, etc.) ;••la démarche ;••le périmètre ;••le calendrier ;••la criticité des informations utilisées dans le cadre de l’homologation ;••les pièces constitutives du dossier d’homologation.2 . L’analyse de risquesElle peut être menée selon une méthode éprouvée conforme aux normes existantesen matière de gestion des risques SSI61

ANNEXE 33 . La politique de sécurité du systèmed’information (PSSI)La PSSI définit les principes et les exigences techniques et organisationnellesde sécurité du système d’information. Il s’agit du document de référence SSIapplicable à l’ensemble de l’organisme ou dédié à un système.L’homologation peut aussi être l’occasion d’élaborer ou de compléter lapolitique de sécurité des systèmes d’information (PSSI) de l’organisme, parexemple afin de généraliser des règles indispensables au système d’informationhomologué. Le guide [PSSI] de l’ANSSI fournit une aide pour élaborer unePSSI .Ce document revêt différentes formes en fonction des interlocuteurs(directives, procédures, codes de conduite, règles organisationnelles et techniques,etc.)La PSSI inclut :••les éléments stratégiques ;••le périmètre du SI, les enjeux liés, les orientations stratégiques, lesaspects légaux et réglementaires ;••les principes de sécurité par domaine (organisationnel, technique, miseen œuvre, etc.).Elle peut être complétée par une ou plusieurs politiques d’application, parexemple les procédures d’exploitation de la sécurité (PES).4 . Le journal de bord de l’homologationIl s’agit du registre des décisions et des principaux événements qui sont intervenuspendant la démarche d’homologation. Il présente les caractéristiques suivantes:• • il s’enrichit au fur et à mesure du projet (document de travail, feuille deroute) pour adapter le processus aux évolutions du projet, notamment pourle planning ;62

ANNEXE 3••Il permet de formaliser les prises de décisions et les mises au pointnécessaires et de disposer d’un point de situation sur l’avancement du processusd’homologation (et les blocages éventuels) ;••Il constitue la base pour réaliser le plan d’action associé à la décision d’homologation;••Il peut se présenter sous plusieurs formes :»»documents isolés (comptes rendus de réunions, notes, etc.) ;»»document unique (registre formel de décisions, ou tableau de synthèseavec renvois à des documents isolés par exemple).5 . Les référentiels de sécuritéLa démarche d’homologation doit être réalisée conformément aux exigencesdécrites dans les référentiels de sécurité de l’autorité et en particulier :••la politique de sécurité des systèmes d’information (PSSI) de l’autorité ;••la législation ou la réglementation particulière applicable à l’autoritéadministrative ;••les exigences de sécurité des systèmes interconnectés au système à homologuer.6 . Le tableau de bord de l’application des règlesd’hygiène informatiqueLes « 40 règles d’hygiène informatique » publiées par l’ANSSI sont applicablesdans toutes les situations. Un tableau de bord mesurant l’application de cesmesures d’hygiène montre la progression au sein du système, l’objectif étant detoutes les appliquer.63

ANNEXE 37 . La cartographie des systèmes d’informationde l’organismeLa cartographie complète du réseau local doit être établie. Elle comprend :••la cartographie physique du réseau qui correspond à la répartitiongéographique des équipements et permet de connaître la position d’unéquipement réseau au sein des différents sites.••la cartographie logique du réseau (plan d’adressage IP, noms de sousréseaux,liens logiques entre ceux-ci, principaux équipements actifs, etc.).Elle fait notamment apparaître les points d’interconnexion avec des entités« extérieures » (partenaires, fournisseurs de services, etc.) ainsi quel’ensemble des interconnexions avec Internet.••la cartographie des applications. Le point de vue applicatif correspondaux applications métier et logiciels d’infrastructure utilisant l’architectureréseau comme support••la cartographie de l’administration du système d’informations.Elle représente le périmètre et le niveau de privilèges des administrateurssur les ressources du parc informatique. Ce point de vue permet, en casde compromission d’un compte d’administration, d’identifier le niveau deprivilège de l’attaquant et la portion du parc potentiellement impactée.8 . Les schémas détaillés des architectures dusystèmeLes schémas détaillés des architectures techniques et fonctionnelles dépendentavant tout du périmètre choisi de l’homologation du SI, ainsi que du niveau dematurité de l’organisme.Les schémas doivent permettre de savoir quelle est la fonction principaledu SI et comment ce SI fonctionne.À cette fin, il faut disposer, au minimum, de l’annuaire (gestion descomptes), du plan d’adressage, de la liste des fonctions de sécurité et de la cartographiedu SI.64

ANNEXE 3Cette documentation doit être mise à jour afin de suivre les modificationssubies par le SI.Par exemple, si le périmètre de l’homologation est une application de téléservice,il faut fournir les éléments suivants :••les procédures d’exploitation de sécurité (PES) ;••le plan du maintien en condition opérationnelle ;••la matrice des flux entrant/sortant (interconnexions) ;••la documentation de la gestion des comptes de l’application ;••la documentation de l’administration du SI et de l’installation ;••plan de sauvegarde et d’archivage des données ;••plan de continuité ou de reprise d’activité.9 . Le document présentant les risquesidentifiés et les objectifs de sécuritéCe document doit être élaboré à l’issue d’une analyse de risques, réalisée (saufpour la démarche Pianissimo) en suivant une méthode éprouvée et maintenue,si possible respectant la norme ISO 27005. Il présente les caractéristiques suivantes:• • il décrit les besoins et objectifs de sécurité du système en termes de disponibilité,d’intégrité et de confidentialité par rapport aux menaces identifiées.Au besoin, il peut être présenté sous la forme d’une Fiche d’ExpressionRationnelle des Objectifs de Sécurité (FEROS) .• • il indique la nature et la sensibilité des informations traitées par le systèmeet précise les contraintes qui restreignent la conception, l’exploitation et lamaintenance du système.• • il doit prendre en compte les architectures d’interconnexion, les moyenspartagés avec d’autres entités, leurs conditions d’exploitation et de contrôle.• • sa rédaction nécessite la participation des acteurs clés du système à homologuer,qui sont interrogés sur leurs besoins, le contexte d’emploi du systèmeet les événements susceptibles d’impacter positivement ou négativement lesystème.65

ANNEXE 3••dans le cadre des systèmes OTAN, il est demandé un énoncé des impératifsde sécurité (SRS) (ou un équivalent national). Le SRS est un énoncécomplet et explicite des principes de sécurité détaillés à satisfaire. Il existeplusieurs types de SRS :»»CSRS, énoncé des impératifs de sécurité applicables à un ensembled’interconnexions lorsque plusieurs SI sont interconnectés ;»»SSRS, énoncé des impératifs de sécurité propres à un système dansdes situations simples (système autonome, par exemple) ;»»SISRS, énoncé des impératifs de sécurité applicables à une interconnexionde systèmes, lorsque deux SIC doivent être connectés entreeux pour échanger des informations, le SISRS constitue la base d’unaccord entre les deux autorités d’exploitation des SIC et les deuxautorités d’approbation ou d’homologation de sécurité ;»»le SEISRS qui est la cible de sécurité (ou énoncé des impératifs desécurité électronique propres à un système.10 . Les procédures d’exploitation du systèmeCes procédures doivent être détaillées et directement applicables. Elles exposentles mesures de sécurité permettant de répondre aux objectifs de sécurité fixés parl’autorité d’homologation. Elles présentent les droits et les devoirs des accédants ausystème ainsi que les actions à réaliser dans le cadre de l’utilisation quotidienne dusystème.Ces procédures sont établies par les équipes d’exploitation internes à l’organismeet/ou par les fournisseurs du système à homologuer, éventuellement àl’aide des guides publiés par l’ANSSI .L’autorité d’homologation doit s’assurer que les procédures fournies ontété testées avec succès avant de prononcer l’homologation. Un dossier de testscomplétera utilement le dossier d’homologation.66

ANNEXE 311 . Les exigences de sécurité à destination dessystèmes interconnectésLes systèmes contenant des informations sensibles ne doivent pas être connectésdirectement aux réseaux publics tels qu’Internet ou les réseaux WiFi deshôtels, des gares ou des aéroports.12 . Les décisions d’homologation des systèmesinterconnectésSi les systèmes connectés au système concerné, ont déjà fait l’objet d’unehomologation, il faut joindre les décisions d’homologation associées aux systèmesainsi que les dossiers associés, si possible et si nécessaire. En effet, il estimpératif de savoir, au minimum, par qui le système a été homologué, à quelledate et quelle est la référence de cette dernière homologation.13 . Les certificats de sécurité des produitsutilisésLes agréments des dispositifs de sécurité, prononcés en application des dispositionsde l’IGI 1300, doivent figurer dans le dossier d’homologation.Les décisions de ne pas faire agréer par l’ANSSI un dispositif de sécurité,lui-même utilisé comme moyen de protection contre les accès non autorisés auxinformations classifiées ou au système, doivent être également jointes au dossier,ainsi que les éléments ayant contribué à ces décisions.67

ANNEXE 314 . Les attestations de qualification desproduits ou prestatairesDans la mesure où le système met en œuvre des produits de sécurité certifiés ouqualifiés ou encore des services de confiance qualifiés, il est nécessaire d’inclureles attestations correspondantes dans le dossier d’homologation.Si elles sont disponibles, les analyses de sécurité des produits de sécurité,en particulier les instructions techniques d’emploi, peuvent également être intégréesau dossier d’homologation.15 . Les plans de tests et d’auditsDes documents doivent identifier formellement les tests et les audits nécessaireset préciser par qui ils doivent être effectués et selon quel planning.Pour mémoire, des audits doivent être prévus après la décision d’homologation,afin d’assurer le maintien en conditions opérationnelles du système.16 . Les rapports de tests et d’audits et lesplans d’action associésPour les systèmes déjà en production depuis un an ou plus, il est recommandéde procéder d’emblée à un audit technique sur le système à homologuer, le caséchéant avant l’analyse des risques.Pour les systèmes en cours de conception, l’audit pourra être réalisé à l’occasionde la procédure de recette applicative.Pour les systèmes existants requérant un besoin particulier de sécurité, ilest recommandé de procéder, en première action, à un audit technique et organisationnelafin d’optimiser la procédure d’homologation.L’audit doit mener à la l’établissement d’une liste des vulnérabilités détectéeset du plan d’action afférent.68

ANNEXE 3Les audits doivent être réalisés par des équipes préalablement validées parl’autorité d’homologation.Ils doivent porter sur les mesures de sécurité liées à l’exploitation du systèmeet les comparer à l’état de l’art.Les audits doivent être menés dans les formes prévues par le référentield’exigences relatif aux prestataires d’audit de la sécurité des systèmes d’information.17 . Le dossier des risques résiduelsCe dossier comporte une analyse de la couverture des risques et de l’atteinte desobjectifs de sécurité au travers :••des procédures d’exploitation sécurisée du système ;••de la PSSI.Il présente également les vulnérabilités résiduelles constatées lors des tests etdes audits et non corrigées ainsi que les plans d’action associés.18 . Les éventuelles décisions d’homologationantérieuresLe dossier doit comporter tous les documents relatifs aux éventuelles homologationsprécédentes.19 . Le tableau de bord des incidents et de leurrésolutionCe tableau recueille l’ensemble des incidents survenus sur le SI avec l’identificationde leur(s) cause(s), les conséquences et les modalités de résolution del’incident. Il précise également le plan d’action associé.69

ANNEXE 320 . Le journal des évolutionsCe journal consigne les évolutions du système, notamment celles ayant uneincidence sur les critères et conditions de l’homologation.Il comprend, en particulier, la liste des mesures de sécurité apportées enprévention de risques ou en correction d’anomalies ou de vulnérabilités constatéesdans les audits.70

ANNEXE 4Annexe 4Liste de menaces, issue de la base de connaissance EBIOSMenaces sur les matérielsUsage d’un équipement ou d’un matériel :••utilisation abusive d’un ordinateur à des fins personnelles, voire pour unusage inapproprié ou illicite ;••stockage de fichiers personnels sur l’ordinateur de bureau (ex. vidéos nonprofessionnelles) ;••usage d’une imprimante à des fins personnelles ou au détriment d’autrui ;••stockage d’informations sensibles sur des supports inappropriés (disquedur non protégé, clé USB, CDROM laissé sur un bureau…) ;••perte ou vol d’un ordinateur (surtout portable), ou d’un support de donnéesélectronique (clé USB, CDROM, disque dur amovible) notammentlors d’un déplacement ou d’un déménagement.Observation d’un équipement :• • observation d’un écran à travers une fenêtre ;• • observation de la saisie d’un code au clavier ;• • écoute d’une conversation diffusée sur les haut-parleurs de l’ordinateur ;• • géolocalisation d’un matériel (à partir de son adresse IP ou par le réseautéléphonique) ;• • interception de signaux compromettants émis par l’affichage à l’écran oules touches du clavier ;• • pose d’un dispositif-espion matériel (keylogger) sur la face arrière d’unposte de travail.71

ANNEXE 4Fonctionnement du matériel :••surcharge d’un disque dur ou d’un serveur aboutissant à une panne ;••perturbations électriques ou électromagnétiques ;••panne électrique involontaire (remplacement d’un poste par un ordinateurplus consommateur en énergie, rupture de câbles électriques suite à destravaux de terrassement, court-circuit dû à la foudre, erreur de branchementou incident électrique…) ;••vieillissement du matériel susceptible d’entraîner un crash du disque dur ;••multiples déplacements du matériel (ordinateur portable) ;••ordinateur travaillant dans un milieu pollué, humide, ou corrosif (atelierindustriel…), ou en présence d’ondes électromagnétiques ou de vibrations;••chute du matériel pendant une installation ou un déménagement (voirvandalisme) ;••effacement des données par passage d’un aimant sur un disque dur ;••présence d’un code malveillant destiné à empêcher le fonctionnement detout ou partie du matériel.Menaces sur les logicielsMenaces sur l’usage de logiciels• • un logiciel est piégé (keylogger), ou corrompu par un code malveillant ;• • un logiciel accède ou copie de manière inappropriée voire illicite des donnéesmétiers, des données de configuration d’équipements, ou collecte desdonnées métiers partagées dans un réseau ;• • un logiciel supprime de manière inappropriée des données, journauxd’événements, enregistrements de conversations, etc. qu’ils soient en mémoire,sur un disque dur ou sur un support ;• • un logiciel crée ou modifie des données de manière inappropriée : messagesinjurieux sur un forum, configuration d’un système, insertion d’unepage web ou défiguration sur un site Internet, élévation de privilèges d’un72

ANNEXE 4compte utilisateur, effacement de traces d’opérations dans un journald’événements, fraude ;••un logiciel collecte des données de configuration d’un réseau, balaie lesadresses internes réseau ou recense les ports ouverts ;••un logiciel exploite des données de base pour en extraire des informationsconfidentielles (recoupement, infocentre) ;••un logiciel utilise des mécanismes de stéganographie pour transmettre desdonnées discrètement ;••un agent utilise un logiciel professionnel pour des besoins personnels ;••un agent connecte son ordinateur portable personnel compromis par unattaquant au réseau ;••un agent transfère systématiquement tous les messages qu’il reçoit sur uncompte de messagerie personnel dont le mot de passe a été cassé par ungroupe d’attaquant notoire ;••une machine du réseau est compromise pour réaliser un envoi massif d’informationspar courrier électronique (spam) ;••un utilisateur utilise, volontairement une copie d’un logiciel dont le fonctionnementn’est pas garanti (par exemple une contrefaçon) ;••un logiciel est utilisé sans achat de la licence correspondante, ou la licencen’est pas renouvelée ;••un logiciel est analysé par l’attaquant en vue d’être corrompu : observationde son fonctionnement, observation de l’emploi de son espace mémoire,ingénierie inverse, etc. ;••tout ou partie du logiciel est détruit par un virus (bombe logique…) ;••le logiciel est modifié de manière involontaire : mise à jour avec une mauvaiseversion, modification de la configuration en maintenance, activationou désactivation de fonctions, changement de paramétrage du réseau,modification des règles de routage ou de résolution des noms de domaine.73

ANNEXE 4Menaces sur les réseaux••un attaquant écoute les informations circulant sur le réseau informatiqueou téléphonique, et réémet un message confidentiel vers l’adresse d’unforum public ;••un attaquant sature le réseau par un envoi massif de messages ;••un point d’accès sans fil mal configuré permet l’écoute de l’ensemble desdonnées qui transitent par Wifi ;••un attaquant sectionne les câbles d’une ligne téléphonique (tord la fibreoptique) empêchant physiquement la transmission des messages ;••une équipe de maintenance remplace un câble existant par un autre demoins grande capacité, etc. ;••des voleurs dérobent les câbles de transmission en cuivre pour les revendreà la ferraille.Menaces sur les personnels••l’unique administrateur d’une application critique est victime d’une épidémiede grippe••une grève des transports paralyse l’accès au site hébergeant les postes detravail ;••une contamination dans le restaurant d’entreprise crée une intoxicationalimentaire chez de nombreux agents ;••l’un des agents se déplaçant régulièrement bavarde avec des inconnusrencontrés au wagon-bar du TGV des anomalies de fonctionnement dusystème ;••un agent, perturbé par une surcharge de tâches, commet des erreurs demanipulation du système ;••l’ergonomie du poste de travail (mauvais éclairage, siège inconfortable,etc.) nuit au bon usage du logiciel ;••un agent passe une part significative de son temps de travail sur les sitesde jeux en ligne, ce qui nuit à l’efficacité du système ;74

ANNEXE 4••l’agent expert dans l’usage d’une fonction critique du système demande samutation pour se rapprocher de son conjoint ;••une réorganisation ou un déménagement rompent les échanges entre personnesqui s’étaient établies pour pallier les faiblesses fonctionnelles dusystème.Menaces sur les locaux• • il existe un risque qu’un incendie se déclenche dans les locaux sans êtredétecté ;• • le bâtiment hébergeant le système se situe dans une zone industriellecomportant des entreprises soumises à autorisation préfectorale (ex.SEVESO) susceptibles de générer un accident industriel (explosion) ;• • emploi de mauvais matériaux, construction défectueuse, mouvements deterrain sapant les fondations, infiltration d’eau dans le sol, etc.75

Version 2.0 - Juin 201420140604-1555Licence Ouverte/Open Licence (Etalab - V1)AGENCE NATIONALE DE LA SÉCURITÉ DES SYSTÈMES D’INFORMATIONANSSI - 51, boulevard de la Tour-Maubourg - 75700 PARIS 07 SPwww.ssi.gouv.fr / communication@ssi.gouv.fr