INSTRUCTION N° 133/DEF/SEC/DIR/SIC relative à la politique de sécurité des systèmes d'information du ministère de la défense.
Du 18 mars 2002NOR D E F M 0 2 5 0 7 3 8 J
Préambule.
Pour simplifier la rédaction et la lecture du présent document, l'expression « système d'information » doit être comprise comme regroupant le système d'information lui-même, les informations traitantes et les informations traitées par le système.
D'autre part, l'ensemble des principes et règles énoncés dans le présent document de politique générale de sécurité des systèmes d'information du ministère de la défense, respecte et complète la réglementation en vigueur, qui figure en tant que de besoin en annexe du présent document.
1. Introduction.
Toutes les administrations et services déconcentrés de l'État sont tenus de mettre en œuvre l'ensemble des mesures d'organisation, techniques et relatives à l'environnement visant à assurer la protection des systèmes d'informations qu'ils utilisent. C'est une obligation réglementaire dès lors qu'il s'agit d'informations classifiées de défense.
Le ministère de la défense utilise des systèmes d'information automatisés. Ces systèmes sont souvent reliés entre eux par des réseaux de transmission permettant l'accès à un grand nombre d'informations ou leur partage. De ce fait, l'ouverture recherchée pour l'amélioration des échanges augmente, au regard de la sécurité des systèmes d'information (SSI), la vulnérabilité des organismes du ministère.
La menace pesant sur les systèmes est complexe et s'est adaptée à l'évolution des technologies et aux comportements des utilisateurs. Elle concerne tous les critères de la SSI : la confidentialité, l'intégrité, la disponibilité, l'authentification et la non-répudiation. Pour s'en préserver, il faut être capable de déterminer ce qui doit être protégé, contre qui et à quel coût. Seule une analyse de risques, objective et structurée, permet :
de déterminer les besoins et d'énoncer les objectifs de sécurité d'un système d'information ;
d'identifier les vulnérabilités potentielles ;
d'inventorier les modes d'attaques associés ;
de définir les parades nécessaires et leurs coûts d'acquisition, de mise en œuvre et de maintien en condition opérationnelle ;
d'identifier les vulnérabilités résiduelles in fine ;
de traiter les incidents et le confinement de leurs effets.
Associée à cette analyse de risques, soumise au commandement, la SSI a pour objet la dissuasion, la prévention, la détection, la réaction et la réparation des atteintes susceptibles d'entraîner des conséquences préjudiciables au fonctionnement et aux missions du ministère de la défense, par exemple :
la prise de décisions inadaptées, due des ingérences internes ou externes ;
le blocage ou la désorganisation des processus qui peuvent conduire à l'incapacité opérationnelle, de décision ou de gestion ;
l'accès non autorisé à l'information protégée ;
l'atteinte aux ressources et en particulier à l'intégrité et à la disponibilité ou à la confidentialité des moyens assurant la protection de l'information ;
l'appropriation frauduleuse de biens ;
l'atteinte aux libertés individuelles ;
l'atteinte au renom du ministère de la défense ou de son personnel ;
la déstabilisation du ministère de la défense ou de son personnel.
Comme tous les systèmes d'information, ceux du ministère sont exposés. Il convient donc de définir et de mettre en place la politique de sécurité des systèmes d'information du ministère de la défense (PSSI) qui s'appuie sur des principes et des règles applicables en matière de sécurité des systèmes d'information en s'assurant que leur application soit globale, adaptée et cohérente. Ces principes et règles ont pour but de définir les actions relatives à l'organisation, aux techniques et aux procédures permettant de s'opposer de manière efficace aux menaces identifiées et de préserver ainsi les intérêts du ministère de la défense.
La PSSI s'inscrit dans le cadre de :
l'instruction générale interministérielle no 900/SGDN/SSD/DR du 20 juillet 1993 (n.i. BO) (parue sous double timbre du SGDN et du SCSSI) ;
la recommandation no 901/DISSI/SCSSI du 2 mars 1994 (n.i. BO) qui régit la protection des informations sensibles non classifiées de défense ;
l' instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 (BOC, p. 4343) (cf. ANNEXE II) relative à l'organisation, la mise en œuvre et la répartition des responsabilités pour le ministère de la défense.
La PSSI repose sur une approche globale et pragmatique : assurer la sécurité des systèmes d'information et des moyens concourant à leur protection en ayant le souci permanent de ne pas entraver sans nécessité, les capacités des différents organismes à accomplir leurs missions.
La PSSI permet la maîtrise de l'évolution prévisible des besoins dans les conditions de sécurité optimales :
en déterminant les besoins de sécurité du système d'information ;
en prescrivant l'identification et l'évaluation des risques associés au système d'information ;
en définissant un juste niveau de sécurité pour lequel un système ou un ensemble de systèmes ne présente pas de vulnérabilité risquant de mettre en cause l'exécution des missions du ministère de la défense ;
en responsabilisant l'ensemble de la structure ;
en sensibilisant l'ensemble du personnel au nécessaire maintien de la rigueur dans l'application des mesures prescrites ;
en adaptant les mesures de protection aux évolutions des menaces, des missions, des structures, des effectifs et des technologies de l'information en vue de garantir leur cohérence et leur pérennité ;
en adaptant les moyens humains et financiers afin d'atteindre les objectifs fixés.
1.1. Schéma décrivant les différentes politiques et les acteurs de la sécurité des systèmes d'information.
Figure 1.
 |
