CIRCULAIRE N° 51437/DEF/CAB/C/23/FSI relative aux procédures de présentation devant la commission de sécurité informatique du ministère de la défense des dossiers relatifs au traitement automatisé d'informations.
Du 04 octobre 1984NOR
1. Généralités.
1.1.
L'organisation mise en place dans le cadre des directives interministérielles pour assurer la sécurité informatique au sein des organismes du ministère de la défense a fait l'objet de l'instruction ministérielle citée en référence.
Une structure à trois niveaux a été définie :
une commission de sécurité informatique (CSI) présidée par un fonctionnaire de sécurité en informatique (FSI) chargée de définir la politique de sécurité, de préciser les mesures nécessaires à sa mise en œuvre et d'en vérifier l'application ; le FSI est directement rattaché au fonctionnaire de sécurité de défense ;
une autorité qualifiée dans chacun des grands organismes du ministère, responsable de la sécurité des systèmes informatiques relevant de son autorité, de leur homologation, de leur contrôle et de l'adaptation éventuelle des mesures de sécurité à la spécificité des systèmes ;
des chefs de centre ou responsables de systèmes, secondés par un officier de sécurité informatique, mettant en œuvre les dispositions prescrites et établissant les consignes particulières de sécurité.
1.2.
Aucune réalisation informatique ne doit être entreprise sans qu'ait été précisée l'importance à accorder à l'aspect sécurité informatique de l'affaire et les exigences minimales auxquelles la solution finale devra répondre.
Cet aspect sécurité, dont les implications financières peuvent être importantes, doit apparaître dans les trois principales étapes de toute réalisation informatique sous la forme suivante :
prise de conscience de cet aspect dès la formalisation du projet ou de l'opération dans le schéma directeur informatique et appréciation générale du surcoût financier entraîné par les mesures de sécurité envisagées ;
expression détaillée et limitative dans le cahier des charges des critères de sécurité exigés ;
analyse, dans le rapport de présentation, du degré de satisfaction des propositions par rapport aux critères de sécurité souhaités.
1.3.
La présente circulaire a pour objet de préciser le domaine d'action de la commission de sécurité informatique pour chacune de ces étapes et les procédures à suivre pour obtenir l'avis de la CSI ou de son président. Ces procédures sont récapitulées en annexe 1.
Les affaires susceptibles de rentrer dans ce cadre peuvent être :
des créations de centres ou systèmes nouveaux devant être homologués ;
des modifications de centres ou systèmes déjà existants dans la mesure où les opérations ou projets envisagés conduiraient :
soit à accroître leur niveau d'homologation s'ils sont déjà homologués ;
soit à les homologuer s'ils ne l'étaient pas.
Il sera nécessaire dans ces deux derniers cas d'examiner les conséquences de l'opération envisagée et notamment d'apprécier dans quelle mesure l'ensemble du système déjà en place satisfait aux règles du nouveau degré d'homologation et de prendre éventuellement les dispositions nécessaires pour les faire respecter.
Elles peuvent concerner :
soit des équipements centraux ou périphériques ;
soit des systèmes de transmission de données et équipements périphériques associés ;
soit des logiciels de contrôle d'accès ou de chiffrement ;
soit éventuellement des applications si leur mise en œuvre implique une modification du niveau d'homologation du centre ou du système.
La commission de sécurité n'est pas compétente en ce qui concerne les composantes informatiques des systèmes d'armes traitant des informations à durée de vie courte dont la protection spécifique est intégrée dans le système dont elles font partie.
2. Schéma directeur.
2.1.
La prise de conscience des contraintes de sécurité doit avoir lieu au plus tard au moment de l'établissement du schéma directeur annuel dans lequel doivent donc apparaître les exigences générales de sécurité arrêtées par chaque autorité qualifiée.
Sur un plan pratique la procédure à adopter sera la suivante :
conservation de la structure habituelle d'élaboration et de présentation des schémas directeurs ;
établissement de deux listes récapitulant l'une les opérations envisagées nécessitant une habilitation et l'autre les projets entraînant une modification de l'habilitation du centre ou du système concerné et donc un nouvel examen du niveau de sécurité.
L'utilisation des repères employés dans le schéma directeur doit permettre de se référer facilement à ce dernier. Les modèles de ces listes sont donnés en annexe 2.
2.2.
Les deux listes récapitulatives doivent permettre :
d'attirer l'attention des autorités qualifiées sur les problèmes de sécurité en cours et sur les choix à exprimer dans ce domaine ;
d'informer la commission de sécurité informatique des futurs besoins de sécurité pour l'ensemble du ministère.
Elles sont établies, éventuellement avec un degré de classification supérieur à celui du schéma directeur, en deux exemplaires et adressées par l'autorité qualifiée pour information :
l'une à la commission de sécurité informatique ;
l'autre à la commission de l'informatique, générale ou spécifique, dont ressort le schéma directeur.
2.3.
L'établissement de ces listes, au même titre que les inscriptions au schéma directeur des autres opérations, n'a qu'une valeur d'information et non d'engagement.
Bien que leur communication ne soit pas demandée il est conseillé de présenter également aux autorités qualifiées une estimation des charges supplémentaires entraînées par la prise en compte de la sécurité pour chacune des opérations mentionnées dans les listes prévues en annexe 2.
Au vu de ces listes et en accord avec les autorités qualifiées le FSI définit à ce stade les procédures de principe qui devront normalement être appliquées pour l'examen ultérieur des dossiers : avis de la commission ou procédure allégée d'avis direct de son président.
3. Cahier des charges.
3.1.
Le cahier des charges transmis aux différents soumissionnaires consultés doit définir sans ambiguïté les exigences minimales de sécurité et l'autorité qualifiée entend satisfaire en fonction du degré de protection qu'elle veut assurer, sans se contenter de demander au fournisseur de décrire tous les dispositifs, caractéristiques ou possibilités des équipements qu'il est susceptible de proposer.
Les exigences de sécurité se déduisent de l'analyse de sécurité conduite à l'occasion de l'étude d'opportunité du projet. Elles feront, chaque fois qu'elles existent l'objet d'un chapitre spécifique du cahier des charges. L'annexe 3 jointe définit un cadre spécifique du cahier des charges. L'annexe 3 jointe définit un cadre dont il est possible de s'inspirer pour rédiger ce chapitre. Le rapport de présentation générale du dossier devra comporter un paragraphe particulier faisant bien ressortir les exigences de sécurité.
Seront concernés par la procédure tous les dossiers relatifs aux opérations ou projets mentionnés dans les listes jointes au schéma directeur ou envisagés après approbation du schéma directeur sans qu'il soit possible d'attendre le schéma directeur suivant.
3.2.
Deux types de procédures sont prévus pour permettre à la commission de sécurité d'émettre un avis sur les dossiers concernés ou de formuler des conseils :
examen du dossier par l'ensemble de la commission réunie en formation plénière ;
examen direct du dossier par le fonctionnaire de sécurité informatique (procédure allégée) : dans ce cas le FSI peut prendre, s'il en épreuve le besoin, l'avis de certains des membres de la commission ou d'experts de son choix. Les membres de la commission sont destinataires de son avis final.
Pour ne pas accroître les délais d'instruction des affaires par la commission de l'informatique compétente (générale ou spécifique) les dossiers seront transmis par l'autorité qualifiée dans les conditions suivantes :
transmission habituelle à la commission d'informatique générale (CIG) ou à la CIS, du nombre réglementaire d'exemplaires ;
envoi simultané d'un exemplaire supplémentaire du cahier des charges et du rapport de présentation directement à la commission de sécurité.
3.3.
Le fonctionnaire de sécurité peut :
soit émettre un avis direct dans un délai de quinze jours ;
soit, lorsque l'importance de l'affaire le justifie en application des dispositions du paragraphe 23, ou lorsqu'un avis défavorable de sa part n'est pas accepté par l'autorité qualifiée, convoquer la commission de sécurité pour examen du dossier dans un délai d'un mois après diffusion des exemplaires supplémentaires nécessaires.
Les avis du fonctionnaire ou de la commission sont adressés à l'autorité qualifiée avec copie à la commission d'informatique concernée.
L'autorité qualifiée peut passer outre aux avis de la commission plénière mais doit alors justifier sa position auprès du ministre.
Les commissions d'informatique ne formulent leur avis qu'après avoir pris connaissance de celui du fonctionnaire ou de la commission de sécurité. Elles n'examinent les dossiers que sur le plan technique et sur celui des procédures de consultation : elles n'ont pas à se prononcer sur l'aspect sécurité du problème et doivent seulement s'assurer que les cahiers des charges ont été éventuellement modifiés pour tenir compte des avis formulés sauf si l'autorité qualifiée a passé outre.
4. Rapport final de choix.
Ce rapport est établi après examen des différentes propositions reçues par le service. Il comporte normalement :
les différentes propositions ;
une analyse technique et financière ;
le choix préférentiel du service.
La présentation du rapport doit permettre à la commission de sécurité d'émettre un avis sur l'aspect sécurité de la solution choisie. Selon l'importance du dossier un document, chapitre ou paragraphe particulier fera ressortir :
le degré de satisfaction de la solution au regard des exigences formulées dans le cahier des charges ;
les exigences qui n'ont pu être satisfaites ;
les délais, les développements et les coûts supplémentaires qu'il serait nécessaire de supporter pour satisfaire toutes les exigences ;
la position de l'autorité qualifiée au regard d'une insatisfaction totale ou partielle et les actions qu'elle envisage de mener à terme pour y remédier.
Les procédures de transmission des dossiers, d'examen et d'avis par les différentes commissions de sécurité et d'informatique sont identiques à celles définies au paragraphe précédent pour les cahiers des charges.
5. Opérations ne nécessitant pas d'avis péalable d'une des deux commissions d'informatique.
Certaines opérations peuvent être réalisées sans qu'il soit nécessaire de rédiger un cahier des charges ni de faire appel à la concurrence : c'est le cas en particulier des applications conçues et réalisées directement par les services. Elles n'ont en général qu'une influence budgétaire interne et ne sont pas toujours mentionnées dans le schéma directeur.
Elles doivent cependant toujours être attentivement examinées par les autorités qualifiées en fonction de leur impact éventuel sur le plan de la sécurité :
modification du niveau d'habilitation ;
conséquences ultérieures sur les procédures utilisées ou les équipements en place.
Il appartient dans ces cas-là aux autorités qualifiées d'apprécier l'intérêt ou la nécessité de demander l'avis de la commission ou du fonctionnaire de sécurité informatique.
En tout état de cause, les prescriptions des articles 5.3 et 5.4 de l'instruction no 4418/DEF du 6 juillet 1981 relatives à la validité et au compte rendu d'homologation doivent être appliquées en cas de modification consécutive du niveau d'homologation.
6. Opérations ne relevant pas de la commission de sécurité.
L'article 2 de l'instruction no 4418/DEF du 6 juillet 1981 précise les types d'information à protéger :
informations protégées de défense nationale ;
informations protégées rentrant dans le cadre de traités d'alliance et d'accords ;
informations nominatives à caractère confidentiel.
Les opérations et projets ne couvrant pas ces catégories d'informations ne seront présentés par les autorités qualifiées que si elles le jugent nécessaire. Sinon, seules les deux commissions ont à se prononcer sur leur réalisation. Il en est de même pour les opérations ou projets ne remettant pas en cause le niveau d'homologation d'un centre ou d'un système déjà homologué. Pour éviter tout oubli et faciliter l'examen des dossiers, la lettre d'envoi ou la fiche de synthèse accompagnant chaque dossier soumis à l'avis préalable d'une des deux commissions de l'informatique du ministère devra obligatoirement comporter un paragraphe mentionnant l'une des informations suivantes :
opération ne présentant pas de caractère particulier de sécurité relevant de la commission de sécurité ;
opération liée à un centre déjà homologué mais n'influant pas sur le niveau de l'homologation actuelle ;
opération pour laquelle un avis de la commission de sécurité informatique a été requis.
Pour le ministre de la défense et par délégation :
Le directeur du cabinet civil et militaire,
François BERNARD.
Annexes
ANNEXE 1. Tableau récapitilatif des procédures.
Etapes. | Objectif. | Forme. | Modalités. |
---|---|---|---|
Schéma directeur. | Informer les commissions des futurs besoins de sécurité. | Liste récapitulative. | Transmis par l'autorité qualifiée en : — un exemplaire à la CI (CIG ou CIS) ; — un exemplaire à la CSI. |
Cahier des charges. | Exprimer les besoins de sécurité de l'autorité qualifiée. | Un paragraphe au rapport de présentation et un chapitre au cahier des charges. | L'autorité qualifiée transmet directement à la CSI : — un exemplaire du rapport de présentation ; — un exemplaire du cahier des charges. |
|
|
| Si l'affaire requiert l'examen en CSI des exemplaires supplémentaires pourront être demandés. |
|
|
| L'avis de la CSI ou du FSI est transmis simultanément à l'autorité qualifiée et à la CI (CIG ou CIS). |
Rapport de choix. | Contribuer au choix de la configuration sous son aspect sécurité. | Un paragraphe au rapport de présentation et sous une forme cohérente au rapport de choix. | Idem ci-dessus, le rapport de choix remplaçant le cahier des charges. |
ANNEXE 2.1.
ANNEXE 2.2.
ANNEXE 3. Plan type du chapitre sécurité du cahier des charges.
1 Concept de sécurité.
a) Les objets d'information.
Classement par niveaux de confidentialité et de sensibilité des informations stockées et traitées dans le système.
Classement des informations par catégories.
b) Les sujets et leurs droits d'accès.
Répartition des droits sur les objets accordés aux sujets en fonction du besoin d'en connaître :
utilisateurs ;
exploitants ;
personnel système ;
responsable sécurité.
c) Les modes d'exploitation.
Il s'agit de fixer l'orientation d'ensemble :
Niveau exclusif avec séparation physique ou quasi-physique entre le système et l'environnement.
Multi-niveaux :
avec traitements séparés par niveau ;
avec multitraitement à niveau dominant (mesures correspondant au niveau le plus élevé) ;
avec multitraitement sans niveau dominant, etc.
d) Exigences de base sur le logiciel de sécurité.
Confinement du logiciel de sécurité : modules de sécurité distincts, interfaces bien définis, etc.
Niveau de protection des mécanismes de sécurité.
Evaluation de l'efficacité du logiciel de sécurité (par exemple : en demandant la réalisation de tests de conformité des fonctions de sécurité à celles décrites dans la documentation).
e) Réseau.
Contraintes générales de sécurité.
2 Contrôle d'accès.
Les spécifications porteront sur tout ou partie des points suivants :
a) Type d'authentification.
Identification de l'utilisateur, du terminal.
Authentification :
authentification de l'utilisateur ;
authentification mutuelle ;
authentification continue.
b) Sûreté d'authentification exigée.
c) Mode d'authentification.
Eventuellement, préciser le mode exigé :
caractéristique physique de l'utilisateur ;
objet détenu (clef, badge, carte à pistes…) ;
secret détenu (mots de passe, dialogue personnalisé…).
d) Surveillance des accès et réaction en cas d'incident.
Passive : trace des tentatives d'accès ou des transactions émises dans un journal à exploitation différée.
Active : déclenchement d'alarme ou d'alerte opérateur avec type de réaction demandée (déconnexion, verrouillage de ressource…).
3 Protection des données et programmes.
Les exigences porteront sur tout ou partie des spécifications suivantes :
a) Définition des options d'accès aux programmes et aux données.
Aucun accès.
Accès en lecture (sur fichier maître, copie…).
Accès en écriture.
Déclenchement d'exécution de programmes.
b) Contrôle général des accès des sujets aux objets et gestion de ces accès.
c) Contrôle supplémentaire d'accès à certaines informations sensibles.
(Mots de passe, clés, autre procédé sûr.)
d) Protection des fonctions de sécurité.
(Programme de sécurité, tables d'accès, liste des mots de passe, etc.).
e) Journalisation des accès aux programmes et aux données sensibles.
f) Détection des incidents et établissement des responsabilités.
g) Détection des tentatives d'atteinte à la sécurité.
h) Contraintes sur le réemploi d'objets mémoire.
i) Logiciel d'effacement.
j) Chiffrement des fichiers.
k) Protection des logiciels de base.
4 Protection contre les rayonnements émis et reçus.
a) Exigences particulières imposées à certains types d'équipement.
Normes AMSG 720…
b) Protection particulière demandée.
(Atténuation de rayonnements par filtre, blindage, …).
c) Exigences de fonctionnement en atmosphère électromagnétique perturbée.
5 Protection des communications.
Exigences particulières à exprimer :
supports de commutation ;
dispositifs de secours ;
chiffrement des informations transmises : mode, compatibilité avec les équipements de chiffrement prévus, … ;
certification des informations transmises.
6 Maintenance, télémaintenance.
Exigences en matière :
d'habilitations des personnels de maintenance ;
de conditions d'exécution de la maintenance ;
de télémaintenance, etc.
7 Sûreté de fonctionnement.
Les problèmes de sûreté de fonctionnement ne sont pas normalement traités dans ce chapitre. Toutefois, ils doivent l'être si le mauvais fonctionnement du système risque d'avoir des conséquences inacceptables sur la sécurité et s'il en résulte des mesures particulières à proposer par le fournisseur.
8 Origine des matériels.
Cf. appendice A.
9 Documentation. Tests.
a) Guide d'utilisateur.
Définition des mécanismes de protection et de leur utilisation.
b) Guide technique pour l'exploitation.
Descriptions qui devront permettre à l'opérateur, à l'ingénieur système et à l'officier de sécurité d'exercer leur fonction de gestion et de contrôle des procédures de sécurité.
c) Documentation de test.
Documents à fournir en matière de plan de test et de résultats.
d) Documentation de conception.
Documentation de description formelle de la sécurité.
APPENDICE « A » A L'ANNEXE 3. Cadre de réponse du fournissuer sur l'origine des équipements.
1 Origine des matériels.
1.1 Unité centrale.
1.2 Périphériques.
1.4 Péri-informatique.
1.4 Terminaux.
2 Origine des logiciels.
2.1 Système de base.
2.2 Moniteur de télétraitement.
2.3 Progiciels.
2.4 SGBD
3 Modification de la configuration.
3.1 Remplacements de matériels.
Certification de conformité à ceux d'origine.
3.2 Changements de version de logiciel.
Certification de conformité aux dispositifs précédents.