Conseil de

Union européenne

Bruxelles, le 6 juillet 2015

(OR. en)

10416/15

CSCI 43
CSC 162

NOTE POINT "I/A"

Origine: Comité de sécurité du Conseil
Destinataire: Coreper/Conseil
Objet: Politique de sécurité en matière d'assurance de l'information concernant
l'ingénierie de sécurité des systèmes de communication et d'information

1. La décision du Conseil concernant les règles de sécurité aux fins de la protection des
informations classifiées de l’Union européenne 1 dispose ce qui suit: "Le cas échéant,
le Conseil approuve, sur recommandation du comité de sécurité, les politiques de sécurité
énonçant les mesures destinées à mettre en œuvre la présente décision" (voir article 6,
paragraphe 1).

2. Le Comité de sécurité du Conseil a décidé de recommander l'approbation d'une politique

établissant des normes concernant l'ingénierie de sécurité des systèmes de communication et
d'information (SIC) aux fins de la protection des informations classifiées de l'UE (ICUE)
présentes dans de tels systèmes, du point de vue de leur confidentialité, de leur intégrité, de
leur disponibilité et, selon les cas, de leur authenticité et de leur non-répudiation.

3. Sous réserve de confirmation par le Coreper, le Conseil est invité à approuver la politique
de sécurité ci-jointe.

1
Décision 2013/488/UE du Conseil (JO L 274 du 15.10.2013, p. 1).

10416/15 hel/DB/pad 1
DGA SSCIS FR
 (Page laissée vide à dessein)

10416/15 hel/DB/pad 2
DGA SSCIS FR
Politique de sécurité en matière d'assurance de l'information (AI) concernant l'ingénierie de
sécurité des systèmes de communication et d'information
IASP 5

10416/15 hel/DB/pad 3
DGA SSCIS FR
I OBJET ET CHAMP D'APPLICATION

1. La présente politique, approuvée par le Conseil conformément à l'article 6, paragraphe 1,

des règles de sécurité du Conseil (ci-après dénommées "RSC"), établit des normes applicables
à la protection des informations classifiées de l'UE (ICUE). Elle constitue un engagement en
vue de contribuer à garantir un niveau équivalent de mise en œuvre des RSC.

2. La présente politique établit des principes et des activités spécifiques, en matière de sécurité,
devant être intégrés dans un cadre d'ingénierie développé par l'organisation afin d'assurer que
les questions de sécurité soient prises en compte en temps voulu lors du développement
des SIC.

3. Le Conseil et le Secrétariat général du Conseil (SGC) appliqueront la présente politique

en matière de sécurité aux fins de la protection des ICUE, dans leurs installations et leurs SIC.

4. Les États membres agiront conformément à leurs dispositions législatives et réglementaires

nationales pour faire en sorte que le traitement des ICUE par les structures nationales, et
notamment les SIC nationaux, soit effectué dans le respect des normes établies dans les
politiques de sécurité.

5. Les agences et les organes de l'Union créés en vertu du titre V, chapitre 2, du TUE,
ainsi qu'Europol et Eurojust, devraient utiliser cette politique de sécurité comme référence
pour la mise en œuvre des règles de sécurité au sein de leurs propres structures.

6. L'ingénierie des systèmes de sécurité doit garantir que la posture de sécurité d'un SIC
correspond aux risques attendus. À défaut, il existerait des possibilités d'utilisation abusive
non détectée du SIC en raison de l'existence de capacités non prévues ou à l'inverse de
l'absence de certaines capacités. Cette politique établit les principes et activités à mettre en
œuvre au minimum pendant la phase de conception d'un SIC (définie dans la politique de
sécurité en matière d'AI concernant la sécurité tout au long du cycle de vie d'un SIC 1) afin de
réduire ces possibilités dans le cadre d'une approche fondée sur la gestion des risques.

2
Voir le doc 16268/12.

10416/15 hel/DB/pad 4
DGA SSCIS FR
7. La présente politique n'est pas destinée à établir un cadre spécifique pour l'ingénierie des
systèmes de sécurité. Il s'agit plutôt, pour l'organisation, d'intégrer la présente politique dans
le cadre d'ingénierie pour les SIC et de veiller à ce que les ressources utiles soient disponibles
pour soutenir sa mise en œuvre. Des lignes de conduite appropriées exposeront, par objectif
de sécurité, les modalités de la mise en œuvre minimale commune de ces principes et de ces
activités.

II INGÉNIERIE DE SÉCURITÉ DES SYSTÈMES

Principes d'ingénierie de sécurité des systèmes