2. Les systèmes d'information cibles.
Tous les systèmes d'information du ministère de la défense, peuvent être atteints quant à leur intégrité, leur disponibilité ou leur confidentialité :
les systèmes d'information classifiés de défense ou sensibles ;
les autres systèmes traitant d'informations classifiées de défense ou sensibles (systèmes de gestion (1), système d'armes, …) ;
les moyens de protection ou de gestion qui leur sont consacrés.
Les mesures de protection à mettre en place découlent de l'intérêt que ces systèmes représente pour le ministère de la défense ou un adversaire potentiel.
En complément de la réglementation en vigueur (interministérielle et ministérielle), ceci conduit :
D'une part à considérer et à protéger avec les moyens adéquats :
les informations classifiées de défense conformément à l'instruction no 900SGDN/SSD/DR du 20 juillet 1999 pour les « informations traitées », c'est à dire regroupant les informations nationales protégées de défense, celles confiées à la France par des pays membres de l'organisation du traité de l'Atlantique Nord (OTAN), de l'union de l'Europe occidentale (UEO) ou tout organisme international en application d'un accord ou d'un protocole de sécurité ;
les informations sensibles non classifiées de défense comme :
les informations diffusion restreinte ;
les informations nominatives ;
les informations de gestion de personnel ;
les informations médicales ;
les informations financières et budgétaires ;
les informations industrielles et technologiques ;
les informations commerciales ;
les informations de gestion des réseaux et des systèmes d'information ;
… ;
toutes les autres informations que l'autorité qualifiée juge utile de protéger.
D'autre part à expliciter les principes et les règles spécifiquement applicables au ministère de la défense.
3. Les principes applicables au ministère de la défense en matière de sécurité des systèmes d'information.
Les 8 principes énoncés ci-dessous régissent la protection des systèmes d'information. Leur application est détaillée au point 4 ci-après.
3.1. Désignation des autorités responsables et fixation de leurs attributions [P1].
Conformément à l' instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 , une voie fonctionnelle SSI est chargée du conseil, du suivi et de l'application des mesures préventives et correctives de SSI à mettre en œuvre.
Les attributions et les responsabilités, relatives à la sécurité des informations et des systèmes d'information, des acteurs intervenants sur les systèmes d'information du ministère de la défense doivent être explicitement spécifiées. Ces acteurs doivent être clairement identifiés et catégorisés (internes, externes avec contrat, stagiaires…). Ils peuvent créer de l'information, en fournir, la mettre en œuvre ou utiliser des systèmes d'information du ministère de la défense. Ils peuvent également être des tiers, externes au ministère de la défense, liés par des contrats.
3.2. Proportionnalité des mesures face aux besoins et aux risques [P2].
La nature et le coût des mesures destinées à assurer la sécurité des systèmes d'information doivent être appropriés et proportionnés à la valeur que le ministère de la défense attache aux systèmes d'information concernés et aux risques encourus. La nature, l'importance et le coût des conséquences des événements redoutés, compte tenu des missions dont il a la charge, doivent être également pris en compte.
La menace doit être évaluée selon une méthode approuvée par le ministère.
3.3. Principe de sécurisation [P3].
Les systèmes d'information, classifiés de défense ou sensibles doivent faire l'objet d'une démarche de sécurisation couvrant l'ensemble de leur cycle de vie, depuis la phase de conception jusqu'à la phase opérationnelle puis le retrait du service. Cette démarche repose sur la maîtrise du périmètre des systèmes, et notamment sur la définition et la gestion de leurs interconnexions (interfaces logiques et physiques) et des flux d'informations associés.
Conformément à la réglementation et en rapport avec les objectifs traduisant les enjeux de sécurité de ces systèmes d'information, cette démarche doit conduire à la formalisation des étapes (analyse de risque et objectifs de sécurité, plan de développement SSI, homologation…) et à la production des documents afférents (FEROS, cible de sécurité, politique de sécurité du système…).
3.4. Complémentarité et homogénéité des mesures [P4].
Les mesures destinées à assurer la sécurité des systèmes d'information doivent prendre en compte l'environnement dans lequel est placé le système, les différents aspects réglementaires, organisationnels et techniques et les différents stades de la protection : organisation, dissuasion, prévention, détection, alerte, réaction et réparation des événements redoutés. Elles doivent en outre être cohérentes entre elles et conformes aux règles de sécurité générale du ministère de la défense. Les premières ne constituent qu'un sous-ensemble particulier des dernières.
Conformément aux besoins de disponibilité identifiés, les systèmes d'information du ministère doivent disposer de procédures d'urgence et de reprise permettant d'assurer la continuité du fonctionnement du service, à la suite d'un sinistre ou d'une agression.
3.5. Coordination des actions [P5].
Les organismes du ministère de la défense doivent agir en temps opportun, de manière coordonnée par la voie fonctionnelle SSI, en complément et en cohérence avec la voie hiérarchique, afin :
d'empêcher les atteintes à la sécurité des systèmes d'information ;
d'en limiter la portée ;
de réévaluer la menace ;
d'adapter et d'homogénéiser les dispositifs de protection.
3.6. Connaissance partagée des mesures de sécurité [P6].
La confiance dans le niveau de sécurité des systèmes d'information du ministère de la défense implique que ses personnels, en tant qu'émetteurs, utilisateurs ou tiers concernés, puissent connaître de façon compatible avec le maintien de la sécurité, les mesures en place (nature et force des dispositions et des dispositifs) destinées à assurer la sécurité des systèmes d'information.
3.7. Vérification périodique des systèmes [P7].
La sécurité des systèmes d'information doit faire l'objet de contrôles périodiques pour tenir compte de l'évolution des missions, des structures, des menaces, des contraintes issues de l'environnement des systèmes d'information du ministère de la défense, ainsi que de l'évolution des lois, des règlements et des technologies de l'information.
Tout au long du cycle d'exploitation et selon une fréquence liée à leur classification ou leur sensibilité, les systèmes d'information font l'objet d'audits évaluant notamment la qualité des paramétrages, la complétude des moyens de protection et l'adaptation des procédures d'exploitation établies en regard des vulnérabilités initiales et de leur évolution éventuelle.
3.8. Systèmes d'information multinationaux [P8].
Pour le traitement d'informations, dans un contexte multinational, des dispositions spécifiques d'applications doivent être prises, notamment lorsque les informations relèvent d'une politique SSI différente de celle du ministère de la défense.
Ces dispositions sont décrites dans le document réf. 130 du référentiel documentaire SSI objet de l'annexe I du présent document.
4. Les règles applicables au ministère de la défense en matière de sécurité des systèmes d'information.
Les règles applicables au ministère de la défense en matière de SSI se répartissent en six domaines. Ces règles donnent lieu à des actions permettant leur mise en application. Dans le corps du texte, elles sont codées en fonction du domaine d'appartenance et du numéro d'apparition conformément au tableau ci-dessous:
| Domaines. | Codification du domaine | Codification de la première règle. |
|---|---|---|
| Principe général pour une PSSI. | PSI | PSI.R 1 |
| Organisation et contrôle de la sécurité des systèmes d'information. | OGS | OGS.R 1 |
| Sécurité liée au personnel. | PER | PER.R 1 |
| Sécurité des biens physiques. | BPH | BPH.R 1 |
| Sécurité liée à l'information. | INF | INF.R 1 |
| Cycle de vie du système d'information. | CVE | CVE.R 1 |
4.1. Principe général de la politique de sécurité des systèmes d'information.
La politique de sécurité des systèmes d'information détient sa légitimité de la responsabilité exercée par le ministre de la défense en matière de SSI. Cette responsabilité s'inscrit dans les orientations de politique générale du domaine fixées par le Premier Ministre.
La PSSI est visée au plus haut niveau du ministère. C'est le document SSI de référence, il est évolutif afin de préserver au mieux sa pérennité vis à vis de la réglementation, des techniques et des technologies en usage.
| PSI.R 1. La PSSI applicable au ministère de la défense est approuvée par le directoire des systèmes d'information et de communication, sur proposition du président de la commission ministérielle de la SSI (CMSSI) ou de son représentant : le fonctionnaire de sécurité des systèmes d'information (FSSI). |
| PSI.R 2. La PSSI s'applique à tous les organismes relevant de l'autorité du ministre et, en tant que de besoins, aux organismes travaillant à son profit. |
| PSI.R 3. La PSSI peut faire l'objet de révisions, à la demande d'un ou plusieurs organismes, après proposition des évolutions éventuelles au FSSI, validation par la CMSSI et approbation par le directoire des systèmes d'information et de communication. |
| PSI.R 4. Le FSSI est informé de toute dérogation aux principes et règles de la PSSI. Il peut soumettre cette dérogation à l'approbation formelle de la CMSSI, lorsqu'il juge qu'elle peut porter préjudice à la sécurité collective. |
| PSI.R 5. Le FSSI informe les autres autorités qualifiées de cette dérogation. |
4.2. Organisation, responsabilité et contrôle de la sécurité des systèmes d'information.
L'existence de principes et règles applicables au ministère de la défense en matière de SSI ne peut suffire à garantir la protection d'un système d'information en l'absence d'une organisation dédiée à la SSI. Pour l'application de ces règles, à tous les niveaux, les responsabilités de chacun doivent être fixées. Chaque responsable identifié doit pouvoir faire appel à des spécialistes capables de prendre en charge : l'élaboration et la diffusion des directives et instructions de sécurité, la formation du personnel, la définition, la conception, la mise en œuvre et le contrôle des mesures de sécurité.
4.2.1. Organisation de la sécurité des systèmes d'information.
| OGS.R1 L'organisation de la SSI prévue par les textes doit être mise en place dans chaque organisme. Elle est destinée à garantir la prise en compte et à mesurer l'efficience de la sécurité des systèmes d'information au ministère de la défense. Elle repose sur une délégation des attributions en matière de conception, organisation, application et contrôle des directives du ministère de la défense. |
L'instruction no 900/SGDN/SSD/DR du 20 juillet 1993 définit l'organisation et les responsabilités des acteurs de la SSI. L'instruction no 910/SGDN/SSD/DR du 19 décembre 1994 définit quant à elle la voie fonctionnelle SSI. Chaque ministère a ensuite en charge l'élaboration de ses propres directives.
La voie fonctionnelle SSI du ministère de la défense est décrite dans l' instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 .
Pour mettre en œuvre l'ensemble des mesures destiné à assurer la protection des systèmes d'information, les acteurs de la voie fonctionnelle SSI s'appuient au plan local sur les administrateurs sécurité, systèmes, réseaux et les exploitants de systèmes, ces experts constituant la voie technique SSI.
4.2.2. Responsabilités des autorités chargées de l'application au ministère de la défense de la politique de sécurité des systèmes d'information.
Les principes et règles fixés par le présent document sont applicables à l'ensemble des autorités qualifiées du ministère. Annuellement, des orientations peuvent être données selon les priorités du ministre.
| OGS.R 2. Chacune des autorités qualifiées du ministère décline à partir de cette PSSI sa propre politique de sécurité, dont elle adresse un exemplaire au fonctionnaire de sécurité des systèmes d'information du ministère (FSSI). |
En complément, des mesures d'application sont établies dans le schéma directeur des systèmes d'information de l'organisme.
Ces mesures sont ensuite détaillées et éventuellement complétées par l'autorité hiérarchique responsable du système d'information.
4.2.3. Application de la politique de sécurité des systèmes d'information.
| OGS.R3 Chaque autorité qualifiée établit le plan d'actions SSI permettant d'atteindre les objectifs de sécurité fixés dans la politique de sécurité des systèmes d'information de l'organisme. Ce plan d'actions (réalisé et prévisionnel) figure dans le rapport d'activités annuel sur la SSI des organismes. |
4.2.4. Documentation de sécurité.
Une documentation à jour, décrivant l'organisation, les dispositions ou les dispositifs de sécurité minimise l'occurrence et les conséquences d'incidents portant atteinte à la disponibilité, à l'intégrité ou à la confidentialité des systèmes d'information du ministère.
4.2.4.1. Référentiel documentaire sécurité des systèmes d'information.
Le référentiel documentaire SSI du ministère est décrit en annexe I. Il est complété en tant que de besoin par chaque organisme.
La documentation SSI doit couvrir l'ensemble des aspects de la SSI, organisationnels, techniques et procéduraux. Elle doit être très largement diffusée aux personnels ayant besoin d'appliquer les règles, directives et procédures d'utilisation. Tous les administrateurs systèmes et réseaux ainsi que tous les personnels intervenants dans la filière SSI doivent connaître l'existence et les grandes lignes du contenu de cette documentation.
| OGS.R 4. Les listes de la documentation et des organismes en charge de sa mise à jour doivent être connues et être mises à disposition de tout le personnel. Un référentiel de la documentation est mis à disposition des échelons de commandement et de la voie fonctionnelle SSI, en tant que de besoin. |
4.2.4.2. Gestion de la documentation sécurité des systèmes d'information.
| OGS.R 5. La documentation doit faire l'objet d'une gestion garantissant la réalisation, la duplication, la diffusion, l'archivage, la classification homogène des documents et les droits de consultation notamment lorsqu'il s'agit des documents électroniques. Tout document SSI doit faire l'objet :
En complément de la documentation d'exploitation, la documentation SSI propre à un système d'information est associée à l'unité collective (2). |
4.2.5. Maintien permanent de la sécurité des systèmes d'information.
| OGS.R 6. Les systèmes d'information sont soumis à des inspections, contrôles et audits réguliers visant à assurer le maintien permanent de la SSI. A tous les niveaux, les autorités sont responsables de cette permanence. |
4.2.5.1. Inspections et contrôles.
Les inspections et contrôles sont effectués conformément à l' instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 .
| OGS.R 7. Afin de s'assurer du respect de l'application de la réglementation et de la conformité des procédures, l'autorité qualifiée fait effectuer périodiquement des inspections ou contrôles, planifiés annuellement. La périodicité ne devra pas être supérieure à 5 ans. Ces inspections ou contrôles peuvent également être déclenchés sur ordre en tant que de besoin. |
4.2.5.2. Audits.
Les audits sont effectués conformément à l' instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 . Ils sont déclenchés à la demande de tout responsable hiérarchique et sont effectués conformément à un plan annuel, élaboré en concertation avec les services et organismes soumis. En cas de nécessité, un réaménagement de ce plan annuel peut être effectué.
| OGS.R 8. Chaque autorité qualifiée doit disposer d'une capacité d'audit (capacité obligatoire pour les systèmes d'information classifiés de défense). Les audits sont réalisés de façon périodique [2 ans pour les systèmes secret défense (SD), 5 ans pour les systèmes confidentiel défense (CD) et les systèmes sensibles ayant vocation d'être interconnectés] ou à chaque modification de nature à remettre en cause l'homologation. Les audits peuvent également être déclenchés sur ordre en tant que de besoin, avec un préavis de trois mois maximum. |
Les audits sont conduits avec le souci de déterminer le niveau de vulnérabilité présenté par le système. Pour avoir une mesure homogène sur les vulnérabilités résiduelles à l'issue des audits, les équipes d'audits doivent être dotées d'outils de diagnostic technique.
| OGS.R 9. Toutes les équipes d'audits sont dotées d'outils destinés à détecter les vulnérabilités en général, notamment par des tests mesurant les vulnérabilités résiduelles des systèmes d'information. L'utilisation de ces outils, par du personnel ayant reçu la formation adaptée, est soumise à des règles d'utilisation. Elles sont établies afin d'éviter de déborder le cadre du système audité et la dégradation d'un ou de plusieurs de ses composants d'une part et les effets collatéraux d'autre part. |
La mission de ces équipes d'audit est d'intervenir pour faire un point de situation, à partir d'un référentiel et donner les recommandations ou solutions permettant de s'y conformer. Lorsque cela s'avère nécessaire, l'équipe d'audit apporte les conseils et recommandations qui s'imposent pour améliorer le niveau de sécurité et prépare avec les responsables SSI locaux et centraux les mesures correctives appropriées.
| OGS.R 10. Les mesures correctives, faisant suite à un audit, font l'objet d'une validation au niveau hiérarchique adapté, et sont inscrites dans le suivi en contrôle de gestion au niveau de l'autorité qualifiée. |
4.3. Sécurité liée au personnel.
Le comportement du personnel est un élément essentiel, le facteur humain est et reste le maillon faible de la SSI. Il ne peut y avoir une sécurité bien assurée sans une formation adaptée et l'adhésion du personnel.
4.3.1. Affectation du personnel.
L'autorité hiérarchique est responsable de la mise en œuvre et du contrôle des règles suivantes :
| PER.R 1. Le personnel, appartenant ou non au ministère de la défense, affecté à un emploi permettant l'accès à des informations classifiées de défense doit faire l'objet d'une habilitation préalable au niveau requis par le niveau de classification de ces informations. |
De plus, celui qui est affecté à un emploi permettant l'accès aux systèmes d'information sensibles du ministère doit avoir un profil d'accès tenant compte du domaine de sensibilité des informations manipulées.
| PER.R 2. Le personnel, appartenant ou non au ministère de la défense, accédant temporairement aux ressources ou informations sensibles ou classifiées (soutien, installation, maintenance, entretien, …) doit être selon les cas, habilité, authentifié et le cas échéant accompagné afin de ne pas pouvoir porter atteinte aux ressources ou informations. |
| PER.R 3. L'accès à un système d'information classifié de défense ou sensible doit respecter le strict besoin d'en connaître de la personne. Une gestion des habilitations et des décisions d'accès à la SSI, décernées pour cette dernière après une formation adaptée selon le ou les systèmes servis, garantit la compétence et la traçabilité des personnels de la voie fonctionnelle SSI. |
| PER.R 4. Les administrateurs (sécurité, système, réseau, données, …), du fait de l'impact potentiel de leur fonction sur le système, doivent être habilités au niveau immédiatement supérieur (limité à SD). Selon la criticité du système, ils doivent en outre faire l'objet d'une décision d'accès à la SSI, s'appuyant sur une formation adaptée. |
4.3.2. Formation du personnel.
| PER.R 5. Le personnel doit avoir reçu la formation SSI adaptée à l'emploi lié à son affectation. Elle se traduit par l'acquisition des connaissances nécessaires de l'organisation, de la technique, de la réglementation spécifique à la SSI et au domaine d'activité concerné, pour assurer une conduite et une utilisation garantissant l'homogénéité de la sécurité. |
4.3.3. Responsabilité et sensibilisation du personnel.
Le personnel engage sa responsabilité pénale personnelle et disciplinaire lorsqu'il accède à un système protégé et qu'il y manipule des données, des logiciels et des matériels. Il doit en être informé. Il doit en outre être sensibilisé aux risques liés à l'utilisation des nouvelles technologies de l'information et, en fonction du besoin d'en connaître, il doit être informé des mesures de sécurité prises pour protéger le système d'information, les données, les logiciels et les matériels auxquels il accède, qu'il utilise ou qui sont mis à sa disposition.
| PER.R 6. Chaque autorité hiérarchique doit tenir informé son personnel :
Elle doit mettre en place un plan de sensibilisation et s'assurer que le personnel a pris connaissance de ses obligations et responsabilités. |
4.4. Sécurité des biens physiques assurant le traitement et la protection des informations.
Les biens physiques associés au système d'information comprennent : les matériels, les logiciels, les documents et les dispositifs de protection nécessaires aux systèmes d'information. Les mesures de protection des biens physiques ont pour but d'empêcher, si possible ou de réduire dans tous les cas, les conséquences des événements redoutés. L'absence de mesures exhaustives impose la mise en œuvre d'une stratégie de sécurité : organisation, dissuasion, prévention, détection, alerte, confinement, réparation et compte-rendu.
4.4.1. Protection des biens physiques.
4.4.1.1. Adéquation des mesures de protection aux catégories de biens physiques.
| BPH.R 1. Les mesures de protection des biens physiques doivent être coordonnées et cohérentes entre elles et avec les autres mesures de protection en vigueur au sein du ministère (locaux et zones, personnels, …). Elles s'adressent également aux équipements individuels de type ordinateurs portables, assistants personnels électroniques, téléphones portables, dès lors qu'ils traitent d'informations ou interfèrent avec un système d'information du ministère. |
4.4.1.2. Suivi permanent et contrôle périodique de la sécurité des dispositifs de protection.
| BPH.R 2. Les organismes doivent s'assurer que les mesures de protection des biens physiques permettent de garantir la disponibilité, l'intégrité et la confidentialité (aux seuls personnels autorisés) des mécanismes de sécurité mis en œuvre. Le contrôle est effectué conformément aux prescriptions du point 4.2.5. |
4.4.2. Gestion des biens physiques.
La base essentielle de la protection repose sur la connaissance des biens physiques qui sont associés au système d'information. La mise en œuvre d'une gestion de ces biens permet un suivi rigoureux de la protection.
4.4.2.1. Continuité dans la gestion des biens physiques.
| BPH.R 3. La gestion des ACSSI (3) doit être effectuée conformément à l'instruction no 910/SGDN/SSD/DR du 19 décembre 1994 (n.i. BO) et à sa directive d'application no 911/DISSI/SCSSI/DR du 20 juin 1995 (n.i. BO). Cette gestion est centralisée au niveau des autorités qualifiées et est assurée par une cellule qui lui est directement rattachée ou un organisme en relevant, ayant reçu délégation. Le traitement des compromissions est défini dans le document relatif à la gestion et la protection des ACSSI (cf. réf. 510 de l'annexe I). |
La configuration doit être gérée rigoureusement. Une instruction particulière fixera les modalités de cette gestion.
Certains produits, logiciels ou matériels, peuvent faire l'objet d'un suivi particulier, sans toutefois relever de la gestion centralisée des ACSSI. Ces produits que l'on désigne sous l'appellation ASGLI (4) sont suivis au plan local notamment aux fins de permettre effectivement la gestion de configuration des moyens concourrant à la SSI.
| BPH.R 4. Tous les biens physiques en dotation doivent faire l'objet d'une gestion permanente et effective quelle que soit leur localisation. Cette gestion inclut la gestion en configuration des équipements, de leurs programmes informatiques et de leur paramétrage. |
4.4.2.2. Marquage des biens physiques.
| BPH.R 5. Tous les biens physiques, notamment les unités logiques, traitant d'informations classifiées de défense doivent faire l'objet d'un marquage indélébile correspondant au niveau des informations traitées. |
4.4.2.3. Utilisation d'équipements personnels.
| BPH.R 6. Tous les équipements personnels communicants (téléphone mobile, assistant personnel, par exemple …) devront faire l'objet de conditions particulières d'utilisation, dès lors qu'ils risquent d'interférer avec le bon fonctionnement des systèmes d'information ou des systèmes d'armes du ministère ou d'y générer des vulnérabilités. |
4.5. Sécurité liée à l'information.
4.5.1. Protection des informations.
| INF.R 1. Chaque autorité qualifiée doit définir les mesures à mettre en œuvre permettant d'assurer la protection en confidentialité, disponibilité et intégrité des informations dont les traitements relèvent de sa responsabilité, qu'elle en soit l'émettrice ou l'utilisatrice. |
| INF.R 2. Les informations, selon leur nature et leur sensibilité, doivent être protégées conformément à la présente PSSI, ou, à défaut de protocole particulier, à la politique de sécurité de l'organisme émetteur. Dans certains cas, un besoin de confinement d'informations peut imposer des mesures spécifiques. |
4.5.2. Continuité dans la protection des informations.
La continuité de la protection des informations doit être maintenue tout au long de leur cycle de vie.
4.5.2.1. Traitement des informations.
| INF.R 3. Chaque responsable d'organisme doit s'assurer de la mise en œuvre continue et cohérente des mesures définies par l'autorité qualifiée permettant d'empêcher la compromission, l'altération et l'indisponibilité des informations dont il a la charge, depuis leur collecte jusqu'à leur diffusion au destinataire final. Elles s'appliquent aux informations lors de :
|
| INF.R 4. Les informations, faisant l'objet d'une mention de manipulation de type Source Secrète ou ACSSI-S doivent faire l'objet d'un traitement au niveau immédiatement supérieur à leur niveau de classification. Les informations porteuses d'une marque d'identification (Spécial France, coalition, …), doivent faire l'objet de traitements spécifiques, voire d'un suivi particulier (cf. réf. 130 et réf. 310 de l'annexe I). |
| INF.R 5. Les informations nominatives doivent faire l'objet d'une déclaration à la commission nationale de l'informatique et des libertés (CNIL) préalablement à leur traitement. D'autres informations liées à l'exploitation des réseaux et des systèmes peuvent également être sujettes à déclaration à la CNIL (annuaires, journaux, traces, …). |
4.5.2.2. Conservation et destruction des informations sensibles et classifiées de défense.
| INF.R 6. Les procédures de protection des informations sensibles et classifiées de défense s'appliquent à chaque étape de l'élaboration des informations ainsi qu'à leurs supports (cf. réf. 390 de l'annexe I) y compris pour leur conservation et leur destruction. |
INF.R6 Les procédures de protection des informations sensibles et classifiées de défense s'appliquent à chaque étape de l'élaboration des informations ainsi qu'à leurs supports (cf. Réf. 390 de l'annexe I) y compris pour leur conservation et leur destruction.
4.6. Sécurité pendant le cycle de vie du système.
Elle s'applique aux :
systèmes d'information et de communication utilisés par les états-majors, directions et services ainsi que les systèmes d'information opérationnels nécessaires à la mise en œuvre des armes, à la conduite, au soutien et au déploiement des forces ;
systèmes mis en œuvre pour les besoins d'aide à la définition, au développement, à l'évaluation et aux tests des systèmes d'armes, de commandement et de communication des armées ;
systèmes mis en œuvre pour les besoins de gestion et de direction des affaires et projets du ministère de la défense ;
réseaux du ministère (en terme d'infrastructure de communication) qui intègrent l'ensemble des réseaux locaux, les interconnexions de réseaux locaux et les segments d'interface en particulier ceux assurant la maîtrise des échanges avec les réseaux publics ;
équipements de traitement de l'information, leurs systèmes d'exploitation et leurs applicatifs associés ;
informations traitées, qu'elles soient classifiées ou sensibles ;
terminaux ou composants de réseaux placés sous la responsabilité d'exploitation du ministère.
4.6.1. Autorisation pour l'utilisation.
4.6.1.1. Contrôle des droits d'accès des utilisateurs.
| CVE.R 1. Tout utilisateur d'un système d'information doit posséder des droits d'accès correspondant à son profil utilisateur. Ces droits doivent faire l'objet d'un contrôle systématique et complet préalable à tout accès. En cas de non-conformité des actions tentées avec les droits correspondants pour cet utilisateur, le système doit selon les modalités de la politique de sécurité, soit être verrouillé, soit être limité à des modes restrictifs. |
4.6.1.2. Identification des utilisateurs.
| CVE.R 2. Tout utilisateur, autorisé par sa hiérarchie à utiliser un système d'information du ministère de la défense, doit être identifié. |
4.6.1.3. Authentification des utilisateurs.
| CVE.R 3. Pour les systèmes traitant d'informations sensibles ou classifiées de défense une authentification adaptée au niveau de confiance requis doit permettre d'établir de façon sûre une relation biunivoque entre la personne physique qui utilise le système et l'utilisateur identifié. |
4.6.1.4. Gestion des moyens d'authentification.
| CVE.R 4. Les moyens d'authentification doivent faire l'objet d'une gestion :
|
4.6.1.5. Administration des droits d'accès.
| CVE.R 5. Les droits d'accès doivent faire l'objet d'une gestion :
La gestion des droits d'accès doit être assurée par l'administrateur sécurité. |
4.6.1.6. Obligation de protection des données d'administration et de gestion de la sécurité.
| CVE.R 6. Les données d'administration et de sécurité, vitales pour le système d'information (authentification, droits d'accès, comptes administrateurs, données de filtrage des gardes de sécurité, …) doivent être protégées par des mesures de sécurité de niveau au moins égal au niveau de classification maximal des informations traitées. |
4.6.2. Sécurité des communications.
(5)
L'architecture des réseaux de communications du ministère de la défense s'appuie sur le principe de cloisonnement des réseaux et des informations, en tenant compte en particulier de leur niveau de classification et des impératifs de disponibilité.
| CVE.R 7. En l'absence de dispositif(s) agréé(s) ou cautionné(s) permettant d'assurer un cloisonnement logiques des informations de niveaux différents, les réseaux de desserte devront être physiquement distincts : le réseau ouvert accessible depuis les réseaux publics, le réseau traitant d'informations sensibles au maximum et le réseau traitant d'informations jusqu'au niveau classifié de défense. |
Pour le transit, on tiendra particulièrement compte des impératifs de disponibilité et de qualité de service tout en préservant les règles de confidentialité.
Toute architecture dérogeant à cette règle, dès lors qu'elle concerne d'autres autorités qualifiées, fera l'objet d'une étude technique spécifique, réalisée par le centre technique SSI du ministère de la défense, et devra être validée en CMSSI.
Avertissement.
A la date de rédaction de la présente PSSI, la position ministérielle sur l'interconnexion de réseaux classifiés de défense, sensibles et non-protégés est de disposer de réseaux physiques distincts jusqu'à ce que des segments d'interface soient homologués en s'appuyant :
sur des produits de chiffrement agréés pour le ou les « coté(s) » du segment le justifiant ;
sur des produits de sécurité informatique, de préférence évalués, au sein du segment d'interface ;
sur des mécanismes de confiance (filtrage, journalisation, moyen d'authentification, labellisation, …) au sein des enclaves respectives.
Il convient également de souligner que seul un assemblage de produits en cours de développement ou à venir permettra de réaliser des interconnexions sécurisées entre des réseaux classifiés de défense et des réseaux sensibles.
4.6.2.1. Echanges de données.
L'échange de données recouvre l'importation ou l'exportation d'informations entre :
des domaines ayant des politiques de sécurité différentes ;
des réseaux de responsabilité de mise en œuvre distincts ;
des applicatifs distincts ;
toutes combinaisons des trois items précédents.
| CVE.R 8. L'échange de données entre les systèmes d'information du ministère ou entre ceux-ci et des systèmes d'information extérieurs, doit être sécurisé, qu'il s'agisse d'informations sensibles ou d'informations classifiées de défense de la défense. |
Les fonctions de sécurité dont dispose l'Intranet défense pour le segment d'interface constituent l'architecture minimale, pour les échanges utilisant les protocoles IP, en complément des mécanismes mis en œuvre au titre des politiques de sécurité des organismes.
Après une analyse de la menace, pour les autres protocoles, des mécanismes de sécurité adaptés au média utilisé doivent être mis en œuvre.
4.6.2.2. Interconnexions de réseaux.
Une interconnexion non maîtrisée est de nature à remettre en cause l'analyse de risque initiale, notamment les principes de cloisonnement, du besoin d'en connaître et de séparation des données de niveaux distincts, mais aussi la disponibilité et l'intégrité des informations et des ressources.
| CVE.R 9. Toute interconnexion de réseaux doit être conforme aux orientations particulières formulées dans la directive OSCAR (6) (cf ANNEXE III et réf. 220 de l'annexe I). |
| CVE.R 10. Tout système d'information, devant être connecté à un réseau du ministère doit respecter la présente politique de sécurité ainsi que celle spécifique à chacun des systèmes. |
| CVE.R 11. Une analyse des vulnérabilités résultant de cette interconnexion doit être réalisée pour cerner l'impact sur la sécurité des systèmes du ministère de la défense et prendre les mesures correctives si nécessaire. Il est recommandé pour mener cette analyse de disposer d'une FEROS d'interconnexion. |
| CVE.R 12. Sous réserve de compatibilité des politiques de sécurité, une autorisation provisoire d'exploitation sera donnée par l'autorité qualifiée désignée, pour une durée maximale non renouvelable d'un an. Ce délai inclut la réalisation de l'audit et des corrections afférentes préalables à la rédaction d'un protocole (conformément à l' instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 ) entre autorités qualifiées en vue de l'homologation de l'interconnexion (7). |
| CVE.R 13. L'interconnexion avec des réseaux appartenant à des pays tiers est soumise à une autorisation du ministre. Cette dernière intervient après instruction :
L'interconnexion sera réalisée en s'appuyant sur le guide de connexion avec un réseau étranger (cf. réf. 310 de l'annexe I). |
4.6.2.3. Protection des informations dans le cadre d'une connexion au réseau internet.
Les modalités pratiques de connexion d'un réseau sensible avec un réseau public sont énoncées dans le document d'orientation pour la sécurisation des interconnexions et des architectures de réseau (OSCAR).
| CVE.R 14. Le raccordement d'un réseau véhiculant des informations classifiées de défense au réseau Internet est interdit. Cette interdiction vaut pour les réseaux véhiculant des informations sensibles, sauf à utiliser des dispositifs de chiffrement cautionnés par le SCSSI. Tout raccordement au réseau Internet selon les modalités en vigueur autorisées par le ministère (cf. réf. 430 de l'annexe I), doit correspondre à l'expression d'un besoin avéré. L'autorisation d'accès au réseau Internet est donnée après instruction du dossier de connexion réalisé sous la responsabilité du chef de l'organisme demandeur, avec le concours de son OSSI, par l'autorité qualifiée. En fonction du concept d'emploi de ce média, et dans certaines circonstances, des mesures de protection particulières (discrétion, réseau privé virtuel, …) devront être prises. |
4.6.3. Cantonnement des dommages résultant d'une atteinte à la sécurité des systèmes d'information.
Les dispositions techniques et organisationnelles doivent être prises pour cantonner au maximum les dommages résultant d'une atteinte à la SSI, que son origine soit accidentelle ou intentionnelle.
4.6.3.1. Réseau d'alerte.
(8)
Un réseau de veille, d'alerte et de réponse est développé au sein du ministère de la défense sous la conduite du FSSI qui coordonne les actions s'y rapportant en s'appuyant sur le réseau de confiance SSI.
L'objectif est de :
diffuser dans les meilleurs délais, au plus près des utilisateurs concernés, les informations pertinentes relatives aux attaques et aux vulnérabilités émanant des CERT ou de tout autre acteur du réseau et les correctifs validés ;
de mutualiser, entre acteurs de la voie fonctionnelle SSI et de la voie technique (les administrateurs et les exploitants de systèmes), les outils et les bases de connaissances correspondantes.
L'organisation, le mode de fonctionnement et les actions à mener sont décrites dans une directive d'application.
| CVE.R 15. Chaque organisme doit mettre en place une organisation permettant de contribuer à la réalisation de cet objectif et en particulier de faire remonter les informations relatives aux systèmes dont il a la charge. |
4.6.3.2. Mesures d'urgence.
| CVE.R 16. Pour empêcher l'accès illicite aux systèmes d'information par des personnes non autorisées, la première mesure d'urgence consiste à prévoir des mesures d'isolement pour le réseau. En tant que de besoin, le système doit être adapté pour que ces mesures ne suspendent pas totalement l'activité, afin de conserver un minimum de capacité opérationnelle. |
| CVE.R 17. Conformément au TTA 191 (n.i. BO), il peut être nécessaire d'assurer le transfert sécurisé (9) ou de détruire d'urgence des informations classifiées de défense ou sensibles. Les mesures associées doivent être regroupées dans un plan établi par chaque organisme. Ce plan, comportant des consignes précises, doit être testé périodiquement, sur l'initiative de l'autorité hiérarchique. Ce plan de destruction doit prendre en compte l'ensemble des supports numériques et des documents papiers qui y sont associés. |
4.6.3.3. Reprise des activités après incident.
| CVE.R 18. Chaque organisme, éventuellement dans un cadre élargi nécessitant une collaboration avec d'autres organismes ministériels voire interministériels, doit élaborer un plan de reprise progressive des activités, pour chacun des systèmes d'information qu'il a en charge. Ce plan de reprise fixe :
|
4.6.3.4. Suivi des incidents de sécurité.
| CVE.R 19. Les organismes en charge de systèmes d'information doivent suivre les incidents les concernant, afin :
|
4.6.3.5. Centralisation et traitement des incidents.
L'assemblage d'incidents mineurs peut permettre l'identification d'une attaque ciblée plus profonde.
D'autre part, une centralisation de la connaissance des incidents peut permettre l'optimisation du traitement des incidents.
| CVE.R 20. Tout incident, même jugé mineur par l'exploitant du système, doit faire l'objet d'une remontée d'incidents par sa voie fonctionnelle SSI. En vue du traitement de ces incidents, doivent être établies les procédures :
|
| CVE.R 21. Toute compromission, possible, supposée ou avérée, sur un système d'information traitant des informations classifiées de défense doit faire l'objet d'une déclaration dans les meilleurs délais à la direction de la protection et de la sécurité de défense. |
Les modalités propres au traitement des compromissions, selon qu'il s'agit d'ACSSI ou de mécanisme cryptologique, de sécurité informatique ou de signaux parasites compromettants, seront décrites dans des directives particulières.
Une directive relative aux remontées et aux traitements des incidents sera élaborée.
4.6.4. Spécifications pour le développement.
Les spécifications SSI sont requises pour le développement de tout système d'information, qu'il doive ou non faire l'objet d'une évaluation en vue de son homologation.
Concernant le développement des programmes et projets destinés aux organismes du ministère de la défense, les règles permettant d'assurer la sécurité des informations durant cette phase devront s'inspirer du référentiel CASSIOPEE (10) réf. 200 de l'annexe I. Elles respecteront la politique technique du domaine technique SSI 259-1/SPOTI/ST/SSI/-- édition no 1 du 20 juillet 2000 (n.i. BO) ainsi que l' instruction 241 /DEF/SEC/DIR/SIC du 26 juin 2001 (BOC, p. 3605) relative à la SSI dans les programmes d'armement et dans les projets de systèmes d'information et de communication.
4.6.4.1. Définition des besoins de sécurité.
| CVE.R 22. Pour un système impliquant plusieurs organismes, une politique de sécurité système (PSS) doit être élaborée pour établir les objectifs de sécurité communs. Cette PSS ne doit pas remettre en cause les politiques de sécurité internes des organismes impliqués. |
Cette PSS se décline en mesures techniques (fonctions dédiées à la sécurité), en mesures non techniques (mesures environnementales, physiques et organisationnelles) et elle distingue, si nécessaire, les conditions nominales et les conditions particulières d'exploitation.
Elle doit être approuvée par l'ensemble des autorités qualifiées concernées.
| CVE.R 23. Chaque système d'information traitant des informations classifiées de défense (obligatoire) ou sensibles (obligatoire, sauf si le système est isolé) doit faire l'objet d'une FEROS (11). Elle doit être conforme à la politique de sécurité interne de l'organisme ou à la PSS si le système implique plusieurs organismes. Un système d'information traitant d'informations sensibles, dont l'organisme disposerait d'une politique de sécurité interne, est dispensé de FEROS si les besoins de sécurité sont satisfaits par cette politique de sécurité interne. |
| CVE.R 24. Lorsque les systèmes sont conçus, développés ou réalisés en application de conventions internationales, les documents nécessaires à leur conception, à leur développement ou à leur réalisation peuvent être remplacés par des documents qui, sous une forme convenue entre les parties, doivent viser à fixer les mêmes objectifs et exigences. Ceci s'applique en particulier pour les systèmes traitant d'informations OTAN [utilisation de la CM (55)-15, CSRS, SSRS, SECOPS, …]. |
4.6.4.2. Elaboration du plan de sécurité.
| CVE.R 25. Chaque système d'information traitant des informations classifiées de défense (obligatoire) ou sensibles (obligatoire, sauf si le système est isolé) doit faire l'objet d'un plan de sécurité, en réponse à la FEROS. Il décrit le système et présente les mesures techniques et non techniques prises pour atteindre les objectifs de la FEROS. Le plan de sécurité est approuvé par l'autorité qualifiée. |
4.6.4.3. Elaboration de la cible de sécurité.
| CVE.R 26. Pour tout équipement de chiffrement, ou système intégrant un tel procédé, devant faire l'objet d'une évaluation, en vue d'une caution ou d'un agrément, une cible de sécurité doit être établie. Elle comprend : la politique de sécurité du système, la spécification des fonctions de sécurité requises de l'équipement, la définition des mécanismes de sécurité et le niveau d'évaluation visé pour l'équipement. La cible de sécurité est approuvée par l'organisme commanditaire. |
4.6.4.4. Acquisition des équipements/logiciels.
| CVE.R 27. La politique d'acquisition des équipements, matériels informatiques et logiciels destinés aux traitements des informations classifiées ou sensibles, matériels et logiciels de sécurité, est centralisée pour chaque autorité qualifiée. |
La commission technique des SIC (CTSIC) établit un catalogue des normes et standards applicables au ministère : NOSSIF (12). Cette même commission proposera les recommandations en matière d'équipements de produit de sécurité sur étagère, après consultation et validation des choix techniques par le centre technique SSI du ministère.
4.6.5. Exploitation sécurisée.
L'exploitation sécurisée d'un système d'information dépend essentiellement de l'application des procédures et des contrôles par les différents acteurs, mais aussi de la mise en œuvre d'outils permettant de suivre les événements survenant au niveau des composants critiques du système d'information et d'outils fournissant en temps différé des rapports sur l'utilisation des composants du système d'information, et faisant apparaître les corrélations nécessaires.
4.6.5.1. Exploitation sécurisée des informations.
| CVE.R 28. Les mesures de protection des informations s'appliquent aux opérations de recueil, de traitement, de sauvegarde, de diffusion, de stockage, de déclassification (éventuelle) et de destruction. Elles s'appliquent également aux supports des informations et à l'ensemble de l'environnement logiciel, lorsqu'il ne peut pas être dissocié des données. |
L'ensemble des éléments concourrant à la prise en compte de la sécurité dans l'exploitation des systèmes d'information est décrit dans le document réf. 480 « procédures d'exploitation de sécurité » de l'annexe I.
4.6.5.2. Contrôle des composants avant leur exploitation.
| CVE.R 29. L'autorisation d'acquérir ou d'installer un composant sur un système d'information est soumise à l'approbation du responsable du système suite à :
|
| CVE.R 30. Le maintien de l'intégrité des logiciels implantés dans les systèmes d'information du ministère de la défense est de la responsabilité des autorités qualifiées. |
Cette intégrité peut être obtenue par un procédé de signature.
4.6.5.3. Contrôle et gestion des supports amovibles classifiés, avant leur réutilisation.
| CVE.R 31. Lorsque des supports amovibles d'informations classifiées doivent être réutilisés par d'autres systèmes d'information comme support d'informations d'un niveau de sensibilité supérieur ou égal à celui précédemment utilisé, ils doivent faire l'objet d'effacement selon les prescriptions du centre technique SSI du ministère de la défense et de contrôles garantissant l'absence totale de toute information, y compris de résidus. Ces actions sont à effectuer par le service informatique de l'organisme, sous le contrôle de l'OSSI pour tout type de mémoire de masse. Dans le cas contraire, ces supports seront détruits conformément à la réglementation ou aux règles en vigueur. |
4.6.5.4. Contrôles de sécurité en phase d'exploitation.
| CVE.R 32. La supervision du système d'information est indispensable en phase d'exploitation ou d'utilisation. Elle doit permettre de détecter « en temps réel » toute utilisation non conforme (accidentelle ou intentionnelle) de l'un quelconque des composants du système, et de réagir dans les meilleurs délais, compatibles avec les objectifs de sécurité définis pour le système. |
4.6.5.5. Analyse des journaux du système, sous l'angle sécurité.
| CVE.R 33. L'analyse de l'utilisation d'un système d'information est indispensable en phase d'exploitation ou d'utilisation. Elle doit permettre de détecter, d'imputer et de réagir a posteriori à toute utilisation non conforme (accidentelle ou intentionnelle) de l'un quelconque des composants du système. |
| CVE.R 34. Les outils utilisés dans les règles CVE.R 28 à CVE.R 33 doivent être conformes au plan de sécurité et à ses procédures d'exploitation de sécurité du système. Ils doivent être actualisés en fonction de l'évolution de la menace technique et du contexte d'utilisation. |
| CVE.R 35. La mise en œuvre de mécanismes ou de journaux autorisant la traçabilité des accès aux données et ressources est :
La journalisation doit respecter les principes de la loi 78-17 du 06 janvier 1978 (BOC, 1979, p. 4161) relative à l'informatique aux fichiers et aux libertés. |
4.6.5.6. Prestations de services externes.
| CVE.R 36. Les prestations de services nécessitant l'accès à des systèmes d'information classifiées de défense ou sensibles, effectuées par des entreprises, doivent se faire tout en assurant la continuité de la sécurité de ces systèmes et en respectant les exigences minimales suivantes :
|
4.6.6. Sécurité de la maintenance.
La maintenance a pour objet la prévention des pannes (maintenance préventive), la réparation des matériels ou des logiciels suite à des incidents de fonctionnement (maintenance curative et corrective) et la modification des logiciels ou des matériels pour tenir compte de l'évolution des besoins, des nécessités réglementaires ou des évolutions technologiques (maintenance évolutive).
| CVE.R 37. La voie fonctionnelle SSI doit être associée à la définition des modalités de maintenance et de son contrôle :
|
| CVE.R 38. Toute maintenance d'équipements et systèmes traitant d'informations classifiées de défense doit faire l'objet des mesures suivantes :
|
4.6.6.1. Usage de la télémaintenance.
La télémaintenance par un organisme externe n'est pas recommandée pour les systèmes traitant d'informations classifiées de défense.
| CVE.R 39. Toute télémaintenance, interne ou externe, doit faire l'objet des mesures complémentaires suivantes :
|
4.6.7. Evaluation, agrément, caution et homologation.
4.6.7.1. Processus.
L'analyse de sécurité (dite évaluation dans le cadre du schéma français d'évaluation et de certification, cf. réf. ECF O 1 présentation du schéma version 2.0 du 16 janvier 1997 diffusée par le SCSSI) d'un mécanisme est un processus qui a pour vocation de déterminer la convergence entre le niveau d'assurance sécurité souhaité et les capacités des mécanismes de protection mis en œuvre pour répondre à ce besoin.
Elle est requise :
pour les mécanismes de sécurité soumis à agrément ou à caution ;
pour les mécanismes intégrés dans les systèmes traitant d'informations classifiées de défense ou présentant des enjeux de sécurité élevés, en vue de leur homologation.
Le processus est initialisé par :
le directeur de programme pour ce qui concerne les programmes d'armement ;
le chef de projet pour ce qui concerne les projets et opérations ;
le directeur d'application ou de systèmes dans les autres cas.
| CVE.R 40. Les analyses de sécurité à partir d'une documentation suffisante doivent être menées avec le souci du respect de coûts et de délais compatibles des objectifs opérationnels de mise en œuvre. Lors de la phase de validation chez les utilisateurs, les évaluations de sécurité devront avoir été conduites et aucune vulnérabilité bloquante ne devra être mise en évidence. A défaut, la recette technique du système sera suspendue. |
En vue du respect des délais, les analyses fonctionnelles et de sécurité doivent être autant que possible menées conjointement.
| CVE.R 41. Les conclusions des analyses de sécurité, nécessaires à la recette opérationnelle du système, indiquant notamment les vulnérabilités résiduelles des mécanismes, sont reportées dans le plan de sécurité, qui est communiqué à l'autorité qualifiée en vue de l'homologation du système. |
4.6.7.2. Evaluation.
Afin de déterminer la convergence entre le niveau d'assurance sécurité souhaité et les capacités des mécanismes de protection mis en œuvre pour répondre à ce besoin, une étude technique est nécessaire. Cette étude peut être conduite suivant différents plans de tests en fonction de l'objectif et du résultat recherchés.
Le centre technique SSI du ministère de la défense fournit un rapport explicitant clairement le degré de confiance et les vulnérabilités résiduelles propres à la cible d'évaluation, et précise les éventuelles restrictions d'emploi.
Ce rapport peut prendre la forme :
d'un avis technique à partir de l'analyse, plus ou moins approfondie, d'un mécanisme sur plate-forme (13) ;
d'une évaluation suivant les critères ITSEC ou les CC (14) ;
d'une investigation conduite selon une méthode propre au centre ;
d'une vérification des évaluations conduites par d'autres CESTI (15).
| CVE.R 42. Les évaluations de composants développés ou utilisés par le ministère de la défense, sont réalisées sous la conduite du centre technique SSI du ministère de la défense. |
| CVE.R 43. Pour les produits de sécurité commerciaux, le recours aux produits certifiés, dont la cible d'évaluation est connue, doit être privilégié. Une analyse doit de toute manière être conduite par le centre technique SSI du ministère afin de déterminer les contre-indications, les restrictions et les recommandations d'emploi (paramétrage, …). |
4.6.7.3. Agrément des composants du système d'information.
| SYS.R 44. L'agrément est requis pour tout composant cryptologique du système d'information, assurant la protection des informations classifiées de défense, dans les conditions d'emploi définies. Il est prononcé par les services du Premier ministre chargés de la sécurité des systèmes d'information qui reconnaissent formellement que le composant, préalablement analysé, peut protéger les informations jusqu'au niveau de classification prévu et dans les conditions d'emploi définies. |
4.6.7.4. Caution des composants cryptologiques du système d'information.
L'utilisation d'un produit cautionné pour la protection des informations sensibles est recommandée et reste de la responsabilité de l'autorité qualifiée.
| CVE.R 45. La demande de caution est recommandée pour tout composant cryptologique du système d'information, assurant la protection des informations sensibles non classifiées de défense, dans les conditions d'emploi définies. Un échec de la caution ne remet pas systématiquement en cause l'utilisation du produit. |
La mise en œuvre d'un produit dans des conditions d'emploi différentes de celles retenues pour la délivrance de sa caution est de la responsabilité de l'autorité qualifiée.
| CVE.R 46. Lorsqu'il n'existe pas de caution pour ces composants cryptologiques, alors une analyse de sécurité du produit, comportant au minimum un test de vulnérabilité, par le centre technique SSI du ministère de la défense s'impose. En cas de résultat négatif majeur du test ou de l'avis défavorable suite à l'évaluation par ce centre, la mise en œuvre d'un produit est de la responsabilité de l'autorité qualifiée : des procédures palliatives sont alors instaurées en l'attente de la disponibilité d'un produit alternatif. |
| CVE.R 47. L'agrément et la caution sont accompagnés d'une instruction technique d'emploi (ITE) qui définit les conditions d'exploitation des produits et la conduite à tenir en cas de perte, de compromission, … |
4.6.7.5. Homologation d'un système d'information ou de ses composants.
La décision d'homologation est un acte formel par lequel l'autorité qualifiée :
valide la mise en exploitation du système ;
engage sa responsabilité en matière de SSI.
Cette décision est prise par l'autorité qualifiée ou toute autorité subordonnée désignée ayant reçu délégation de signature dans ce domaine, la responsabilité de l'autorité qualifiée n'étant pas déléguée.
| CVE.R 48. L'homologation est requise pour l'ensemble du système d'information (avant sa mise en exploitation) ou de ses composants assurant la collecte, le traitement, le stockage, la diffusion, la protection des informations qui sont classifiées de défense ou sensibles, dans les conditions d'emploi définies. |
4.6.7.6. Révision de l'homologation.
| CVE.R 49. Tout système d'information assurant le traitement, le stockage, la diffusion ou la protection d'informations classifiées de défense ou sensibles doit faire l'objet d'une révision de son homologation préalablement attribuée, dès lors que :
|
5. Définitions.
5.1. Système d'information.
Au sens de l'instruction no 900/SGDN/SSD/DIR du 20 juillet 1993, un système d'information est défini comme un moyen dont le fonctionnement :
fait appel, sous toutes ses formes, à l'électricité ;
est destiné à élaborer, traiter, stocker, acheminer, présenter ou détruire l'information.
Vue conceptuelle : ensemble des traitements et des données nécessaires au fonctionnement du ministère de la défense ou à l'accomplissement de ses missions.
Vue opérationnelle : ensemble constitué des hommes, des locaux, des équipements informatiques, des équipements électroniques et des procédures nécessaires aux activités du ministère de la défense.
Vue technique : ensemble constitué des systèmes d'information du ministère de la défense.
La politique de sécurité définie comme les principes et règles applicables au ministère de la défense en matière de SSI concerne le système d'information du ministère.
5.2. Informations.
Pour le ministère, les informations sont tout à la fois la base et la matière des décisions et des activités :
informations relevant du secret de défense ou relevant de traités d'alliances (OTAN, UE) et d'accords comportant des protocoles de sécurité fixant les équivalences entre les niveaux de classification ;
informations stratégiques associées :
aux systèmes d'armes en période d'études et de développement lorsqu'elles ne rentrent pas dans la catégorie des informations classifiées ou sensibles ;
à la politique budgétaire ;
à la politique d'équipement ;
informations sensibles (classement éventuellement assorti d'une mention spécifique telle que « médical », « personnel », …) ;
informations nominatives régies par la loi « informatique et libertés » ;
informations vitales pour le fonctionnement d'un système (logiciels de base, logiciels techniques, …).
5.3. Menace.
L'élaboration et la mise en place des mesures garantissant la sécurité des informations reposent sur l'identification des menaces à prendre en compte et sur la connaissance des points faibles. La concrétisation de ces menaces entraverait les missions du ministère.
D'origines externes ou internes, les menaces qui pèsent sur les informations et les systèmes s'apprécient dans un contexte permanent de guerre de l'information. La connaissance de leurs origines permet d'évaluer la force et les moyens d'un agresseur potentiel.
Pour un système donné, la menace n'est pas unique, elle revêt différentes formes qui évoluent dans le temps.
5.4. Vulnérabilité.
La vulnérabilité du système d'information résulte des faiblesses ou des failles dans la conception, la réalisation et la protection de ses composants. Leur utilisation non conforme, qu'elle soit malveillante ou non, peut porter atteinte à la confidentialité, à la disponibilité et à l'intégrité des informations.
5.5. Risque.
Corrélé à une menace identifiée et à une ou plusieurs vulnérabilité (s) révélées(s), le risque qualifie les conséquences de l'exploitation potentielle d'une vulnérabilité, au niveau d'un ou plusieurs composants du système d'information, et dont la possibilité d'occurrence est évaluée.
5.6. Sécurité d'un système.
État du système dans lequel les vulnérabilités sont contenues dans les limites compatibles avec la bonne exécution des missions qu'il supporte, et pour lequel les risques sont ramenés à un seuil acceptable et accepté par l'autorité qualifiée.
Elle découle de l'application d'un ensemble de procédures, de dispositifs, de méthodes concourant à atteindre le niveau de sécurisé fixé et le niveau de risque que l'autorité qualifiée tolère pour chaque système.
5.7. Sécurité du système d'information.
État du système d'information dans lequel les informations sont protégées contre les modifications, les destructions, les divulgations ou les utilisations non autorisées. L'état de sécurité apporte la garantie que le système d'information assure correctement les fonctions opérationnelles.
5.8. Critères (disponibilité, intégrité, confidentialité).
La sécurité des informations est appréciée à l'aide de trois critères : la disponibilité, l'intégrité et la confidentialité.
Normalisés dans les ITSEC (information technology security evaluation criteria), ces critères sont définis comme suit :
disponibilité garantie de continuité de service ou d'accès à une ressource ;
intégrité garantie d'exhaustivité, d'exactitude et de non-altération de la ressource ;
confidentialité garantie de non-accès et de non-divulgation à des tiers non autorisés.
5.9. Besoin d'en connaître.
L'article 7 du décret 98-608 du 17 juillet 1998 (BOC, p. 2709) relatif à la protection des secrets de la défense nationale précise : « Nul n'est qualifié pour connaître des informations ou supports protégés s'il n'a fait au préalable l'objet d'une décision d'habilitation et s'il n'a besoin de les connaître pour l'accomplissement des sa fonction ou de sa mission. »
Pour le ministre de la défense et par délégation :
Le directeur du cabinet civil et militaire,
Michel THENAULT.
Annexes
ANNEXE I. Référentiel documentaire de la sécurité des systèmes d'information.
1 Organisation.
Réf. 100 : Référentiel des textes relatifs à la sécurité des systèmes d'information (SSI).
Réf. 110 : Instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 (BOC, p. 4343).
Réf. 120 : Politique SSI du ministère de la défense.
Réf. 130 : Politiques SSI applicable aux systèmes d'information utilisés en contexte international et ne relevant pas de la PSSI du ministère de la défense (à élaborer).
Réf. 140 : Standard d'élaboration de la documentation de sécurité (à élaborer).
2 Prise en compte de la sécurité des systèmes d'information dans la conception et la mise en place d'un système d'information.
Réf. 200 : Prise en compte de la SSI dans les programmes d'armement, CASSIOPEE édition 1998 Bêta diffusée par la DGA/SPOTI/ST/SSI.
Réf. 210 : Gestion du risque (à élaborer).
Réf. 220 : Sécurisation des connexions, OSCAR.
Réf. 230 : Évaluation et agrément ( Instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 ).
Réf. 240 : Rédaction du DSSI ( Instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 ).
Réf. 250 : Homologation ( Instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 ).
Réf. 260 : Principes généraux de l'homologation des interconnexions (à élaborer).
3 Moyens de sécurité.
Réf. 300 : Guide sécurité Internet à l'usage de l'utilisateur et charte Internet.
Réf. 301 : Guide de connexion à Internet pour l'administrateur (à élaborer).
Réf. 310 : Guide de connexion d'un réseau du ministère de la défense avec un réseau étranger (à élaborer).
Réf. 320 : Guide pour l'installation de NT.
Réf. 330 : Stratégie d'utilisation d'un firewall (à élaborer).
Réf. 340 : Stratégie d'utilisation d'un anti-virus (à élaborer).
Réf. 350 : Stratégie d'utilisation d'un contrôle d'accès (à élaborer).
Réf. 360 : Guide pour le Tempest.
Réf. 370 : Marquage (en cours d'élaboration).
Réf. 380 : Sensibilisation, formation (à élaborer).
Réf. 390 : Guide pratique 972 (0498) pour la protection des supports classifiés de défense.
4 Système d'information en exploitation.
Réf. 400 : Guide sur la conduite des audits (à élaborer).
Réf. 410 : Mise à jour du DSSI ( instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 ).
Réf. 420 : Inspection ( instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 ).
Réf. 430 : Internet [ instruction 8192 /DEF/CAB/CM/3 du 24 février 1997 (BOC, p. 1374)].
Réf. 440 : Administration et gestion de la sécurité (à élaborer).
Réf. 450 : Rapport d'incident SSI (à élaborer).
Réf. 460 : Fraude informatique et contrefaçon.
Réf. 470 : Référentiel sur les menaces techniques.
Réf. 480 : Procédures d'exploitation de sécurité.
5 Gestion des ACSSI.
Réf. 500 : Identification des ACSSI (à élaborer).
Réf. 510 : Gestion et protection des ACSSI (à élaborer).
ANNEXE II. Instruction n o 4418/DEF/SEC/DIR/SIC du 25 septembre 2000.
Voir instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 (BOC, p. 4343).
ANNEXE III. Directive d'orientation pour la sécurisation des interconnexions et des architectures de réseau (OSCAR).
Contenu
diffusée par note no 178/DEF/SEC/DIR/SIC du 4 mai 2001 (n.i. BO).
Contenu
| Version. | Date. | Commentaires. |
|---|---|---|
| 2.0 | 3 mai 2001. | Première version diffusée de la directive. |
| 1.98 | 19 avril 2001 | Prise en compte des remarques CGA, EMAA, DGSE. |
| 1.97 | 7 février 2001. | Remarques de la réunion du 6 février 2001 et du CGA. |
| 1.96 | 10 janvier 2001. | Remarques EMAA et réunion du 9 janvier 2002. |
| 1.95 | 4 décembre 2000. | Remarques SecDirSic, SPOTI. |
| 1.94 | 26 octobre 2000. | Remarques EMA et SGA. |
| 1.93 | 27 septembre 2000. | Remarques SecDir Sic, EMA et SPOTI intégrées, amélioration schémas. |
1 Introduction.
1.1 Présentation du contexte.
L'utilisation des applications fondées sur les technologies de type Intranet/Internet, est de plus en plus incontournable tant dans le monde civil que dans celui de la défense, compte tenu de leur facilité d'utilisation et de leur capacité de partage et de diffusion d'informations.
Cependant, l'avènement de technologies (java ou active X entre autres) ou de méthodes de travail nouvelles (le groupware par exemple) participe à l'ouverture des réseaux en négligeant le plus souvent la sécurité au profit de la convivialité et de l'interopérabilité. L'engouement pour Internet peut représenter un réel danger pour nos institutions, en absence d'analyse pertinente sur le besoin de cette connexion et en moyens à mettre en œuvre pour en assurer la sécurité. Le « réseau des réseaux » n'a pas été conçu pour assurer la confidentialité des échanges ni l'intégrité ou la disponibilité des informations, services ou ressources. Néanmoins, ce danger ne doit pas interdire une ouverture responsable et maîtrisée des réseaux.
La grande majorité des systèmes d'information mis en place est supportée par des réseaux locaux, s'appuyant sur des protocoles de type TCP/IP. Interconnecter ces systèmes ne pose pas de difficultés techniques, de nombreux types de produits répondant à ce besoin.
La difficulté majeure relève de la mise en place de solutions de sécurité pour ouvrir l'accès à un système tout en le protégeant contre les accès non autorisés, malveillants ou des erreurs d'utilisation.
La solution de sécurité choisie, doit permettre d'assurer la confidentialité, l'intégrité et la disponibilité des informations ou services sensibles de l'organisation concernée contre un ensemble de menaces, d'origine interne ou externe.
Ce guide se limite aux aspects de l'interconnexion.
Les vulnérabilités principales sont induites par les applications et protocoles utilisés.
En effet, pour réduire les coûts et augmenter la pérennité des systèmes, on utilise des produits standards complexes, évolutifs, largement diffusés qui présentent de multiples risques, déterminant des vulnérabilités intrinsèques, nombreuses et souvent redoutables.
La vulnérabilité générale des systèmes est la conséquence de la permissivité induite par l'emploi des mêmes applicatifs et protocoles au sein des réseaux locaux et dans les moyens nécessaires à leur interconnexion, même si inversement cette utilisation massive de protocoles de fait ou d'interfaces de haut niveau autorise le travail transverse.
L'interconnexion de réseaux étant de nature à permettre le rapprochement de fichiers et d'informations, il est indispensable de faire une déclaration à la CNIL.
Ce document s'intéresse principalement aux interconnexions de systèmes d'informations français entre eux. En ce qui concerne les interconnexions avec des systèmes multinationaux, seule une ébauche, fondée sur les textes réglementaires en vigueur est fournie.
1.2 But du document.
L'objectif principal de ce document est d'aider le lecteur à définir son besoin de sécurité avant la mise en œuvre d'une interconnexion de systèmes. Ce document ne constitue pas une documentation technique mais uniquement une aide à l'élaboration d'une interconnexion de systèmes d'information.
Il définit un ensemble de règles minimales qui doivent être mises en œuvre, lorsqu'il est souhaité de raccorder des systèmes d'information, situés sur un même site ou sur des sites différents, en regard des enjeux de sécurité en terme de confidentialité, d'intégrité et de disponibilité des données respectivement traitées et à vocation d'être échangées.
Avertissement.
A la date de rédaction de ce document, la position ministérielle sur l'interconnexion de réseaux classifiés de défense et de réseaux sensibles est de disposer de réseaux distincts jusqu'à ce que des segments d'interface soient homologués en s'appuyant :
d'abord, sur des produits de chiffrement agrées pour le ou les « côté(s) » du segment le justifiant ;
ensuite, sur des produits de sécurité informatique de préférence évalués au sein du segment d'interface ;
enfin, sur des mécanismes de confiance (filtrage, journalisation, moyen d'authentification, labellisation , …) au sein des enclaves respectives.
Il convient également de souligner que seul un assemblage de produits en cours de développement ou à venir permettra de réaliser des interconnexions sécurisées entre des réseaux classifiés de défense et des réseaux sensibles.
1.3 Plan du document.
Ce document comprend les quatre parties suivantes :
exigences générales aux niveaux réglementaire, technique et financier ;
proposition d'une démarche méthodique indispensable pour une prise en compte efficace des objectifs de sécurité ;
proposition en terme d'exigences fonctionnelles de cas d'interconnexion type ;
moyens nécessaires à la mise en place de l'interconnexion.
En point 9 et 10, on trouvera une liste de menaces auxquelles les systèmes d'information peuvent être soumis et des exemples d'architectures d'interconnexion.
1.4 A qui s'adresse ce document ?
Il s'adresse aux maîtres d'ouvrage, aux maîtres d'œuvres, aux responsables des systèmes d'information des organismes et aux officiers de sécurité des systèmes d'information (OSSI) qui cherchent des orientations pour la sécurisation des interconnexions de systèmes.
2 Exigences.
2.1 Aspects législatifs et réglementaires.
Les dispositions législatives et réglementaires sont essentielles dans le domaine de la sécurité. Elles doivent être prises en compte lors de l'interconnexion de systèmes d'information.
Pour ces aspects, le CéDéROM élaboré par le centre de l'armement pour la sécurité des systèmes d'informations (DGA/CELAR/CASSI) et les services du Premier Ministre apporte une aide précieuse.
Afin d'aider le lecteur, un ensemble de textes pertinents est présenté en annexe I.
2.2 Analyse préalable.
Avant toute interconnexion d'un système vers un autre système, les responsables des systèmes à interconnecter doivent simultanément et en cohérence :
Définir les besoins opérationnels en matière d'interconnexion en définissant des capacités particulières à atteindre :
définir les services à autoriser entre les deux réseaux ;
définir l'architecture et les services supportés par le segment d'interface.
Prendre connaissance des politiques de sécurité des systèmes à interconnecter ainsi que celle du support d'interconnexion afin d'identifier les menaces et les mesures prises. Les responsables des systèmes à interconnecter doivent notamment identifier les vulnérabilités résiduelles de chaque système et, le cas échéant, celles générées du fait de l'interconnexion.
Définir les besoins de sécurité des informations à échanger :
définir leur sensibilité en CID (confidentialité, intégrité, disponibilité) ;
définir le besoin d'authentification ou de preuve éventuel ;
appliquer une démarche méthodique (telle que celle proposée au point 3).
2.3 Pré-requis.
Les utilisateurs doivent être habilités au niveau des informations qu'ils manipulent. Les utilisateurs des systèmes internes doivent être sensibilisés aux menaces et aux vulnérabilités potentielles liées à l'interconnexion.
L'interconnexion de systèmes manipulant des informations classifiées de défense implique que chacun des systèmes ait été préalablement homologué au niveau des informations considérées.
Tous les éléments réservés à l'interconnexion des systèmes doivent être physiquement protégés et installés dans des locaux accessibles uniquement pour des tâches d'administration ou de maintenance. Ces locaux seront dotés de protection physique en adéquation avec le niveau de sensibilité des informations traitées.
2.4 Exigences financières et organisationnelles.
Avant toute décision de nouvelle connexion, il est recommandé de s'assurer auprès des organismes compétents et conformément aux politiques mises en place que l'acquisition de produits de sécurité est possible :
sur le plan financier ;
sur le plan humain (l'administration et la gestion de la sécurité des SICs traitant d'information classifiées de défense doivent être assurées par du personnel du ministère, disponible, compétent et habilité) ;
sur le plan des évaluations et des audits ;
sur le plan de la maintenance du produit (la maintenance ou le paramétrage d'un produit de sécurité doit être réalisée par du personnel du ministère ou une société habilitée si besoin est).
La mise en place d'une interconnexion doit s'accompagner de la création d'une fonction d'administration permanente du système mandatée par l'autorité d'emploi qui sera chargée à temps plein de sa gestion et de son exploitation. Par exemple, les outils sélectionnés pour le segment d'interface seront mis en œuvre par du personnel formé et habilité.
Les administrateurs du système d'interconnexion doivent se tenir informés des problèmes de sécurité des systèmes d'information. Ils peuvent pour cela consulter les avis du CERT Administration, s'inscrire dans les info-groupes correspondants ou consulter les services adéquats du ministère de la défense (relais du CERTA, CELAR/CASSI) ou de toute autre instance, du secteur public ou privée, à laquelle ils sont adhérents.
2.5 Politiques de sécurité.
Conformément à l' instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 , un protocole d'accord doit être établi à partir d'un pré-requis explicite décrivant les politiques de sécurité des SIC candidats à l'interconnexion. Doivent aussi être décrits pour les SIC respectifs et le segment d'interface :
les modes (exclusif, dominant, multiniveau) et les procédures d'exploitation (de sécurité) ;
les vulnérabilités résiduelles existantes et probables supplémentaires dues à l'interconnexion (document annexe qui devra faire l'objet d'une classification) ;
l'adaptation ou la reconfiguration des réseaux existants ou l'intégration de services de sécurité complémentaires pour les applications existantes.
L'interconnexion à de nouveaux systèmes peut nécessiter la réactualisation des politiques de sécurité des organismes. Cette réactualisation devra faire l'objet d'un accord entre les organismes concernés. Elle donnera lieu à l'élaboration d'une politique de sécurité liée à l'interconnexion.
L'interconnexion de réseaux peut nécessiter l'adaptation ou la reconfiguration des réseaux existants.
Le principe applicable à toute interconnexion est que tout ce qui n'est pas expressément autorisé est interdit.
La stratégie de filtrage intégrant les informations de chaque politique de sécurité des SIC candidats doit être élaborée et testée avant interconnexion effective, en configurant les machines selon une « stratégie pessimiste » (deny all), puis en n'ouvrant progressivement que les seuls services autorisés et les paramétrages associés. Un audit du segment d'interface doit être réalisé pour valider ce choix.
2.6 Support d'interconnexion.
Deux cas peuvent se présenter :
utilisation d'un support (ligne ou réseau déjà chiffré) homologué au niveau de l'information manipulée ;
le support n'est pas homologué. Il faudra prévoir un dispositif de chiffrement adapté pour assurer la confidentialité et l'intégrité des informations échangées.
Les entités s'assureront de la disponibilité du support d'interconnexion auprès de l'administrateur du support.
2.7 Caractérisation du besoin.
Outre le respect du niveau d'habilitation détenu par les personnels en regard du niveau de classification ou de sensibilité des données traitées, manipulées ou échangées, le besoin doit être précisé selon les trois critères suivants, traduisibles dans l'architecture informatique :
besoin d'en connaître ;
besoin d'en modifier ;
besoin d'en disposer.
Le besoin peut être affiné à l'aide des critères détaillés dans le point 3.
2.8 Produits.
Les produits destinés à l'interconnexion doivent avoir reçu au minimum un avis technique par le CELAR/CASSI.
Le paramétrage des produits destinés à l'interconnexion doit s'appuyer sur des avis techniques émis par le CELAR.
Des outils concourrant au maintien de la qualité de la sécurité dans le temps doivent être mis en œuvre (analyse de vulnérabilités, détection d'intrusion, analyse de log, traçabilité des actions).
2.9 Architectures de sécurité.
Les architectures d'interconnexion doivent avoir été validées sous l'aspect opérationnel et sécurité en s'appuyant sur l'expertise du CELAR/CASSI sous la responsabilité de l'autorité qualifiée désignée.
3 Démarche méthodique.
3.1 Cas général.
Après avoir établi une politique de sécurité d'interconnexion, la démarche méthodique à suivre est :
Figure 2.
 |
PHASE 1.
La première phase consiste à déterminer les objectifs de sécurité et les menaces, afin de définir ce que l'on veut protéger et contre quoi on veut se protéger (appelé « périmètre de l'interconnexion »). Elle sera conduite selon la méthode EBIOS (1) élaborée par les services du Premier Ministre.
Pour la détermination des objectifs, on considérera les trois composantes habituelles (confidentialité, intégrité et disponibilité) pour le système global puis, éventuellement, pour ses constituants ou pour les différents types d'informations manipulées.
Concernant les menaces, les deux listes de menaces fournies en point 9 seront analysées afin de sélectionner les menaces les plus pertinentes.
Pour les organismes manipulant des informations classifiées de défense, le résultat de cette phase doit être utilisé pour réaliser une FEROS (2) d'interconnexion.
Durant cette phase d'analyse des besoins de sécurité, un protocole d'accord concernant les politiques de sécurité de chaque organisme concerné par l'interconnexion devra être élaboré.
Les exigences de sécurité devront tenir compte de l'état de l'art technique et des limitations qui peuvent en découler.
PHASE 2.
Dans cette phase, on identifiera le cas type (décrit au point 4) auquel le système d'interconnexion correspond en renseignant les différents paramètres :
le niveau de maîtrise du support d'interconnexion ;
le niveau de sensibilité des informations ou des services présents sur le réseau interne en termes de disponibilité, d'intégrité et de confidentialité ;
le besoin d'en connaître, d'en modifier, d'en disposer.
En complément, on dressera une première liste des mesures techniques et non techniques à mettre en place en tenant compte des contraintes de l'organisme, des architectures types proposées dans le présent document et des enjeux du système.
PHASE 3.
L'objectif de cette phase est de sélectionner les produits de sécurité permettant la mise en place de la solution retenue dans le respect des mesures techniques et non techniques qui ont été définies lors des phases précédentes.
PHASE 4.
Cette phase doit permettre d'analyser dans le détail la solution retenue afin de vérifier :
son adéquation aux objectifs de sécurité définis en phase 1 ;
la prise en compte des menaces qui doivent être réduites par les produits et les mesures choisies ;
le niveau des vulnérabilités résiduelles ;
sa cohérence avec le budget alloué ;
sa cohérence avec les ressources disponibles (en personnels, en locaux, …) en qualité et en quantité, lorsqu'il faudra en assurer l'exploitation.
L'analyse détaillée peut nécessiter la mise en place de maquettes pour des tests en grandeur réelle.
Si les résultats de l'analyse ne sont pas satisfaisants, il est nécessaire de reprendre la phase 2 puis la phase 3 pour trouver une solution conforme aux besoins. On pourra par exemple modifier les supports utilisés pour l'interconnexion, le rapport entre les mesures techniques et les mesures non techniques.
Cette démarche est répétée jusqu'à obtention des objectifs souhaités.
En cas d'impossibilité de convergence vers une solution répondant à toutes les contraintes, il sera nécessaire de remonter à la phase 1 pour diminuer éventuellement le périmètre de sécurité de l'interconnexion.
PHASE 5.
Cette phase accompagne la mise en place de la solution retenue. Le responsable du système d'interconnexion doit rédiger un document d'administration et d'utilisation (3). Des tests de vulnérabilité devront être menés afin de s'assurer de la validité des mesures mises en place.
Dans le cas d'une connexion mettant en œuvre un traitement d'informations classifiées de défense, une homologation (4) doit être obtenue auprès de l'autorité qualifiée, avant la mise en service de la connexion. Cette homologation peut s'appuyer sur un agrément dans le cas où l'autorité d'emploi en a fait la demande conformément à la phase 1. L'agrément est prononcé par les services du Premier ministre chargés de la sécurité des systèmes d'information. Il est la reconnaissance formelle que le composant, préalablement évalué sous la conduite du centre technique SSI du ministère, peut protéger les informations suivant le niveau de classification spécifié, dans les conditions d'emploi définies.
Tous les éléments des phases 3, 4 et 5 doivent figurer dans le dossier de sécurité du système d'information.
3.2 Cas particuliers.
Dans l'hypothèse où l'un des systèmes à interconnecter ne disposerait pas de FEROS, il conviendrait de rédiger une politique de sécurité pour l'interconnexion et d'organiser des audits pour s'assurer de la bonne implémentation des mesures techniques découlant de cette politique.
Après examen des politiques de sécurité respectives ou à défaut des mécanismes et procédures de sécurité mises en œuvre, l'identification des vulnérabilités résiduelles générées par l'interconnexion devra être réalisée. Selon les vulnérabilités résiduelles de chacun des systèmes et les menaces retenues au titre de l'interconnexion :
le renforcement respectif des mécanismes et procédures sera requis pour chacun des systèmes et la mise en œuvre de mécanismes et procédures complémentaires pourra être demandé ;
des mécanismes complémentaires devront être installés sur le segment d'interface.
En l'absence de visibilité sur au moins l'un des systèmes à interconnecter ou en cas d'urgence avérée, le segment d'interface sera mis en œuvre et sécurisé sous la responsabilité du réseau maîtrisé.
4 Cas type.
L'ensemble des cas types identifiés dans ce document figure dans les paragraphes suivants.
Chaque cas comporte :
des hypothèses sur les conditions d'emploi et le support d'interconnexion ;
des exigences fonctionnelles concernant le contrôle des flux ;
des exigences fonctionnelles concernant le système d'interconnexion (ou zone de transit).
Il est interdit d'interconnecter directement des réseaux dont l'écart de sensibilité est supérieur à 1 (par exemple : secret défense - sensible).
L'interconnexion de deux réseaux dont l'écart de sensibilité est égal à 1 mais dont au moins l'un d'eux est connecté à un réseau de même écart de sensibilité, crée une interconnexion entre réseaux dont l'écart de sensibilité est supérieur à 1. Cette interconnexion est interdite.
On trouvera dans ce chapitre :
d'une part les interconnexions entre systèmes traitant d'informations de même niveau de sensibilité, (secret défense/secret défense, confidentiel défense/confidentiel défense, sensible/sensible) ;
d'autre part les interconnexions entre systèmes traitant d'informations de niveau de sensibilité différentes (secret défense/confidentiel défense, confidentiel défense/sensible, sensible/internet).
Afin d'éviter au lecteur une recherche entre un socle d'exigences communes et les spécificités, on retrouve pour chacun des cas l'ensemble des mesures minimales à prendre pour étudier leur interconnexion.
4.1 Interconnexions entre systèmes traitant d'informations de même niveau de sensibilité.
4.1.1 Secret défense - secret défense.
4.1.1.1 Conditions d'emploi.
Toute information manipulée au sein des réseaux locaux ainsi qu'à l'interconnexion est au maximum du niveau secret défense, y compris pour les agrégats (5).
En attendant l'utilisation d'un système de signature ou de marquage fiable, l'information est marquée (Il peut s'agir dans un premier temps d'écrire secret défense sur les documents).
Toute personne manipulant des informations secret défense doit avoir reçu l'habilitation correspondant à ce niveau mais tout le monde n'a pas le même besoin d'en connaître, d'en modifier et d'en disposer.
Pour le (ou les) administrateur(s) de l'interconnexion, une habilitation au niveau SECRET DÉFENSE est requise.
Un système d'imputabilité des échanges et des actions (traçabilité) existe au préalable dans chacun des réseaux locaux.
Les réseaux locaux sont notamment protégés par des logiciels anti-virus.
De plus, une zone de transit entre les deux réseaux permettra de contrôler et de journaliser les échanges.
4.1.1.2 Support d'interconnexion.
L'interconnexion pourra se réaliser dans les cas suivants :
liaisons ou réseaux homologués secret défense ;
ligne point à point munie d'un dispositif de chiffrement agréé au niveau secret défense.
4.1.1.3 Contrôle des échanges au niveau de la zone de transit.
Les utilisateurs ayant un besoin d'échange doivent être identifiés et authentifiés auprès du réseau de destination avant toute autre action :
l'utilisateur demande une autorisation à l'émetteur (propriétaire du document) ;
l'émetteur fournit une autorisation explicite ;
le système de transit doit journaliser le transfert (source, destination, etc.) ;
le réseau destinataire dispose d'un système de non répudiation.
Lors des besoins d'échange, les exigences minimales suivantes devront être remplies :
un filtrage du couple d'adresses MAC/IP existera au sein de la zone de transit ;
une analyse sémantique des protocoles et des applications utilisés existera au sein de la zone de transit ;
les échanges seront journalisés.
En l'absence de justification opérationnelle avérée, les deux réseaux ne seront pas interconnectés de manière permanente.
4.1.2 Confidentiel défense - confidentiel défense.
4.1.2.1 Conditions d'emploi.
Toute information manipulée au sein des réseaux locaux ainsi qu'à l'interconnexion est au maximum du niveau confidentiel défense, y compris par les agrégats.
En attendant l'utilisation d'un système de signature ou de marquage fiable, l'information est marquée (Il peut s'agir dans un premier temps d'écrire confidentiel défense sur les documents).
Toute personne manipulant des informations confidentiel défense doit avoir reçu l'habilitation correspondant à ce niveau mais tout le monde n'a pas le même besoin d'en connaître, d'en modifier et d'en disposer.
Pour le (ou les) administrateur(s) de l'interconnexion, une habilitation au niveau SECRET DÉFENSE est requise.
Les réseaux locaux sont protégés par des logiciels anti-virus.
Un système d'imputabilité des échanges et des actions (traçabilité) existe au préalable dans chacun des réseaux locaux.
En l'absence de contrôle des échanges dans les systèmes à interconnecter, la zone de transit devra permettre de contrôler et journaliser les échanges.
4.1.2.2 Support d'interconnexion.
L'interconnexion pourra se réaliser dans les cas suivants :
liaisons ou réseaux homologués confidentiel défense ;
ligne point à point munie d'un dispositif de chiffrement agréé au niveau confidentiel défense.
4.1.2.3 Contrôle des échanges au niveau de la zone de transit.
Les utilisateurs ayant un besoin d'échange doivent être identifiés/ authentifiés auprès du réseau de destination avant toute autre action :
un filtrage du couple d'adresses MAC/IP existera au sein de la zone de transit ;
une analyse sémantique des protocoles et des applications utilisés existera au sein de la zone de transit ;
les échanges seront journalisés.
En l'absence de justification opérationnelle avérée, les deux réseaux ne seront pas interconnectés de manière permanente.
4.1.3 Sensible - sensible.
4.1.3.1 Conditions d'emploi.
Toute information manipulée au sein des réseaux locaux ainsi qu'à l'interconnexion est au maximum sensible et jugée non publique.
Un système d'imputabilité des échanges et des actions doit exister au sein de la zone de transit.
Les réseaux locaux sont protégés par des logiciels anti-virus.
Pour le (ou les) administrateur(s) de l'interconnexion, une habilitation au niveau CONFIDENTIEL DÉFENSE est requise.
En l'absence de contrôle des échanges dans les systèmes à interconnecter, la zone de transit devrait permettre de contrôler et journaliser les échanges.
4.1.3.2 Support d'interconnexion.
L'interconnexion pourra se réaliser dans les cas suivants :
si le support d'interconnexion est non public, des moyens de chiffrement adaptés sont recommandés en vue de préserver l'intégrité des informations échangées ;
si le support d'interconnexion est public, des moyens de chiffrement adaptés sont obligatoires en vue de préserver l'intégrité des informations échangées.
4.1.3.3 Contrôle des échanges au niveau de la zone de transit.
Les utilisateurs ayant un besoin d'échange doivent être identifiés/ authentifiés auprès du réseau de destination avant toute autre action :
un filtrage du couple d'adresses MAC/IP existera au sein de la zone de transit ;
une analyse sémantique des protocoles et des applications utilisés existera au sein de la zone de transit ;
les échanges seront journalisés.
4.2 Interconnexions entre systèmes traitant d'informations de niveau de sensibilité différentes.
L'état de l'art actuel en matière de SSI en France ne permet pas de réaliser techniquement de connexion bi-directionnelle (du point de vue fonctionnel) entre systèmes d'informations traitant d'informations de niveau de sensibilité différentes.
Seules des mesures organisationnelles permettent de s'affranchir des difficultés concernant le marquage de l'information (et son contrôle).
C'est pourquoi un principe est proposé ci-dessous afin d'assurer le transfert sélectif d'informations du monde de plus grande sensibilité vers le monde de sensibilité inférieure.
L'autorité qualifiée du système d'information du monde « haut » devra s'assurer de la mise en place de procédures « manuelles » d'extraction de l'information (i.e. sous le contrôle d'un opérateur humain, dont le rôle sera de valider que l'information sélectionnée est de sensibilité compatible avec celle du monde « bas »).
Elle devra également s'assurer que cet extrait d'informations de sensibilité au plus égale à celle du monde « bas » est placé (en dehors de toute connexion directe du monde « haut » vers le monde « bas ») au sein de la passerelle d'interconnexion (par exemple via des supports amovibles). Cet extrait d'information pourra alors être accédé par les utilisateurs du monde « bas » dûment autorisés.
Pour ce qui concerne les transferts du monde « bas » vers le monde « haut », un mode « diode » est mis en place avec les contrôles nécessaires. Ce mode diode peut être réalisé soit manuellement (transfert d'informations via un support amovible) soit automatiquement dans les conditions prévues par le premier alinéa du présent point 4.2 et de l'avertissement (en utilisant par exemple un produit agréé dans les conditions ci-dessus permettant ce type de fonctionnement).
La liste des utilisateurs et des serveurs autorisés à demander le transfert d'informations de sensibilité basse du réseau de niveau haut vers le réseau de niveau bas sera clairement identifiée.
Les autorités qualifiées rédigeront les conditions dans lesquelles les transferts du niveau haut vers le niveau bas seront organisés. Ce transfert se fera dans la mesure du possible via un point d'accès unique.
Le schéma ci-après résume les principes énoncés précédemment.
Figure 3.
 |
4.2.1 Secret défense - confidentiel défense.
4.2.1.1 Conditions d'emploi.
Toute information traitée au niveau de la zone de transit est du niveau maximum confidentiel défense.
Les utilisateurs de chacun des réseaux sont habilités au niveau des informations qu'ils manipulent.
Pour le (ou les) administrateur(s) de l'interconnexion, une habilitation au niveau SECRET DÉFENSE est requise.
Un système d'imputabilité des échanges et des actions existe au préalable dans chacun des réseaux locaux.
En l'absence actuelle d'un procédé de marquage électronique d'un document afin d'indiquer son niveau de classification, aucune information ne pourra transiter automatiquement du réseau SD vers le réseau CD.
Les informations venant du réseau confidentiel défense doivent passer par une zone de transit avant d'entrer dans le réseau secret défense.
Les services autorisés au niveau de la zone de transit doivent être préalablement identifiés. On utilisera des services de procuration (proxy) afin de relayer les échanges. Ces services seront hébergés sur un pare-feu.
Pour chaque service de procuration, on doit pouvoir définir des règles d'accès fondées sur la source, la destination, la durée, une fenêtre de temps ou toute combinaison de ces paramètres.
Toute solution doit être configurée en partant du principe que « tout ce qui n'est pas expressément autorisé est interdit ».
4.2.1.2 Support d'interconnexion.
L'interconnexion entre un réseau SD et un réseau CD pourra se réaliser dans les cas suivants :
liaison ou réseau homologué CONFIDENTIEL DÉFENSE ;
ligne point à point muni d'un dispositif de chiffrement agréé au niveau CONFIDENTIEL DÉFENSE.
4.2.1.3 Contrôle des échanges au niveau de la zone de transit.
Les utilisateurs ayant un besoin d'échange doivent être identifiés/ authentifiés auprès du réseau de destination avant toute autre action.
Toutes les informations venant du réseau confidentiel défense doivent être contrôlées et filtrées au minimum :
par des antivirus ;
par des relais applicatifs.
L'administration du pare-feu sera de préférence réalisée uniquement à partir des consoles locales. Si une administration à distance est préférable pour des raisons opérationnelles, celle-ci devra être protégée par un canal protégé et si possible dédié. Un dispositif d'authentification forte (par exemple mots de passe à usage unique) est requis.
La politique de sécurité du segment d'interface est imposée par la (ou les) autorités du (des) réseau(x) et sa mise en œuvre et son contrôle sera réalisé par l'autorité qualifiée désignée du segment d'interface.
L'administrateur, habilité SECRET DÉFENSE, est mandaté par l'autorité d'emploi du réseau secret défense.
Les flux de service sont manipulés comme de l'information secret défense. Les flux d'administration en provenance du réseau CD sont interdits.
Un dispositif de détection d'intrusion doit être mis en œuvre ainsi qu'un ensemble d'outils permettant d'exploiter les journaux d'audit.
Un filtrage des adresses logiques existera au sein de la zone de transit.
Les échanges seront journalisés au sein de la zone de transit.
La durée de conservation des journaux sera conforme à la réglementation en vigueur.
Dès lors qu'on interconnecte un réseau à un réseau manipulant du classifié de défense, le système réalisant la zone de transit devra avoir reçu un agrément et être homologué avant toute mise en exploitation.
4.2.2 Confidentiel défense - sensible.
Ce type de raccordement ne pourra être réalisé qu'après la mise en œuvre d'une passerelle satisfaisant aux exigences de sécurité et ayant été préalablement homologuée par une commission ad'hoc suite à un audit de sécurité, conformément à l' instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 . Pour satisfaire aux exigences de sécurité, le concept, l'architecture et les composants de la passerelle devront avoir été évalués par le centre technique SSI du ministère de la défense et agréés par le service central de la certification du Premier ministre.
4.2.2.1 Conditions d'emploi.
Toute information traitée au niveau de la zone de transit est du niveau maximum sensible.
Les utilisateurs de chacun des réseaux sont habilités au niveau des informations qu'ils manipulent.
Pour le (ou les) administrateur(s) de l'interconnexion, une habilitation au niveau SECRET DÉFENSE est requise.
Un système d'imputabilité des échanges et des actions existe au préalable dans chacun des réseaux locaux.
En l'absence actuelle d'un procédé de marquage électronique d'un document afin d'indiquer son niveau de classification, aucune information ne pourra transiter automatiquement du réseau CD vers le réseau sensible.
Les informations venant du réseau sensible doivent passer par une zone de transit avant d'entrer dans le réseau confidentiel défense.
Les services autorisés au niveau de la zone de transit doivent être préalablement identifiés. On utilisera des services de procuration (proxy) afin de relayer les échanges. Ces services seront hébergés sur un pare-feu.
Pour chaque service de procuration, on doit pouvoir définir des règles d'accès basées sur la source, la destination, le temps, une fenêtre de temps ou toute combinaison de ces paramètres.
Toute solution doit être configurée en partant du principe que « tout ce qui n'est pas expressément autorisé est interdit ».
4.2.2.2 Support d'interconnexion.
Le support d'interconnexion devra être considéré comme sensible.
4.2.2.3 Contrôle des échanges au niveau de la zone de transit.
Les utilisateurs ayant un besoin d'échange doivent être identifiés/ authentifiés auprès du réseau de destination avant toute autre action.
Toutes les informations venant du réseau sensible doivent être contrôlées et filtrées au minimum :
par des antivirus ;
par des relais applicatifs.
L'administration du pare-feu sera de préférence réalisée uniquement à partir des consoles locales Si une administration à distance est préférable pour des raisons opérationnelles, celle-ci devra être protégée par un canal protégé et si possible dédié. Un dispositif d'authentification forte (par exemple mots de passe à usage unique) est requis.
La politique de sécurité du segment d'interface est imposée par la (ou les) autorités du (des) réseau(x) et sa mise en œuvre et son contrôle sera réalisé par l'autorité qualifiée désignée du segment d'interface.
L'administrateur, habilité SECRET DÉFENSE, est mandaté par l'autorité d'emploi du réseau confidentiel défense.
Les flux de service sont manipulés comme de l'information CONFIDENTIEL DÉFENSE. Les flux d'administration en provenance du réseau sensible sont interdits.
Un dispositif de détection d'intrusion doit être mis en œuvre ainsi qu'un ensemble d'outils permettant d'exploiter les journaux d'audit.
Un filtrage des adresses logiques existera au sein de la zone de transit.
Les échanges seront journalisés au sein de la zone de transit.
La durée de conservation des journaux sera conforme à la réglementation en vigueur.
Dès lors qu'on interconnecte un réseau à un réseau manipulant du classifié de défense, le système réalisant la zone de transit devra avoir reçu un agrément et être homologué avant toute mise en exploitation.
4.2.3 Sensible - public.
Ce type de raccordement ne pourra être réalisé qu'après la mise en œuvre d'une passerelle satisfaisant aux exigences de sécurité et ayant été préalablement homologuée par une commission ad hoc suite à un audit de sécurité, conformément à l' instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 . Pour satisfaire aux exigences de sécurité, le concept, l'architecture et les composants de la passerelle devront avoir été évalués par le centre technique SSI du ministère de la Défense et cautionnés par le service central de la certification du Premier Ministre.
4.2.3.1 Conditions d'emploi.
Une zone de transit permet de contrôler les échanges entre les deux réseaux. Toute information traitée au niveau de la zone de transit est publique.
La zone de transit devrait être dotée de dispositifs permettant une analyse sémantique des informations sortant du réseau sensible.
Aucune information sensible issue du réseau sensible n'est autorisée à passer dans le réseau public sans que des précautions particulières aient été prises (chiffrement logiciel par exemple). Les informations non sensibles issues du réseau sensible sont autorisées à passer dans le réseau public.
Pour le (ou les) administrateur(s) de l'interconnexion, une habilitation au niveau CONFIDENTIEL DÉFENSE est requise.
Les services autorisés au niveau de la zone de transit doivent être préalablement identifiés. On utilisera des services de procuration (proxy) afin de relayer les échanges. Ces services seront hébergés sur un pare feu.
Pour chaque service de procuration, on doit pouvoir définir des règles d'accès basées sur la source, la destination, la durée, une fenêtre de temps ou toute combinaison de ces paramètres.
Toute solution doit être configurée en partant du principe que « tout ce qui n'est pas expressément autorisé est interdit ».
4.2.3.2 Contrôle des échanges au niveau de la zone de transit.
Les utilisateurs du réseau sensible ayant un besoin d'échange doivent être identifiés/ authentifiés auprès de la zone de transit.
Toutes les informations venant du réseau public doivent être contrôlées et filtrées au minimum :
par des antivirus ;
par des relais applicatifs.
L'administration du pare-feu sera de préférence réalisée uniquement à partir des consoles locales. Si une administration à distance est préférable pour des raisons opérationnelles, celle-ci devrait être protégée par un dispositif d'authentification forte (au minimum mots de passe à usage unique).
Le système d'interconnexion (ou zone de transit) est sous contrôle du réseau sensible. L'administrateur est mandaté par l'autorité d'emploi du réseau sensible.
Les flux de service sont manipulés comme de l'information sensible. Les flux d'administration en provenance du réseau public sont interdits.
Un dispositif de détection d'intrusion doit être mis en œuvre ainsi qu'un ensemble d'outils permettant d'exploiter les journaux d'audit.
Les échanges seront journalisés au sein de la zone de transit.
La durée de conservation des journaux sera conforme à la réglementation en vigueur.
5 Postes distants et portables.
Les machines portables sont de plus en plus utilisées et leur niveau de performances est du même ordre que celui des machines de bureau. L'utilisation de ces équipements entraîne une augmentation sensible des risques, principalement pour les raisons suivantes :
leur faible taille (assistants informatiques personnels par exemple) accroît fortement la possibilité de perte ou de vol ;
leur capacité de stockage leur permet de transporter des volumes importants d'information ;
ils sont utilisés en dehors des lieux de travail habituels, dans un environnement non maîtrisé, sans que le contrôle de leur exploitation soit possible.
Il est donc important de définir des règles d'utilisation qui permettent de limiter ces risques.
C'est ainsi que :
chaque machine portable doit être assignée à un utilisateur unique qui sera responsable de son utilisation. Dans le cas où une machine est utilisée par plusieurs personnes, l'une d'entre elles devra être désignée pour assurer cette responsabilité ;
les machines portables, ainsi que leurs supports amovibles, doivent porter une étiquette indiquant le plus haut niveau de classification permis pour le stockage ou le traitement de l'information ;
à moins que la machine portable ne fasse partie du système homologué :
son utilisation est interdite pour le stockage ou le traitement d'informations de niveau supérieur à CONFIDENTIEL DÉFENSE ;
son introduction dans les zones réservées où sont traitées des informations supérieures à CONFIDENTIEL DÉFENSE est interdite.
l'utilisation de machines portables n'est autorisée qu'à l'intérieur d'un local assurant la protection requise pour le traitement des informations manipulées ;
la configuration du matériel doit être enregistrée et validée par l'OSSI du site sur lequel se connecte le portable ;
les machines portables utilisées pour le traitement des informations de niveau confidentiel défense ne peuvent être connectées à un réseau téléphonique qu'à la condition de disposer de moyens agréés permettant la protection de ces données (chiffrement à la volée, en ligne, etc.) ;
il existera un mécanisme d'identification et d'authentification adapté au niveau de classification de l'information manipulée ;
les machines portables doivent être équipées d'un anti-virus, mis à jour fréquemment ;
les données stockées sur le disque dur seront chiffrées à la volée ;
les données échangées seront chiffrées en fonction du niveau de classification de la machine.
Concernant le raccordement des postes distants (qui peuvent être des portables), les points critiques à régler pour permettre ce type d'accès sont les suivants :
l'identification et l'authentification du poste distant ;
l'identification et l'authentification de l'utilisateur ;
la protection des informations échangées.
Nota.
A la date de rédaction de ce guide, il n'existe pas de solution logicielle ayant reçu une caution pour protéger un portable sensible.
6 Connexions multinationales.
6.1 Programmes en coopération.
Le degré de maîtrise sur les utilisateurs distants est faible voire inexistant. Ici encore, une analyse de la politique de sécurité du site distant est indispensable avant toute connexion.
L'isolement physique entre le réseau utilisé pour le programme en coopération et le ou les réseaux du ministère est obligatoire.
6.2 Connexions à l'organisation du traité de l'Atlantique Nord.
Un réseau manipulant des informations OTAN doit être homologué à cet effet par une autorité d'homologation de la sécurité. Si les informations sont de niveau inférieur ou égal à « Diffusion restreinte OTAN », leur accès doit être contrôlé en fonction du besoin d'en connaître.
Sinon, les exigences de la section X du CM (55)15 doivent s'appliquer ainsi que le document AC/35-D/1023 (guide pour la définition des classes de fonctionnalités et des niveaux d'assurance en fonction de l'environnement). Concernant les interconnexions, on pourra aussi s'inspirer des documents AC/35-D/1022 (recommandations pour les interconnexions de systèmes) et AC/35-WP/218 (document de travail : directives concernant la mise en œuvre des pare-feu).
Pour régler de manière efficace les problèmes liés au besoin d'en connaître et à l'habilitation il est préférable de ne pas connecter directement les systèmes OTAN avec les systèmes nationaux. En effet, si tous les utilisateurs d'un réseau où sont manipulées des informations OTAN ne sont pas habilités OTAN, il devient rapidement obligatoire (dès le niveau confidentiel OTAN) d'utiliser des solutions techniques complexes (multi-niveaux).
Pour cette raison, il est préférable de cantonner les informations OTAN sur un réseau maîtrisé accessible uniquement aux utilisateurs habilités.
Nota.
Un groupe de travail OTAN dépendant du sous-comité 4 de l'AC/322 étudie actuellement la problématique de l'interconnexion d'un SIC OTAN avec ses partenaires. Les résultats de ce groupe de travail viendront alimenter ce référentiel.
6.3 Connexions internes au sein de l'Union Européenne.
Un réseau manipulant des informations UEO doit être homologué à cet effet par une autorité d'homologation de la sécurité. Si les informations sont de niveau inférieur ou égal à « UEO Diffusion restreinte », leur accès doit être contrôlé en fonction du besoin d'en connaître.
Sinon, les exigences de la section X du règlement de sécurité de l'UEO (RS 100) doivent s'appliquer ainsi que le paragraphe 6 du document RS 200 (directives provisoires de l'UEO pour la sécurité des communications). Concernant la sécurité informatique, on pourra s'inspirer des Règlements de Sécurité de l'UEO de la série RS 300.
Pour régler de manière efficace les problèmes liés au besoin d'en connaître et à l'habilitation, il est préférable de ne pas connecter directement les systèmes UEO avec les systèmes nationaux. En effet, si tous les utilisateurs d'un réseau, où sont manipulées des informations UEO ne sont pas habilités UEO, il devient rapidement obligatoire (dès le niveau confidentiel UEO) d'utiliser des solutions techniques complexes (multi-niveau).
Pour cette raison, il est préférable de cantonner les informations UEO sur un réseau réservé accessible uniquement aux utilisateurs habilités.
7 Moyens nécessaires à la mise en place des interconnexions.
7.1 Sensibilisation et formation.
Des actions de sensibilisation ou de formation doivent être mises en place au sein de chaque organisme. Ces actions doivent porter sur des sujets techniques et organisationnels, mais aussi sur les aspects juridiques notamment pour les conséquences pénales éventuelles.
7.2 Supervision des interconnexions.
La supervision des interconnexions doit permettre :
le suivi de la qualité de service des interconnexions ;
la gestion, le contrôle et l'entretien du bon fonctionnement des équipements garantissant la sécurité des interconnexions ;
l'analyse régulière des fichiers d'audit (au minimum journalière) ;
le contrôle et la modification des tables de routage et de filtrage ;
l'isolement d'un système vis-à-vis des systèmes qui lui sont connectés en cas de problème de sécurité sur ce système.
Elle s'appuie pour cela sur les mécanismes de supervision en place au niveau de chaque site ou organisme.
Les systèmes interconnectés et les différents types d'interconnexions (liaisons, serveur d'information, ...) doivent permettre en local (sur le site concerné pour le responsable sécurité de l'organisme) le déclenchement d'alarmes de sécurité sûres en cas :
de tentative d'intrusion ;
de compromission d'éléments secrets (mots de passe, clés, …) ;
d'apparition de virus ;
d'exportation illicite de données ;
de réception de logiciels exécutables ou d'éléments actifs présentant un danger pour les réseaux ou applications supportées.
Les conditions d'administration des interconnexions devront être précisées dans chaque cas et validées par l'OSSI (administration distante, authentification forte, infogérance, …).
Tous les problèmes de sécurité seront enregistrés au niveau des systèmes interconnectés et transmis à l'OSSI de l'organisation dont dépendent ces systèmes. Celui-ci tiendra sa hiérarchie informée, conformément à la réglementation en vigueur, notamment lorsqu'un incident de sécurité peut avoir un impact sur d'autres systèmes d'information.
L'OSSI prendra les mesures correctives qui s'imposent en liaison si nécessaire avec les OSSI des réseaux interconnectés.
Tous les documents relatifs à ces incidents et les actions entreprises seront archivés et seront mentionnés dans le rapport annuel SSI.
7.3 Maintien de la sécurité dans le temps.
Le maintien de la sécurité dans le temps incombe aux autorités responsables des systèmes.
Les autorités qualifiées doivent, en liaison avec les autorités responsables, faire procéder à des contrôles de sécurité portant sur des thèmes tels que :
le respect des procédures de sécurité (qualité et changements des mots de passe, tenue à jour des droits d'accès en fonction des mutations et départs de personnels, tests de sauvegardes/ restaurations, …) ;
la mise en œuvre et l'exploitation des outils de sécurité (analyse des journaux de sécurité, tenue à jour des anti-virus, …) ;
la gestion de configurations matérielle et logicielle (contrôle des périphériques et des logiciels, …) ;
le niveau et les modalités d'entretien des connaissances du personnel en charge de l'administration du segment d'interface ;
la fréquence minimum des audits et les occurrences (nouveaux services, modifications d'architecture ou de matériels, …) devant générer un nouvel audit (ou diagnostic technique seul.
Lorsqu'une modification est effectuée sur le système d'information, il est indispensable de mesurer son impact sur la sécurité. Le système sera réévalué, dès lors que l'importance des modifications le justifie, en reprenant les phases 4 et 5 de la méthode proposée dans le présent document, pour détecter les éventuelles vulnérabilités supplémentaires consécutives à ces changements.
8 Textes de sécurité des systèmes d'information pertinents pour l'interconnexion de systèmes d'information et de communications.
8.1 Code pénal.
Art 226-16. le traitement informatisé d'informations nominatives.
Le fait, y compris par négligence, de procéder ou de faire procéder à des traitements automatisés d'informations nominatives ( loi 78-17 du 06 janvier 1978 relative à l'informatique, aux fichiers et aux libertés) sans qu'aient été respectées les formalités préalables à leur mise en œuvre prévues par la loi est puni de trois ans d'emprisonnement et de 300 000F d'amendes.
Art 226-17.
Le fait de procéder ou de faire procéder à des traitements automatisés d'informations nominatives sans prendre toutes les précautions utiles pour préserver la sécurité de ces informations et notamment empêcher qu'elles ne soient déformées, endommagées ou communiquées à des tiers non autorisés est puni de cinq ans d'emprisonnement et de 2 000 000 F d'amende.
Art 323-1. L'atteinte aux systèmes de traitement automatisé de données.
Le fait d'accéder ou de se maintenir, frauduleusement, dans tout ou partie d'un système de traitement automatisé de données est puni d'un an d'emprisonnement et de 1 000 000F d'amende. Lorsqu'il en est résulté soit la suppression ou la modification de données contenues dans le système, soit une altération du fonctionnement de ce système, la peine est de deux ans d'emprisonnement et de 200 000F d'amende.
Ces dispositions s'appliquent même si les informations traitées ou le système attaqué ne font pas l'objet d'obligation de protection. Le responsable d'un système d'information peut être « poursuivi » si ses installations ont permis à la suite d'une insuffisance de protection ou de surveillance de réaliser de tels délits.
Art 410-1. L'atteinte aux intérêts fondamentaux de la nation.
Cet article concerne notamment l'indépendance de la nation, les moyens de sa défense et de sa diplomatie, la sauvegarde de sa population, les éléments essentiels de son potentiel scientifique et économique.
Il réprime notamment la divulgation à des puissances étrangères de données informatisées, la destruction ou la détérioration de systèmes de traitement informatisé de données, lorsque ces actes sont de nature à porter atteinte aux intérêts fondamentaux de la nation.
8.2 Lois.
Loi 78-17 du 06 janvier 1978 (BOC, 1979, p. 4161) modifiée relative à l'informatique, aux fichiers et aux libertés.
Une commission nationale de l'informatique et des libertés (CNIL) est instituée. Elle est chargée de veiller au respect des dispositions de la loi no 78-17, notamment en informant toutes les personnes concernées de leurs droits et obligations, en se concertant avec elles et en contrôlant les applications de l'informatique aux traitements des informations nominatives.
Les traitements automatisés d'informations nominatives doivent, préalablement à leur mise en œuvre, faire l'objet d'une déclaration auprès de la CNIL.
Loi no 96-659 du 26 juillet 1996 (JO du 27, p. 11384) sur la réglementation des télécommunications
Les fonctions d'authentification et de contrôle d'intégrité font l'objet d'un usage libre alors que les fonctions de confidentialité sont soumises à un usage réglementé.
Cette loi est accompagnée de nombreux décrets, dont deux sont relatifs à l'utilisation de la cryptographie :
décret 99-199 du 17 mars 1999 (BOC, 2000, p. 15) définissant les catégories de moyens et de prestation de cryptologie pour lesquelles la procédure de déclaration préalable est substituée à celle d'autorisation ;
décret 99-200 du 17 mars 1999 (BOC, 2000, p. 17) définissant les catégories de moyens et de prestations de cryptologie dispensées de toutes formalité préalable.
Une loi sur la société de l'information (LSI) sera déposée au parlement début 2001, elle comporte un volet sur la cryptologie qui abrogera l'article 28 de la loi 90-1170 du 29 décembre 1990 . Le projet est consultable sur Internet.
Loi no 2000-230 du 13 mars 2000 (JO du 14, p. 3968) portant adaptation du droit de la preuve aux technologies de l'information et relative à la signature électronique
Décret 98-608 du 17 juillet 1998 (BOC, p. 2709) relatif à la protection des secrets de la défense nationale.
Décret no 2001-272 du 30 mars 2001 (JO du 31, p. 5070) pris pour application de l'article 1316-4 du droit civil.
8.3 Instructions.
No 1300/SGDN/SSD/DR du 13 mars 1982 (n.i. BO).
Les informations classifiées de défense nationale qui ont fait l'objet de mesures de protection destinées à en restreindre la diffusion ne doivent pas être communiquées au public ni à une personne non qualifiée.
La destruction, le vol ou la reproduction non autorisée de telles informations est également répréhensible. Ces faits sont également punissables lorsqu'ils sont la conséquence d'une négligence ou d'une imprudence.
No 900/SGDN/SSD/DR du 20 juillet 1993 (n.i. BO) sur la sécurité des systèmes d'information qui font l'objet d'une classification de défense pour eux-mêmes ou pour les informations traitées.
Cette instruction définit la sécurité des systèmes d'information en matière de confidentialité, disponibilité, intégrité. Institue une voie fonctionnelle SSI. Lorsque les mesures générales et particulières de sécurité déjà prises ne permettent pas d'assurer à des informations classifiées de défense traitées par un système informatique une protection correspondant à leur niveau de classification, il convient en outre de les protéger, soit à l'aide de moyens de sécurité informatique agréés, soit en ayant recours à des produits informatiques agréés. Les objectifs de sécurité doivent figurer dans la FEROS (fiche d'expression rationnelle des objectifs de sécurité).
Les autorités hiérarchiques sont personnellement responsables de l'application des mesures destinées à assurer la sécurité des systèmes d'information.
No 4600 sur la sécurité des points et réseaux sensibles.
Cette instruction définit comment doivent être mises en place les mesures propres à assurer la continuité de l'exercice du pouvoir, le maintien de la capacité de résistance à toute agression, la vie du pays et de sa population. Permet d'assurer la capacité opérationnelle des réseaux sensibles. Le volet vulnérabilité cybernétique de ces points et réseaux sensibles est en cours d'investigation
No 486/SGDN/STS/TSE/CUS/DR du 1er mars 1993 (n.i. BO) sur la protection du patrimoine scientifique et technique français dans les échanges internationaux.
Cette instruction limite la diffusion du patrimoine scientifique et technique national en fonction des impératifs de la défense tout en maintenant une coopération de bon niveau.
Instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 sur la mise en œuvre de la SSI au sein du ministère de la défense.
Cette instruction fixe les modalités de mise en œuvre de la SSI et sa prise en compte dans le cycle de vie des systèmes d'information du ministère de la défense dès lors qu'ils relèvent des champs d'application de l'instruction no 900/SGDN/SSD/DIR du 20 juillet 1993 (n.i. BO) ou de la recommandation 901/DISSI/SCSSI du 2 mars 1994 (n.i. BO).
Les paragraphes 4.3.2 et 4.3.3 traitent respectivement de l'interconnexion de systèmes internes du ministère et de l'interconnexion avec des systèmes extérieurs au ministère.
Instruction 11258 du 21 mars 2000 (BOC, p. 3497) relative à la délimitation des domaines secret défense et confidentiel défense.
8.4 Recommandations, guides.
Recommandation no 901/DISSI/SCSSI du 2 mars 1994 pour la protection des systèmes d'information traitant des informations sensibles non classifiées de défense. Il est recommandé d'avoir des moyens de protection ayant reçu la caution du SCSSI. Préconise la définition d'une cible de sécurité.
Guide no 730 sur les systèmes d'information et applications sensibles.
Mise en place de mesures visant à garantir la continuité du fonctionnement et la fiabilité de tels systèmes.
9 Menaces génériques.
9.1 Liste proposée dans l'expression des besoins et identification des objectifs de sécurité.
Écoute passive.
Intentionnel.
L'écoute consiste à se placer sur le réseau, à analyser et à sauvegarder les informations qui circulent. De nombreux appareils du commerce facilitent les analyses et permettent d'interpréter en temps réel les trames quels que soient les protocoles de communication.
L'attaquant va essayer de récupérer un signal électromagnétique et de l'interpréter pour en déduire des informations compréhensibles. L'interception peut porter sur des signaux hyperfréquences ou hertziens, émis, rayonnés ou conduits. L'agresseur se mettra à la recherche des émissions satellites, radio, mais aussi des signaux parasites émis par les systèmes informatiques (terminaux, câbles, éléments conducteurs,...).
Atteinte.
Confidentialité.
Saturation du matériel.
Accidentel.
Engorgement, dépassement des capacités de stockage, de calcul, de requêtes…
Intentionnel.
Parasitage intense et continu de la ressource.
Atteinte.
Disponibilité.
Informations sans garantie de l'origine.
Accidentel/Intentionnel.
Le système d'information peut faire appel à des informations issues de sources extérieures à l'organisme ; ces informations peuvent être des faux ou des contrefaçons, soit pour désinformer le récepteur et porter atteinte à la fiabilité du système ou à la validité de ses informations.
Atteinte.
Intégrité et disponibilité.
Utilisation illicite de matériels.
Intentionnel.
L'attaquant bénéficiera à son profit des services rendus par le système de manière illicite.
Connexion frauduleuse.
Il s'agit d'un accès non autorisé qui correspond au vol des données d'identification/authentification d'une personne afin de s'en arroger les droits ou en contournant les contrôles d'accès (porte dérobée).
Atteinte.
Confidentialité, intégrité et disponibilité.
Violation du niveau de sécurité.
Cette menace concerne uniquement les systèmes sur lesquels sont appliquées plusieurs politiques de sécurité de niveaux différents. Elle consiste en une violation du niveau de sécurité afin d'accéder à des informations par le biais d'une autre politique de sécurité moins sévère.
Une trappe, point d'entrée dans une application généralement placé par un développeur pour faciliter la mise au point des programmes, peut être utilisée pour contourner les mesures de sécurité.
Les mesures de sécurité peuvent également être contournées en exploitant le fonctionnement asynchrone de parties ou de commandes de système (modification des informations sur l'état du système).
Atteinte.
Confidentialité, intégrité et disponibilité.
Fouille.
La fouille informatique consiste à étudier méthodiquement l'ensemble des fichiers et des variables d'un système d'information pour en retirer des données de valeur.
Les sauvegardes de contexte (points de reprise en cas d'incident) contiennent des informations de l'état du système qui peuvent être consultées par un attaquant averti.
Atteinte.
Confidentialité.
Mystification.
Dans ce cas l'attaquant va simuler le comportement d'une machine pour tromper un utilisateur légitime et s'emparer de son nom et de son mot de passe.
Atteinte.
Confidentialité, intégrité et disponibilité.
Porte dérobée.
Une trappe est un point d'entrée dans une application généralement placé par un développeur pour faciliter la mise au point des programmes ; il peut être utilisé pour contourner les mesures de sécurité.
Atteinte.
Confidentialité, intégrité, disponibilité.
Altération du logiciel.
Intentionnel.
Il s'agit de toute action effectuée avec des moyens logiciels pour altérer, détruire les programmes ou porter atteinte au bon fonctionnement de la ressource. On peut citer par exemple :
Bombe logique : une bombe est un programme en attente d'un événement spécifique déterminé par le programmeur pour faciliter la mise au point des programmes (ex. : date).
Atteinte.
Intégrité et disponibilité.
Virus : c'est un programme à effet malicieux capable de se reproduire et qui comporte des fonctions nuisibles pour le système d'information ; on parle d'infection. Le virus dispose de fonctions qui lui permettent de tester s'il a déjà contaminé un programme, de se propager en se recopiant sur un programme et de se déclencher comme une bombe logique quand un événement se produit.
Atteinte.
Intégrité et disponibilité.
Ver : un ver est un programme à effet malicieux qui a la faculté de se déplacer à travers un réseau qu'il peut chercher à perturber en le rendant indisponible.
Atteinte.
Intégrité et disponibilité.
Piégeage du logiciel.
Intentionnel.
L'agresseur tentera d'introduire des fonctions cachées, en principe en phase de conception, de fabrication, de transport ou de maintenance, dans le système d'information. Seule une évaluation de la sécurité du système donnera au défenseur une certaine assurance. La non-vérification des matériels et des logiciels peut faciliter le piégeage ou l'introduction de virus dans les systèmes informatiques. De même, un manque de test de sécurité sur les services du réseau peut entraîner une violation de la sécurité. On peut citer par exemple :
Cheval de Troie : programme qui contient des fonctionnalités supplémentaires de manière à entraver la politique de sécurité en simulant une action et en réalisant une autre.
Atteinte.
Confidentialité et intégrité.
Canal caché : c'est une attaque de très haut niveau. Il permet de la fuite d'informations en violant la politique de sécurité. Knode les classe en quatre catégories :
les canaux de stockage qui permettent de transférer de l'information par le biais d'objets écrits en toute légalité par un processus et lus en toute légalité par un autre ;
les canaux temporels qui permettent à un processus d'envoyer un message à un autre en modulant l'utilisation des ressources système afin que les variations des temps de réponse puissent être observées ;
les canaux de raisonnement qui permettent à un processus de déduire de l'information à laquelle il n'a pas normalement accès ;
les canaux dits de « fabrication » qui permettent de créer de l'information en formant des agrégats qui ne peuvent être obtenus directement.
Atteinte.
Confidentialité et intégrité.
Altération des données.
Interception.
L'interception est un accès avec modification des informations transmises sur les voies de communication. Les quatre types d'interception sont :
Intentionnel.
La destruction de messages.
La modification de messages (modification de l'information, ré-agencement de l'information à l'intérieur des messages ou ré-agencement de la suite des messages).
L'insertion de messages.
Refus de service (décalage dans le temps d'un message).
Atteinte.
Intégrité.
Balayage : le balayage consiste à envoyer un ensemble d'informations de natures diverses afin de déterminer celles qui suscitent une réponse positive. Cette technique est analogue à celle qui consiste à balayer une gamme de fréquences pour trouver un signal porteur (recherche de numéros d'accès à des systèmes, types de machines…).
Atteinte.
Confidentialité.
Virus, bombe logique, trappe.
Accidentel.
Se reporter à la menace « piégeage du logiciel ».
Erreurs d'utilisation.
Accidentel.
Il s'agit d'erreurs de manipulation, d'utilisation des matériels ou des dégradations de matériels ou logiciels commises de manière involontaire (contamination par virus…) par le personnel de l'organisme.
Atteinte.
Disponibilité et intégrité.
Usurpation de droits.
Mascarade (déguisement, usurpation d'identité).
Intentionnel.
Il s'agit de se faire passer pour un utilisateur habilité sur le réseau pour tenter d'y pénétrer puis pour bénéficier des droits, privilèges, services de celui dont on usurpe l'identité.
Un utilisateur est caractérisé par ce qu'il est (ex. : empreintes digitales), ce qu'il possède (ex. : carte magnétique) et ce qu'il sait (ex. : mot de passe) ; pour se faire passer pour lui, l'agresseur doit s'emparer d'un ou plusieurs éléments propres à l'utilisateur. Si le contrôle d'accès se fait par mot de passe, l'attaquant tentera de le lire quand l'utilisateur le rentrera au clavier ou quand il le transmettra par le réseau.
Remarque : le rejeu est une variante du déguisement qui permet à un attaquant de pénétrer dans un SI en envoyant une séquence de connexion effectuée par un utilisateur légitime et préalablement enregistrée à son insu.
Atteinte.
Confidentialité, intégrité et disponibilité.
Substitution.
Ce type d'attaque est réalisable sur un réseau ou sur un système d'information comportant des terminaux distants. L'agresseur écoute une ligne et intercepte la demande de déconnexion d'un utilisateur travaillant sur une machine distante. Il peut alors se substituer à ce dernier et continuer une session normale sans que le système ne note un changement d'utilisateur.
Atteinte.
Confidentialité, intégrité et disponibilité.
Reniement d'actions.
Intentionnel.
Le reniement (plus usuellement la répudiation) correspond pour une entité impliquée par exemple dans le cadre d'un échange d'informations, au fait de nier avoir participé à toute ou partie de la communication, de nier avoir reçu ou émis un message déterminé, ou au fait de prétendre avoir émis (reçu) un message (fichier) différent. Cette menace s'applique à de nombreuses actions réalisées sur les SI.
Atteinte.
Intégrité, preuve, contrôle.
9.2 Compléments sur les menaces.
L'écoute de réseau (sniffing).
Intentionnel.
Écoute du réseau local afin de récupérer des informations sur certains protocoles.
Atteinte.
Confidentialité.
L'usurpation d'adresses (spoofing).
Intentionnel.
Usurpation d'identité pour se faire passer pour une autre machine (modification adresse source des paquets envoyés). Permet de passer les contrôles d'accès basiques.
Atteinte.
Confidentialité, intégrité, disponibilité.
Le déni de service et notamment l'ICMP Echo flooding.
Intentionnel.
Bombarder une machine victime de paquets (par exemple ICMP-ECHO) afin de la surcharger. Permet à l'attaquant de faire un déni de service.
Atteinte.
Disponibilité.
L'utilisation du réseau comme réflecteur : amplificateur d'attaques (smurfing).
Intentionnel.
Utilisation d'un réseau tiers pour réaliser un déni de service. Principes identiques au flooding pour la réalisation du déni de service.
Atteinte.
Disponibilité.
La désynchronisation TCP et la tempête ACK
Intentionnel.
L'attaquant s'arrange pour arriver dans un état où deux machines qui communiquent par TCP ne peuvent plus échanger de paquets pour cause de désaccord de leurs compteurs de séquence. Quand le serveur ou le client reçoit un paquet avec un mauvais numéro de séquence, il envoie un paquet ACK à l'autre. Ce processus ne s'arrêtant pas, il y aura saturation des machines.
Atteinte.
Disponibilité.
Les fausses connexions (SYN flooding).
Intentionnel.
Réaliser des connexions à moitié ouvertes vers une machine de telle sorte que sa file d'attente soit saturée.
Atteinte.
Disponibilité.
Le routage à la source (source rooting).
Intentionnel.
Utiliser l'option source routing du paquet IP pour spécifier une route différente de celle du routeur. L'attaquant spécifie en entier la route pour accéder à la machine cible. En retour, le serveur fait passer ses paquets par la voie inverse. Le pirate reçoit alors les réponses alors qu'il ne devrait pas les avoir.
Atteinte.
Confidentialité, intégrité, disponibilité.
Il convient également de rajouter toutes les vulnérabilités liées à la dualité d'emploi des démons d'administration réseau (détournés de leur finalité initiale) tels que Telnet, rlogin, FTP, TFTP, RSH, Finger, UUCP, SMTP, NNTP, TIS et portmapper, NFS, HTTP, X11,…
10 Architectures types.
Contenu
Cette annexe tente de décrire simplement les différents composants d'architecture et des architectures types d'interconnexion. Pour plus d'informations techniques, le lecteur devra s'adresser aux spécialistes et experts en réseau et sécurité des systèmes d'information.
Les schémas de principe indiqués dans cette annexe ne préjugent pas de la redondance ou de la complémentarité des moyens que l'on pourra utiliser dans une véritable interconnexion. A ce titre, l'exemple de l'architecture prévue pour l'intranet sensible de défense est donnée à titre indicatif.
Contenu
Figure 8.
 |
10.1 Ponts.
Les ponts peuvent être utilisés pour raccorder deux segments de réseau en local ou à distance. Les ponts permettent de réaliser un filtrage des adresses, ce filtrage étant généralement dynamique. Le pont travaille souvent par auto-apprentissage, c'est à dire qu'il « apprend » de quel côté se trouvent les différentes adresses et fait passer ou non les trames en fonction de cette connaissance.
Les ponts sont donc plus utilisés pour segmenter des réseaux, plutôt que pour filtrer les échanges entre deux segments de réseaux. Ils offrent en effet des performances intéressantes, au détriment des mécanismes de sécurité qui restent de bas niveau.
10.2 Filtres de paquets.
Ces produits effectuent un filtrage sur les adresses sources et destinations, voire sur d'autres protocoles. Ils sont généralement connus sous la dénomination de routeurs. Le filtrage peut s'appliquer aux paquets entrants dans la machine, aux paquets sortants ou aux deux.
Ils sont utilisés pour relier des segments de réseau en local ou à distance.
Le routage peut être statique ou dynamique ou être fondé sur une combinaison des deux. Le routage dynamique peut être dangereux, un attaquant pouvant envoyer de faux messages de modification.
Les règles de filtrage sont sur la plupart des produits assez complexes à configurer et à tester et peuvent facilement laisser des failles de sécurité. Par ailleurs, ils restent vulnérables aux attaques liées aux falsifications d'adresses, rien ne permettant d'authentifier ces informations. Enfin, un autre de leurs inconvénients est qu'ils ne masquent pas la configuration du réseau interne.
10.3 Pare-feu.
Le terme pare-feu recouvre une grande diversité de systèmes. On peut en effet, appeler ainsi tout système qui permet d'appliquer la politique de sécurité d'interconnexion. Pour cette raison, un filtre de paquets tel qu'il a été présenté, ci-avant peut recevoir la dénomination de pare-feu. Pour éviter toute confusion, nous ne retiendrons pas les simples filtres de paquets dans la catégorie pare-feu.
Un pare-feu est constitué d'un ou de plusieurs éléments parmi :
des filtres de paquets ;
des passerelles applicatives ;
des serveurs d'applications.
Une passerelle applicative offre des services qui filtrent et transmettent les communications pour des services tels que le courrier, le transfert de fichiers,… Seuls les services qui possèdent un service de procuration sur la passerelle sont autorisés et tous les autres sont bloqués.
Un serveur d'applications héberge les services que l'on souhaite offrir vers l'extérieur. On peut y trouver un serveur oueb consultable depuis un réseau externe, un serveur de messagerie qui reçoit tous les messages entrants ou sortants, …
Plusieurs combinaisons de ces éléments sont possibles, nous allons en présenter trois.
10.3.1 Passerelle à liaison double.
La passerelle à liaison double possède deux interfaces réseau, une connectée vers le réseau externe, l'autre vers le réseau interne.
Figure 4.
 |
Tout le trafic est filtré par la passerelle applicative. Cette méthode permet de cacher la structure du réseau interne.
Elle présente en revanche les inconvénients suivants :
la passerelle constitue un goulet d'étranglement et un point de passage obligé ce qui peut poser des problèmes de fiabilité ;
elle ne supporte que les applications pour lesquelles existent des services de procuration.
10.3.2 Passerelle avec filtre.
Dans cette configuration on utilise un routeur et une passerelle. Le routeur transmet tout le trafic reçu de l'extérieur vers la passerelle. De même, le routeur ne transmet vers l'extérieur que le trafic en provenance de la passerelle.
Figure 5.
 |
Cette solution est plus performante que la précédente et offre plus de souplesse puisqu'il est possible d'autoriser des flux directs entre l'extérieur et certains systèmes pour des applications choisies.
Elle est en revanche moins sûre que la précédente et peut être plus complexe à mettre en œuvre.
10.3.3 Pare-feu sous réseau.
Il s'agit de l'architecture la plus complexe, qui peut être utilisée pour une protection forte.
Figure 6.
 |
Le filtre de paquets connecté au réseau externe accepte le trafic en provenance ou à destination de la passerelle applicative ou du serveur DMZ (De-Militarized Zone) et refuse tout le reste.
Le filtre de paquets connecté au réseau interne accepte le trafic provenant ou à destination de la passerelle applicative ou du serveur DMZ et refuse tout le reste.
On empêche ainsi toute liaison directe entre le réseau interne et le réseau externe. Le réseau interne est ainsi complètement masqué depuis l'extérieur.
10.4 Connexion de postes distants et des portables.
La connexion de postes par l'intermédiaire de liaisons spécialisées (raccordements permanents) ne sera pas étudiée dans ce paragraphe. Ce cas de raccordement est en effet équivalent au raccordement de deux réseaux.
On se limitera donc au raccordement de postes distants par des connexions établies à la demande c'est à dire par le réseau téléphonique commuté (RTC).
On prendra comme hypothèse que les utilisateurs distants font partie du même organisme que celui qui gère le réseau sur lequel on souhaite les raccorder. Pour les autres cas, une fois l'accès distant réalisé dans son organisme, l'opération se ramène à un raccordement de réseaux locaux.
Les points critiques à régler pour permettre ce type d'accès sont les suivants :
l'identification et l'authentification du poste distant ;
la protection des informations échangées.
L'architecture technique à mettre en place est la suivante : conforme au sensible-public.
Figure 7.
 |
Le serveur d'accès distant assure :
la conversion de protocole entre l'accès réseau commuté et l'accès ;
l'identification et l'authentification de l'utilisateur distant.
Il peut être constitué d'un équipement autonome spécialisé à cet effet ou éventuellement d'un serveur qui assure cette fonction.
De plus, si les informations sont classifiées, un dispositif de chiffrement agréé doit être utilisé.
Pour éviter le rejeu des échanges d'identification/ authentification, ceux-ci doivent être uniques. Il faut donc s'appuyer sur des mécanismes de type mots de passe unique (calculettes par exemple) ou des mécanismes cryptographiques (cartes de sécurité par exemple).
L'utilisation de serveurs d'accès distants sur un réseau CD doit s'envisager en prenant un maximum de précautions.
Il semble préférable, pour réduire les risques, d'utiliser des équipements réservés, dont le système d'exploitation est maîtrisé. Une telle installation doit être validée par des tests de vulnérabilités pour déterminer et valider les paramètres de configuration.
Le tableau ci-dessous indique les exigences minimales en terme d'identification/authentification et de chiffrement en fonction de la classification des informations susceptibles de transiter lors de la connexion de postes distants.
| Identification/authentification. | Chiffrement. | |
|---|---|---|
| Public - sensible. | Ressource logique. | Obligatoire pour le sensible (par logiciel au minimum). |
| Confidentiel défense. | Pas de dispositif agréé, authentification implicite par les dispositifs de chiffrement. | Obligatoire. |
| Secret défense. | Le raccordement de postes distants est interdit. | |
Appendice GLOSSAIRE.
- ATM
Asynchronous transfert mode.
- DMZ
Demilitarized zone.
- FTP
File transfer protocol.
- HDLC
High level data link control.
- ICMP
Internet control message protocol.
- MAC
Media access control.
- PPP
Point to point protocol.
- RIP
Routing internet protocol.
- RNIS
Réseau numérique à intégration de service.
- RTC
Réseau téléphonique commuté.
- SMTP
Simple mail transfer protocol.
- TCP/UDP
Transfert control protocol/user data protocol.
ANNEXE IV. Cadre réglementaire de la sécurité des systèmes d'information.
1 Textes législatifs.
Nouveau code pénal, plus particulièrement les articles relatifs à la protection du secret de défense : trahison et espionnage, articles 411-1 à 411-9 ;
Loi 78-17 du 06 janvier 1978 (BOC, 1979, p. 6161) relative à l'informatique, aux fichiers et aux libertés.
Loi 92-597 du 01 juillet 1992 (BOC, p. 2997) relative à la propriété intellectuelle.
Loi du 22 juillet 1992 relative à la fraude informatique (n.i. BO).
Arrêté du 18 février 1986 (BOC, p. 1365), décrets no 92-1358 du 28 décembre 1992 (n.i. BO, JO du 30, p. 17914), no 98-206 du 23 mars 1998 (n.i. BO, JO du 25, p. 4448), no 98-207 du 23 mars 1998 (n.i. BO, JO du 25, p. 4449) relatifs aux moyens de cryptologie et loi de 1996 sur les télécoms.
2 Textes réglementaires interministériels.
Instruction no 1300/SGDN/SSD du 12 mars 1982 (n.i. BO) relative à la protection du secret de défense spécifie les mesures liées :
à l'organisation et le fonctionnement des services de sécurité de défense ;
à la protection des personnes ;
à la protection des informations classifiées ;
à la protection du patrimoine national et des informations qui doivent rester diffusion restreinte ;
à la sensibilisation aux risques de compromission d'informations classifiées de défense ;
aux contrôles et inspections.
Instruction no 900/SGDN/SSD/DR du 20 juillet 1993 (n.i. BO) (no 900/DISSI/SCSSI/DR) relative à la sécurité des systèmes d'information traitant des informations faisant l'objet d'une classification de défense.
Recommandation no 901/DISSI/SCSSI du 2 mars 1994 (n.i. BO) relative à la sécurité des systèmes d'information traitant des informations sensibles non classifiées de défense.
Instruction no 910/SGDN/SSD du 19 décembre 1994 (n.i. BO) (no 910/DISSI/SCSSI) et directive no 911/DISSI/SCSSI du 20 juin 1995 (n.i. BO) relatives à l'organisation et à la gestion des articles contrôlés de la SSI (ACSSI).
Fascicule no 650/DISSI. /SCSSI du 28 mars 1994 (n.i. BO) concernant la menace et les attaques informatiques.
Directive no 515/SGDN/SSD/DR du 30 juin 1983 (n.i. BO) relative à la protection du secret de défense en bureautique.
Instruction no 2000/SGDN/SSD/DR du 1er octobre 1986 (n.i. BO) relative aux dispositions à prendre pour la protection du secret et des informations concernant la défense nationale et la sûreté de l'État dans les marchés ainsi que dans tous les autres contrats administratifs qui entraînent la mise en œuvre de systèmes d'information faisant l'objet d'une classification de défense pour eux-mêmes ou pour les informations traitées. Elle aborde, en particulier, les dispositions à prendre vis à vis des personnes, des documents et des matériels.
Instruction no 50/SGDN/SD du 9 janvier 1971 (n.i. BO) relative aux dispositions générales et aux protocoles de sécurité à établir dans le cadre d'études et de rapport entre la France et les pays étrangers.
Instruction no 486/SGDN/STS/TSE/CVS/DR du 1er mars 1993 (n.i. BO) relative à la protection du patrimoine scientifique et technique français dans les échanges internationaux.
Instruction no 300/SGDN/TTS/SSI du 21 juin 1997 (n.i. BO) relative aux rayonnements compromettants et aux règles techniques de sécurité des matériels de transmission.
Guide no 480/SGDN/DISSI/SCSSI du 15 mai 1990 (n.i. BO), relatif à la protection contre les signaux parasites compromettants.
Directive no 485/SGDN/DISSI/SCSSI du 15 décembre 1988 (n.i. BO), relative à l'installation des sites et des systèmes informatiques : protection contre les signaux compromettants.
Directive no 495/SGDN/TTS/SSI du 19 septembre 1997 (n.i. BO), relative au zonage TEMPEST.
Répertoire no 490/SGDN/DISSI/SCSSI/DR du 15 décembre 1987 (n.i. BO), relatif aux matériels évalués au plan de la protection contre l'émission de signaux compromettants.
Schéma français d'évaluation et de certification de la sécurité des technologies de l'information : ECF 01 Version 2 du 16 janvier 1997 (Présentation du schéma) et ECF 03 version 1 du 16 janvier 1997 (procédures d'évaluation et de certification).
3 Textes réglementaires spécifiques au ministère de la défense.
Instruction 4418 /DEF/SEC/DIR/SIC du 25 septembre 2000 (BOC, p. 4343) relative à l'organisation de la SSI.
Instruction 8192 /DEF/CAB/CM/3 du 24 février 1997 (BOC, p. 1374) relative aux modalités d'accès et de à l'utilisation du réseau Internet au sein du ministère de la défense.
Instruction no 2500/DEF/C23 du 26 janvier 1983 (n.i. BO) relative à la protection du secret dans les marchés et autres contrats passés par les organismes relevant du ministère de la défense.
Instruction no 2550/DEF/C23 du 11 août 1983 (n.i. BO) relative à la protection des informations dans les entreprises.
Instruction no 2551/DEF/C23 du 20 décembre 1984 (n.i. BO) relative à la mise en œuvre des mesures applicables aux traitements.
Instruction no 2600/SGDN/AC/GL/DR du 26 septembre 1977 (n.i. BO) relative à la protection des points sensibles.
Catalogue no 1200/DEF/CAB/C23 (n.i. BO) relatif aux sociétés habitées pour les marchés de défense.