PROTECTION DES ICUE TRAITÉES DANS LES SIC
I. INTRODUCTION
1. La présente annexe énonce les modalités d’application de l’article 10.
2. Les propriétés et les notions d’AI figurant ci-après sont essentielles pour la sécurité et l’exécution correcte des opérations dans le cadre d’un SIC.
Authenticitégarantie que l’information est véridique et émane de sources dignes de foi.
Disponibilitécaractéristique de l’information selon laquelle elle est accessible et utilisable, à la demande d’une entité autorisée.
Confidentialitépropriété selon laquelle les informations ne sont pas divulguées à des personnes ou à des entités non autorisées et l’accès à ces informations n’est pas accordé à des processus non autorisés.
Intégritépropriété consistant à préserver l’exactitude et le caractère complet des informations et éléments.
Non-répudiationla possibilité de prouver qu’une action ou un événement a eu lieu, de sorte qu’il ne peut être contesté par la suite.
II. PRINCIPES D’ASSURANCE DE L’INFORMATION
3. Les dispositions énoncées ci-après constituent les éléments fondamentaux permettant de garantir la sécurité de tout SIC traitant des ICUE. Les modalités précises de mise en œuvre de ces dispositions sont définies dans les politiques et les lignes directrices en matière de sécurité d’AI.
Gestion des risques de sécurité
4. La gestion des risques de sécurité fait partie intégrante de la définition, de l’élaboration, de l’exploitation et de la maintenance d’un SIC. La gestion des risques (évaluation, traitement, acceptation et communication) est mise en œuvre conjointement, dans le cadre d’un processus itératif, par les représentants des détenteurs de systèmes, les autorités responsables du projet, les autorités chargées de l’exploitation et les autorités d’homologation de sécurité selon une procédure d’évaluation des risques ayant fait ses preuves, transparente et pouvant être parfaitement comprise. Le domaine d’application du SIC et ses ressources sont clairement définis dès le début du processus de gestion des risques.
5. Les autorités compétentes examinent les menaces potentielles qui pèsent sur le SIC, tiennent à jour les évaluations des menaces et veillent à leur exactitude afin que celles-ci rendent compte de l’environnement opérationnel du moment. Elles actualisent en permanence leurs connaissances relatives aux questions de vulnérabilité et revoient régulièrement l’évaluation de la vulnérabilité afin de suivre l’évolution de la technologie de l’information.
6. Le traitement des risques de sécurité vise à appliquer un ensemble de mesures de sécurité offrant un équilibre satisfaisant entre les besoins des utilisateurs, les coûts et le risque de sécurité résiduel.
7. Les exigences spécifiques, l’étendue et le niveau de détail fixés par l’AHS compétente aux fins de l’homologation d’un SIC sont proportionnés au risque évalué, compte tenu de tous les facteurs pertinents, y compris le niveau de classification des ICUE qui sont traitées dans le SIC. Dans le cadre de l’homologation, le risque résiduel fait l’objet d’un énoncé formel et est accepté par une autorité responsable.
Sécurité du SIC tout au long de son cycle de vie
8. Assurer la sécurité d’un SIC tout au long de son cycle de vie, de son lancement à son retrait, est une obligation.
9. Le rôle de chaque acteur d’un SIC et les interactions entre ces acteurs, en termes de sécurité du système, doivent être clairement déterminés pour chaque phase du cycle de vie.
10. Tout SIC, y compris les mesures de sécurité techniques et non techniques dont il fait l’objet, est soumis à des essais de sécurité au cours du processus d’homologation afin de s’assurer que le niveau d’assurance requis est atteint et de vérifier qu’il est correctement mis en œuvre, intégré et configuré.
11. Des évaluations, inspections et examens de sécurité sont réalisés à intervalles réguliers durant la phase opérationnelle ainsi que dans le cadre de la maintenance d’un SIC, de même qu’en toute circonstance exceptionnelle.
12. Les documents relatifs à la sécurité d’un SIC évoluent tout au long du cycle de vie de celui-ci, évolution qui s’inscrit pleinement dans le cadre du processus de gestion du changement et de la configuration.
Meilleures pratiques
13. Le SGC et les États membres travaillent de concert à l’élaboration des meilleures pratiques destinées à protéger les ICUE traitées par un SIC. Les lignes directrices concernant les meilleures pratiques énoncent des mesures visant à assurer la sécurité du SIC sur le plan technique et physique ainsi qu’au niveau de l’organisation et des procédures et dont l’efficacité pour lutter contre certaines menaces et vulnérabilités a été démontrée.
14. Il convient, aux fins de la protection des ICUE traitées par un SIC, de mettre à profit les enseignements tirés par les entités travaillant dans le domaine de l’AI, que ce soit au sein ou en dehors de l’Union.
15. La diffusion et la mise en œuvre ultérieure des meilleures pratiques contribuent à atteindre un niveau équivalent d’assurance dans l’ensemble des SIC traitant des ICUE et exploités par le SGC et les États membres.
Défense en profondeur
16. Afin d’atténuer les risques qui pèsent sur un SIC, un éventail de mesures de sécurité techniques et non techniques organisées en plusieurs niveaux de défense doit être mis en œuvre. Ces niveaux sont notamment les suivants:
a) la dissuasionmesures de sécurité visant à dissuader un éventuel adversaire de projeter une attaque du SIC;
b) la préventionmesures de sécurité visant à empêcher ou à stopper une attaque du SIC;
c) la détectionmesures de sécurité visant à déceler une attaque du SIC en train de se produire;
d) la résiliencemesures de sécurité visant à faire en sorte que l’attaque n’ait un impact que sur un nombre aussi faible que possible d’informations ou de ressources du SIC et à prévenir d’autres dommages; et
e) le retour aux conditions opérationnellesmesures de sécurité visant à rétablir la sécurité du SIC.
La rigueur de ces mesures de sécurité est déterminée sur la base d’une évaluation des risques.
17. L’ANS ou une autre autorité compétente s’assure:
a) que les capacités de cyber défense sont mises en œuvre afin de faire face aux menacées dont l’ampleur dépasse les limites de l’organisation ou du pays touché; et
b) que les réactions sont coordonnées et que les informations sur ces menaces et incidents et sur l’ensemble des risques qui en découlent sont partagées (capacités de réaction en cas d’urgence informatique).
Principes du minimalisme et du moindre privilège
18. Seuls sont mis en œuvre les fonctions, dispositifs et services indispensables pour répondre aux exigences opérationnelles.
19. Les utilisateurs d’un SIC et les processus automatisés se voient uniquement accorder les droits d’accès, les privilèges ou les autorisations requises pour mener à bien leur tâche, afin de limiter tout dommage résultant d’accidents, d’erreurs ou d’utilisations non autorisées des ressources du SIC.
20. Les procédures d’enregistrement mises en œuvre par un SIC, le cas échéant, sont vérifiées dans le cadre du processus d’homologation.
Sensibilisation à l’assurance de l’information
21. La sensibilisation aux risques et aux mesures de sécurité disponibles constitue la première ligne de défense destinée à assurer la sécurité des SIC. En particulier, tout le personnel intervenant dans le cycle de vie d’un SIC, y compris les utilisateurs, doit bien comprendre:
a) que les défaillances en matière de sécurité peuvent porter gravement atteinte aux SIC;
b) le préjudice potentiel que peuvent causer à autrui l’interconnectivité et l’interdépendance; et
c) la responsabilité et l’obligation de rendre des comptes qui lui incombent concernant la sécurité du SIC, selon les fonctions qui sont les siennes dans le cadre des systèmes et processus.
22. Afin que les responsabilités en matière de sécurité soient bien comprises, une formation et une sensibilisation à l’AI sont obligatoires pour tout le personnel concerné, y compris les cadres supérieurs et les utilisateurs du SIC.
Évaluation et approbation des produits de sécurité informatique
23. Le niveau de confiance requis dans les mesures de sécurité, défini comme un niveau d’assurance, est déterminé à l’issue du processus de gestion des risques et conformément aux politiques et lignes directrices applicables en matière de sécurité.
24. Le niveau d’assurance fait l’objet d’une vérification au moyen de procédés et de méthodes reconnus à l’échelon international ou agréés au niveau national. Il s’agit principalement d’évaluations, de contrôles et d’audits.
25. Les produits cryptographiques destinés à protéger les ICUE sont évalués et agréés par une AAC nationale d’un État membre.
26. Avant d’être recommandés au Conseil ou au secrétaire général pour agrément, en application de l’article 10, paragraphe 6, ces produits cryptographiques doivent avoir satisfait à une évaluation par seconde partie réalisée par une autorité dûment qualifiée (AQUA) d’un État membre n’intervenant pas dans la conception ni dans la fabrication de l’équipement concerné. L’ampleur de l’évaluation par seconde partie nécessaire dépend du niveau de classification maximal envisagé des ICUE que ces produits doivent protéger. Le Conseil approuve une politique de sécurité concernant l’évaluation et l’agrément de produits cryptographiques.
27. Lorsque des motifs opérationnels particuliers le justifient, le Conseil ou le secrétaire général, selon le cas, peut, sur recommandation du comité de sécurité, ne pas respecter les exigences prévues aux paragraphes 25 et 26 de la présente annexe et délivrer un agrément à titre provisoire pour une période spécifique, en application de la procédure énoncée à l’article 10, paragraphe 6.
28. Le Conseil, statuant sur recommandation du comité de sécurité, peut accepter le processus d’évaluation, de sélection et d’homologation des produits cryptographiques qui est en place dans un État tiers ou dans une organisation internationale et peut en conséquence tenir ces produits cryptographiques comme homologués aux fins de la protection des ICUE communiquées à cet État tiers ou à cette organisation internationale.
29. L’AQUA est une AAC d’un État membre qui a été agréée, sur la base de critères définis par le Conseil, pour procéder à la deuxième évaluation des produits cryptographiques destinés à protéger les ICUE.
30. Le Conseil approuve une politique de sécurité concernant la qualification et l’approbation des produits de sécurité informatique non cryptographiques.
Transmission à l’intérieur de zones sécurisées et de zones administratives
31. Nonobstant les dispositions de la présente décision, lorsque la transmission d’ICUE s’effectue uniquement à l’intérieur de zones sécurisées ou de zones administratives, une transmission non chiffrée ou d’un niveau de chiffrement inférieur peut être envisagée compte tenu des résultats d’un processus de gestion des risques et avec l’accord de l’AHS.
Interconnexion sécurisée des SIC
32. Aux fins de la présente décision, on entend par «interconnexion» la connexion directe d’au moins deux systèmes informatiques permettant à ceux-ci d’échanger des données et d’autres ressources en matière d’information (communication, par exemple) de façon unidirectionnelle ou multidirectionnelle.
33. Un SIC doit de prime abord considérer tout système informatique interconnecté comme n’étant pas fiable et mettre en œuvre des mesures de protection destinées à contrôler les échanges d’informations classifiées.
34. Lorsqu’un SIC est interconnecté avec un autre système électronique, les conditions de base suivantes doivent être réunies:
a) les conditions opérationnelles ou d’activités pour ces interconnexions sont définies et approuvées par les autorités compétentes;
b) l’interconnexion est soumise à un processus de gestion des risques et d’homologation et est approuvée par les AHS compétentes; et
c) des services de protection en bordure (SPB) sont mis en place à la périphérie de tout SIC.
35. Il ne peut y avoir aucune interconnexion entre un SIC homologué et un réseau non protégé ou public, sauf lorsque le SIC comporte un système de protection en bordure homologué installé à cette fin entre le SIC et le réseau non protégé ou public. Les mesures de sécurité applicables à une telle interconnexion sont examinées par l’autorité chargée de l’assurance de l’information compétente et approuvées par l’AHS compétente.
Lorsque le réseau public ou non protégé sert uniquement à des fins de transmission et que les données sont chiffrées au moyen d’un produit cryptographique agréé conformément à l’article 10, une telle connexion n’est pas considérée comme une interconnexion.
36. Un SIC homologué pour traiter des informations TRÈS SECRET UE/EU TOP SECRET ne peut pas être interconnecté directement ou en cascade à un réseau non protégé ou public.
Supports de données informatiques
37. Les supports de données informatiques sont détruits conformément aux procédures approuvées par l’autorité de sécurité compétente.
38. Les supports de données informatiques sont réutilisés, déclassés ou déclassifiés conformément aux lignes directrices en matière de sécurité qui doivent être arrêtées en vertu de l’article 6, paragraphe 2.
Situations d’urgence
39. Nonobstant les dispositions de la présente décision, les procédures spécifiques décrites ci-après peuvent être appliquées dans les situations d’urgence, telles que les crises, les conflits ou les guerres, imminentes ou effectives, ou dans des circonstances opérationnelles exceptionnelles.
40. Sous réserve du consentement de l’autorité compétente, les ICUE peuvent être transmises au moyen de produits cryptographiques agréés pour un niveau de classification inférieur ou sans faire l’objet d’un chiffrement dans le cas où tout retard causerait un préjudice indéniablement plus important que celui qui découlerait de la divulgation du matériel classifié et dans les conditions suivantes:
a) l’expéditeur et le destinataire ne possèdent pas le dispositif de chiffrement nécessaire ou ne possèdent aucun dispositif de chiffrement; et
b) le matériel classifié ne peut être communiqué en temps voulu par aucun autre moyen.
41. Les informations classifiées transmises dans les conditions visées au paragraphe 39 ne portent aucun marquage ni indication qui les distinguerait d’informations non classifiées ou pouvant être protégées à l’aide d’un produit cryptographique disponible. Leur destinataire est informé, sans délai et par d’autres moyens, du niveau de classification.
42. Lorsque des informations sont transmises en application du paragraphe 39, un rapport est par la suite adressé à ce sujet à l’autorité compétente et au comité de sécurité.
III. AUTORITÉS COMPÉTENTES EN MATIÈRE D’ASSURANCE DE L’INFORMATION
43. Les États membres et le SGC instituent les autorités compétentes en matière d’AI ci-après. Ces autorités ne doivent pas nécessairement être dotées d’entités structurées distinctes. Elles sont investies de mandats distincts. Cependant, ces autorités et leurs responsabilités connexes peuvent être associées ou intégrées dans la même entité structurée ou se partager entre différentes entités structurées, à condition que l’on veille à éviter au niveau interne tout conflit d’intérêt et tout chevauchement des tâches.
Autorité chargée de l’assurance de l’information
44. L’AAI s’acquitte des tâches suivantes:
a) définir les politiques et les lignes directrices de sécurité en matière d’AI et en surveiller l’efficacité et la pertinence;
b) conserver et gérer les données techniques relatives aux produits cryptographiques;
c) veiller à ce que les mesures en matière d’AI sélectionnées aux fins de la protection des ICUE soient conformes aux orientations régissant leur éligibilité et leur sélection;
d) veiller à ce que les produits cryptographiques soient sélectionnés conformément aux orientations régissant leur éligibilité et leur sélection;
e) coordonner la formation et la sensibilisation à l’AI;
f) mener des consultations avec le fournisseur du système, les intervenants en matière de sécurité et les représentants des utilisateurs au sujet des politiques et des lignes directrices de sécurité en matière d’AI; et
g) veiller à ce que les sous-divisions spécialisées du comité de sécurité disposent, de par leur composition, des compétences requises en matière d’AI.
Autorité TEMPEST
45. L’autorité TEMPEST (AT) est chargée de veiller à la conformité des SIC aux stratégies et lignes directrices TEMPEST. Elle approuve les contre-mesures TEMPEST pour les installations et les produits destinés à protéger des ICUE jusqu’à un certain niveau de classification dans leur environnement opérationnel.
Autorité d’agrément cryptographique
46. L’autorité d’agrément cryptographique (AAC) est chargée de veiller à ce que les produits cryptographiques soient conformes aux politiques respectives des différents États membres et du Conseil en matière cryptographique. Elle agrée les produits cryptographiques pour la protection d’ICUE jusqu’à un certain niveau de classification dans leur environnement opérationnel. S’agissant des États membres, l’AAC est en outre chargée de l’évaluation des produits cryptographiques.
Autorité de distribution cryptographique
47. L’autorité de distribution cryptographique (ADC) s’acquitte des tâches suivantes:
a) gérer le matériel cryptographique de l’Union européenne et en rendre compte;
b) veiller à ce que les procédures et les circuits appropriés soient mis en place pour rendre compte de tout le matériel cryptographique de l’Union européenne et en assurer la manutention, le stockage et la distribution en toute sécurité; et
c) assurer le transfert et la reprise du matériel cryptographique de l’Union européenne auprès des personnes ou des services utilisateurs.
Autorité d’homologation de sécurité
48. L’autorité d’homologation de sécurité de chaque système s’acquitte des tâches suivantes:
a) veiller à ce que les SIC soient conformes aux politiques et lignes directrices de sécurité pertinentes, délivrer une déclaration d’homologation pour les SIC en vue du traitement des ICUE jusqu’à un certain niveau de classification dans leur environnement opérationnel et indiquant les conditions et modalités de l’homologation ainsi que les critères dont l’existence justifie une nouvelle homologation;
b) mettre en place un processus d’homologation de sécurité conforme aux politiques pertinentes et indiquant clairement les conditions d’homologation que doivent remplir les SIC relevant de sa responsabilité;
c) définir une stratégie d’homologation de sécurité qui indique le niveau de précision du processus d’homologation en fonction du niveau d’assurance requis;
d) étudier et approuver les documents se rapportant à la sécurité, y compris en ce qui concerne la gestion des risques et les énoncés des risques résiduels, les énoncés des impératifs de sécurité propres à un système (ci-après dénommés «SSRS»), les documents concernant la vérification de la mise en œuvre des mesures de sécurité et les procédures d’exploitation de sécurité (ci-après dénommées «SecOP»), et veiller à ce qu’ils soient conformes aux politiques et aux règles du Conseil en matière de sécurité;
e) vérifier la mise en œuvre des mesures de sécurité en rapport avec les SIC en effectuant elle-même ou en finançant des évaluations, des inspections ou des réexamens en la matière;
f) définir les exigences en matière de sécurité (par exemple les niveaux d’habilitation de sécurité du personnel) applicables aux postes sensibles dans le cadre d’un SIC;
g) accepter la sélection des produits cryptographiques et TEMPEST ayant fait l’objet d’une approbation qui sont utilisés pour assurer la sécurité d’un SIC;
h) approuver, le cas échéant dans le cadre d’une approbation conjointe, l’interconnexion d’un SIC à d’autres SIC; et
i) mener des consultations avec le fournisseur du système, les intervenants en matière de sécurité et les représentants des utilisateurs au sujet de la gestion des risques de sécurité, et notamment du risque résiduel, et des conditions et modalités de la déclaration d’homologation.
49. L’AHS du SGC est chargée de l’homologation de tous les SIC exploités dans le cadre de la compétence du SGC.
50. L’AHS compétente d’un État membre est chargée de l’homologation des SIC et des éléments des SIC exploités dans le cadre de la compétence d’un État membre.
51. Un comité conjoint d’homologation de sécurité (CHS) est chargé de l’homologation des SIC qui sont du ressort aussi bien de l’AHS du SGC que des AHS des États membres. Ce comité est composé d’un représentant de l’AHS de chaque État membre, un représentant de l’AHS de la Commission assistant à ses réunions. Les autres entités disposant de nœuds de connexion avec un SIC sont invitées à assister aux réunions lorsque celles-ci portent sur le système considéré.
Le CHS est présidé par un représentant de l’AHS du SGC. Il statue par consensus entre les représentants des AHS des institutions, des États membres et des autres entités disposant de nœuds de connexion avec le SIC considéré. Le CHS rend compte à intervalles réguliers de ses activités au comité de sécurité et notifie à celui-ci toute déclaration d’homologation.
Autorité opérationnelle chargée de l’assurance de l’information
52. L’autorité opérationnelle chargée de l’AI pour chaque système s’acquitte des tâches suivantes:
a) élaborer des documents relatifs à la sécurité de chaque système conformes à la politique et aux lignes directrices en matière de sécurité, et notamment les SSRS, y compris en ce qui concerne le risque résiduel, les SecOP et le volet cryptographique du processus d’homologation des SIC;
b) participer à la sélection et à la mise à l’essai des mesures, dispositifs et logiciels de sécurité technique propres à un système, superviser leur mise en œuvre et s’assurer qu’ils sont installés, configurés et entretenus de manière sûre conformément aux documents de sécurité pertinents;
c) participer à la sélection des mesures et des dispositifs de sécurité TEMPEST lorsque les SSRS le prévoient, et veiller à ce qu’ils soient installés et entretenus de manière sûre en coopération avec l’AT;
d) assurer le suivi de la mise en œuvre et de l’application des SecOP et, s’il y a lieu, déléguer les responsabilités opérationnelles de sécurité au détenteur du système;
e) gérer et utiliser les produits cryptographiques, assurer la protection des éléments chiffrés et contrôlés et, au besoin, assurer la production de variables cryptographiques;
f) procéder au réexamen et à des analyses de sécurité et à des tests, notamment afin d’établir les rapports nécessaires sur les risques encourus, comme l’exige l’AHS;
g) dispenser une formation sur l’AI propre à chaque SIC; et
h) mettre en œuvre et gérer des mesures de sécurité propres à chaque SIC.