8. L'organisation doit élaborer des procédures pour appliquer les principes énoncés ci-dessous.
Tout écart par rapport à ces principes doit être justifié dans la documentation relative à la
sécurité du SIC:
a) mise à l'épreuve continue de la sécurité: toutes les hypothèses et tous les éléments de
fait concernant la sécurité doivent être régulièrement réévalués, selon ce que l'autorité
d'homologation juge approprié;
b) configurations sécurisées: les meilleures pratiques en ce qui concerne la configuration
de l'architecture et de la conception doivent être respectées, en appliquant au minimum
les concepts de défense en profondeur, de conception en couches/segmentation, de
minimalisme et de simplicité. Les motivations des choix des configurations doivent être
documentées;
c) produit de sécurité: les SIC doivent recourir à des produits qualifiés, conformément à la
politique de sécurité en matière d'AI applicable et tels que définis dans l'architecture de
sécurité de l'entreprise. Le choix d'un produit qui ne répond pas à ces critères doit être
documenté et justifié par l'autorité opérationnelle responsable chargée de l'AI, et
approuvé par la procédure d'homologation. La mise en œuvre est définie dans le cadre
d'une ou de configurations approuvées et actualisées, et maîtrisée par un personnel
qualifié;
d) formation à la sécurité: le personnel associé aux activités d'ingénierie destinées à assurer
la sécurité ou ayant une influence sur la sécurité (concernant par exemple l'architecture,
la conception, la programmation, la configuration, les tests, les passations de marché,
etc.) doit avoir un niveau suffisant de formation; cette formation doit être documentée;

10416/15 hel/DB/pad 5
DGA SSCIS FR
 e) services de sécurité: tout SIC doit mettre en œuvre, au minimum, des services de
sécurité concernant l'identification et l'authentification, le contrôle d'accès et l'obligation
de justification. Les mécanismes correspondants doivent être conformes au niveau de
robustesse et d'assurance exigé dans l'énoncé des impératifs de sécurité propres à un
système (SSRS);
f) rôles de sécurité: les rôles liés au développement des systèmes et à l'assurance de la
qualité (y compris l'homologation) ne peuvent être joués par les mêmes intervenants;
g) séparation des systèmes: les systèmes opérationnels et d'essai devraient être distincts. Si
le système opérationnel est également utilisé pour tester les mises à jour (par exemple
les correctifs ou les nouvelles versions de programmes), la documentation de sécurité
doit comprendre toutes les tâches à exécuter pour éviter de compromettre les objectifs
de sécurité des SIC.

Vue d'ensemble du contexte de sécurité des SIC

9. La sécurité d'un SIC peut être compromise bien avant que le système soit livré pour utilisation
opérationnelle: une évaluation déficiente des vulnérabilités potentielles dans la conception et
les futurs environnements opérationnels peut laisser la porte ouverte à l'intégration (ou au
maintien) de composantes ou fonctionnalités indésirables qui pourraient avoir un impact sur la
posture de sécurité.

10. Pour recenser ces vulnérabilités et procéder à leur évaluation précise, l'organisation doit
mettre au point et actualiser en permanence une vue d'ensemble du contexte de sécurité des
SIC. Cette vue d'ensemble est intégrée dans l'architecture de sécurité de l'entreprise et doit:
a) recenser et surveiller toutes les ressources utilisées au cours du cycle de vie des SIC,
qu'il s'agisse de ressources techniques (par exemple les algorithmes réutilisés, les
normes de programmation, des outils tels que des compilateurs...), de ressources
humaines (liées par exemple aux compétences, à l'habilitation...), d'installations (par
exemple le niveau de protection, l'accès...) ou de procédures (par exemple pour les
marchés publics, la chaîne d'approvisionnement, l'application de correctifs...);
b) définir le niveau de confiance attribué à ces ressources;
c) disposer de procédures appropriées pour l'introduction, la modification ou le retrait des
ressources;
d) être mise à l'épreuve, en ce qui concerne les hypothèses et la garantie de sécurité, de
manière à vérifier qu'elle continue d'opérer conformément à son appétence au risque.

10416/15 hel/DB/pad 6
DGA SSCIS FR
11. Lors du développement d'un nouveau SIC (ou d'une nouvelle composante d'un SIC existant),
la vue d'ensemble sera utilisée pour compléter l'architecture de sécurité conceptuelle, mise au
point lors de la phase de justification, par des exigences supplémentaires concernant
l'architecture, afin de contrer les vulnérabilités et menaces potentielles. Ces exigences
supplémentaires doivent être prises en compte dans l'évaluation des risques spécifique au
système et documentées dans le SSRS.

Activités d'ingénierie de sécurité des systèmes

12. Pour garantir une bonne intégration de la sécurité dans les systèmes, le cadre de l'architecture
des SIC et les procédures de gestion des projets de l'organisation doivent comprendre au
minimum les activités qui suivent:
a) pour la modélisation des activités et de l'architecture, sélection de langages capables de
représenter la problématique de sécurité liée au SIC;
b) production de vues d'ensemble détaillées concernant l'architecture et la conception,
intégrant les services et les mécanismes de sécurité;
c) développement d'un cadre de dossiers d'assurance de la sécurité afin d'établir comment
les allégations et les éléments de preuve doivent être formulés et testés.

13. L'organisation doit mettre au point une stratégie pour le développement des SIC (ou de leurs
composantes) soit par des ressources internes, soit par un ou plusieurs fournisseurs extérieurs.
Cette stratégie doit prendre en compte les paramètres de sécurité en ce qui concerne les
aspects suivants au minimum:
a) capacité interne de développement de SIC conformes à des objectifs de sécurité
spécifiques;
b) critères de sélection pour le développement d'un SIC soit en interne soit en externe;
c) dispositions relatives aux marchés publics afin de garantir que les exigences de sécurité
soient dûment prises en compte lors de la sélection d'une offre;
d) dispositions à inclure dans les documents contractuels afin de définir les droits et les
obligations des fournisseurs.

10416/15 hel/DB/pad 7
DGA SSCIS FR
14. Pour fixer le cadre du développement d'un SIC, l'organisation doit:
a) créer un répertoire d'architectures et de solutions documentées et maîtrisées répondant
aux besoins opérationnels les plus génériques de l'organisation;
b) créer un catalogue de contrôles de sécurité maîtrisés pouvant être utilisés pour mettre en
œuvre une posture de sécurité. Ces contrôles doivent être étayés par les procédures
applicables concernant les modalités de la fourniture des preuves de leur efficacité;
c) définir les environnements approuvés pour le développement des SIC, en fournissant
des détails sur les ressources (par exemple les installations, les logiciels, les outils, le
personnel...) à mettre en œuvre pour garantir l'intégrité des systèmes et la confidentialité
des tests en cours de développement. Ces environnements approuvés doivent être
conformes à la vue d'ensemble du contexte de sécurité des SIC.

15. Au cours du développement d'un système, les procédures doivent garantir:

a) que tout écart par rapport au répertoire de l'architecture de sécurité de l'entreprise soit
justifié, et que toute utilisation d'un nouveau produit ou d'une variante soit justifiée par
une preuve de capacité concernant la configuration ou le fonctionnement en matière de
sécurité, ou expressément acceptée par l'autorité d'homologation de sécurité (AHS);
b) que, lorsqu'un système complexe doit être subdivisé, les objectifs de sécurité des
composantes restent conforment à ceux du système entier;
c) que, lorsque l'architecture ou la conception connaissent une évolution majeure, des vues
d'ensemble actualisées soient approuvées par les intervenants, afin de confirmer que les
préoccupations de sécurité restent prises en compte de façon adéquate.

Tests des systèmes de sécurité

16. L'organisation doit planifier des tests de sécurité progressifs au cours du développement du
système. Les tests qui doivent être pratiqués pour garantir la posture de sécurité du SIC
lorsque le système est déployé dans les installations opérationnelles doivent être décrits dans
un document sur les tests relatifs à l'installation du SIC. Ce document fait partie des
procédures d'exploitation de sécurité (SecOP).

10416/15 hel/DB/pad 8
DGA SSCIS FR
17. Un ou plusieurs dossiers d'assurance de la sécurité doivent être élaborés pour définir la
manière dont les allégations relatives à la sécurité peuvent être étayées par des éléments de
preuve. Ceux-ci devraient être mesurables et reproductibles et se fonder sur des données
mesurables concrètes. Les dossiers doivent garantir que les mécanismes concernant la
robustesse et la garantie de sécurité sont conformes aux dispositions du SSRS.

18. L'organisation doit veiller à ce que:

a) les objectifs, les procédures et les instruments, en ce qui concerne les tests, soient
conformes aux dossiers de sécurité;
b) les tests soient exécutés par du personnel qualifié;
c) les tests de sécurité partiels soient effectués dès que possible au cours du processus de
développement, afin d'éviter des décisions partielles, en matière de développement, qui
pourraient avoir pour conséquence de compromettre les objectifs de sécurité pour le
SIC;
d) en cas d'externalisation, des procédures soient suivies pour garantir un contrôle adéquat
des tests exécutés et une classification des données relatives aux tests.

Résultats de la phase d'ingénierie

19. Le système fourni à des fins opérationnelles doit être accompagné, au minimum, des
documents qui suivent en matière de sécurité:
a) le SSRS;
b) les SecOP;
c) des plans relatifs aux ressources de sécurité, afin de renforcer la sécurité, y compris les
conditions et garanties détaillées applicables aux passations de marché et à
l'externalisation, le cas échéant.

_____________________

10416/15 hel/DB/pad 9
DGA SSCIS FR