Sélection de la langue

Government of Canada / Gouvernement du Canada

Acquisition des systèmes et des services

Précédent

Sur cette page

 

Les contrôles et les activités associés à la famille de l’acquisition des systèmes et des services (SA pour System and Services Acquisition) s’appliquent à la passation de marchés pour l’acquisition des produits et des services nécessaires afin de soutenir la mise en œuvre et l’exploitation des systèmes organisationnels. Ils permettent de s’assurer que des ressources suffisantes sont affectées pour assurer une protection adéquate des systèmes organisationnels et ils appuient les processus relatifs au cycle de développement des systèmes qui intègrent des considérations de sécurité.

SA-01 Politique et procédures d’acquisition des systèmes et des services

Activité

  1. Développer, documenter et diffuser à [Affectation : personnel ou rôles définis par l’organisation]
    1. une politique d’acquisition des systèmes et des services [Sélection (un choix ou plus) : au niveau organisationnel; au niveau du processus lié à une mission ou à une activité; au niveau du système] qui
      1. définit l’objectif, la portée, les rôles, les responsabilités, l’engagement de la direction, la coordination entre les entités organisationnelles et la conformité
      2. est conforme aux lois, aux décrets, aux directives, à la réglementation, aux politiques, aux normes et aux lignes directrices applicables
    2. des procédures pour faciliter la mise en œuvre de la politique d’acquisition des systèmes et des services ainsi que des contrôles connexes
  2. Désigner une ou un [Affectation : responsable désigné par l’organisation] pour gérer l’élaboration, la documentation et la diffusion de la politique et des procédures d’acquisition des systèmes et des services
  3. Passer en revue et mettre à jour, par rapport à l’acquisition des systèmes et des services,
    1. la politique actuelle [Affectation : fréquence définie par l’organisation] ou à la suite de [Affectation : événements définis par l’organisation]
    2. les procédures [Affectation : fréquence définie par l’organisation] ou à la suite de [Affectation : événements définis par l’organisation]

Discussion

La politique et les procédures d’acquisition des systèmes et des services abordent les contrôles de la famille SA qui ont été mis en œuvre dans les systèmes et les organisations. La politique de gestion des risques est un facteur important dans l’établissement de telles politiques et procédures. Les politiques et les procédures contribuent à l’assurance de la sécurité et de la protection de la vie privée. Par conséquent, il est important que les programmes de sécurité et de protection de la vie privée collaborent à l’élaboration de la politique et des procédures d’acquisition des systèmes et des services.

En règle générale, les politiques et les procédures liées au programme de sécurité et de protection de la vie privée au niveau organisationnel sont préférables et peuvent éliminer le besoin pour des politiques et des procédures propres à la mission ou au système. La politique peut être intégrée à la politique générale de sécurité et de protection de la vie privée ou, inversement, elle peut être représentée par de multiples politiques tenant compte de la nature complexe de certaines organisations.

Les procédures peuvent être établies pour les programmes de sécurité et de protection de la vie privée, pour les processus liés à la mission ou aux activités, et pour les systèmes, le cas échéant. Les procédures décrivent comment les politiques ou les contrôles sont mis en œuvre et peuvent s’appliquer aux personnes ou aux rôles qui font l’objet de la procédure. Les procédures peuvent être documentées dans les plans de sécurité et de protection de la vie privée du système ou dans un ou plusieurs documents distincts.

Les événements qui peuvent précipiter une mise à jour de la politique et des procédures d’acquisition des systèmes et des services comprennent les conclusions d’une évaluation ou d’une vérification, des incidents ou violations de sécurité, et des changements apportés aux lois, aux décrets, aux directives, à la réglementation, aux politiques, aux normes et aux lignes directrices applicables. Répéter les contrôles ne constitue pas une politique ou une procédure organisationnelle.

Contrôles et activités connexes

PM-09, PS-08, SA-08, SI-02 et SI-12.

Améliorations

Aucune.

Références

Haut de la page 
 

SA-02 Affectation des ressources

Contrôle

  1. Déterminer les exigences de haut niveau en matière de sécurité et de protection de la vie privée de l’information pour le système ou les services connexes lors de la planification des processus liés à la mission et aux activités
  2. Déterminer, documenter et affecter les ressources nécessaires pour protéger le système ou les services connexes dans le cadre du processus de planification des immobilisations et de contrôle des investissements
  3. Établir un poste distinct pour la sécurité et la protection de la vie privée de l’information dans sa documentation de programmation et de budgétisation

Discussion

L’attribution des ressources pour la sécurité et la protection de la vie privée de l’information comprend le financement pour l’acquisition et le maintien des systèmes et des services, et les risques liés à la chaîne d’approvisionnement tout au long du cycle de développement des systèmes.

Contrôles et activités connexes

PL-07, PM-03, PM-11, SA-09, SR-03 et SR-05.

Améliorations

Aucune.

Références

Haut de la page 
 

SA-03 Cycle de développement des systèmes

Activité

  1. Acquérir, développer et gérer le système au moyen de [Affectation : cycle de développement des systèmes défini par l’organisation] qui comprend les facteurs à considérer en matière de sécurité et de protection de la vie privée de l’information
  2. Définir et documenter les rôles et les responsabilités en matière de sécurité et de protection de la vie privée de l’information tout au long du cycle de développement des systèmes
  3. Identifier les personnes qui assument des rôles et des responsabilités en matière de sécurité et de protection de la vie privée de l’information
  4. Intégrer le processus de gestion des risques liés à la sécurité et à la protection de la vie privée de l’information de l’organisation dans les activités du cycle de développement des systèmes

Discussion

Un processus de cycle de développement des systèmes constitue une condition essentielle à la réussite des étapes de développement, de mise en œuvre et d’exploitation des systèmes. L’intégration précoce des facteurs à considérer en matière de sécurité et de protection de la vie privée dans le cadre du cycle de développement des systèmes est un principe fondamental de l’ingénierie de la sécurité et de la protection de la vie privée des systèmes. L’application des contrôles nécessaires pendant le cycle de développement des systèmes exige une compréhension élémentaire de la sécurité et de la protection de la vie privée de l’information, des menaces, des vulnérabilités, des effets négatifs et des risques auxquels s’exposent les missions et les activités prioritaires de l’organisation.

Les principes d’ingénierie de la sécurité du contrôle SA-08 aident les personnes à concevoir, à coder et à tester adéquatement les systèmes et les services connexes. Les organisations comprennent le personnel qualifié (par exemple, une ou un cadre supérieur de la gouvernance en matière de sécurité du ministère, une ou un haut fonctionnaire ou cadre supérieur en matière de protection de la vie privée, les architectes en sécurité et en protection de la vie privée, et les ingénieures et ingénieurs en sécurité et en protection de la vie privée) qui prend part aux processus du cycle de développement des systèmes et veille à que les exigences définies en matière de sécurité et de protection de la vie privée soient intégrées dans les systèmes de l’organisation. Les programmes de formation en sécurité et en protection de la vie privée basée sur les rôles peuvent permettre aux personnes qui assument des rôles clés en matière de sécurité et de protection de la vie privée d’acquérir l’expérience, les compétences et l’expertise nécessaires à la conduite des activités constitutives du cycle de développement des systèmes.

La parfaite intégration des exigences de sécurité et de protection de la vie privée à l’architecture d’entreprise permet également d’assurer que les facteurs importants à considérer en matière de sécurité et de protection de la vie privée sont pris en compte tout au long du cycle de vie des systèmes et qu’ils sont directement liés aux processus liés à la mission et aux activités de l’organisation. Le processus facilite également l’intégration des architectures de sécurité et de protection de la vie privée de l’information à l’architecture d’entreprise, conformément aux stratégies de gestion des risques de l’organisation. Comme le cycle de développement des systèmes comprend plusieurs organisations (par exemple, des fournisseurs externes, des développeuses et développeurs, des intégratrices et intégrateurs, des fournisseurs de service), les fonctions et les contrôles de gestion des risques liés à la chaîne d’approvisionnement jouent des rôles importants dans la gestion efficace du système durant leur cycle de vie.

Contrôles et activités connexes

AT-03, PL-08, PM-07, SA-04, SA-05, SA-08, SA-11, SA-15, SA-17, SA-22, SA-400, SR-03, SR-04, SR-05 et SR-09.

Améliorations

  • (01) Cycle de développement des systèmes : Gestion de l’environnement de préproduction
    • S’assurer que la protection des environnements de préproduction est proportionnelle au risque tout au long du cycle de développement du système, du composant de système ou du service qui s’y rapporte.
    • Discussion : L’environnement de préproduction comprend les environnements de développement, de test et d’intégration. L’analyse de criticité et l’application de contrôles aux développeuses et développeurs permettent également d’offrir un environnement de développement de système plus sécurisé.
    • Contrôles et activités connexes : CM-02, CM-04, RA-03, RA-09 et SA-04.
  • (02) Cycle de développement des systèmes : Utilisation de données opérationnelles et en temps réel
      1. Approuver, documenter et contrôler l’utilisation de données en temps réel dans les environnements de préproduction pour le système, le composant de système ou le service qui s’y rapporte
      2. Protéger les environnements de préproduction pour le système, le composant de système ou le service qui s’y rapporte de manière à avoir le même niveau d’incidence ou le même niveau de classification que toute donnée en cours d’utilisation en temps réel dans les environnements de préproduction
    • Discussion : Les données en temps réel sont également appelées « données opérationnelles ». L’utilisation de données opérationnelles ou en temps réel dans les environnements de préproduction (c’est-à-dire, de développement, de test et d’intégration) peut poser des risques importants pour les organisations. De plus, l’utilisation de données en temps réel qui contiennent des renseignements personnels aux fins de test, de recherche et de formation augmente le risque de divulgation ou d’utilisation non autorisée de tels renseignements. Par conséquent, il est important pour l’organisation de gérer tout risque additionnel qui pourrait découler de l’utilisation de données opérationnelles ou en temps réel.
      Les organisations peuvent réduire les risques au minimum en utilisant de fausses données pendant les activités de conception, de développement et de test menées sur les systèmes, les composants de systèmes ou les services qui s’y rapportent. Les techniques d’évaluation des risques peuvent être utilisées pour déterminer si l’utilisation de données opérationnelles ou en temps réel pose un risque acceptable. L’utilisation de renseignements personnels aux fins de test exige que les individus soient informés à l’avance d’une telle utilisation.
    • Discussion au sein du GC : Pour utiliser des renseignements personnels lors d’activités de tests, l’organisme peut utiliser les tests comme usage compatible des renseignements conformément à l’alinéa 8(2)(a) de la LPRP. Pour qu’un tel usage soit acceptable, les individus doivent avoir été mis au courant de l’utilisation de leurs renseignements aux fins de test au point de collecte des renseignements personnels et les fichiers de renseignements personnels connexes doivent refléter l’utilisation de l’information aux fins de test, lorsque cela est approprié. Si aucun avis n’a été fourni aux individus au point de collecte ou si l’utilisation de l’information aux fins de test n’est pas mentionnée comme usage compatible dans le FRP connexe, les responsables du programme devraient communiquer avec les responsables de la protection de la vie privée pour obtenir des conseils sur ce qui constitue un usage compatible et un usage secondaire.
    • Contrôles et activités connexes : PM-25 et RA-03.
  • (03) Cycle de développement des systèmes : Mise à jour technologique
    • Planifier et mettre en œuvre un calendrier de mise à jour technologique pour le système tout au long du cycle de développement du système.
    • Discussion : La planification de la mise à jour technologique peut comprendre le matériel, les logiciels, les micrologiciels, les processus, les compétences du personnel, les fournisseurs, les fournisseurs de services et les installations. L’utilisation d’une technologie obsolète ou quasi obsolète peut augmenter les risques pour la sécurité et la protection de la vie privée associés aux composants non pris en charge, aux composants contrefaits ou recyclés, aux composants incapables de mettre en œuvre les exigences de sécurité et de protection de la vie privée, les composants lents ou non fonctionnels, les composants provenant de sources non fiables, les erreurs commises par le personnel par inadvertance ou une complexité accrue. Les mises à jour technologiques sont effectuées au cours de la phase d’exploitation et de maintenance du cycle de développement de systèmes.
    • Contrôles et activités connexes : MA-06.

Références

Haut de la page 
 

SA-04 Processus d’acquisition

Contrôle

Inclure, explicitement ou en référence, les exigences, les descriptions et les critères suivants en utilisant [Sélection (un choix ou plus) : langage contractuel normalisé; [Affectation : langage contractuel défini par l’organisation]] dans le contrat d’acquisition du système, des composants du système ou des services qui s’y rapportent

  1. exigences fonctionnelles de sécurité et de protection de la vie privée
  2. exigences en matière de robustesse du mécanisme
  3. exigences d’assurance de sécurité et de protection de la vie privée
  4. contrôles nécessaires pour satisfaire les exigences de sécurité et de protection de la vie privée
  5. exigences liées à la documentation sur la sécurité et la protection de la vie privée
  6. exigences liées à la protection de la documentation sur la sécurité et la protection de la vie privée
  7. description de l’environnement de développement du système et de l’environnement dans lequel on prévoit exploiter le système
  8. affectation de responsabilités ou identification des parties responsables de la sécurité et la protection de la vie privée de l’information et de la gestion des risques liés à la chaîne d’approvisionnement
  9. critères d’acceptation

Discussion

Les exigences fonctionnelles de sécurité et de protection de la vie privée sont habituellement dérivées des exigences de haut niveau en matière de sécurité et de protection de la vie privée décrites au contrôle SA-02. Les exigences dérivées comprennent les capacités, les fonctions et les mécanismes de sécurité et de protection de la vie privée. Les exigences en matière de robustesse qui s’appliquent aux capacités, aux fonctions et aux mécanismes énoncent le degré d’exactitude, d’achèvement, de résistance au trafiquage ou aux contournements, et de résistance aux attaques directes.

Les exigences en matière d’assurance peuvent être indiquées dans l’énoncé des travaux dans le cadre du processus de passation du marché et inclure les processus, les procédures et les méthodologies de développement, ainsi que les données des activités de développement et d’évaluation qui prouvent que la fonctionnalité requise a bien été mise en œuvre et que son mécanisme offre la robustesse nécessaire. La publication Activités de gestion des risques pour la cybersécurité et la vie privée tout au long du cycle de vie des systèmes (ITSP.10.037) du Centre pour la cybersécurité décrit le processus d’ingénierie des exigences dans le cadre du cycle de vie des systèmes.

Les contrôles se veulent une description des mesures et des capacités de protection qu’il convient de mettre en œuvre pour atteindre les objectifs précis de l’organisation sur le plan de la sécurité et de la protection de la vie privée, et tenir compte des exigences en matière de sécurité et de protection de la vie privée des parties prenantes. Les contrôles sont sélectionnés et mis en œuvre de manière à satisfaire les exigences du système et à inclure les responsabilités de l’organisation et celles des développeuses et développeurs. Les contrôles peuvent comprendre les aspects techniques, administratifs, physiques et liés à la protection de la vie privée. Dans certains cas, la sélection et la mise en œuvre d’un contrôle peuvent nécessiter de la part de l’organisation des spécifications additionnelles sous la forme d’exigences dérivées ou de valeurs de paramètres de contrôle instanciés. Les exigences dérivées et les valeurs de paramètres de contrôle peuvent s’avérer nécessaires pour fournir le niveau approprié de détail de mise en œuvre des contrôles pendant le cycle de développement des systèmes.

Les exigences liées à la documentation sur la sécurité et la protection de la vie privée portent sur toutes les phases du cycle de développement des systèmes. La documentation fournit aux utilisatrices, aux utilisateurs, aux administratrices et aux administrateurs des conseils sur la mise en œuvre et le fonctionnement des contrôles. Le degré de détail requis dans une telle documentation se fonde sur la catégorisation de la sécurité ou sur le niveau de classification du système, de même que sur l’ampleur de la dépendance à l’égard des capacités, des fonctions ou des mécanismes dont dépendent les organisations pour satisfaire les attentes en matière de réponse aux risques. Les exigences peuvent comprendre les paramètres de configuration imposés qui précisent les fonctions, les ports, les protocoles et les services qui sont autorisés. Les critères d’acceptation visant les systèmes, les composants de systèmes et les services qui s’y rapportent sont définis de la même façon que les critères visant toute acquisition ou tout approvisionnement organisationnels.

Les organisations peuvent établir d’autres exigences qui soutiennent la sécurité et les activités afin de tenir compte de leurs responsabilités et de celles de la développeuse ou du développeur, ainsi que des exigences en matière de notification et d’échéanciers aux fins de soutien, de maintenance et de mise à jour.

Discussion au sein du GC

Les exigences fonctionnelles relatives à la protection des renseignements personnels se trouvent au chapitre 1 du Guide des approvisionnements de SPAC, sous le paragraphe 1.70, Protection des renseignements personnels dans le cadre de l’attribution de contrats. Le document d’orientation du SCT, Prise en compte de la protection des renseignements personnels avant de conclure un marché, fournit de l’information additionnelle sur le traitement des renseignements personnels. Les exigences fonctionnelles incluent les obligations contractuelles en matière de propriété des renseignements personnels, le maintien de l’exactitude, de la protection de la vie privée et de l’intégrité des renseignements personnels, les restrictions sur l’utilisation ou la divulgation secondaire de renseignements sans consentement, l’élimination des dossiers contenant des renseignements personnels, dont le retour de dossier au GC le cas échéant, l’acceptation des risques de vérification de la protection de la vie privée, les mécanismes de plaintes concernant la protection de la vie privée et les atteintes à la vie privée, ainsi que les exigences prévues par la loi concernant la divulgation de renseignements personnels.

Contrôles et activités connexes

CM-06, CM-08, PS-07, SA-03, SA-05, SA-08, SA-11, SA-15, SA-16, SA-17, SA-21, SA-400, SR-03 et SR-05.

Améliorations

  • (01) Processus d’acquisition : Propriétés fonctionnelles des contrôles
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte donne une description des propriétés fonctionnelles des contrôles à mettre en œuvre.
    • Discussion : Les propriétés fonctionnelles des contrôles de sécurité et de protection de la vie privée décrivent une fonctionnalité (par exemple, une capacité de sécurité et de protection de la vie privée, une fonction ou un mécanisme) qui est visible par l’intermédiaire de l’interface des contrôles. De plus, elles excluent les fonctionnalités et les structures de données qui sont au cœur du fonctionnement des contrôles.
    • Contrôles et activités connexes : Aucun.
  • (02) Processus d’acquisition : Renseignements relatifs à la conception et à la mise en œuvre des contrôles
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte fournisse des renseignements sur la conception et la mise en œuvre des contrôles, ce qui comprend : [Sélection (un choix ou plus) : interfaces de systèmes externes servant à la sécurité; conception de haut niveau; conception de bas niveau; code source ou schémas des composants matériels; [Affectation : renseignements produits par l’organisme sur la conception et sur la mise en œuvre]] selon [Affectation : degré de détails défini par l’organisation].
    • Discussion : Les organisations pourraient exiger un degré différent de détail dans la documentation relative à la conception et à la mise en œuvre des contrôles à employer dans les systèmes organisationnels, les composants de systèmes ou les services qui s’y rapportent en fonction des exigences de la mission ou des activités, des exigences en matière de résilience et de robustesse, et des exigences en matière d’analyse et de tests. Les systèmes peuvent être partitionnés en plusieurs sous-systèmes. Chacun de ces sous-systèmes peut également comprendre un ou plusieurs modules. La conception de haut niveau pour les systèmes se traduit par des sous-systèmes interreliés par des interfaces qui fournissent des fonctionnalités de sécurité. La conception de bas niveau du système donne lieu à des modules interreliés par des interfaces qui fournissent des fonctionnalités de sécurité. La documentation de conception et de mise en œuvre peut comprendre le fabricant, la version, le numéro de série, la signature hachée de vérification, les bibliothèques de logiciels utilisées, la date d’achat ou de téléchargement, ainsi que le fournisseur ou la source du téléchargement. Le code source et les schémas de composants matériels sont considérés comme des représentations de la mise en œuvre du système.
    • Contrôles et activités connexes : Aucun.
  • (03) Processus d’acquisition : Méthodes, techniques et pratiques en matière de développement
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte démontre que le cycle de développement du système comprend
      1. [Affectation : méthodes d’ingénierie définies par l’organisation]
      2. [Sélection (un choix ou plus) : [Affectation : méthodes d’ingénierie de la sécurité de système définies par l’organisation]; [Affectation : méthodes d’ingénierie de la protection de la vie privée définies par l’organisation]]
      3. [Affectation : méthodes de développement logiciel définies par l’organisation; méthodes de test, d’évaluation, de vérification et de validation; et processus de contrôle de la qualité]
    • Discussion : Le fait de suivre un cycle de développement de système qui comprend des méthodes de développement de logiciels conformes aux normes en vigueur, des méthodes d’ingénierie de système, des méthodes d’ingénierie de sécurité et de protection de la vie privée de système et des processus de contrôle de la qualité contribue à réduire le nombre et la sévérité des éventuelles erreurs pouvant survenir dans les systèmes, les composants de systèmes ou les services qui s’y rapportent. La réduction du nombre et de la sévérité de telles erreurs diminue également le nombre des vulnérabilités d’un système donné, de ses composants et de ses services.
      La transparence dans les méthodes et les techniques sélectionnées et mises en œuvre par les développeuses et développeurs pour l’ingénierie de systèmes, l’ingénierie de la sécurité et de la protection de la vie privée des systèmes, le développement logiciel, les évaluations des composants et des systèmes et les processus de contrôle de la qualité offre un niveau plus élevé d’assurance dans la fonctionnalité de sécurité du système, les composants du système ou les services du système que les organisations se procurent.
    • Contrôles et activités connexes : Aucun.
  • (04) Processus d’acquisition : Attribution de composants à des systèmes
    • Annulé : Intégré au contrôle CM-08(09).
  • (05) Processus d’acquisition : Configurations de systèmes, de composants et de services
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte s’assure de
      1. produire un système, des composants ou des services dont les [Affectation : configurations de sécurité définies par l’organisation] sont mises en œuvre
      2. utiliser les configurations comme valeurs par défaut pour tout système, composant ou service devant faire ultimement l’objet d’une réinstallation ou d’une mise à niveau
    • Discussion : Les exemples de configurations de la sécurité comprennent le document Exigences de base en matière de sécurité pour les zones de sécurité de réseau (ITSP.80.022), les STIG, ainsi que les limitations liées aux fonctions, aux ports, aux protocoles et aux services. Les caractéristiques de sécurité peuvent comprendre l’exigence selon laquelle les mots de passe par défaut doivent avoir été changés.
    • Discussion au sein du GC : Les ministères et organismes du GC peuvent également consulter le document Exigences de configuration relatives à la gestion du système, ainsi que la Norme sur les configurations courantes des services de la TI intégrée du SCT.
    • Contrôles et activités connexes : Aucun.
  • (06) Processus d’acquisition : Utilisation de produits de cybersécurité
      1. Utiliser uniquement les produits gouvernementaux sur étagère (GOTS pour Government Off-the-Shelf) ou COTS de cybersécurité et les produits informatiques sécurisés qui constituent une solution approuvée par le Centre pour la cybersécurité pour protéger l’information classifiée lorsque les réseaux servant à transmettre cette information ont un niveau de classification inférieur à celui de l’information transmise
      2. Exiger que ces produits soient évalués ou validés par le Centre pour la cybersécurité ou conformément à des procédures approuvées par le Centre pour la cybersécurité.
    • Discussion : Aucune.
    • Discussion au sein du GC : Il est possible que les produits de cybersécurité COTS ou les produits informatiques sécurisés servant à protéger l’information classifiée par des moyens cryptographiques doivent utiliser une méthode de gestion des clés approuvée par le Centre pour la cybersécurité. Prière de se reporter à l’Infrastructure de gestion des clés du gouvernement du Canada (IGC GC) pour de plus amples renseignements (réservé au GC).
    • Contrôles et activités connexes : SC-08, SC-12, SC-13.
  • (07) Processus d’acquisition : Profils de protection reconnus par le Programme canadien lié aux Critères communs
      1. Limiter l’utilisation de produits commerciaux de cybersécurité et de produits informatiques sécurisés à ceux qui ont déjà été évalués selon un profil de protection reconnu par le Programme canadien lié aux Critères communs (PCCC) pour un type de technologie particulier, si un tel profil existe
      2. S’il n’y a aucun profil de protection reconnu par le PCCC pour un type de technologie en particulier et qu’un produit de TI commercial a recours à une fonctionnalité cryptographique pour appliquer sa stratégie de sécurité, exiger que le module cryptographique soit validé selon la norme FIPS (Federal Information Processing Standard) ou reconnu par le PCCC
    • Discussion : Le Centre pour la cybersécurité assure les activités du PCCC et certifie les produits. Prière de consulter le Portail des Critères communs (en anglais seulement) pour plus de renseignements sur les profils de protection. Prière de se reporter au Programme de validation des modules cryptographiques (PVMC) du Centre pour la cybersécurité pour plus de renseignements sur les modules cryptographiques homologués FIPS.
    • Contrôles et activités connexes : IA-07, SC-12 et SC-13.
  • (08) Processus d’acquisition : Plan de surveillance continue des contrôles
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte élabore un plan pour assurer une surveillance continue de l’efficacité des contrôles, conformément au programme de surveillance continue de l’organisation.
    • Discussion : Les plans de surveillance continue visent à établir si les contrôles qui sont planifiés, exigés et déployés au sein du système, des composants du système ou des services qui s’y rapportent continuent d’être efficaces, en se fondant sur les changements inévitables appelés à survenir.
      Les plans de surveillance continue des développeuses et développeurs produisent un degré de détails tel que l’information fournie peut être intégrée aux programmes de surveillance continue mis en œuvre par les organisations. Les plans de surveillance continue peuvent inclure les types d’activités d’évaluation et de surveillance des contrôles prévus, la fréquence de la surveillance continue et les mesures à prendre advenant l’échec ou l’inefficacité des contrôles.
    • Contrôles et activités connexes : CA-07.
  • (09) Processus d’acquisition : Fonctions, ports, protocoles et services utilisés
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte détermine les fonctions, les ports, les protocoles et les services qui seront utilisés dans l’organisation.
    • Discussion : La détermination précoce des fonctions, des ports, des protocoles et des services (par exemple, pendant les phases initiales de définition des besoins et de conception) permet aux organisations d’influer sur la modélisation d’un système, de ses composants ou des services qui s’y rapportent.
      Cette intervention précoce dans le cycle de développement des systèmes permet aux organisations d’éviter ou de réduire au minimum l’utilisation des fonctions, des ports, des protocoles ou des services pouvant poser des risques tout aussi importants qu’inutiles, et de comprendre les avantages de bloquer l’accès à certains ports, protocoles ou services, ou de demander à des fournisseurs de services de systèmes de faire de même.
      Une détermination hâtive des fonctions, des ports, des protocoles et des services évite d’avoir à reconfigurer les contrôles après la mise en œuvre d’un système, de ses composants ou des services qui s’y rapportent. Le contrôle SA-09 décrit les exigences liées aux services de systèmes externes. Les organisations déterminent les fonctions, les ports, les protocoles et les services qui sont fournis depuis des sources externes.
    • Contrôles et activités connexes : CM-07 et SA-09.
  • (10) Processus d’acquisition : Utilisation de produits de justificatifs d’identité numériques approuvés
    • Utiliser seulement les produits informatiques recommandés par le Centre pour la cybersécurité pour la capacité des justificatifs d’identité numériques mise en œuvre dans les systèmes de l’organisation.
    • Discussion : Les produits doivent se conformer aux exigences formulées par le Centre pour la cybersécurité dans le document Guide sur l’authentification des utilisateurs dans les systèmes de technologie de l’information (ITSP.30.031) relativement au niveau d’assurance et au niveau de robustesse de l’authentification des justificatifs d’identité numériques des employées, des employés, des entrepreneures et des entrepreneurs du GC. Les systèmes et les organisations ont recours à des jetons d’authentification, comme les cartes à puce, pour l’AMF.
    • Contrôles et activités connexes : IA-02, IA-08 et PM-09.
  • (11) Processus d’acquisition : Système d’enregistrement
    • Inclure les [Affectation : exigences en matière de la LPRP définies par l’organisation] dans le contrat d’acquisition relatif à l’exploitation d’un système d’enregistrement au nom d’une organisation afin d’assurer la mission ou les activités de cette dernière.
    • Discussion : Lorsqu’une organisation assure l’exploitation d’un système d’enregistrement dans le cadre d’un contrat pour réaliser sa mission ou ses activités, elle doit appliquer les exigences imposées par la LPRP aux systèmes d’enregistrement conformément à ses pouvoirs.
      À l’occasion, les entrepreneures et entrepreneurs représenteront le GC et recueilleront les renseignements personnels associés aux programmes d’exploitation ou aux services. Les entrepreneures et entrepreneurs doivent faire preuve de transparence en indiquant qu’ils représentent le GC et informer les individus de la façon dont leurs renseignements personnels pourraient être communiqués au gouvernement. Les obligations en matière de protection de la vie privée et de sécurité s’appliquent lorsque les entrepreneures et entrepreneurs représentent le GC. Préciser dans le contrat d’acquisition les droits de garde des renseignements personnels advenant le cas où l’entrepreneure ou entrepreneur représenterait le GC et collecterait les renseignements personnels d’individus.
    • Contrôles et activités connexes : PT-06.
  • (12) Processus d’acquisition : Propriété des données
      1. Inclure les exigences relatives à la propriété des données organisationnelles dans le contrat d’acquisition
      2. Exiger que toutes les données soient supprimées du système de l’entrepreneure ou entrepreneur et retournées à l’organisation dans les [Affectation : délais définis par l’organisation]
    • Discussion : Les entrepreneures et entrepreneurs qui exploitent un système contenant des données appartenant à une organisation doivent inclure dans le contrat les stratégies et les procédures en place pour supprimer les données de leurs systèmes et/ou retourner les données dans les délais stipulés dans le contrat.
    • Contrôles et activités connexes : Aucun.

Références

Haut de la page 
 

SA-05 Documentation relative aux systèmes

Activité

  1. Obtenir ou élaborer la documentation à l’intention des administratrices et administrateurs d’un système, d’un composant du système ou du service qui s’y rapporte, qui décrit
    1. la configuration, l’installation et l’exploitation sécurisées du système, du composant ou du service
    2. l’utilisation et la maintenance efficaces des fonctions et mécanismes de sécurité et de protection de la vie privée
    3. les vulnérabilités connues associées à la configuration et à l’utilisation des fonctions administratives et privilégiées
  2. Obtenir ou élaborer la documentation des utilisatrices et utilisateurs d’un système, d’un composant du système ou du service qui s’y rapporte, laquelle décrit
    1. les fonctions et mécanismes de sécurité et de protection de la vie privée accessibles aux utilisatrices et utilisateurs, et la façon d’utiliser efficacement ces fonctions et mécanismes
    2. les méthodes d’interaction utilisateur qui permettent aux utilisatrices et utilisateurs d’utiliser le système, le composant ou le service de façon plus sécurisée et de protéger leur vie privée
    3. les responsabilités des utilisatrices ou utilisateurs concernant le maintien de la sécurité du système, de ses composants ou des services qui s’y rapportent, et de la vie privée de ces personnes
  3. Documenter les tentatives visant à obtenir des documents sur le système, ses composants ou les services qui s’y rapportent, qui n’existent pas ou qui ne sont pas disponibles, et réagir en [Affectation : mesures définies par l’organisation]
  4. Distribuer la documentation à [Affectation : personnel ou rôles définis par l’organisation]

Discussion

La documentation et les artéfacts créés par la développeuse ou le développeur aident le personnel à comprendre la mise en œuvre et le fonctionnement des contrôles. Les organisations envisagent d’établir des mesures particulières afin de définir le degré de qualité et d’achèvement du contenu fourni. La documentation relative aux systèmes peut être utilisée pour déterminer les rôles, les responsabilités et les attentes de la développeuse, du développeur et de l’organisation, et pour soutenir la gestion des risques liés à la chaîne d’approvisionnement, le processus d’intervention en cas d’incident et d’autres fonctions. Le personnel ou les rôles qui ont besoin de la documentation comprennent les propriétaires de systèmes, les responsables de la sécurité des systèmes et les administratrices et administrateurs de systèmes. Les tentatives d’obtenir la documentation consistent à communiquer avec les fabricants ou les fournisseurs, et à procéder à des recherches en ligne.

L’incapacité d’obtenir la documentation peut survenir en raison de la désuétude d’un système ou d’un composant, ou d’un manque de soutien de la part des développeuses, des développeurs, des entrepreneures et des entrepreneurs. S’il est impossible d’obtenir la documentation, les organisations pourraient devoir recréer une partie de la documentation, si celle-ci s’avère nécessaire à la mise en œuvre ou au fonctionnement efficaces des contrôles.

La protection s’appliquant à la documentation est proportionnelle à la catégorie de sécurité ou à la classification du système. La documentation portant sur les vulnérabilités des systèmes pourrait nécessiter un niveau de protection accru. L’exploitation sécurisée d’un système comprend le démarrage initial du système et la reprise sûre des opérations du système après une anomalie.

Contrôles et activités connexes

CM-04, CM-06, CM-07, CM-08, PL-02, PL-04, PL-08, PS-02, SA-03, SA-04, SA-08, SA-09, SA-10, SA-11, SA-15, SA-16, SA-17, SI-12 et SR-03.

Améliorations

  • (01) Documentation relative aux systèmes : Propriétés fonctionnelles des contrôles de sécurité
    • Annulé : Intégré au contrôle SA-04(01).
  • (02) Documentation relative aux systèmes : Interfaces des systèmes externes servant à la sécurité
    • Annulé : Intégré au contrôle SA-04(02).
  • (03) Documentation relative aux systèmes : Conception de haut niveau
    • Annulé : Intégré au contrôle SA-04(02).
  • (04) Documentation relative aux systèmes : Conception de bas niveau
    • Annulé : Intégré au contrôle SA-04(02).
  • (05) Documentation relative aux systèmes : Code source
    • Annulé : Intégré au contrôle SA-04(02).

Références

Aucune.

SA-06 Restrictions relatives à l’utilisation des logiciels

Annulé : Intégré au contrôle CM-10 and SI-07.

SA-07 Logiciels installés par les utilisatrices et utilisateurs

Annulé : Intégré au contrôle CM-11 and SI-07.

Haut de la page 
 

SA-08 Principes d’ingénierie de la sécurité et de la protection de la vie privée

Contrôle

Appliquer les principes d’ingénierie de la sécurité et de la protection de la vie privée des systèmes suivants pour la spécification, la conception, le développement, la mise en œuvre et la modification des systèmes et des composants de systèmes : [Affectation : principes d’ingénierie de la sécurité et de la protection de la vie privée des systèmes définis par l’organisation].

Discussion

Les principes d’ingénierie de la sécurité et de la protection de la vie privée des systèmes sont étroitement liés au cycle de développement des systèmes et mis en œuvre au cours de celui-ci (voir le contrôle SA-03). Les organisations peuvent appliquer les principes d’ingénierie de la sécurité et de la protection de la vie privée aux nouveaux systèmes en cours de développement ou aux systèmes faisant l’objet d’une mise à niveau. Dans le cas des systèmes existants, les organisations appliquent, dans la mesure du possible, les principes d’ingénierie de la sécurité et de la protection de la vie privée aux mises à niveau et aux modifications en tenant compte de l’état actuel du matériel, des logiciels et des micrologiciels des systèmes en question.

L’application des principes d’ingénierie de la sécurité et de la protection de la vie privée des systèmes aide les organisations à développer des systèmes fiables, sécurisés et résilients et à réduire l’exposition aux interruptions, aux risques, aux menaces et aux problèmes de protection de la vie privée pour les utilisatrices et utilisateurs. Les exemples des principes d’ingénierie de la sécurité et de la protection de la vie privée des systèmes comprennent le développement de mesures de protection en couches; l’établissement de stratégies, d’architectures et de contrôles de sécurité et de protection de la vie privée comme base de la conception et du développement des systèmes; l’intégration d’exigences de sécurité et de protection de la vie privée au cycle de développement des systèmes; la délimitation des frontières de sécurité physiques et logiques; l’assurance que les développeuses et développeurs sont formés pour concevoir des logiciels sécurisés; l’adaptation des contrôles pour répondre aux besoins de l’organisation; et la modélisation des menaces afin d’établir les cas d’utilisation, les agents de menace, les vecteurs et schémas d’attaque, les schémas de conception et les contrôles compensatoires nécessaires pour atténuer les risques.

Les organisations qui appliquent des principes et concepts d’ingénierie de la sécurité et de protection de la vie privée des systèmes peuvent faciliter le développement de systèmes, de composants de systèmes et des services sécurisés et dignes de confiance, réduire les risques à des niveaux acceptables et prendre des décisions éclairées en matière de gestion des risques. Les principes d’ingénierie de la sécurité des systèmes peuvent également être utilisés pour protéger contre certains risques liés à la chaîne d’approvisionnement, dont l’intégration de matériel résistant au trafiquage dans la conception.

Discussion au sein du GC

Les mesures de protection de la vie privée des programmes fédéraux reposent sur dix principes de traitement équitable de l’information. En règle générale, les organisations ont besoin de politiques qui dictent les stratégies de protection de la vie privée, limitent la collecte, l’utilisation, la divulgation et la conservation des renseignements personnels et font en sorte que les personnes soient au courant de la façon dont leurs renseignements personnels sont traités et qu’elles aient le droit d’y accéder.

Contrôles et activités connexes

PL-08, PM-07, RA-02, RA-03, RA-09, SA-03, SA-04, SA-15, SA-17, SA-20, SC-02, SC-03, SC-32, SC-39, SI-400, SR-02, SR-03, SR-04 et SR-05.

Améliorations

  • (01) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Abstractions claires
    • Mettre en place le principe de la conception sécurisée des abstractions claires.
    • Discussion : Le principe d’abstractions claires repose sur le fait qu’un système est composé d’interfaces et de fonctions simples et bien définies offrant une vue uniforme et intuitive des données et de la façon dont les données sont gérées. La clarté, la simplicité, la nécessité et la suffisance des interfaces de système – combinées à une définition précise du comportement fonctionnel – favorisent l’analyse, l’inspection et la mise à l’essai, ainsi qu’une utilisation appropriée et sécurisée du système. La clarté d’une abstraction est subjective.
      Parmi les exemples de l’application de ce principe : éviter les interfaces redondantes et inutiles, masquer l’information et éviter la surcharge sémantique des interfaces ou de leurs paramètres. Le masque d’information (c’est-à-dire, une programmation indépendante de la représentation) est une discipline de conception utilisée pour s’assurer que la représentation interne de l’information dans un composant du système n’est pas visible par les autres composants du système qui évoquent ou appellent le premier composant. Il est ainsi possible de faire en sorte que l’abstraction publiée ne soit pas influencée par la façon dont les données sont gérées à l’interne.
    • Contrôles et activités connexes : Aucun.
  • (02) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Mécanisme moindre commun
    • Mettre en place le principe du moindre mécanisme commun dans la conception sécurisée des [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe du moindre mécanisme commun repose sur le fait qu’il faut minimiser les mécanismes communs à plus d’une utilisatrice ou un utilisateur et ceux qui sont nécessaires à tous les utilisateurs (Popek, 1974). La minimisation des mécanismes sous-entend que différents composants d’un système font en sorte de ne pas utiliser le même mécanisme pour accéder à une ressource du système.
      Chaque mécanisme partagé (en particulier un mécanisme employant des variables communes) représente un chemin d’accès potentiel à l’information entre les utilisatrices et utilisateurs et est conçu avec soin pour veiller à ce qu’il ne compromette pas accidentellement la sécurité (Saltzer & Schroeder, 1975). La mise en place du principe du moindre mécanisme commun aide à réduire les conséquences négatives du partage d’états du système entre différents programmes.
      Un seul programme arrivant à corrompre un état partagé (y compris des variables communes) a le potentiel de corrompre d’autres programmes qui dépendent de cet état. Le principe du moindre mécanisme commun prend également en charge le principe de simplicité de la conception et permet de corriger le problème des canaux mémoire secrets (Lampson, 1973).
    • Contrôles et activités connexes : Aucun.
  • (03) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Modularité et structuration en couches
    • Mettre en place les principes de conception sécurisée de la modularité et de la structuration en couches dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Les principes de modularité et de structuration en couches sont à la base des disciplines d’ingénierie des systèmes. La modularité et la structuration en couches dérivées de la décomposition fonctionnelle permettent de gérer efficacement la complexité des systèmes et font en sorte qu’il est possible de comprendre la structure du système. La décomposition modulaire – ou l’amélioration de la conception du système – pose des défis et résiste aux énoncés de principe généraux.
      La modularité sert à isoler les fonctions et les structures de données connexes dans des unités logiques bien définies. La structuration en couches permet de mieux comprendre les relations entre ces unités afin de clarifier les dépendances et d’éviter toute complexité indésirable. Le principe de conception sécurisée de la modularité s’ajoute à la modularité fonctionnelle pour inclure des considérations basées sur les relations d’approbation, les privilèges et la stratégie de sécurité.
      La décomposition modulaire axée sur la sécurité comprend l’affectation de stratégies aux systèmes d’un réseau, la séparation des applications du système dans des processus comportant des espaces d’adresses distinctes, l’affectation de stratégies de système aux couches ainsi que la séparation des processus en des sujets avec privilèges distincts basés sur les domaines de privilèges pris en charge par le matériel.
    • Contrôles et activités connexes : SC-02 et SC-03.
  • (04) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Dépendances partiellement hiérarchisées
    • Mettre en place le principe de conception sécurisée des dépendances partiellement hiérarchisées dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe des dépendances partiellement hiérarchisées repose sur le fait que la synchronisation, l’appel et les autres dépendances du système sont partiellement hiérarchisées. Un concept fondamental de la conception de système est la structuration en couches dans le cadre de laquelle le système est organisé en des modules ou des composants bien définis et fonctionnellement reliés. Les couches sont hiérarchisées de façon linéaire pour ce qui est des dépendances entre les couches, faisant en sorte que les couches supérieures soient dépendantes des couches inférieures.
      Alors qu’elles fournissent les fonctionnalités aux couches supérieures, certaines couches peuvent être autonomes et ne pas dépendre des couches inférieures. Bien qu’il soit impossible de hiérarchiser partiellement toutes les fonctions dans un système donné, les problèmes inhérents de la circularité peuvent être plus faciles à gérer si des dépendances circulaires doivent survenir dans les couches.
      Les dépendances partiellement hiérarchisées et la structuration en couches du système contribuent considérablement à la simplicité et à l’uniformité de la conception du système. Les dépendances partiellement hiérarchisées facilitent également la mise à l’essai et l’analyse des systèmes.
    • Contrôles et activités connexes : Aucun.
  • (05) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Accès avec médiation efficace
    • Mettre en place le principe de conception sécurisée de l’accès avec médiation efficace dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe d’accès avec médiation efficace repose sur le fait que les mécanismes d’application des stratégies utilisent le moindre mécanisme commun disponible pour satisfaire les exigences des parties prenantes tout en respectant les limites imposées. La médiation de l’accès aux ressources du système (c’est-à-dire l’unité centrale de traitement (UCT), la mémoire, les dispositifs, les ports de communications, les services, l’infrastructure, les données et l’information) est souvent la principale fonction de sécurité des systèmes sécurisés. Elle permet également d’offrir les protections nécessaires à la capacité que le système fournit aux parties prenantes.
      La médiation de l’accès aux ressources peut donner lieu à des goulots d’étranglement au niveau des performances si le système n’a pas été conçu correctement. Par exemple, l’accès avec médiation efficace peut être réalisé en faisant appel à des mécanismes matériels. Après avoir obtenu accès à une ressource de niveau inférieur, comme la mémoire, les mécanismes de protection matérielle peuvent s’assurer d’interdire tout accès sortant.
    • Contrôles et activités connexes : AC-25.
  • (06) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Échange minimal
    • Mettre en place le principe de conception sécurisée de l’échange minimal dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe d’échange minimal repose sur le fait qu’aucune ressource informatique n’est partagée entre des composants du système (par exemple, les sujets, les processus et les fonctions) à moins qu’il ne soit absolument nécessaire de le faire. L’échange minimal aide à simplifier la conception et la mise en œuvre du système.
      Pour protéger les ressources des domaines utilisateur contre les entités actives arbitraires, aucune ressource n’est partagée à moins que l’échange n’ait été explicitement demandé et autorisé. Le besoin d’avoir recours au partage de ressources peut être motivé par le principe de conception du moindre mécanisme commun dans les cas des entités internes ou découler des exigences des parties prenantes. Cela dit, l’échange interne est soigneusement conçu pour éviter les problèmes de performances, ainsi que les problèmes liés aux canaux temporels et aux canaux mémoire secrets.
      L’échange effectué au moyen d’un mécanisme commun peut rendre les données et l’information plus susceptibles de faire l’objet d’une divulgation, d’une utilisation, d’une modification ou d’un accès non autorisé et avoir une incidence négative sur la capacité inhérente fournie par le système. Pour minimiser l’échange causé par les mécanismes communs, il est possible de concevoir ces derniers de manière à ce qu’ils soient réentrants ou virtualisés afin de préserver la séparation. Par ailleurs, l’utilisation de données globales pour l’échange d’information est examinée en profondeur. L’absence d’encapsulation peut brouiller les relations parmi les entités prenant part à l’échange.
    • Contrôles et activités connexes : SC-31.
  • (07) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Complexité réduite
    • Mettre en place le principe de conception sécurisée de la complexité réduite dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de complexité réduite repose sur le fait que la conception du système est aussi simple et petite que possible. Une conception simple et petite est plus facile à comprendre et à analyser, et moins sujette aux erreurs. Le principe de complexité réduite s’applique à tous les aspects d’un système, mais il est particulièrement important pour la sécurité en raison des diverses analyses réalisées pour obtenir des preuves de la propriété de sécurité émergente du système. Pour assurer la réussite de telles analyses, il est essentiel de faire appel à une conception simple et de petite taille.
      L’application du principe de complexité réduite permet aux développeuses et développeurs de système de comprendre l’exactitude et l’exhaustivité des fonctions de sécurité du système. Elle facilite également l’identification des vulnérabilités potentielles. La conséquence de la complexité réduite veut que la simplicité du système soit directement liée au nombre de vulnérabilités qu’il contiendra. En d’autres mots, les systèmes plus simples contiennent moins de vulnérabilités.
      Les avantages de la complexité réduite font en sorte qu’il est plus facile de comprendre si la stratégie de sécurité a bien été intégrée dans la conception du système et qu’il y a moins de vulnérabilités susceptibles d’être introduites lors du processus de développement technique. Un autre avantage est qu’on peut en venir à une conclusion par rapport à l’exactitude, à l’exhaustivité et à l’existence des vulnérabilités avec un degré élevé d’assurance comparativement aux conclusions formulées dans des situations où la conception du système est fondamentalement plus complexe.
      La transition de technologies plus anciennes à de plus nouvelles (par exemple, la transition de IPv4 à IPv6) peut exiger une mise en œuvre simultanée des technologies anciennes et nouvelles au cours de la période de transition. Cela pourrait donner lieu à une hausse temporaire dans la complexité du système durant la transition.
    • Contrôles et activités connexes : Aucun.
  • (08) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Évolutivité sécurisée
    • Mettre en place le principe de conception sécurisée de l’évolutivité dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe d’évolutivité sécurisée repose sur le fait qu’un système est développé de manière à faciliter la maintenance de ses propriétés de sécurité lorsque des changements sont apportés à la structure du système, à ses interfaces, à ses interconnexions (c’est-à-dire l’architecture du système), à ses fonctionnalités ou à ses configurations (c’est-à-dire la mise en application des stratégies de sécurité). Les changements comprennent une capacité nouvelle, améliorée ou mise à niveau du système, les activités de maintenance et de maintien, et la reconfiguration.
      Bien qu’il ne soit pas possible de planifier tous les aspects de l’évolution du système, on peut anticiper les mises à niveau et les changements du système en procédant à l’analyse de l’orientation stratégique de la mission ou des activités, des changements anticipés dans l’environnement de menace et des besoins anticipés en matière de maintenance et de maintien. Il n’est pas réaliste de s’attendre à ce que des systèmes complexes demeurent sécurisés dans des contextes non envisagés lors de leur développement, peu importe si de tels contextes sont liés à l’environnement opérationnel ou à l’utilisation.
      Un système peut être sécurisé dans certains nouveaux contextes, mais on ne peut garantir qu’un comportement émergent sera toujours sécurisé. Il est plus facile d’intégrer la robustesse dans un système dès le départ. Par conséquent, le maintien de la robustesse du système exige que l’on planifie les changements plutôt que de s’adapter de manière spontanée ou non méthodique.
      Les avantages de ce principe comprennent des coûts moindres pour le cycle de vie du fournisseur, des coûts de possession moins élevés, une plus grande sécurité du système, une gestion plus efficace des risques liés à la sécurité et moins d’incertitude quant au risque.
    • Contrôles et activités connexes : CM-03.
  • (09) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Composants fiables
    • Mettre en place le principe de conception sécurisée des composants fiables dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe des composants fiables repose sur le fait qu’un composant est, au minimum, à la fois fiable et robuste à un niveau proportionnel aux dépendances de sécurité qu’il prend en charge (c’est-à-dire dans quelle mesure les autres composants peuvent garantir qu’il accomplit ses fonctions de sécurité). Le principe permet de composer les composants de manière à ce que la fiabilité et la robustesse ne soient pas réduites par inadvertance et que la confiance ne soit pas accordée de façon injustifiée par la suite. En définitive, ce principe exige quelques mesures au moyen desquelles la confiance accordée à un composant, ainsi que sa fiabilité et sa robustesse, peuvent être mesurées sur une même échelle d’abstraction.
      Le principe des composants fiables est particulièrement pertinent si on considère des systèmes et des composants dans lesquels on retrouve des dépendances complexes aux chaînes d’approbation. La dépendance fiable est également appelée une relation d’approbation et on peut retrouver des chaînes de relations d’approbation.
      Le principe des composants fiables s’applique aussi à un composant complexe qui est composé de sous-composants (par exemple, un sous-système) susceptibles d’avoir différents niveaux de fiabilité. L’hypothèse conservatrice est que la fiabilité d’un composant complexe repose sur le sous-composant le moins fiable. Il peut être possible de justifier l’ingénierie de la sécurité en déterminant que la fiabilité d’un composant complexe en particulier est supérieure à l’hypothèse conservatrice. Cela dit, une telle justification reflète le raisonnement logique résultant d’une déclaration claire des objectifs de fiabilité, ainsi que de preuves pertinentes et crédibles. La fiabilité d’un composant complexe n’est pas la même que celle d’une application plus grande de la mise en couches de la défense en profondeur dans le composant ou d’une duplication des composants. Les techniques de défense en profondeur n’accroissent pas la fiabilité de l’ensemble au-delà de celle du composant le moins fiable.
    • Contrôles et activités connexes : Aucun.
  • (10) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Confiance hiérarchique
    • Mettre en place le principe de conception sécurisée de la confiance hiérarchique dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de confiance hiérarchique des composants repose sur le principe des composants fiables et sur le fait que les dépendances de sécurité d’un système formeront un ordre partiel si elles permettent d’assurer le principe des composants fiables. L’ordre partiel offre les bases nécessaires au raisonnement de la fiabilité et de la robustesse lorsqu’il s’agit de composer un système sécurisé à partir de composants développés ou acquis indépendamment. Pour analyser la fiabilité et la robustesse d’un système composé de composants développés ou acquis indépendamment, il est essentiel d’éliminer les dépendances circulaires. Si un composant plus fiable ou plus robuste situé sur une couche inférieure du système en venait à dépendre d’un composant moins fiable et moins robuste sur une couche supérieure, il en résulterait une réduction globale de la fiabilité ou de la robustesse du système en raison de l’élément plus faible dont dépend le système.
      Les relations d’approbation (ou chaînes d’approbation) peuvent se manifester de plusieurs manières. Par exemple, le certificat racine d’une hiérarchie de certificats est le nœud le plus fiable de la hiérarchie, ce qui fait en sorte que les branches de la hiérarchie constituent des nœuds moins fiables. C’est également le cas dans un système multicouche à assurance élevée lorsque le noyau de sécurité (y compris la base matérielle) situé sur la couche la plus basse du système constitue le composant le plus fiable.
      Toutefois, le principe de confiance hiérarchique n’interdit pas l’utilisation de composants excessivement fiables. Dans un système à fiabilité faible, il arrive qu’il soit raisonnable de faire appel à un composant à fiabilité élevée plutôt qu’à un composant moins fiable (par exemple, pour des raisons de disponibilité ou de rentabilité). Dans de tels cas, toute dépendance d’un composant à fiabilité élevée à un composant moins fiable ne mine pas la fiabilité du système à faible fiabilité qui en résulte ni n’augmente sa fiabilité ou sa robustesse.
    • Contrôles et activités connexes : Aucun.
  • (11) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Seuil de modification inverse
    • Mettre en place le principe de conception sécurisée du seuil de modification inverse dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de seuil de modification inverse repose sur les principes de composants fiables et de confiance hiérarchique et sur le fait que le degré de protection fourni à un composant est proportionnel à sa fiabilité. À mesure que la confiance conférée à un composant augmente, la protection contre la modification non autorisée du composant augmente dans la même mesure.
      La protection contre la modification non autorisée peut prendre la forme d’une autoprotection du composant et d’une robustesse intrinsèque, ou encore provenir des protections accordées au composant par d’autres éléments ou attributs de l’architecture de sécurité (pour inclure les protections dans l’environnement d’exploitation).
    • Contrôles et activités connexes : Aucun.
  • (12) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Protection hiérarchique
    • Mettre en place le principe de conception sécurisée de la protection hiérarchique dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de protection hiérarchique repose sur le fait qu’un composant ne doit pas être protégé des composants plus fiables. Dans le cas limite d’un composant offrant la fiabilité la plus élevée, celui-ci se protège de tous les autres composants. Par exemple, si le noyau d’un système d’exploitation est considéré comme étant le composant le plus fiable d’un système, alors il se protège lui-même contre les applications non fiables qu’il prend en charge, mais, à l’inverse, les applications n’ont pas à se protéger du noyau.
      La fiabilité des utilisatrices et utilisateurs est un facteur à considérer dans l’application du principe de protection hiérarchique. Un système approuvé n’a pas à se protéger d’une utilisatrice ou un utilisateur d’une fiabilité équivalente dans la mesure où l’utilisation de systèmes non fiables dans des environnements au niveau de sécurité le plus élevé où les utilisatrices et utilisateurs font l’objet d’une fiabilité élevée et où d’autres protections sont mises en place pour restreindre et protéger l’environnement d’exécution au niveau de sécurité le plus élevé.
    • Contrôles et activités connexes : Aucun.
  • (13) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Éléments de sécurité minimisés
    • Mettre en place le principe de conception sécurisée des éléments de sécurité minimisés dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe des éléments de sécurité minimisés repose sur le fait que le système ne comporte aucun composant fiable superflu. Le principe des éléments de sécurité minimisés comporte deux aspects : le coût global et la complexité de l’analyse de la sécurité.
      Les composants fiables sont généralement plus coûteux à construire et à mettre en œuvre en raison de la rigueur accrue nécessaire au développement des processus et des exigences liées à l’intégrité de la chaîne d’approvisionnement. Les composants fiables exigent une analyse plus poussée de la sécurité pour déterminer leur robustesse et la mise en place de plus amples contrôles dans la chaîne d’approvisionnement pour déterminer leur fiabilité. Pour réduire les coûts et la complexité de l’analyse de la sécurité, un système devrait ainsi contenir le moins de composants fiables possible.
      L’analyse de l’interaction des composants fiables avec les autres composants du système est l’un des aspects les plus importants de la vérification de la sécurité des systèmes. Si les interactions entre les composants sont inutilement complexes, la sécurité du système sera également plus difficile à évaluer que celle dont les relations d’approbation internes sont simples et élégamment élaborées. En règle générale, miser sur moins de composants fiables donne lieu à moins de relations d’approbation internes et à un système plus simple.
    • Contrôles et activités connexes : Aucun.
  • (14) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Droit d’accès minimal
    • Mettre en place le principe de conception sécurisée du droit d’accès minimal dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de droit d’accès minimal repose sur le fait que l’on doit affecter suffisamment de privilèges à chaque composant du système pour accomplir ses fonctions, mais sans plus. L’application du principe de droit d’accès minimal limite la portée des actions du composant, ce qui a deux conséquences désirées : l’incidence sur la sécurité d’un composant sera moindre advenant une défaillance, une corruption ou une mauvaise utilisation et il sera plus facile de procéder à l’analyse de la sécurité du composant. Le principe de droit d’accès minimal est un principe omniprésent qui se reflète dans tous les aspects de la conception d’un système sécurisé. Les interfaces utilisées pour appeler les capacités du composant ne sont accessibles que par certains sous-ensembles de la population d’utilisatrices et utilisateurs, et la conception du composant prend en charge un degré de granularité suffisamment précis pour assurer la décomposition des privilèges.
      Par exemple, dans le cas d’un mécanisme de vérification, on pourrait retrouver une interface pour la ou le gestionnaire des vérifications, qui configure les paramètres de vérification, une interface pour l’exploitante ou exploitant des vérifications, qui s’assure que les données de vérification sont collectées et stockées en toute sécurité et, pour finir, une autre interface pour la réviseuse ou le réviseur des vérifications, qui doit afficher les données de vérification collectées sans toutefois effectuer d’opérations à partir de ces données.
      En plus de ses manifestations dans l’interface du système, le principe de droit d’accès minimal peut être utilisé comme principe directeur pour la structure interne du système en tant que tel. Un aspect du droit d’accès minimal interne est de construire des modules de manière à ce que seules les fonctions d’un module puissent effectuer des opérations directes sur les éléments encapsulés par ce module. Il est possible d’accéder indirectement aux éléments externes à un module susceptibles d’être touchés par l’exploitation de ce module dans le cadre d’une interaction (par exemple, lors d’un appel de fonction) avec le module qui contient ces éléments. Un autre aspect du droit d’accès minimal interne veut que la portée d’un module ou d’un composant donné comprenne uniquement les éléments du système qui sont nécessaires pour son fonctionnement et que les modes d’accès des éléments (par exemple, lecture, écriture) soient minimaux. La minimisation des fonctions qui utilisent des privilèges élevés (par exemple, la restriction des outils et des fonctions qui s’exécutent en mode noyau) est un exemple de droit d’accès minimal dans le développement logiciel.
    • Contrôles et activités connexes : AC-06, CM-07.
  • (15) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Autorisation des prédicats
    • Mettre en place le principe de conception sécurisée de l’autorisation des prédicats dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe d’autorisation des prédicats repose sur le fait que les conceptrices et concepteurs de système doivent considérer d’exiger que de multiples entités autorisées donnent leur consentement avant de permettre l’exécution d’une opération très critique ou l’accès à des données, de l’information ou des ressources hautement sensibles.
      À l’origine, Saltzer (Saltzer & Schroeder, 1975) a nommé l’autorisation des prédicats « la séparation des privilèges ». C’est en quelque sorte l’équivalent de la séparation des tâches. La division des privilèges parmi plusieurs partis diminue la probabilité d’une utilisation abusive et fournit l’assurance qu’un incident, une déception ou un abus de confiance ne peut à lui seul déclencher une action définitive qui pourrait causer des dommages importants.
      Les options de conception pour un tel mécanisme peuvent exiger une action simultanée (par exemple, larguer un missile nucléaire exige que deux personnes autorisées différentes donnent la bonne commande dans un délai très court) ou une séquence d’opérations où chaque action successive est déclenchée par une certaine action antérieure, sans qu’une seule personne ne puisse être en mesure de déclencher plus d’une action.
    • Contrôles et activités connexes : AC-05.
  • (16) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Fiabilité autonome
    • Mettre en place le principe de conception sécurisée de la fiabilité autonome dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de fiabilité autonome repose sur le fait que les systèmes doivent réduire leur dépendance envers les autres systèmes pour assurer leur propre fiabilité. Un système est fiable par défaut et toute connexion à une entité externe sert à compléter ses fonctions. Si un système doit maintenir une connexion à une autre entité externe afin de maintenir sa fiabilité, alors ce système est vulnérable aux menaces malveillantes et non malveillantes, ce qui pourrait donner lieu à une perte ou à une dégradation de cette connexion.
      L’avantage du principe de fiabilité autonome est que l’isolation d’un système le rendra moins vulnérable aux attaques. Une conséquence de ce principe touche la capacité du système (ou d’un composant du système) à fonctionner en isolation pour ensuite se synchroniser de nouveau avec les autres composants une fois la connexion établie.
    • Contrôles et activités connexes : Aucun.
  • (17) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Composition distribuée sécurisée
    • Mettre en place le principe de conception sécurisée de la composition distribuée sécurisée dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de composition distribuée sécurisée repose sur le fait que la composition distribuée sécurisée qui permet d’appliquer la même stratégie de sécurité au système donne lieu à un système qui applique, au minimum, cette stratégie avec autant d’efficacité que les composants individuels.
      Plusieurs des principes de conception de systèmes sécurisés abordent la façon dont les composants peuvent ou devraient interagir. La nécessité de créer ou d’activer une capacité à partir de la composition de composants distribués peut accroître la pertinence de ces principes. Plus particulièrement, la transition d’une stratégie de sécurité d’un système autonome à un système distribué ou à un système de systèmes peut avoir des résultats inattendus ou émergents.
      Les mécanismes d’uniformité des protocoles de communications et des données distribuées aident à assurer une application uniforme de la stratégie dans l’ensemble d’un système distribué. L’architecture de sécurité d’un système à composition distribuée fait l’objet d’une analyse rigoureuse pour assurer le niveau d’assurance d’une application appropriée de la stratégie à l’échelle du système.
    • Contrôles et activités connexes : Aucun.
  • (18) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Voies de communication fiables
    • Mettre en place le principe de conception sécurisée des voies de communication fiables dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe des voies de communication fiables repose sur le fait qu’au moment de composer un système dans lequel une menace potentielle pèse sur les communications entre les composants (c’est-à-dire les interconnexions entre chaque composant), chaque voie de communication est fiable à un niveau proportionnel aux dépendances de sécurité qu’elle prend en charge (c’est-à-dire dans quelle mesure les autres composants lui font confiance pour exécuter ses fonctions de sécurité). Les voies de communication fiables sont mises en place en combinant un accès restreint à la voie de communication (pour assurer une correspondance acceptable dans la fiabilité et la robustesse des points d’extrémité prenant part à la communication) et le recours à des mesures de protection de bout en bout pour les données transmises par l’intermédiaire de la voie de communication (pour protéger contre l’interception et la modification, et pour accroître l’assurance d’une communication de bout en bout appropriée).
    • Contrôles et activités connexes : SC-08, SC-12 et SC-13.
  • (19) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Protection continue
    • Mettre en place le principe de conception sécurisée de la protection continue dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de protection continue repose sur le fait que les composants et les données servant à appliquer la stratégie de sécurité sont soumis à une protection interrompue qui est conforme à la stratégie de sécurité et aux hypothèses de l’architecture de sécurité. On ne peut offrir aucune assurance que le système est en mesure de protéger la protection de la vie privée, l’intégrité et la disponibilité de sa capacité de conception s’il y a des lacunes dans la protection. Toute assurance quant à la capacité de sécuriser une fonctionnalité fournie exige que les données et l’information fassent l’objet d’une protection continue. Cela signifie qu’il n’y a aucune période au cours de laquelle les données et l’information sont laissées sans protection alors qu’elles sont sous le contrôle du système (c’est-à-dire au cours de la création, du stockage, du traitement ou de la communication des données et de l’information, ainsi que lors de l’initialisation, de l’exécution, de la défaillance, de l’interruption et de l’arrêt du système).
      Une protection continue exige l’adoption des principes du concept de contrôleur de référence selon lequel chaque requête est validée par le contrôleur de référence, faisant en sorte que ce dernier soit en mesure de se protéger contre le trafiquage et qu’il soit possible d’établir une assurance suffisante de l’exactitude et de l’exhaustivité du mécanisme à partir de l’analyse et des tests. De plus, elle exige l’adoption du principe de défaillance et de reprise sécurisées (à savoir la préservation d’un état sécurisé lors d’une erreur, d’un défaut, d’une défaillance et d’une attaque fructueuse; la préservation d’un état sécurisé lors d’une reprise à des modes opérationnels normaux, dégradés ou autres).
      Une protection continue s’applique également aux systèmes conçus pour s’exécuter dans différentes configurations, y compris celles qui fournissent une capacité opérationnelle totale et les configurations en mode dégradé qui fournissent une capacité opérationnelle partielle. Le principe de protection continue exige que les changements apportés aux stratégies de sécurité du système puissent être retracés jusqu’au besoin opérationnel qui guide la configuration et être vérifiés (c’est-à-dire pouvoir s’assurer que les changements proposés ne poussent pas le système à passer à un état non sécurisé).
      Une traçabilité et une vérification insuffisantes peuvent mener à des états irréguliers ou à une discontinuité de la protection en raison de la nature complexe et indécidable du problème. L’utilisation de définitions de configuration prévérifiées qui reflètent la nouvelle stratégie de sécurité permet de réaliser l’analyse nécessaire pour déterminer si la transition des anciennes stratégies aux nouvelles est essentiellement atomique et s’il est garanti que les effets résiduels de l’ancienne stratégie n’entreront pas en conflit avec la nouvelle stratégie. La capacité de démontrer une protection continue est fondée sur une articulation claire des besoins de protection du cycle de vie en tant qu’exigences des parties prenantes en matière de sécurité.
    • Contrôles et activités connexes : AC-25.
  • (20) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Gestion sécurisée des métadonnées
    • Mettre en place le principe de conception sécurisée de la gestion sécurisée des métadonnées dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de gestion sécurisée des métadonnées repose sur le fait que les métadonnées sont des objets de première classe en ce qui concerne la stratégie de sécurité lorsque la stratégie exige une protection complète de l’information ou que le sous-système de sécurité doit se protéger lui-même. Le principe de gestion sécurisée des métadonnées est axé sur la reconnaissance qu’un système, un sous-système ou un composant ne peut se protéger lui-même que s’il protège les données dont il dépend pour s’exécuter correctement.
      Les données ne sont généralement pas interprétées par le système sur lequel elles sont stockées. Ce dernier peut avoir une valeur sémantique (il contient l’information) pour les utilisatrices, les utilisateurs et les programmes qui traitent les données. À l’inverse, les métadonnées sont de l’information sur les données, comme un nom de fichier ou la date à laquelle le fichier a été créé. Les métadonnées sont liées aux données cibles qu’elles décrivent d’une manière que le système peut interpréter, mais elles n’ont pas à être stockées avec les données cibles ou à proximité de celles-ci. Certaines métadonnées peuvent avoir pour cible d’autres métadonnées (par exemple, le niveau de classification ou d’incidence sur un nom de fichier), ce qui est notamment le cas pour les métadonnées autoréférentes.
      La seconde nature apparente des métadonnées peut entraîner la négligence de son besoin de protection légitime, ce qui va à l’encontre de la stratégie de sécurité qui comprend l’exfiltration de l’information. Une préoccupation particulière associée à la protection insuffisante des métadonnées touche les systèmes à sécurité multiniveau (MLS pour Multilevel Secure). Les systèmes MLS gèrent l’accès d’une personne à un objet en fonction des niveaux de sensibilité relative. Par conséquent, les étiquettes du niveau de sensibilité sont apposées directement ou affectées indirectement aux personnes et aux objets qui relèvent du contrôle du système MLS.
      La conséquence des métadonnées étiquetées pour les systèmes MLS veut qu’une étiquette soit ajoutée aux objets contenant des métadonnées. Comme pour les évaluations des besoins de protection des données, il convient de s’assurer que les mesures de protection de la confidentialité et de l’intégrité soient évaluées, précisées et affectées aux métadonnées, comme ça serait le cas pour les données de la mission, de l’organisation ou des systèmes.
    • Contrôles et activités connexes : Aucun.
  • (21) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Auto-analyse
    • Mettre en place le principe de conception sécurisée de l’auto-analyse dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe d’auto-analyse repose sur le fait qu’un composant de système est en mesure d’évaluer son état interne et sa fonctionnalité dans une certaine mesure à plusieurs phases d’exécution et que cette capacité d’auto-analyse est proportionnelle au niveau de robustesse conféré au système. Au niveau du système, l’auto-analyse peut être effectuée dans le cadre des évaluations hiérarchiques de la robustesse réalisées en partant de la base. Selon cette approche, les composants des niveaux inférieurs vérifient l’intégrité des données et corrigent la fonctionnalité (dans une certaine mesure) des composants de niveaux supérieurs. Par exemple, des séquences de démarrage fiables comprennent un composant approuvé d’un niveau inférieur qui atteste de l’intégrité des composants des niveaux supérieurs suivants de manière à établir une chaîne d’approbation transmissible.
      À la racine, un composant s’atteste lui-même, ce qui sous-entend généralement une présomption axiomatique ou de nature environnementale par rapport à son intégrité. Les résultats des auto-analyses peuvent être utilisés pour offrir une protection contre les erreurs induites à l’externe, les défectuosités internes ou les erreurs temporaires. L’adoption de ce principe permet de détecter certaines défectuosités ou erreurs simples sans laisser les conséquences de l’erreur ou de la défectuosité se propager à l’extérieur du composant. Par ailleurs, l’autotest peut être utilisé pour attester de la configuration du composant en détectant les conflits potentiels dans la configuration par rapport à la configuration prévue.
    • Contrôles et activités connexes : CA-07.
  • (22) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Responsabilisation et traçabilité
    • Mettre en place le principe de conception sécurisée de la responsabilisation et de la traçabilité dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de responsabilisation et de traçabilité repose sur le fait qu’il est possible d’établir la trace des mesures relatives à la sécurité (c’est-à-dire les interactions entre sujet et objet) pour l’entité au nom de laquelle l’action a été prise. Ce principe exige une infrastructure fiable qui peut consigner les détails des actions qui touchent la sécurité du système (par exemple, un sous-système de vérification).
      Pour ce faire, le système doit être en mesure d’identifier de façon unique l’entité au nom de laquelle l’action est exécutée et d’enregistrer la séquence pertinente des actions exécutées. La stratégie de responsabilisation exige également que la piste de vérification elle-même soit protégée contre l’accès et la modification non autorisés.
      Le principe de droit d’accès minimal facilite le traçage des actions d’entités en particulier, puisqu’il accroît la granularité de la responsabilisation. Le fait d’associer les actions aux entités du système, et ultimement aux utilisatrices et utilisateurs, et de sécuriser la piste de vérification contre les accès et les modifications non autorisés favorise la non-répudiation, car une fois qu’une action est enregistrée, il n’est pas possible de modifier la piste de vérification.
      Une autre fonction importante de la responsabilisation et de la traçabilité est liée à l’analyse régulière et judiciaire des événements associés à la violation de la politique de sécurité. L’analyse des journaux de vérification peut fournir des renseignements supplémentaires qui peuvent permettre de déterminer non seulement le chemin ou la composante qui a permis la violation de la stratégie de sécurité, mais aussi les actions des personnes associées à cette violation.
    • Contrôles et activités connexes : AC-06, AU-02, AU-03, AU-06, AU-09, AU-10, AU-12, IA-02 et IR-04.
  • (23) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Valeurs par défaut sécurisées
    • Mettre en place le principe de conception sécurisée des valeurs par défaut sécurisées dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe des valeurs par défaut sécurisées repose sur le fait que la configuration par défaut d’un système (y compris ses sous-systèmes, ses composants et ses mécanismes sous-jacents) constitue une application restrictive et conservatrice de la stratégie de sécurité. Le principe des valeurs par défaut sécurisées s’applique à la configuration initiale (c’est-à-dire par défaut) d’un système, ainsi qu’à l’ingénierie et à la conception de sécurité du contrôle de l’accès et des autres fonctions de sécurité qui suivent une stratégie consistant à tout refuser à l’exclusion de ce qui est explicitement autorisé.
      L’aspect initial de la configuration de ce principe exige que toute configuration d’usine d’un système, d’un sous-système ou d’un composant de système n’aide pas à contrevenir à la stratégie de sécurité et puisse empêcher le système de s’exécuter dans la configuration par défaut dans les cas où la stratégie de sécurité à propre dit exige que l’utilisatrice ou utilisateur opérationnel procède à la configuration. Les valeurs par défaut restrictives font en sorte que le système s’exécute comme en usine avec l’autoprotection adéquate et soit en mesure d’éviter les atteintes à la sécurité avant que la stratégie de sécurité et la configuration du système aient été établies. Dans les cas où la protection fournie par le produit d’usine est inadéquate, les parties prenantes évaluent le risque posé par l’utilisation du produit en question avant d’établir un état sécurisé initial.
      Le respect du principe des valeurs par défaut sécurisées permet de garantir qu’un système est dans un état sécurisé au moment de terminer son initialisation. Dans les situations où le système n’arrive pas à terminer l’initialisation, il exécutera une opération demandée au moyen des valeurs par défaut sécurisées ou n’exécutera aucune opération. Il convient de se référer aux principes de protection continue et de défaillance et reprise sécurisées qui sont similaires à ce principe pour fournir la capacité de détecter les défaillances et d’assurer la reprise par la suite.
      L’approche en matière d’ingénierie de la sécurité relative à ce principe repose sur le fait que les mécanismes de sécurité refusent les requêtes à moins qu’on puisse établir qu’elles ont été formées adéquatement et qu’elles respectent la stratégie de sécurité. L’option sécurisée est d’autoriser une requête dans la mesure où l’on peut établir qu’elle respecte la stratégie. Dans un large système, les conditions à respecter pour accepter une demande qui est refusée par défaut sont souvent plus concises et complètes que celles qu’il faudrait vérifier pour refuser une demande autorisée par défaut.
    • Contrôles et activités connexes : CM-02, CM-06 et SA-04.
  • (24) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Défaillance et reprise sécurisées
    • Mettre en place le principe de conception sécurisée de la défaillance et de la reprise sécurisées dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de défaillance et de reprise sécurisées repose sur le fait que ni la défaillance d’une fonction ou d’un mécanisme d’un système ni la reprise effectuée advenant une défaillance ne saurait donner lieu à la violation d’une stratégie de sécurité. Le principe de défaillance et de reprise sécurisées est similaire au principe de protection continue qui vise à s’assurer qu’un système est en mesure de détecter (dans les limites fixées) les défaillances actuelles et imminentes à toutes les étapes de son exécution (c’est-à-dire l’initialisation, l’exécution normale, l’arrêt et la maintenance) et à prendre les mesures appropriées pour veiller à ne pas enfreindre les stratégies de sécurité. Dans les cas précisés, le système est de plus capable de rétablir ses activités après une défaillance actuelle ou imminente afin d’assurer une reprise des activités sécurisées normales, dégradées ou autres tout en veillant à ce qu’un état sécurisé soit maintenu de manière à ne pas enfreindre les stratégies de sécurité.
      Une défaillance est une condition dans le cadre de laquelle le comportement d’un composant déroge du comportement indiqué ou attendu pour le résultat explicitement documenté. Advenant la détection d’une fonction de sécurité défaillante, le système peut se reconfigurer de manière à contourner le composant défectueux tout en maintenant la sécurité et à fournir la totalité ou une partie de la fonctionnalité au système d’origine, ou il peut s’éteindre entièrement pour éviter d’enfreindre davantage les stratégies de sécurité. Pour ce faire, les fonctions de reconfiguration du système sont conçues pour assurer une application continue de la stratégie de sécurité au cours des diverses phases de reconfiguration.
      Une autre technique à utiliser pour assurer la reprise advenant des défaillances consiste à procéder à une restauration à un état sécurisé (lequel peut correspondre à l’état initial), puis à éteindre ou à remplacer le service ou le composant défaillant de manière à pouvoir reprendre les activités sécurisées. La défaillance d’un composant peut être détectée ou non par les composants qui l’utilisent. Le principe de défaillance sécurisée veut que les composants plantent dans un état qui refuse l’accès plutôt que de l’autoriser.
      Par exemple, une opération nominalement atomique qui est interrompue avant sa complétion n’enfreint pas la stratégie de sécurité et est conçue de manière à gérer les événements d’interruption en faisant appel à un niveau d’atomicité plus élevé et à des mécanismes de restauration (par exemple, des transactions). Si un service est utilisé, ses propriétés d’atomicité sont bien documentées et caractérisées de manière à ce que le composant qui a recours à ce service puisse détecter et gérer les événements d’interruption de façon appropriée. Par exemple, un système est conçu pour répondre en douceur à la déconnexion et prendre en charge la resynchronisation et l’uniformité des données après la déconnexion.
      Les stratégies de protection contre les défaillances qui font appel à la réplication des mécanismes d’application des stratégies (ce qu’on appelle parfois la défense en profondeur) peuvent permettre au système de continuer à un état sécurisé même si un mécanisme n’a pas réussi à le protéger. Si les mécanismes sont similaires, par contre, la protection additionnelle peut être illusoire, car l’adversaire n’a qu’à mener une série d’attaques. Dans un système en réseau, percer la sécurité d’un système ou d’un service peut permettre à un attaquant de faire la même chose pour tous les autres systèmes et services reproduits qui sont similaires.
      En utilisant plusieurs mécanismes de protection aux fonctions considérablement différentes, on peut réduire la probabilité qu’une attaque soit répliquée ou répétée. Des analyses sont effectuées pour évaluer les coûts et les avantages de telles techniques de redondance par rapport à l’utilisation accrue des ressources et aux effets négatifs sur les performances globales du système. Des analyses supplémentaires sont effectuées à mesure que la complexité de ces mécanismes augmente, comme ça pourrait être le cas pour les comportements dynamiques. Une complexité accrue réduit généralement la robustesse. Lorsqu’une ressource ne peut pas faire l’objet d’une protection continue, il est capital de détecter et de réparer toute brèche de sécurité avant que la ressource soit utilisée de nouveau dans un contexte sécurisé.
    • Contrôles et activités connexes : CP-10, CP-12, SC-07, SC-08, SC-24 et SI-13.
  • (25) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Sécurité économique
    • Mettre en place le principe de conception sécurisée de la sécurité économique dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de sécurité économique repose sur le fait que les mécanismes de sécurité ne coûtent pas plus que les dommages potentiels qui pourraient découler d’une violation de la sécurité. Il s’agit d’une forme d’analyse coûts-avantages axée sur la sécurité qui sert à la gestion des risques. Les hypothèses en matière de coûts formulées dans l’analyse coûts-avantages permettent d’éviter que les conceptrices et concepteurs de système incorporent des mécanismes de sécurité offrant une robustesse plus importante que nécessaire lorsque la robustesse d’un mécanisme est proportionnelle au coût. Le principe de sécurité économique exige également l’analyse des avantages de l’assurance par rapport au coût de cette assurance pour ce qui est de l’effort nécessaire pour obtenir des preuves pertinentes et crédibles.
    • Contrôles et activités connexes : RA-03.
  • (26) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Sécurité des performances
    • Mettre en place le principe de conception sécurisée de la sécurité des performances dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de la sécurité des performances repose sur le fait que les mécanismes de sécurité sont construits de manière à ne pas dégrader inutilement les performances des systèmes. Les exigences de conception des parties prenantes et des systèmes en matière de performances et de sécurité sont articulées et hiérarchisées de façon précise. Pour que la mise en œuvre des systèmes respecte ses exigences de conception et soit acceptée par les parties prenantes (c’est-à-dire la validation par rapport aux exigences des parties prenantes), les conceptrices et concepteurs sont soumis aux contraintes précises que les besoins en matière de performances des capacités imposent aux besoins de protection.
      Les services de sécurité intensifs sur le plan des calculs, comme la cryptographie, sont évalués afin de démontrer qu’ils n’auront aucune incidence importante sur les considérations prioritaires en matière de performances ou qu’ils peuvent fournir un compromis acceptable entre les performances et une protection fiable. Parmi les compromis à considérer, on retrouve des services de sécurité qui sont moins intensifs sur le plan des calculs dans la mesure où de tels services sont disponibles et suffisants. L’insuffisance d’un service de sécurité est déterminée par la capacité et la robustesse fonctionnelles du mécanisme. La robustesse d’un mécanisme est sélectionnée en fonction des exigences de sécurité, des problèmes de temps système essentiels aux performances (par exemple, la gestion des clés cryptographiques) et d’une évaluation de la capacité de la menace.
      Le principe de la sécurité des performances mène à l’incorporation de fonctionnalités qui facilitent l’application de la stratégie de sécurité, mais qui nécessitent un temps système minimal, comme les mécanismes matériels de bas niveau sur lesquels les services de niveaux supérieurs sont élaborés. De tels mécanismes de bas niveau sont généralement très spécifiques; leurs fonctionnalités sont limitées et ils sont optimisés aux fins de performances. Par exemple, une fois que les droits d’accès pour une partie de la mémoire sont accordés, plusieurs systèmes utilisent les mécanismes matériels pour s’assurer que tous les accès futurs utilisent la bonne adresse dans la mémoire et le bon mode d’accès.
      L’application de ce principe réitère la nécessité de concevoir la sécurité du système à partir de zéro et d’intégrer des mécanismes simples aux couches inférieures qui peuvent servir de fondement pour les mécanismes de niveau supérieur.
    • Contrôles et activités connexes : SC-12, SC-13, SI-02 et SI-07.
  • (27) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Sécurité tenant compte du facteur humain
    • Mettre en place le principe de conception sécurisée de la sécurité tenant compte du facteur humain dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de la sécurité tenant compte du facteur humain repose sur le fait que l’interface utilisateur des fonctions de sécurité et des services de soutien est intuitive et conviviale et qu’elle permet de fournir une rétroaction des actions effectuées par les utilisatrices et utilisateurs qui ont une incidence sur une telle stratégie et son application. Les mécanismes qui permettent d’appliquer la stratégie de sécurité ne sont pas intrusifs pour les utilisatrices et utilisateurs et sont conçus de manière à ne pas nuire à l’efficacité de ces derniers.
      Les mécanismes d’application des stratégies de sécurité offrent également aux utilisatrices et utilisateurs une rétroaction claire, utile et pertinente et des avertissements lorsque des choix non sécurisés sont effectués. Une attention particulière est accordée aux interfaces par l’entremise desquelles le personnel responsable de l’administration et de l’exploitation des systèmes configure et met en place les stratégies de sécurité. Idéalement, les membres du personnel devraient être en mesure de comprendre les conséquences de leurs choix.
      Le personnel qui assume des responsabilités d’administration et d’exploitation de systèmes est en mesure de configurer les systèmes avant leur démarrage et de les administrer lors de leur exécution tout en étant persuadé que ses intentions ont bien été prises en compte dans les mécanismes des systèmes. Les services, les fonctions et les mécanismes de sécurité ne nuisent pas à l’utilisation prévue du système et ne compliquent pas son utilisation inutilement. Il convient de faire un compromis entre l’utilisabilité du système et la robustesse nécessaire pour appliquer les stratégies de sécurité. Si les mécanismes de sécurité sont frustrants ou difficiles à utiliser, les utilisatrices et utilisateurs pourraient les désactiver, les éviter ou les utiliser d’une manière qui va à l’encontre des exigences de sécurité et des besoins de protection pour lesquels les mécanismes ont été conçus.
    • Contrôles et activités connexes : Aucun.
  • (28) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Sécurité acceptable
    • Mettre en place le principe de conception sécurisée de la sécurité acceptable dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de sécurité acceptable exige que le niveau de protection de la vie privée et de performances fourni par le système réponde aux attentes des utilisatrices et utilisateurs. La perception du respect de la vie privée peut avoir une incidence sur les comportements, le moral et l’efficacité des utilisatrices et utilisateurs. Selon la stratégie de protection de la vie privée de l’organisation et la conception du système, les utilisatrices et utilisateurs devraient être en mesure de limiter leurs actions de manière à protéger leur vie privée. Si les systèmes ne parviennent pas à fournir des interfaces intuitives ou à répondre aux attentes en matière de protection de la vie privée et de performances, les utilisatrices et utilisateurs peuvent choisir d’éviter entièrement le système ou de l’utiliser d’une façon qui pourrait être inefficace, voire non sécurisée.
    • Contrôles et activités connexes : Aucun.
  • (29) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Procédures reproduisibles et documentées
    • Mettre en place le principe de conception sécurisée des procédures reproduisibles et documentées dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe des procédures reproduisibles et documentées repose sur le fait que les techniques et les méthodes employées pour construire un composant de système permettent au même composant d’être reconstruit entièrement et correctement à une date ultérieure. Les procédures reproduisibles et documentées soutiennent le développement d’un composant qui est identique au composant créé plus tôt, dont l’utilisation peut être répandue.
      Dans le cas des autres artéfacts de système (par exemple, la documentation et les résultats des tests), la reproductibilité permet d’assurer l’uniformité et d’inspecter les artéfacts. Les procédures reproduisibles et documentées peuvent être introduites à différentes phases du cycle de développement des systèmes et contribuer à la capacité d’évaluer les énoncés d’assurance du système. Il s’agit notamment des procédures systématiques pour le développement et l’examen du code, les procédures de gestion des configurations pour les outils de développement et les artéfacts de systèmes, ainsi que les procédures pour la livraison des systèmes.
    • Contrôles et activités connexes : CM-01, SA-01, SA-10, SA-11, SA-15, SA-17, SC-01 et SI-01.
  • (30) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Rigueur procédurale
    • Mettre en place le principe de conception sécurisée de la rigueur procédurale dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de rigueur procédurale repose sur le fait qu’un processus du cycle de vie des systèmes est proportionnel à sa fiabilité et à sa robustesse prévues. La rigueur procédurale définit la portée, la profondeur et la granularité des procédures du cycle de vie des systèmes. De rigoureuses procédures du cycle de vie des systèmes aident à renforcer l’assurance que le système est adéquat et exempt de fonctionnalités imprévues de nombreuses façons. Premièrement, les procédures imposent des automatismes régulateurs au processus du cycle de vie, comme interdire l’introduction de fonctionnalités non définies.
      Deuxièmement, les procédures rigoureuses appliquées aux activités d’ingénierie de la sécurité des systèmes qui génèrent les spécifications et les autres documents de conception des systèmes aident à mieux comprendre le système tel qu’il a été conçu plutôt que de se fier au composant et d’espérer que sa mise en œuvre repose sur une spécification faisant autorité (et pouvant être trompeuse). Pour finir, il est plus facile d’apporter des modifications à un composant de système existant lorsque les spécifications détaillées décrivent sa conception actuelle que lorsqu’on ne peut se référer au code source ou aux schémas pour tenter d’en comprendre le fonctionnement.
      La rigueur procédurale permet de s’assurer que les exigences fonctionnelles de sécurité et d’assurance sont satisfaites et elle permet d’éclairer la détermination de la fiabilité et de la robustesse. La rigueur procédurale est proportionnelle au degré d’assurance demandé au système. Si l’assurance requise pour le système est faible, un niveau élevé de rigueur procédurale peut générer des coûts inutiles. Cela dit, s’il est essentiel d’offrir une assurance élevée, le coût associé à la rigueur procédurale est justifié.
    • Contrôles et activités connexes : Aucun.
  • (31) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Modification de systèmes sécurisés
    • Mettre en place le principe de conception sécurisée de la modification de systèmes sécurisés dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de modification de systèmes sécurisés repose sur le fait que la modification d’un système maintient sa sécurité pour ce qui a trait aux exigences de sécurité et à la tolérance au risque des parties prenantes. Les mises à niveau ou les modifications apportées aux systèmes peuvent transformer les systèmes sécurisés en systèmes non sécurisés. Les procédures liées à la modification des systèmes garantissent que si le système doit maintenir sa fiabilité et sa robustesse, la même rigueur appliquée à son développement initial sera également appliquée à tous les changements apportés au système. Comme les modifications peuvent avoir une incidence sur la capacité du système à maintenir son état sécurisé, une analyse méticuleuse de la sécurité de la modification est nécessaire avant de procéder à sa mise en œuvre et à son déploiement. Ce principe est similaire au principe d’évolutivité sécurisée.
    • Contrôles et activités connexes : CM-03 et CM-04.
  • (32) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Documentation adéquate
    • Mettre en place le principe de conception sécurisée de la documentation adéquate dans les [Affectation : systèmes ou composants de systèmes désignés par l’organisation].
    • Discussion : Le principe de documentation adéquate repose sur le fait que le personnel organisationnel responsable d’interagir avec le système dispose de la documentation adéquate et de l’information nécessaire pour contribuer à la sécurité du système plutôt que d’y nuire. Malgré les tentatives de se conformer à des principes tels que la sécurité tenant compte du facteur humain et la sécurité acceptable, les systèmes sont fondamentalement complexes et il n’est pas toujours facile de déterminer le but de la conception des mécanismes de sécurité et les ramifications d’une mauvaise utilisation ou configuration de ces mécanismes.
      Des utilisatrices et utilisateurs mal informés et insuffisamment formés peuvent introduire des vulnérabilités en raison d’omissions et d’erreurs réelles. La disponibilité de la documentation et de la formation peut aider à fournir aux membres du personnel les connaissances nécessaires pour assumer le rôle essentiel qu’elles et ils jouent dans l’application de principes tels que la protection continue. La documentation est écrite clairement et étayée par une formation offrant une sensibilisation en matière de sécurité et la compréhension des responsabilités relatives à la sécurité.
    • Contrôles et activités connexes : AT-02, AT-03 et SA-05.
  • (33) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Minimisation
    • Mettre en place le principe de protection de la vie privée de la minimisation au moyen de [Affectation : processus définis par l’organisation].
    • Discussion : Le principe de minimisation repose sur le fait que les organisations ne doivent collecter que les renseignements personnels ou l’information sensible qui concernent directement un programme opérationnel ou une activité de l’institution. Dans le même sens, les organisations ne doivent conserver les renseignements personnels et l’information sensible que pour la période nécessaire à l’atteinte du but fixé. Advenant le cas où l’information sensible ou les renseignements personnels doivent être communiqués à d’autres programmes ou organisations, il convient de les limiter à ce qui est expressément exigé par le programme ou l’organisation destinataire. Les organisations devraient mettre en place des processus pour appliquer le principe de minimisation conformément aux lois et aux politiques applicables.
    • Discussion au sein du GC : Cette amélioration est obligatoire pour les ministères et les organismes du GC.
    • Contrôles et activités connexes : PE-08, PM-25, SC-42 et SI-12.
  • (400) Principes d’ingénierie de la sécurité et de la protection de la vie privée : Ingénieures et ingénieurs brevetés et agréés
    • Avoir recours à des ingénieures et ingénieurs brevetés et agréés en sécurité qui assument la responsabilité des spécifications, de la conception, du développement et de la mise en œuvre de solutions de sécurité et de protection de la vie privée du système d’information.
    • Discussion : Aucune.
    • Contrôles et activités connexes : Aucun.

Références

Haut de la page 
 

SA-09 Services de systèmes externes

Contrôle

  1. Exiger que les fournisseurs de services de systèmes externes respectent les exigences organisationnelles en matière de sécurité et de protection de la vie privée et aient recours aux contrôles suivants : [Affectation : contrôles définis par l’organisation]
  2. Définir et documenter la surveillance organisationnelle, de même que les rôles et responsabilités des utilisatrices et utilisateurs en ce qui a trait aux services de systèmes externes
  3. Mettre en œuvre sur une base continue des processus, des méthodes et des techniques pour surveiller la conformité aux contrôles des fournisseurs de services externes : [Affectation : méthodes, techniques et processus définis par l’organisation]

Discussion

Les services de systèmes externes sont fournis par un fournisseur externe et l’organisation n’exerce aucun contrôle direct sur le plan de la mise en œuvre des contrôles requis ou de l’évaluation de l’efficacité de ces contrôles. Les organisations peuvent établir des relations avec des fournisseurs de services externes de nombreuses façons, y compris au moyen de partenariats, de contrats, d’ententes interorganismes, d’ententes liées aux secteurs d’activités, d’accords de licence, de coentreprises et d’échanges de chaîne d’approvisionnement.

La responsabilité en matière de gestion des risques pouvant découler du recours à des services de systèmes externes continue d’incomber aux autorités responsables. Dans le cas des services externes, la chaîne d’approbation exige que les organisations créent et maintiennent un certain niveau de confiance en la capacité de chaque fournisseur participant à une relation client-fournisseur d’assurer une protection adéquate des services rendus. La portée et la nature de cette chaîne d’approbation varient en fonction des relations établies entre les organisations et les fournisseurs externes. Les organisations documentent les bases de la relation d’approbation pour que celle-ci puisse faire l’objet d’une surveillance.

La documentation des services de systèmes externes comprend les rôles et responsabilités du gouvernement, des fournisseurs de services et des utilisatrices et utilisateurs terminaux en matière de sécurité, ainsi que tout accord sur les niveaux de service pertinent. Les accords sur les niveaux de service définissent les attentes de rendement pour les contrôles mis en œuvre, décrivent les résultats mesurables et identifient les exigences en matière de solution et d’intervention pour les situations de non-respect qui ont été relevées.

Contrôles et activités connexes

AC-20, CA-03, CP-02, IR-04, IR-07, PL-10, PL-11, PS-07, SA-02, SA-04, SR-03, SR-05 et SA-400.

Améliorations

  • (01) Services de systèmes externes : Évaluations des risques et approbations organisationnelles
      1. Procéder à une évaluation des risques organisationnels avant d’acquérir ou d’externaliser des services de sécurité de l’information
      2. S’assurer que l’acquisition ou l’externalisation des services de sécurité de l’information est approuvée par [Affectation : personnel ou rôles définis par l’organisation]
    • Discussion : Les services de sécurité de l’information comprennent l’utilisation de dispositifs de sécurité, comme des pare-feu ou des services de gestion des clés, ainsi que la surveillance des incidents, leur analyse et les interventions connexes. Les risques évalués peuvent comprendre les risques liés au système, à la mission ou aux activités, à la sécurité, à la protection de la vie privée ou à la chaîne d’approvisionnement.
    • Contrôles et activités connexes : CA-06, RA-03 et RA-08.
  • (02) Services de systèmes externes : Établissement des fonctions, des ports, des protocoles et des services
    • Exiger que les fournisseurs de services de systèmes externes identifient les fonctions, les ports, les protocoles et les autres services nécessaires à l’utilisation des services en question : [Affectation : services de systèmes externes définis par l’organisation].
    • Discussion : L’information provenant de fournisseurs de services externes en ce qui a trait aux fonctions, aux ports, aux protocoles et aux services utilisés aux fins de la prestation des services en question peut s’avérer utile lorsqu’il s’agit de comprendre pourquoi il est avantageux d’imposer certaines restrictions à des services ou à des fonctions ou encore de bloquer certains ports ou protocoles.
    • Contrôles et activités connexes : CM-06 et CM-07.
  • (03) Services de systèmes externes : Établissement et maintien d’une relation de confiance avec les fournisseurs de services
    • Établir, documenter et maintenir des relations de confiance avec les fournisseurs de services externes en fonction des exigences, des propriétés, des conditions ou des facteurs suivants : [Affectation : exigences de sécurité et de protection de la vie privée, propriétés, conditions ou facteurs définis par l’organisation qui constituent des relations de confiance acceptables].
    • Discussion : Les relations de confiance entre les organisations et les fournisseurs de services externes reflètent le degré de confiance que le risque associé à l’utilisation des services externes se situe à un niveau acceptable. La relation de confiance permet aux organisations d’accroître le degré de certitude à l’égard de l’aptitude des fournisseurs de services à garantir un rendement adéquat en matière de sécurité. Elle peut également s’avérer utile au moment de prendre des mesures d’intervention en cas d’incident ou de planifier des mises à niveau ou une obsolescence.
      De telles relations peuvent s’avérer compliquées en raison du nombre potentiellement élevé d’entités qui prennent part aux interactions avec la clientèle, des relations hiérarchiques et des niveaux de confiance, ainsi que de la nature des interactions entre les diverses parties. Dans certains cas, le degré de confiance se fonde sur le niveau de contrôle que les organisations peuvent exercer sur les fournisseurs de services externes pour ce qui a trait aux contrôles nécessaires pour assurer la protection du service, de l’information ou de la vie privée des individus, ainsi que sur les facteurs permettant de prouver l’efficacité des contrôles mis en place. Le niveau de contrôle est déterminé par les conditions générales d’utilisation énoncées dans les contrats ou les accords sur les niveaux de service.
    • Contrôles et activités connexes : SR-02.
  • (04) Services de systèmes externes : Concordance des intérêts des clients et des fournisseurs
    • Prendre les mesures suivantes pour confirmer que les intérêts de [Affectation : fournisseurs de services externes désignés par l’organisation] répondent aux intérêts de l’organisation : [Affectation : actions définies par l’organisation].
    • Discussion : Comme les organisations comptent de plus en plus sur les services de fournisseurs externes, il est possible que les intérêts des organisations et des fournisseurs divergent. Dans de telles situations, la simple application de contrôles techniques, procéduraux ou opérationnels pourrait s’avérer insuffisante, particulièrement lorsque les fournisseurs responsables de la mise en œuvre et de la gestion de ces contrôles fonctionnent selon des modalités qui ne correspondent pas aux intérêts des organisations clientes. Pour résoudre de telles questions, les organisations peuvent prendre diverses mesures, comme exiger des vérifications des antécédents de certaines et certains membres du personnel des fournisseurs externes, examiner les registres de propriété, embaucher des fournisseurs de services dont la fiabilité est démontrée (comme des fournisseurs qui ont satisfait aux exigences d’autres organisations) et procéder à des visites périodiques, routinières ou inopinées des installations de fournisseurs de services.
    • Contrôles et activités connexes : Aucun.
  • (05) Services de systèmes externes : Lieux de traitement, de stockage et de service
    • Circonscrire les lieux de [Sélection (un choix ou plus) : traitement de l’information; stockage de l’information ou de données; services de systèmes] à [Affectation : lieux désignés par l’organisation] en se fondant sur [Affectation : exigences ou conditions définies par l’organisation].
    • Discussion : Le choix des lieux de prestation des services essentiels de traitement et de stockage de l’information, ou l’emplacement des systèmes peut avoir une incidence directe sur l’aptitude des organisations à exécuter adéquatement les fonctions liées à leur mission et à leurs activités. Ce type de situation se présente lorsque des fournisseurs externes administrent eux-mêmes les lieux de traitement, de stockage ou de service. Les critères que les fournisseurs de services utilisent pour sélectionner les lieux de traitement, de stockage ou de service peuvent être différents de ceux employés par l’organisation.
      Par exemple, les organisations pourraient vouloir restreindre les emplacements de stockage des données ou de l’information à certains lieux pour faciliter les activités d’intervention lors d’incidents touchant la sécurité de l’information ou de violations de données. Les activités d’intervention en cas d’incident, notamment les analyses criminalistiques et les enquêtes après coup des incidents, pourraient être entravées par les lois ou les protocoles en vigueur dans les sites où le traitement et le stockage ont lieu ou dans les sites depuis lesquels les services de systèmes s’exécutent.
    • Contrôles et activités connexes : SA-05, SA-400 et SR-04.
  • (06) Services de systèmes externes : Clés cryptographiques contrôlées par l’organisation
    • Maintenir un contrôle exclusif des clés cryptographiques pour le matériel chiffré stocké ou transmis par l’entremise d’un système externe.
    • Discussion : Maintenir le contrôle exclusif des clés cryptographiques dans un système externe empêche le personnel du système externe de déchiffrer les données organisationnelles. Le contrôle organisationnel des clés cryptographiques peut être mis en place en chiffrant et déchiffrant les données dans l’organisation alors que les données sont envoyées et reçues depuis un système externe ou en ayant recours à un composant qui permet d’utiliser localement les fonctions de chiffrement et de déchiffrement sur le système externe tout en permettant un accès organisationnel exclusif aux clés de chiffrement.
    • Contrôles et activités connexes : SC-12, SC-13 et SI-04.
  • (07) Services de systèmes externes : Vérification de l’intégrité contrôlée par l’organisation
    • Fournir la capacité de vérifier l’intégrité de l’information qui réside sur le système externe.
    • Discussion : Le stockage de l’information organisationnelle dans un système externe ne devrait permettre qu’une visibilité limitée de l’état de sécurité de ses données. La capacité de l’organisation de vérifier et de valider l’intégrité des données qui y sont stockées sans les transférer au système externe offre une telle visibilité.
    • Contrôles et activités connexes : SI-07.
  • (08) Services de systèmes externes : Lieu de stockage et de traitement (au Canada)
    • Restreindre le lieu géographique du traitement de l’information et du stockage des données aux installations situées dans la frontière gouvernementale et juridique du Canada.
    • Discussion : Le choix du lieu géographique de la prestation des services essentiels de traitement et de stockage de l’information peut avoir une incidence directe sur l’aptitude des organisations à exécuter adéquatement les fonctions liées à leur mission et à leurs activités. Une compromission ou une violation de l’information et des systèmes à incidence élevée peut avoir des conséquences négatives ou catastrophiques sur les biens ou les activités de l’organisation, les individus, les autres organisations et le Canada. Restreindre le traitement et le stockage de l’information à incidence élevée aux installations dans la frontière gouvernementale et juridique du Canada permet de fournir un plus grand contrôle sur un tel traitement et un tel stockage.
    • Contrôles et activités connexes : SA-05, SA-400 et SR-04.

Références

Haut de la page 
 

SA-10 Gestion des configurations par les développeuses et développeurs

Activité:Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte s’assure de

  1. procéder à la gestion des configurations au cours [Sélection (un choix ou plus) : de la conception; du développement; de la mise en œuvre; de l’exploitation; de l’élimination] du système, du composant ou du service
  2. documenter, gérer et contrôler l’intégrité des changements apportés aux [Affectation : éléments de configuration définis par l’organisation dans le cadre de la gestion des configurations]
  3. mettre en œuvre uniquement les changements approuvés par l’organisation au système, au composant ou au service
  4. documenter les changements approuvés apportés au système, au composant ou au service et les répercussions potentielles de tels changements sur la sécurité et la protection de la vie privée
  5. assurer le suivi des failles de sécurité informatique et de leur résolution dans le système, le composant ou le service et faire rapport des conclusions au [Affectation : personnel désigné par l’organisation]

Discussion

Les organisations considèrent la qualité et l’achèvement des activités de gestion des configurations menées par les développeuses et développeurs comme des preuves directes de l’application efficace des contrôles de sécurité. Les contrôles comprennent la protection contre la modification ou la destruction non autorisée des copies maîtresses de tout le matériel utilisé pour générer certains aspects de la sécurité matérielle, logicielle ou micrologicielle du système. Le maintien de l’intégrité des changements apportés au système, au composant du système ou au service qui s’y rapporte exige que le contrôle rigoureux des configurations tout au long du cycle de développement du système fasse en sorte d’enregistrer les changements autorisés et d’empêcher les changements non autorisés.

Les éléments de configuration qui font partie de la gestion des configurations sont les suivants : le modèle formel; les spécifications de conception fonctionnelles, de haut niveau et de bas niveau; les autres données de conception; la documentation relative à la mise en œuvre; les schémas relatifs au code source et aux composants matériels; la version actuelle du code objet; les outils de comparaison des descriptions de nouvelles versions de composants matériels et de code source servant à la sécurité avec les versions précédentes; ainsi que les accessoires et la documentation de test.

Selon les besoins liés à la mission et aux activités des organisations ou la nature des relations contractuelles en vigueur, les développeuses et développeurs peuvent assurer la gestion des configurations pendant les phases d’exploitation et de maintenance du cycle de développement du système.

Contrôles et activités connexes

CM-02, CM-03, CM-04, CM-07, CM-09, SA-04, SA-05, SA-08, SA-15, SI-02, SR-03, SR-04, SR-05 et SR-06.

Améliorations

  • (01) Gestion des configurations par les développeuses et développeurs : Vérification de l’intégrité des logiciels et des micrologiciels
    • Exiger que la développeuse ou le développeur du système, du composant de système ou du service qui s’y rapporte vérifie l’intégrité des composants logiciels et micrologiciels.
    • Discussion : La vérification de l’intégrité des logiciels et des micrologiciels permet aux organisations de détecter les changements non autorisés apportés aux composants logiciels et micrologiciels au moyen d’outils, de techniques et de mécanismes fournis par la développeuse ou le développeur. Les mécanismes de vérification de l’intégrité peuvent également détecter la contrefaçon de composants logiciels et micrologiciels. Les organisations vérifient l’intégrité des logiciels et des micrologiciels au moyen, par exemple, du hachage unidirectionnel sécurisé fourni par les développeuses et développeurs. Les logiciels et micrologiciels qui sont produits incluent également les mises à jour qui doivent être appliquées à ces logiciels et micrologiciels.
    • Contrôles et activités connexes : SI-07 et SR-11.
  • (02) Gestion des configurations par les développeuses et développeurs : Processus de gestion des configurations de rechange
    • Prévoir un processus de gestion des configurations de rechange auquel participent des membres du personnel en l’absence d’une équipe de développeuses et développeurs ou d’intégratrices et intégrateurs spécialisés en gestion des configurations.
    • Discussion : Le processus de gestion des configurations de rechange peut être requis si les organisations utilisent des produits informatiques COTS. Les processus de gestion des configurations de rechange comprennent le personnel de l’organisation qui examine et approuve les changements proposés à apporter aux systèmes, aux composants de systèmes et aux services qui s’y rapportent, et qui est chargé de mener des analyses des répercussions sur la sécurité et la protection de la vie privée avant la mise en œuvre de tout changement apporté aux systèmes, aux composants ou aux services.
    • Contrôles et activités connexes : Aucun.
  • (03) Gestion des configurations par les développeuses et développeurs : Vérification de l’intégrité du matériel
    • Exiger que la développeuse ou le développeur du système, du composant de système ou du service qui s’y rapporte vérifie l’intégrité des composants matériels.
    • Discussion : La vérification de l’intégrité du matériel permet aux organisations de détecter les changements non autorisés apportés aux composants matériels au moyen d’outils, de techniques, de méthodes et de mécanismes fournis par la développeuse ou le développeur. Les organisations peuvent vérifier l’intégrité des composants matériels en exigeant des étiquettes irreproductibles et des numéros de série vérifiables fournis par les développeuses et développeurs et en imposant l’utilisation de mécanismes d’inviolabilité. Les composants matériels qui sont produits incluent également les mises à jour matérielles et micrologicielles qui doivent être appliquées à ces composants.
    • Contrôles et activités connexes : SI-07.
  • (04) Gestion des configurations par les développeuses et développeurs : Génération fiable
    • Exiger que la développeuse ou le développeur d’un système, d’un composant du système ou d’un service qui s’y rapporte emploie des outils permettant de comparer les versions nouvellement générées aux versions précédentes des descriptions, du code source et du code objet des composants matériels servant à la sécurité.
    • Discussion : La génération fiable des descriptions, du code source et du code objet tient compte des changements autorisés apportés aux composants matériels, logiciels et micrologiciels d’une version à l’autre au cours de leur développement. Elle met l’accent sur l’efficacité du processus de gestion des configurations des développeuses et développeurs et visent à s’assurer que les versions nouvellement générées des descriptions, du code source et du code objet du matériel servant à la sécurité continuent d’appliquer la stratégie de sécurité du système, du composant de système ou du service qui s’y rapporte. En revanche, les contrôles SA-10(01) et SA-10(03) permettent aux organisations de détecter les changements non autorisés apportés aux composants matériels, logiciels et micrologiciels au moyen des outils, des techniques ou des mécanismes fournis par les développeuses et développeurs.
    • Contrôles et activités connexes : Aucun.
  • (05) Gestion des configurations par les développeuses et développeurs : Intégrité du mappage pour le contrôle des versions
    • Exiger que la développeuse ou le développeur d’un système, d’un composant du système ou d’un service qui s’y rapporte maintienne l’intégrité du mappage entre les données de la version maîtresse qui décrivent, d’une part, la version actuelle du matériel, des logiciels et des micrologiciels servant à la sécurité et, d’autre part, la copie maîtresse des données de la version qui se trouve actuellement sur le site.
    • Discussion : L’intégrité du mappage pour le contrôle des versions permet de résoudre la question des changements apportés aux composants matériels, logiciels et micrologiciels au cours du développement initial et des mises à jour du cycle de vie du système. Il est essentiel de maintenir l’intégrité entre les copies maîtresses des composants matériels, logiciels et micrologiciels servant à la sécurité (y compris les éléments de conception, les schémas du matériel et le code source) et les données équivalentes des copies maîtresses dans les environnements opérationnels pour garantir la disponibilité des systèmes organisationnels dont dépendent les fonctions liées à la mission et aux activités de l’organisation.
    • Contrôles et activités connexes : Aucun.
  • (06) Gestion des configurations par les développeuses et développeurs : Distribution fiable
    • Exiger que la développeuse ou le développeur d’un système, d’un composant du système ou d’un service qui s’y rapporte exécute les procédures visant à garantir que les mises à jour des composants matériels, logiciels et micrologiciels servant à la sécurité, qui sont distribuées à l’organisation sont en tout point conformes aux spécifications des copies maîtresses.
    • Discussion : La distribution fiable des mises à jour des composants matériels, logiciels et micrologiciels servant à la sécurité permet de garantir que les mises à jour en question constituent des représentations fidèles des copies maîtresses maintenues par la développeuse ou le développeur et qu’elles n’ont pas été trafiquées en cours de distribution.
    • Contrôles et activités connexes : Aucun.
  • (07) Gestion des configurations par les développeuses et développeurs : Représentantes et représentants de la sécurité et de la protection de la vie privée
    • Exiger que [Affectation : représentante ou représentant de la sécurité et de la protection de la vie privée désigné par l’organisation] soit membre de [Affectation : processus de gestion et de contrôle des configurations défini par l’organisation].
    • Discussion : Les représentantes et représentants en matière de sécurité et de protection de la vie privée de l’information peuvent comprennent les responsables de la sécurité des systèmes, les cadres supérieures et supérieurs de la gouvernance en matière de sécurité du ministère, les hauts fonctionnaires ou cadres supérieures et supérieurs en matière de protection de la vie privée et les responsables de la protection de la vie privée des systèmes. Il est important d’avoir parmi le personnel des représentantes et représentants qui sont dotés d’une expertise en sécurité de l’information, car les changements aux configurations des systèmes peuvent avoir des répercussions imprévues, dont certaines pouvant avoir trait à la sécurité ou à la protection de la vie privée. La détection rapide de ces changements permet d’éviter des conséquences négatives inattendues qui pourraient avoir des conséquences sur l’état de sécurité et de protection de la vie privée des systèmes. Le processus de gestion et de contrôle des configurations de cette amélioration reflète celui défini par l’organisation dans le contrôle SA-10B.
    • Contrôles et activités connexes : Aucun.

Références

Haut de la page 
 

SA-11 Évaluations et tests effectués par les développeuses et développeurs

Activité

Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte fasse ce qui suit à toutes les phases de postconception du cycle de développement du système de manière à

  1. élaborer et mettre en œuvre un plan pour les évaluations des contrôles de sécurité et de protection de la vie privée en cours
  2. procéder au test ou à l’évaluation [Sélection (un choix ou plus) : unité; intégration; système; régression] tous les [Affectation : fréquence définie par l’organisation] selon [Affectation : profondeur et couverture définies par l’organisation]
  3. fournir une preuve de l’élaboration d’un plan d’évaluation et des résultats des tests ou de l’évaluation
  4. mettre en œuvre un processus vérifiable de correction des défauts
  5. corriger les défauts relevés au cours des tests et de l’évaluation

Discussion

Des tests et des évaluations confirment que les contrôles requis ont été adéquatement mis en œuvre, qu’ils fonctionnent selon les attentes, qu’ils permettent d’appliquer la stratégie de sécurité et de protection de la vie privée en vigueur et qu’ils répondent aux exigences de sécurité et de protection de la vie privée établies. L’interconnexion des composants de systèmes ou les changements apportés à ces derniers pourraient influer sur les propriétés de sécurité des systèmes et la vie privée des utilisatrices et utilisateurs. Ces interconnexions ou changements, comme la mise à niveau ou le remplacement d’applications, de systèmes d’exploitation et de micrologiciels, peuvent avoir un effet défavorable sur les contrôles mis en œuvre précédemment.

Une évaluation continue au cours du développement fournit des modalités de test et d’évaluation complémentaires que les développeuses et développeurs peuvent utiliser dans le but de réduire ou d’éliminer les défauts éventuels. Les tests liés à des applications logicielles sur mesure peuvent exiger le recours à des approches, comme l’examen manuel du code, l’examen de l’architecture de sécurité, les tests d’intrusion, ainsi que l’analyse statique, l’analyse dynamique, l’analyse binaire ou une combinaison de ces trois types d’analyse.

Les développeuses et développeurs peuvent utiliser les approches d’analyse, ainsi que l’instrumentation de sécurité et les tests à données aléatoires, dans une gamme d’outils et dans le cadre des examens du code source. Les plans d’évaluation de la sécurité et de la protection de la vie privée comprennent les activités que les développeuses et développeurs seront appelés à mener, notamment des analyses, des tests, des évaluations et des examens visant des composants logiciels ou micrologiciels, le degré de rigueur à respecter, la fréquence des tests et des évaluations en cours, ainsi que les types d’artéfacts produits durant ces activités.

La profondeur des tests et des évaluations porte sur le degré de rigueur et de détail associé au processus d’évaluation. L’envergure des tests et des évaluations renvoie à la portée (par exemple, le nombre et le type) des artéfacts compris dans le processus d’évaluation. Les contrats contiennent les critères d’acceptation relatifs aux plans d’évaluation de la sécurité et de la protection de la vie privée, les processus de correction des lacunes ainsi que les preuves que les plans et les processus ont été appliqués rigoureusement et en temps opportun. Les méthodes d’examen et de protection des plans d’évaluation, des preuves et de la documentation sont proportionnelles à la catégorie de sécurité ou au niveau de classification du système visé. Les contrats peuvent préciser les exigences relatives à la protection des documents.

Contrôles et activités connexes

CA-02, CA-07, CM-04, SA-03, SA-04, SA-05, SA-08, SA-15, SA-17, SI-02, SR-05, SR-06 et SR-07.

Améliorations

  • (01) Évaluations et tests effectués par les développeuses et développeurs : Analyse statique du code
    • Exiger que la développeuse ou le développeur d’un système, d’un composant du système ou du service qui s’y rapporte utilise des outils d’analyse statique du code pour identifier les défauts courants et documenter les résultats de l’analyse.
    • Discussion : L’analyse statique du code dicte la technologie et la méthodologie employées pour les examens de sécurité et comprend une vérification des lacunes dans le code, ainsi que l’intégration de code ou de bibliothèques qui contiennent des vulnérabilités connues ou qui sont désuets et non pris en charge. L’analyse statique du code peut être utilisée pour relever les vulnérabilités et imposer l’adoption des pratiques de codage sécurisé. Elle est particulièrement efficace lorsqu’elle est utilisée dans les premières phases du processus de développement, au moment où les changements de code peuvent être automatiquement analysés dans le but de trouver les lacunes. L’analyse statique du code peut fournir des conseils clairs en matière de correction et relever les défauts à corriger par les développeuses et développeurs. Les preuves d’une mise en œuvre adéquate de l’analyse statique peuvent comprendre l’agrégation de la densité des défauts pour les types de défauts critiques, la preuve que les défauts ont été inspectés par les développeuses, les développeurs ou les spécialistes de la sécurité et les preuves que les défauts ont été corrigés. Une forte densité de résultats ignorés (couramment appelés de faux positifs) pourrait être le symptôme d’un problème lié au processus ou à l’outil d’analyse. Dans de tels cas, les organisations établissent la validité des preuves en les comparant à celles obtenues d’autres sources.
    • Contrôles et activités connexes : Aucun.
  • (02) Évaluations et tests effectués par les développeuses et développeurs : Modélisation des menaces et analyses des vulnérabilités
    • Exiger que la développeuse ou le développeur du système, du composant ou du service qui s’y rapporte effectue une modélisation des menaces et des analyses des vulnérabilités au cours du développement, ainsi que des tests et une évaluation du système, du composant ou du service qui
      1. utilise l’information contextuelle suivante : [Affectation : information relative aux répercussions définie par l’organisation, environnement opérationnel, menaces connues ou présumées, et niveaux acceptables de risque]
      2. utilise les méthodes et les outils suivants : [Affectation : méthodes et outils définis par l’organisation]
      3. procède à la modélisation et à l’analyse du niveau de rigueur suivant : [Affectation : profondeur et étendue de modélisation et d’analyse définies par l’organisation]
      4. démontre que les critères d’acceptation suivants ont été respectés : [Affectation : critères d’acceptation définis par l’organisation]
    • Discussion : Les systèmes, les composants de systèmes et les services qui s’y rapportent peuvent s’écarter considérablement des spécifications fonctionnelles et de conception qui ont été créées pendant les phases de conception et de formulation des exigences du cycle de développement des systèmes. Par conséquent, les mises à jour des analyses des menaces et des vulnérabilités de ces systèmes, de ces composants de systèmes ou des services qui s’y rapportent, qui sont effectuées en cours de développement et avant la mise en service, sont essentielles à une exploitation efficace des systèmes, des composants et des services en question. Les analyses des vulnérabilités et la modélisation des menaces, à cette phase du cycle de développement des systèmes, permettent de veiller à ce que les changements apportés à la conception et à la mise en œuvre soient pris en compte et que les vulnérabilités résultant de ces changements soient examinées et fassent l’objet de mesures d’atténuation.
    • Contrôles et activités connexes : PM-15, RA-03 et RA-05.
  • (03) Évaluations et tests effectués par les développeuses et développeurs : Vérification indépendante des plans d’évaluation et des preuves
      1. Exiger que [Affectation : critères d’indépendance définis par l’organisation] soit en mesure d’attester de l’adéquation de la mise en œuvre du plan d’évaluation de sécurité et de vérifier les preuves produites pendant les tests et les évaluations
      2. Veiller à ce que l’agente ou agent indépendant ait reçu suffisamment d’information pour mener à bien le processus de vérification ou qu’il dispose de l’autorité nécessaire pour obtenir l’information en question
    • Discussion : Les agentes et agents indépendants possèdent les compétences nécessaires (par exemple, l’expertise, les aptitudes, la formation, les certifications et l’expérience) pour attester de l’adéquation de la mise en œuvre des plans d’évaluation de la sécurité et de la protection de la vie privée formulés par les développeuses ou développeurs.
    • Contrôles et activités connexes : AT-03, RA-05.
  • (04) Évaluations et tests effectués par les développeuses et développeurs : Revues manuelles du code
    • Exiger que la développeuse ou le développeur d’un système, d’un composant du système ou du service qui s’y rapporte procède à la revue manuelle du code de [Affectation : code particulier désigné par l’organisation] au moyen des procédures, des techniques ou des processus suivants : [Affectation : procédures, techniques et processus définis par l’organisation].
    • Discussion : Les revues manuelles du code sont généralement réservées aux composants fondamentaux (logiciels et micrologiciels) des systèmes. Ces revues de code sont efficaces, lorsqu’il s’agit de relever les lacunes nécessitant une connaissance des exigences ou du contexte relatifs à l’application, lesquels sont généralement inaccessibles aux techniques et aux outils automatisés d’analyse comme les analyses statiques ou dynamiques. Les avantages de la revue manuelle du code comprennent la possibilité de comparer les matrices de contrôle d’accès aux contrôles d’application et l’examen approfondi des mises en œuvre et des contrôles cryptographiques.
    • Contrôles et activités connexes : Aucun.
  • (05) Évaluations et tests effectués par les développeuses et développeurs : Tests d’intrusion
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte procède à des tests d’intrusion
      1. au niveau de rigueur suivant : [Affectation : profondeur et étendue des tests définies par l’organisation]
      2. selon les contraintes suivantes : [Affectation : contraintes définies par l’organisation]
    • Discussion : Le test d’intrusion est une méthodologie d’évaluation au cours de laquelle les évaluatrices et évaluateurs ont recours à toute la documentation accessible sur des produits informatiques ou des systèmes et se conforment à des contraintes prédéterminées pour tenter de contourner les fonctions de sécurité et de protection de la vie privée mises en œuvre dans les produits informatiques et les systèmes.
      Parmi les renseignements utiles nécessaires aux évaluatrices et évaluateurs qui effectuent les tests d’intrusion, on retrouve les spécifications de conception des produits et des systèmes, le code source et les guides d’administration et d’utilisation. Les tests d’intrusion peuvent comprendre notamment les tests en boîte blanche, grise ou noire combinés à des analyses menées par des spécialistes chevronnées et chevronnés, qui visent à simuler des attaques.
      L’objectif des tests d’intrusion est de découvrir les vulnérabilités dans les systèmes, les composants de systèmes et les services qui peuvent résulter d’erreurs de mise en œuvre, de fautes de configuration ou encore de lacunes ou défectuosités opérationnelles. Les tests d’intrusion peuvent être effectués conjointement avec les revues manuelles et automatisées du code dans le but de produire un niveau d’analyse plus élevé que celui que l’on retrouve couramment.
      Si l’information des sessions utilisateur et d’autres renseignements personnels sont collectés ou enregistrés au cours des tests d’intrusion, il convient de les traiter de façon appropriée pour en protéger la protection de la vie privée.
    • Contrôles et activités connexes : CA-08, PM-14, PM-25, PT-02, SA-03, SI-02 et SI-06.
  • (06) Évaluations et tests effectués par les développeuses et développeurs : Examens de la surface d’attaque
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte procède à des examens de la surface d’attaque.
    • Discussion : Les surfaces d’attaque des systèmes et des composants de systèmes sont des secteurs exposés qui accentuent la vulnérabilité des systèmes aux cyberattaques. Les surfaces d’attaque comprennent tous les secteurs accessibles où des faiblesses ou des défauts touchant les composants matériels, logiciels et micrologiciels pourraient être exploités par des adversaires. Les examens de la surface d’attaque visent à s’assurer que les développeuses et développeurs analysent les changements de conception et de mise en œuvre apportés aux systèmes et atténuent les vecteurs d’attaque générés consécutivement aux changements. La correction des défauts signalés comprend la proscription des fonctions risquées.
    • Contrôles et activités connexes : SA-15.
  • (07) Évaluations et tests effectués par les développeuses et développeurs : Vérification de la portée des tests et des évaluations
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte s’assure que la portée des tests et des évaluations fournit une couverture complète des contrôles requis au niveau de rigueur suivant : [Affectation : profondeur et étendue des tests et des évaluations définies par l’organisation].
    • Discussion : Il est possible de vérifier si les tests et les évaluations fournissent une couverture complète des contrôles requis en faisant appel à diverses techniques d’analyse formelle ou informelle. Chacune de ces techniques fournit un niveau d’assurance accru qui correspond au degré de formalité de l’analyse. Il est possible de rigoureusement démontrer que la couverture des contrôles atteint des niveaux supérieurs d’assurance en recourant à la modélisation formelle et à des techniques d’analyse comme la corrélation entre la mise en œuvre de contrôles et des scénarios de tests comparables.
    • Contrôles et activités connexes : SA-15.
  • (08) Évaluations et tests effectués par les développeuses et développeurs : Analyse dynamique du code
    • Exiger que la développeuse ou le développeur d’un système, d’un composant du système ou du service qui s’y rapporte utilise des outils d’analyse dynamique du code pour relever les défauts courants et documenter les résultats de l’analyse.
    • Discussion : L’analyse dynamique du code fournit une vérification d’exécution des programmes informatiques au moyen d’outils permettant de signaler l’occurrence de corruption de la mémoire, ainsi que les problèmes liés aux privilèges des utilisatrices et utilisateurs ou d’autres éventuels problèmes de sécurité. L’analyse dynamique du code met à profit des outils d’exécution pour vérifier si les fonctionnalités de sécurité s’exécutent comme prévu.
      Il existe un type d’analyse dynamique, que l’on nomme également test à données aléatoires, qui provoque des défaillances de programme en introduisant délibérément des données mal formatées ou aléatoires dans les programmes informatiques. Les stratégies des tests à données aléatoires se fondent sur l’utilisation prévue des applications et sur les spécifications de fonctions et de conception des applications.
      Pour comprendre la portée des analyses dynamiques du code et de l’assurance qu’elle fournit, les organisations peuvent également envisager de mener des analyses de couverture de code (par exemple, la vérification du degré auquel le code a été testé au moyen de mesures, comme le pourcentage des sous-routines testées ou le pourcentage des instructions de programme appelées pendant l’exécution de la suite de tests) et/ou des analyses de concordance (par exemple, le signalement des mots qui sont mal placés dans le code du logiciel, notamment les termes dérogatoires ou les mots qui ne sont pas de l’anglais ou du français).
    • Contrôles et activités connexes : Aucun.
  • (09) Évaluations et tests effectués par les développeuses et développeurs : Tests de sécurité des applications interactives
    • Exiger que la développeuse ou le développeur d’un système, d’un composant du système ou du service qui s’y rapporte utilise des outils de tests de la sécurité des applications interactives pour relever les défauts et documenter les résultats.
    • Discussion : Les tests de sécurité des applications interactives (également connus pour être axés sur l’instrumentation) permettent de détecter les vulnérabilités en observant les applications lors de leur exécution dans le cadre du test. Le recours à l’instrumentation repose sur des mesures directes des applications en cours d’exécution et utilise l’accès au code, aux interactions avec les utilisatrices et utilisateurs, aux bibliothèques, aux cadres d’applications, aux connexions d’arrière-plan et aux configurations pour mesurer directement l’efficacité des contrôles.
      Lorsqu’ils sont combinés à des techniques d’analyse, les tests de sécurité des applications interactives peuvent relever les vulnérabilités potentielles et confirmer l’efficacité des contrôles. Les tests axés sur l’instrumentation s’effectuent en temps réel et peuvent être utilisés tout au long du cycle de développement des systèmes.
    • Contrôles et activités connexes : Aucun.

Références

Haut de la page 
 

SA-12 Protection de la chaîne d’approvisionnement

Annulé : Transféré sous la famille de contrôles SR.

Améliorations

  • (01) Protection de la chaîne d’approvisionnement : Stratégies, outils et méthodes d’acquisition
    • Annulé : Transféré sous le contrôle SR-05.
  • (02) Protection de la chaîne d’approvisionnement : Examen des fournisseurs
    • Annulé : Transféré sous le contrôle SR-06.
  • (03) Protection de la chaîne d’approvisionnement : Expédition et entreposage sécurisés
    • Annulé : Intégré au contrôle SR-03.
  • (04) Protection de la chaîne d’approvisionnement : Diversité des fournisseurs
    • Annulé : Transféré sous le contrôle SR-03(01).
  • (05) Protection de la chaîne d’approvisionnement : Limitation des dommages
    • Annulé : Transféré sous le contrôle SR-03(02).
  • (06) Protection de la chaîne d’approvisionnement : Réduction du temps d’approvisionnement
    • Annulé : Intégré au contrôle SR-05(01).
  • (07) Protection de la chaîne d’approvisionnement : Évaluation préalable à la sélection, à l’acceptation et à la mise à jour
    • Annulé : Transféré sous le contrôle SR-05(02).
  • (08) Protection de la chaîne d’approvisionnement : Utilisation du renseignement de toutes sources
    • Annulé : Intégré au contrôle RA-03(02).
  • (09) Protection de la chaîne d’approvisionnement : Sécurité opérationnelle
    • Annulé : Transféré sous le contrôle SR-07.
  • (10) Protection de la chaîne d’approvisionnement : Attestation de l’authenticité et de la non-altérité
    • Annulé : Transféré sous le contrôle SR-04(03).
  • (11) Protection de la chaîne d’approvisionnement : Tests d’intrusion et analyse d’éléments, de processus et des parties prenantes
    • Annulé : Transféré sous le contrôle SR-06(01).
  • (12) Protection de la chaîne d’approvisionnement : Accords interorganisationnels
    • Annulé : Transféré sous le contrôle SR-08.
  • (13) Protection de la chaîne d’approvisionnement : Composants de systèmes d’information essentiels
    • Annulé : Intégré au contrôle MA-06 and RA-09.
  • (14) Protection de la chaîne d’approvisionnement : Identité et traçabilité
    • Annulé : Transféré sous le contrôle SR-04(01) and SR-04(02).
  • (15) Protection de la chaîne d’approvisionnement : Processus visant à réagir aux faiblesses et aux lacunes
    • Annulé : Intégré au contrôle SR-03.

SA-13 Fiabilité

Annulé : Intégré au contrôle SA-08.

 

SA-14 Analyse de criticité

Annulé : Intégré au contrôle RA-09.

Améliorations

  • (01) Analyse de criticité : Composants essentiels sans autre source d’approvisionnement viable
    • Annulé : Intégré au contrôle SA-20.
Haut de la page 
 

SA-15 Processus, normes et outils de développement

Activité

  1. Exiger que la développeuse ou le développeur d’un système, d’un composant du système ou d’un service qui s’y rapporte suive un processus de développement documenté qui permet
    1. de répondre explicitement aux exigences de sécurité et de protection de la vie privée
    2. d’identifier les normes et les outils devant servir au processus de développement
    3. de documenter les options et les configurations particulières aux outils utilisés dans le processus de développement
    4. de documenter, de gérer et de garantir l’intégrité des changements apportés aux processus et aux outils servant au développement
  2. Examiner les processus, les normes, les outils, les options d’outils et les configurations d’outils liés au développement [Affectation : fréquence définie par l’organisation] pour établir si les processus, les normes, les outils, les options des outils et les configurations des outils peuvent répondre aux exigences de sécurité et de protection de la vie privée suivantes : [Affectation : exigences de sécurité et de protection de la vie privée définies par l’organisation]

Discussion

Les outils de développement comprennent les langages de programmation et les systèmes de conception assistée par ordinateur. L’examen des processus de développement peut inclure l’utilisation de modèles d’évolution dans le but de définir l’efficacité potentielle des processus en question. Le maintien de l’intégrité des changements dans les outils et les processus facilite une évaluation et une atténuation efficaces de la chaîne d’approvisionnement. Une telle intégrité exige un contrôle des configurations tout au long du cycle de développement des systèmes afin d’assurer le suivi des changements autorisés et de prévenir les changements non autorisés.

Contrôles et activités connexes

MA-06, SA-03, SA-04, SA-08, SA-10, SA-11, SI-02, SR-03, SR-04, SR-05, SR-06 et SR-09.

Améliorations

  • (01) Processus, normes et outils de développement : Mesure de la qualité
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte s’assure de
      1. définir les mesures de la qualité au début du processus de développement
      2. fournir des preuves que les critères de qualité sont respectés à [Sélection (un choix ou plus) : [Affectation : fréquence définie par l’organisation]; [Affectation : échéancier d’examen de programmes défini par l’organisation]; au moment de la mise en service]
    • Discussion : Les organisations ont recours à des paramètres de mesure de la qualité pour établir les niveaux acceptables de qualité des systèmes. Ces paramètres peuvent comprendre des jalons de qualité, qui représentent un ensemble de critères d’accomplissement ou de normes de suffisance qui définissent l’exécution adéquate de phases particulières du projet de développement des systèmes. Par exemple, un jalon de qualité pourrait exiger l’élimination de tous les avertissements de compilateurs ou établir que les avertissements n’ont aucune incidence sur l’efficacité des capacités de sécurité et de protection de la vie privée requises. Pendant l’exécution des phases des projets de développement, les jalons de qualité s’avèrent des indicateurs de progression clairs et précis. D’autres paramètres de mesure s’appliquent à l’intégralité du projet de développement. Les mesures peuvent également inclure la définition des seuils de sévérité des vulnérabilités selon la tolérance au risque de l’organisation, comme exiger l’élimination de toute vulnérabilité connue des systèmes mis en service et la définition des niveaux de sévérité Moyen et Élevé du Common Vulnerability Scoring System (CVSS).
    • Contrôles et activités connexes : Aucun.
  • (02) Processus, normes et outils de développement : Outils de traçabilité des contrôles de sécurité et de protection de la vie privée
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte utilise des outils de traçabilité des contrôles de sécurité et de protection de la vie privée au cours du processus de développement.
    • Discussion : L’objectif est de créer une matrice de traçabilité des exigences de sécurité et de protection de la vie privée. Les équipes de développement de systèmes sélectionnent et déploient des outils de suivi de la sécurité et de la protection de la vie privée, notamment des systèmes de suivi de la vulnérabilité ou des éléments de travail visant à faciliter l’attribution, le triage, le filtrage et le suivi des éléments de travail accomplis ou des tâches associées aux processus de développement.
    • Contrôles et activités connexes : SA-11.
  • (03) Processus, normes et outils de développement : Analyse de criticité
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte procède à une analyse de criticité
      1. aux points de décision suivants dans le cycle de développement du système : [Affectation : points de décision dans le cycle de développement du système définis par l’organisation]
      2. au niveau de rigueur suivant : [Affectation : profondeur et étendue de l’analyse de criticité définies par l’organisation]
    • Discussion : L’analyse de criticité effectuée par la développeuse ou le développeur fournit l’information nécessaire à l’analyse de criticité réalisée par les organisations. L’apport des développeuses et développeurs est essentiel à l’analyse de criticité, puisque les organisations pourraient ne pas avoir accès à la documentation détaillée sur la conception des composants des systèmes qui sont développés en tant que produits COTS. Une telle documentation de conception comprend les spécifications fonctionnelles, les conceptions de haut niveau, les conceptions de bas niveau, le code source et les schémas du matériel.
      L’analyse de criticité est importante pour les systèmes organisationnels qui ont été désignés en tant que biens de grande importance. Les biens de grande importance peuvent être des systèmes à incidence moyenne ou élevée en raison de l’intérêt accru des adversaires ou les conséquences potentiellement négatives sur l’entreprise fédérale. L’apport des développeuses et développeurs est particulièrement important lorsque les organisations procèdent à des analyses de criticité de la chaîne d’approvisionnement.
    • Contrôles et activités connexes : RA-09.
  • (04) Processus, normes et outils de développement : Modélisation des menaces et analyse des vulnérabilités
    • Annulé : Intégré au contrôle SA-11(02).
  • (05) Processus, normes et outils de développement : Réduction de la surface d’attaque
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte réduise les surfaces d’attaque à [Affectation : limites définies par l’organisation].
    • Discussion : La réduction de la surface d’attaque s’aligne étroitement sur les analyses de menaces et de vulnérabilité ainsi que sur l’architecture et la conception des systèmes. La réduction de la surface d’attaque constitue un moyen de réduire les risques encourus par les organisations en limitant considérablement les occasions d’exploiter les faiblesses et les lacunes (par exemple, les vulnérabilités potentielles) inhérentes aux systèmes, aux composants de systèmes et aux services qui s’y rapportent. La réduction de la surface d’attaque comprend la mise en place du concept des défenses par couche, l’application des principes de droit d’accès minimal et de fonctionnalité minimale, l’adoption des pratiques de développement logiciel sécurisé, la proscription des fonctions risquées, la réduction des points d’entrée disponibles aux utilisatrices et utilisateurs non autorisés, la réduction de la quantité de code à exécuter et l’élimination des API qui sont vulnérables aux attaques.
    • Contrôles et activités connexes : AC-06, CM-07, RA-03 et SA-11.
  • (06) Processus, normes et outils de développement : Amélioration continue
    • Exiger que la développeuse ou le développeur d’un système d’information, d’un composant du système ou du service qui s’y rapporte mette en œuvre un processus détaillé visant expressément à améliorer continuellement le processus de développement.
    • Discussion : Les développeuses et développeurs de systèmes, de composants de systèmes et de services qui s’y rapportent évaluent l’efficacité et l’efficience de leurs processus de développement pour faire en sorte qu’ils répondent toujours mieux aux objectifs de qualité et qu’ils soient dotés des capacités de sécurité et de protection de la vie privée requises compte tenu des environnements de menaces.
    • Contrôles et activités connexes : Aucun.
  • (07) Processus, normes et outils de développement : Analyse automatisée des vulnérabilités
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte, [Affectation : fréquence définie par l’organisation]
      1. réalise une analyse automatisée des vulnérabilités au moyen de [Affectation : outils définis par l’organisation]
      2. définisse les possibilités d’exploitation des vulnérabilités relevées
      3. définisse les mesures d’atténuation des risques liés aux vulnérabilités décelées
      4. fournisse les données produites par les outils et les résultats des analyses à [Affectation : personnel ou rôles définis par l’organisation]
    • Discussion : Les outils automatisés peuvent analyser plus efficacement les faiblesses ou lacunes exploitables dans les systèmes vastes et complexes, puisqu’ils hiérarchisent les vulnérabilités selon leur gravité et formulent des recommandations pour l’atténuation des risques.
    • Contrôles et activités connexes : RA-05 et SA-11.
  • (08) Processus, normes et outils de développement : Réutilisation de l’information sur les menaces et les vulnérabilités
    • Exiger que la développeuse ou le développeur d’un système, d’un composant du système ou d’un service qui s’y rapporte utilise une modélisation des menaces et des analyses des vulnérabilités exécutées sur des systèmes, des composants ou des services semblables de façon à éclairer le processus de développement en cours.
    • Discussion : Les analyses des vulnérabilités menées sur des applications logicielles semblables peuvent fournir de précieux renseignements susceptibles de résoudre d’éventuels problèmes de conception et de mise en œuvre dans les systèmes en cours de développement. Des systèmes ou des composants de systèmes semblables pourraient exister au sein des organisations des développeuses et développeurs. De l’information en matière de vulnérabilité est disponible auprès d’une diversité de sources des secteurs privé et public, notamment la National Vulnerability Database du NIST (en anglais seulement).
    • Contrôles et activités connexes : Aucun.
  • (09) Processus, normes et outils de développement : Utilisation de données en temps réel
    • Annulé : Intégré au contrôle SA-03(02).
  • (10) Processus, normes et outils de développement : Plan d’intervention en cas d’incident
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte s’assure d’élaborer, de mettre en œuvre et de mettre à l’essai un plan d’intervention en cas d’incident.
    • Discussion : Le plan d’intervention en cas d’incident remis par les développeuses et développeurs peut fournir de l’information qui n’est pas aisément accessible aux organisations et peut être intégrée aux plans d’intervention en cas d’incident de l’organisation. L’information des développeuses et développeurs peut également être extrêmement utile, notamment lorsque les organisations doivent réagir aux vulnérabilités décelées dans les produits COTS.
    • Contrôles et activités connexes : IR-08.
  • (11) Processus, normes et outils de développement : Système ou composant d’archivage
    • Exiger que la développeuse ou le développeur d’un système ou d’un composant du système archive le système ou le composant à mettre en service avec les preuves connexes qui appuient l’examen de sécurité et de protection de la vie privée final.
    • Discussion : L’archivage du système ou des composants du système exige que la développeuse ou le développeur conserve les principaux artéfacts de développement, ce qui comprend les spécifications du matériel, le code source, le code objet et les documents pertinents du processus de développement susceptibles de fournir une configuration de référence facilement accessible pour les mises à niveau ou les modifications du système et des composants.
    • Contrôles et activités connexes : CM-02.
  • (12) Processus, normes et outils de développement : Réduction des renseignements personnels
    • Exiger que la développeuse ou le développeur du système ou du composant du système limite l’utilisation de renseignements personnels dans les environnements de développement et de test.
    • Discussion : Les organisations peuvent minimiser le risque qui pèse sur la vie privée des individus en faisant appel à des techniques comme la dépersonnalisation ou les données synthétiques. Limiter l’utilisation de renseignements personnels dans les environnements de développement et de test aide à réduire le niveau de risque d’atteinte à la vie privée créé par un système.
    • Discussion au sein du GC : Sauf dans des circonstances exceptionnelles, les environnements de développement et de test ne devraient pas utiliser de renseignements personnels permettant d’identifier des individus. Il est recommandé que la mise à l’essai des systèmes soit effectuée au moyen de fausses données, de données codées ou de renseignements personnels dépersonnalisés. À l’occasion, la mise à l’essai des systèmes pourrait être externalisée. Malgré l’utilisation de renseignements personnels dépersonnalisés, il est recommandé que la documentation sur les marchés exige que le fournisseur tiers supprime les données de test une fois le développement ou les tests terminés afin de protéger les systèmes contre une possible réidenfication ou fuite de données.
    • Contrôles et activités connexes : PM-25, SA-03 et SA-08.
  • (13) Processus, normes et outils de développement : Syntaxe de journalisation
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte utilise [Affectation : format de journalisation sécurisée défini par l’organisation] pour journaliser [Affectation : types d’événements définis par l’organisation] au [Affectation : niveau de détail défini par l’organisation].
    • Discussion : Pour assurer une intervention plus efficace en cas d’incident et permettre de rétablir plus rapidement les actions liées à la sécurité, il convient d’établir des exigences précises pour la journalisation sécurisée et de faire en sorte qu’il soit facile d’associer les données opérationnelles aux journaux d’événements de vérification produits par les applications. Les types d’événements sont conformes à ceux définis au contrôle AU-02.
    • Contrôles et activités connexes : AU-02, AU-03, IR-04, IR-08 et SA-05.

Références

Haut de la page 
 

SA-16 Formation offerte par la développeuse ou le développeur

Contrôle

Exiger que la développeuse ou le développeur d’un système, d’un composant du système ou d’un service qui s’y rapporte fournisse la formation portant sur l’utilisation et l’exploitation adéquates des fonctions, des contrôles et des mécanismes de sécurité et de protection de la vie privée mis en œuvre : [Affectation : formation définie par l’organisation].

Discussion

La formation fournie par la développeuse ou le développeur concerne les développeuses et développeurs externes et internes (de l’organisation en question). L’efficacité des contrôles mis en œuvre dans les systèmes de l’organisation repose sur la formation du personnel. Il peut s’agir d’une formation en ligne et assistée par ordinateur, d’une formation en classe ou d’une formation pratique (comme une microformation). Les organisations peuvent également demander que les développeuses et développeurs fournissent du matériel de formation afin d’offrir des options de formation en interne ou d’autoformation à leurs personnels respectifs. Les organisations établissent le type de formation qui répond à leurs besoins et peuvent demander divers types de formation selon les fonctions, les contrôles ou les mécanismes de sécurité et de protection de la vie privée visés.

Contrôles et activités connexes

AT-02, AT-03, PE-03, SA-04 et SA-05.

Améliorations

Aucune.

Références

SCT, Directive sur la gestion de la sécurité – Annexe H : Procédures obligatoires relatives aux mesures de sécurité dans la sensibilisation à la sécurité et la formation

Haut de la page 
 

SA-17 Architecture et conception de la sécurité et de la protection de la vie privée de la développeuse ou du développeur

Activité

Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte produise des spécifications de conception et une architecture de sécurité et de protection de la vie privée qui

  1. est conforme à l’architecture de sécurité et de protection de la vie privée de l’organisation qui fait partie intégrante de l’architecture d’entreprise de l’organisation
  2. décrit intégralement et précisément les fonctions de sécurité et de protection de la vie privée requises ainsi que l’attribution des contrôles de sécurité parmi les composants physiques et logiques
  3. expose comment les fonctions de sécurité et de protection de la vie privée, les mécanismes et les services fonctionnent ensemble pour fournir les capacités de sécurité requises et favoriser une approche coordonnée en matière de protection

Discussion

L’architecture de sécurité et de protection de la vie privée et la conception des développeuses et développeurs concernent les développeuses et développeurs externes, mais elles pourraient également être appliquées au développement interne. Par opposition, le contrôle PL-08 vise d’abord les développeuses et développeurs internes de façon à ce que les organisations puissent développer une architecture de sécurité et de protection de la vie privée qui s’intègre à l’architecture d’entreprise. La distinction entre les contrôles SA-17 et PL-08 est particulièrement importante lorsque les organisations externalisent le développement des systèmes, des composants de système ou des services qui s’y rapportent et lorsqu’il est impératif de démontrer l’uniformité de l’architecture d’entreprise et celle de sécurité et de protection de la vie privée de l’organisation.

Les documents 15408-2 et 15408-3 de l’ISO/IEC, et l’ITSP.10.037, Activités de gestion des risques pour la cybersécurité et la vie privée tout au long du cycle de vie des systèmes du Centre pour la cybersécurité, fournissent de l’information sur l’architecture et la conception de la sécurité, notamment des modèles de stratégies officiels, des composants relatifs à la sécurité, de la correspondance formelle et informelle, une conception simple et la façon de structurer le droit d’accès minimal et la mise à l’essai.

Contrôles et activités connexes

PL-02, PL-08, PM-07, SA-03, SA-04, SA-08 et SC-07.

Améliorations

  • (01) Architecture et conception de la sécurité et de la protection de la vie privée de la développeuse ou du développeur : Modèle formel de stratégie
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte s’assure de
      1. produire, en parfaite intégration avec le processus de développement, un modèle formel de stratégie décrivant [Affectation : éléments de stratégie organisationnelle de sécurité désignés par l’organisme] à mettre en œuvre
      2. démontrer que le modèle formel de stratégie est cohérent et suffisant pour appliquer les dispositions de la stratégie organisationnelle de sécurité dès lors que celle-ci est en vigueur
    • Discussion : Les modèles formels décrivent des comportements particuliers ou des stratégies de sécurité et de protection de la vie privée en langage formel, ce qui permet de prouver l’adéquation de ces comportements et de ces stratégies de façon formelle. Tous les composants de systèmes ne peuvent pas forcément être modélisés. En règle générale, les spécifications formelles concernent des stratégies ou des comportements particuliers qui revêtent un certain intérêt, comme des stratégies de contrôles d’accès non discrétionnaires. Pour ce qui est du modèle formel de stratégie, les organisations choisissent un langage et une approche en se fondant sur la nature des stratégies et des comportements devant être décrits et sur les outils disponibles.
    • Contrôles et activités connexes : AC-03, AC-04 et AC-25.
  • (02) Architecture et conception de la sécurité et de la protection de la vie privée de la développeuse ou du développeur : Composants servant à la sécurité
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte s’assure de
      1. définir le matériel, les logiciels et les micrologiciels servant à la sécurité
      2. fournir un argumentaire démontrant l’exhaustivité de la définition du matériel, des logiciels et des micrologiciels de sécurité
    • Discussion : Dans le cas d’un système, d’un composant de système ou d’un service qui s’y rapporte, le matériel, les logiciels et les micrologiciels servant à la sécurité forment la partie dont le fonctionnement adéquat sera garant des propriétés de sécurité qui sont exigées.
    • Contrôles et activités connexes : AC-25 et SA-05.
  • (03) Architecture et conception de la sécurité et de la protection de la vie privée de la développeuse ou du développeur : Correspondance formelle
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte s’assure de
      1. produire, en parfaite intégration avec le processus de développement, des spécifications formelles de haut niveau qui décrivent les interfaces du matériel, des logiciels et des micrologiciels servant à la sécurité sur le plan des exceptions, des messages d’erreur et des effets
      2. montrer – par des preuves accessibles et, s’il y a lieu, par des démonstrations informelles – que les spécifications de haut niveau sont conformes au modèle formel de stratégie
      3. montrer, par des démonstrations informelles, que les spécifications formelles de haut niveau prennent en compte toutes les interfaces du matériel, des logiciels et des micrologiciels servant à la sécurité
      4. montrer que les spécifications formelles de haut niveau décrivent précisément le matériel, les logiciels et les micrologiciels utilisés à des fins de sécurité
      5. décrire les mécanismes liés au matériel, aux logiciels et aux micrologiciels servant à la sécurité qui ne sont pas explicitement pris en compte dans les spécifications formelles de haut niveau, mais qui sont inhérents à ce matériel, à ces logiciels et à ces micrologiciels servant à la sécurité
    • Discussion : La correspondance est un élément important de l’assurance gagnée en cours de modélisation. Elle démontre que la mise en œuvre constitue une transformation précise du modèle, et que tout code ou détail de mise en œuvre additionnel n’aura aucune incidence sur les comportements ou sur les stratégies en cours de modélisation.
      Les méthodes formelles peuvent être utilisées pour montrer que la description formelle d’un système est conforme aux propriétés de sécurité de haut niveau, et que la description formelle de système est adéquatement mise en œuvre, et ce, par la description d’un niveau inférieur, notamment la description des composants matériels.
      La cohérence entre les spécifications formelles de haut niveau et les modèles formels de stratégies est généralement impossible à prouver hors de tout doute. Par conséquent, une combinaison de méthodes formelles et informelles pourrait être requise pour démontrer la cohérence. La cohérence entre les spécifications de haut niveau et la mise en œuvre pourraient nécessiter l’utilisation de démonstrations informelles en raison des contraintes liées à l’applicabilité des méthodes formelles dans le but de prouver que les spécifications sont intégralement conformes à la mise en œuvre. Les mécanismes liés au matériel, aux logiciels et aux micrologiciels, qui sont strictement inhérents aux composants servant à la sécurité, comprennent les registres de mappage, ainsi que les entrées et sorties directes liées à la mémoire.
    • Contrôles et activités connexes : AC-03, AC-04, AC-25, SA-04 et SA-05.
  • (04) Architecture et conception de la sécurité et de la protection de la vie privée de la développeuse ou du développeur : Correspondance informelle
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte s’assure de
      1. produire, en parfaite intégration avec le processus de développement, des spécifications descriptives informelles de haut niveau qui décrivent les interfaces du matériel, des logiciels et des micrologiciels servant à la sécurité sur le plan des exceptions, des messages d’erreur et des effets
      2. montrer par [Sélection (un choix) : démonstration informelle; arguments convaincants fournis, si possible, par des méthodes formelles] que les spécifications descriptives de haut niveau sont conformes au modèle formel de stratégie
      3. montrer, par des démonstrations informelles, que les spécifications descriptives de haut niveau prennent en compte toutes les interfaces du matériel, des logiciels et des micrologiciels servant à la sécurité
      4. montrer que les spécifications descriptives de haut niveau décrivent précisément les interfaces du matériel, des logiciels et des micrologiciels servant à la sécurité
      5. décrire les mécanismes liés au matériel, aux logiciels et aux micrologiciels servant à la sécurité qui ne sont pas explicitement pris en compte dans les spécifications descriptives de haut niveau, mais qui sont strictement inhérents à ce matériel, à ces logiciels et à ces micrologiciels servant à la sécurité
    • Discussion : La correspondance est un élément important de l’assurance gagnée en cours de modélisation. Elle démontre que la mise en œuvre constitue une transformation précise du modèle, et que le code ou le détail de mise en œuvre additionnel n’aura aucune incidence sur les comportements ou les stratégies en cours de modélisation. La cohérence entre les spécifications descriptives de haut niveau (par exemple, une conception de haut niveau ou de bas niveau) et le modèle formel de stratégie est généralement impossible à prouver hors de tout doute. Par conséquent, une combinaison de méthodes formelles et informelles pourrait être requise pour démontrer la cohérence. Les mécanismes liés au matériel, aux logiciels et aux micrologiciels, qui sont strictement inhérents au matériel, aux logiciels et aux micrologiciels servant à la sécurité, comprennent les registres de mappage, ainsi que les entrées et sorties directes liées à la mémoire.
    • Contrôles et activités connexes : AC-03, AC-04, AC-25, SA-04 et SA-05.
  • (05) Architecture et conception de la sécurité et de la protection de la vie privée de la développeuse ou du développeur : Conception simple
    • Exiger que la développeuse ou le développeur du système, du composant du système ou du service qui s’y rapporte s’assure de
      1. concevoir et structurer le matériel, les logiciels et les micrologiciels servant à la sécurité de façon à créer un mécanisme de protection complet, de conception simple et doté d’une sémantique précisément définie
      2. structurer en interne le matériel, les logiciels et les micrologiciels servant à la sécurité, en portant une attention particulière au mécanisme en question
    • Discussion : Le principe de complexité réduite repose sur le fait que la conception du système est aussi simple et petite que possible (voir le contrôle SA-08(07)). Une conception petite et simple est plus facile à comprendre et à analyser, en plus d’être moins vulnérable aux erreurs (voir les contrôles AC-25 et SA-08(13)). Le principe de complexité réduite s’applique à tous les aspects d’un système, mais il est particulièrement important pour la sécurité en raison des diverses analyses réalisées pour obtenir des preuves de la propriété de sécurité émergente du système. Pour assurer la réussite de telles analyses, il est essentiel de faire appel à une conception simple et de petite taille.
      L’application du principe de complexité réduite aide les développeuses et développeurs de système à comprendre l’exactitude et l’exhaustivité des fonctions de sécurité du système et à faciliter la détermination des vulnérabilités potentielles. La conséquence de la complexité réduite veut que la simplicité du système soit directement liée au nombre de vulnérabilités qu’il contiendra. En d’autres mots, les systèmes plus simples contiennent moins de vulnérabilités.
      Deux avantages importants de la complexité réduite font en sorte qu’il soit plus facile de comprendre si la stratégie de sécurité a bien été intégrée dans la conception du système et qu’il y ait moins de vulnérabilités susceptibles d’être introduites lors du processus de développement technique. Ce principe permet également de rendre des conclusions par rapport à l’exactitude, à l’exhaustivité et à l’existence des vulnérabilités avec un degré élevé d’assurance comparativement aux conclusions formulées dans des situations où la conception du système est fondamentalement plus complexe.
    • Contrôles et activités connexes : AC-25, SA-08 et SC-03.
  • (06) Architecture et conception de la sécurité et de la protection de la vie privée de la développeuse ou du développeur : Structure de mise à l’essai
    • Exiger que la développeuse ou le développeur du système, du composant de système ou du service qui s’y rapporte structure le matériel, les logiciels et les micrologiciels servant à la sécurité de manière à faciliter la mise à l’essai.
    • Discussion : L’application des principes du développement sécurisé abordés dans le document SP 800-160 Volume 1 Revision 1 du NIST (en anglais seulement) et dans le cadre de développement mentionné dans l’ITSP.10.037, Activités de gestion des risques pour la cybersécurité et la vie privée tout au long du cycle de vie des systèmes du Centre pour la cybersécurité permet de favoriser une mise à l’essai et une évaluation complètes, uniformes et exhaustives des systèmes, des composants de systèmes et des services. L’exhaustivité d’une telle mise à l’essai contribue aux preuves produites pour créer un cas ou un argument d’assurance efficace par rapport à la robustesse du système, du composant du système ou du service.
    • Contrôles et activités connexes : SA-05 et SA-11.
  • (07) Architecture et conception de la sécurité et de la protection de la vie privée de la développeuse ou du développeur : Structure relative au droit d’accès minimal
    • Exiger que la développeuse ou le développeur du système, du composant de système ou du service qui s’y rapporte structure le matériel, les logiciels et les micrologiciels servant à la sécurité de manière à faciliter le contrôle de l’accès avec le droit d’accès minimal.
    • Discussion : Le principe de droit d’accès minimal repose sur le fait que l’on doit affecter suffisamment de privilèges à chaque composant pour lui permettre d’accomplir ses fonctions, mais sans plus (voir le contrôle SA-08(14)). L’application du principe de droit d’accès minimal limite la portée des actions du composant, ce qui a deux effets désirables. Dans un premier temps, l’incidence sur la sécurité advenant la défaillance, la corruption ou une mauvaise utilisation du composant du système est limitée. Dans un second temps, l’analyse de la sécurité du composant est simplifiée.
      Le principe de droit d’accès minimal est un principe omniprésent qui se reflète dans tous les aspects de la conception d’un système sécurisé. Les interfaces utilisées pour appeler les capacités du composant ne sont accessibles que par certains sous-ensembles de la population d’utilisatrices et utilisateurs, et la conception du composant prend en charge un degré de granularité suffisamment précis pour assurer la décomposition des privilèges.
      Par exemple, dans le cas d’un mécanisme de vérification, on pourrait retrouver une interface pour la ou le gestionnaire des vérifications qui configure les paramètres des vérifications, une interface pour l’exploitante ou exploitant des vérifications qui s’assure que les données de vérification sont collectées et stockées en toute sécurité et, pour finir, une autre interface pour la vérificatrice ou le vérificateur des vérifications qui doit afficher les données de vérification collectées sans toutefois effectuer d’opérations à partir de ces données.
      En plus de ses manifestations dans l’interface du système, le principe de droit d’accès minimal peut être utilisé comme principe directeur pour la structure interne du système en tant que tel. Un aspect du droit d’accès minimal interne est de construire des modules de manière à ce que seules les fonctions d’un module puissent effectuer des opérations directes sur les éléments encapsulés par ce module. Il est possible d’accéder indirectement aux éléments externes à un module susceptibles d’être touchés par l’exploitation de ce module dans le cadre d’une interaction (par exemple, lors d’un appel de fonction) avec le module qui contient ces éléments.
      Un autre aspect du droit d’accès minimal interne veut que la portée d’un module ou d’un composant donné comprenne uniquement les éléments du système qui sont nécessaires pour son fonctionnement et que les modes d’accès des éléments (par exemple, lecture, écriture) soient minimaux.
    • Contrôles et activités connexes : AC-05, AC-06 et SA-08.
  • (08) Architecture et conception de la sécurité et de la protection de la vie privée de la développeuse ou du développeur : Orchestration
    • Concevoir [Affectation : systèmes ou composants de systèmes critiques désignés par l’organisation] avec un comportement coordonné pour mettre en œuvre les capacités suivantes : [Affectation : capacités définies par l’organisation, par système ou composant].
    • Discussion : Les ressources de sécurité distribuées qui se trouvent à différentes couches ou dans différents éléments des systèmes peuvent interagir de façon imprévue ou inappropriée. Les conséquences négatives peuvent comprendre des défaillances en cascade, des interférences ou des lacunes dans la couverture. La coordination du comportement des ressources de sécurité (par exemple, en s’assurant qu’un correctif est appliqué à toutes les ressources avant d’apporter un changement dans la configuration qui suppose que le correctif a été installé) peut éviter de telles interactions négatives.
    • Contrôles et activités connexes : Aucun.
  • (09) Architecture et conception de la sécurité et de la protection de la vie privée de la développeuse ou du développeur : Diversité de la conception
    • Utiliser les différentes conceptions de [Affectation : systèmes ou composants de systèmes critiques désignés par l’organisation] pour satisfaire à un ensemble commun d’exigences ou fournir une fonctionnalité équivalente.
    • Discussion : La diversité de conception repose sur l’imposition des mêmes exigences à plusieurs développeuses et développeurs, chacun étant responsable de développer une variante du système ou du composant du système qui répond à ces exigences. Les variantes peuvent se trouver dans la conception du logiciel, dans la conception du matériel ou dans la conception du logiciel et du matériel. Les différences dans les conceptions des variantes peuvent découler de l’expérience des développeuses et développeurs (par exemple, avant l’utilisation d’un schéma de conception), du style de conception (par exemple, au moment de décomposer une fonction obligatoire en plus petites tâches, déterminer ce qui constitue une tâche distincte et jusqu’où il convient de décomposer les tâches en sous-tâches), de la sélection des bibliothèques à intégrer dans la variante et de l’environnement de développement (par exemple, différents outils de conception facilitent la visualisation des schémas de conception).
      La diversité de la conception du matériel consiste notamment à prendre différentes décisions concernant l’information qu’il convient de conserver sous forme analogique et de convertir sous forme numérique, à transmettre la même information à différents moments et à introduire des délais dans l’échantillonnage (diversité temporelle). La diversité de la conception est souvent utilisée pour prendre en charge la tolérance aux anomalies.
    • Contrôles et activités connexes : Aucun.

Références

Haut de la page 
 

SA-18 Résistance au trafiquage et détection

Annulé : Transféré sous le contrôle SR-09.

Améliorations

  • (01) Résistance au trafiquage et détection : Multiples phases du cycle de développement de systèmes
    • Annulé : Transféré sous le contrôle SR-09(01).
  • (02) Résistance au trafiquage et détection : Inspection des systèmes ou des composants
    • Annulé : Transféré sous le contrôle SR-10.
Haut de la page 
 

SA-19 Authenticité des composants

Annulé : Transféré sous le contrôle SR-11.

Améliorations

  • (01) Authenticité des composants : Formation anticontrefaçon
    • Annulé : Transféré sous le contrôle SR-11(01).
  • (02) Authenticité des composants : Contrôle des configurations pour l’entretien et la réparation des composants
    • Annulé : Transféré sous le contrôle SR-11(02).
  • (03) Authenticité des composants : Mise hors service des composants
    • Annulé : Transféré sous le contrôle SR-12.
  • (04) Authenticité des composants : Analyse anticontrefaçon
    • Annulé : Transféré sous le contrôle SR-11(03).
Haut de la page 
 

SA-20 Développement sur mesure des composants essentiels

Contrôle

Procéder à une nouvelle mise en œuvre ou au développement sur mesure des composants de systèmes essentiels suivants : [Affectation : composants essentiels désignés par l’organisation].

Discussion

Les organisations déterminent que certains composants de systèmes ne peuvent vraisemblablement pas être considérés comme fiables en raison de certaines menaces ou de vulnérabilités inhérentes, et que ces mêmes composants ne disposent pas de contrôles de sécurité aptes à atténuer raisonnablement les risques. La remise en œuvre ou le développement sur mesure de tels composants peut satisfaire aux exigences d’assurance élevée et être accompli en apportant des changements aux composants de systèmes (y compris le matériel, les logiciels et les micrologiciels) pour faire en sorte que les attaques courantes des adversaires aient peu de chances de réussir.

Dans les cas où aucune autre source n’est disponible et que les organisations décident de ne pas procéder à la remise en œuvre ou au développement sur mesure des composants de systèmes essentiels, des contrôles additionnels peuvent être employés. Les contrôles comprennent une vérification accrue, des restrictions d’accès au code source et aux utilitaires du système et la protection contre la suppression des fichiers système et d’application.

Contrôles et activités connexes

CP-02, RA-09 et SA-08.

Améliorations

Aucune.

Références

Activités de gestion des risques pour la cybersécurité et la vie privée tout au long du cycle de vie des systèmes (ITSP.10.037)

Haut de la page 
 

SA-21 Filtrage de sécurité des développeuses et développeurs

Contrôle

Exiger que la développeuse ou le développeur de [Affectation : système, composant de système ou service qui s’y rapporte désigné par l’organisation]

  1. dispose des autorisations d’accès requises en fonction des [Affectation : responsabilités gouvernementales officielles définies par l’organisation] qui ont été attribuées
  2. satisfasse aux critères additionnels de filtrage de sécurité du personnel définis par l’organisation : [Affectation : critères additionnels de sélection du personnel définis par l’organisation]

Discussion

Le filtrage de sécurité des développeuses et développeurs concerne les développeurs externes. Le filtrage de sécurité des développeuses et développeurs internes est abordé dans le contrôle PS-03. Puisque les systèmes, les composants de systèmes ou les services qui s’y rapportent peuvent être employés dans le cadre d’activités de nature critique qui s’avèrent essentielles à la protection des intérêts du Canada en matière de sécurité nationale ou économique, il est primordial que les organisations s’assurent que les développeuses et développeurs soient dignes de confiance. Il se pourrait que le niveau de fiabilité des développeuses et développeurs doive correspondre à celui des autres personnes ayant accès aux systèmes, aux composants ou aux services après le déploiement.

Les habilitations de sécurité, les vérifications des antécédents, la citoyenneté et la nationalité sont des exemples de critères d’autorisation d’accès ou de filtrage de sécurité du personnel. La vérification de la fiabilité des développeuses et développeurs peut également nécessiter l’examen et l’analyse des titres de propriété ainsi que des relations que l’entreprise entretient avec des entités pouvant interférer avec la qualité ou la fiabilité des systèmes, des composants ou des services en cours de développement.

Le fait de respecter les critères visant les autorisations d’accès et le filtrage de sécurité du personnel se manifeste par la production de listes des personnes autorisées à mener des activités de développement sur les divers systèmes, composants de systèmes et/ou services qui s’y rapportent, de façon à permettre aux organisations d’établir si une développeuse ou un développeur répond aux exigences relatives aux autorisations d’accès et au filtrage de sécurité.

Contrôles et activités connexes

PS-02, PS-03, PS-06, PS-07, SA-04 et SR-06.

Améliorations

  • (01) Filtrage de sécurité des développeuses et développeurs : Validation du filtrage de sécurité
    • Annulé : Intégré au contrôle SA-21.

Références

Haut de la page 
 

SA-22 Composants de systèmes non pris en charge

Contrôle

  1. Remplacer les composants des systèmes lorsqu’ils ne sont plus pris en charge par les développeuses, les développeurs, les fournisseurs ou les fabricants
  2. Offrir les options suivantes pour les solutions de rechange visant à assurer la continuité du soutien des composants non pris en charge faisant l’objet d’un [Sélection (un choix ou plus) : soutien interne; [Affectation : soutien offert par des fournisseurs externes défini par l’organisation]]

Discussion

La prise en charge (ou le soutien) des composants de systèmes comprend les correctifs logiciels, les mises à jour de micrologiciels, les remplacements de pièces et les contrats de maintenance. Les exemples de composants non pris en charge comprennent les circonstances où les fournisseurs ne produisent plus de correctifs logiciels critiques ou de mises à jour pour les produits, ce qui peut mener à des possibilités pour les adversaires d’exploiter les faiblesses des composants installés. Les exceptions au remplacement des composants de systèmes non pris en charge comprennent les systèmes qui fournissent des capacités essentielles à la mission ou aux activités lorsque des technologies plus récentes ne sont pas disponibles ou lorsque les systèmes sont tellement isolés qu’il est impossible d’installer des composants de remplacement.

Les autres sources de soutien permettent de répondre au besoin de fournir un soutien continu pour les composants de systèmes qui ne sont plus pris en charge par les fabricants d’origine, les développeuses, les développeurs ou les fournisseurs lorsque ces composants sont essentiels à la mission et aux activités de l’organisation. Au besoin, les organisations peuvent établir un soutien interne en développant des correctifs sur mesure pour les composants logiciels critiques ou avoir recours à des services de fournisseurs externes capables de fournir, au moyen de relations contractuelles, du soutien continu pour les composants non pris en charge qui ont été désignés. Ces relations contractuelles peuvent comprendre des fournisseurs de logiciels libres à valeur ajoutée. Le risque accru d’utilisation de composants de systèmes non pris en charge peut être atténué, par exemple, en empêchant la connexion de ces composants aux réseaux publics ou non contrôlés ou en mettant en œuvre d’autres formes d’isolation.

Contrôles et activités connexes

PL-02, SA-03 et SA-400.

Améliorations

  • (01) Composants de systèmes non pris en charge : Solution de rechange visant à assurer la continuité du soutien
    • Annulé : Intégré au contrôle SA-22.

Références

SCT, Directive sur les services et le numérique – Annexe H : Norme sur la technologie de l’information à risque

Haut de la page 
 

SA-23 Spécialisation

Activité

Avoir recours [Sélection (un choix ou plus) : à la conception; à la modification; au renforcement; à la reconfiguration] des [Affectation : systèmes ou composants de systèmes désignés par l’organisation] prenant en charge des services ou des fonctions essentiels à la mission pour renforcer la robustesse de ces systèmes ou composants.

Discussion

Il est souvent nécessaire d’améliorer un système ou un composant de système qui prend en charge des fonctions ou des services essentiels à la mission pour maximiser la robustesse de la ressource. Parfois, cette amélioration est effectuée au niveau de la conception. Dans d’autres cas, elle est réalisée au cours de la phase postconception, que ce soit en modifiant le système concerné ou en renforçant le système au moyen de composants additionnels. Par exemple, des fonctions supplémentaires d’authentification ou de non-répudiation peuvent être ajoutées au système pour renforcer l’identité des ressources critiques selon les autres ressources qui dépendent de ressources définies par l’organisation.

Contrôles et activités connexes

RA-09 et SA-08.

Améliorations

Aucune.

Références

Activités de gestion des risques pour la cybersécurité et la vie privée tout au long du cycle de vie des systèmes (ITSP.10.037)

Haut de la page 
 

SA-24 Conception aux fins de cyberrésilience

Contrôle

  1. Concevoir les systèmes organisationnels, les composants de systèmes ou les systèmes qui s’y rapportent de manière à renforcer leur cyberrésilience en définissant
    1. les buts suivants en matière de cyberrésilience : [Affectation : buts en matière de cyberrésilience définis par l’organisation]
    2. les objectifs suivants en matière de cyberrésilience : [Affectation : objectifs en matière de cyberrésilience définis par l’organisation]
    3. les techniques de cyberrésilience suivantes : [Affectation : techniques de cyberrésilience définies par l’organisation]
    4. les approches de mise en œuvre de la cyberrésilience suivantes : [Affectation : approches de mise en œuvre de la cyberrésilience définies par l’organisation]
    5. les principes de conception de la cyberrésilience suivants : [Affectation : principes de conception de la cyberrésilience définis par l’organisation]
  2. Mettre en œuvre et passer en revue les buts, les objectifs, les techniques, les approches de mise en œuvre et les principes de conception dans le cadre du processus de gestion des risques organisationnels ou du processus d’ingénierie de la sécurité des systèmes

Discussion

La cyberrésilience est essentielle pour assurer la survivance des systèmes essentiels à la mission et des biens de grande valeur. La cyberrésilience met l’accent sur la limitation des dommages causés par l’adversité ou des conditions susceptibles de mener à la perte des biens. Les dommages peuvent toucher (1) les organisations (par exemple, une atteinte à la réputation, de plus grands risques existentiels), (2) les fonctions liées à la mission ou aux activités de l’organisation (par exemple, une capacité réduite de mener à bien les missions en cours et celles à venir), (3) la sécurité (par exemple, une capacité réduite d’atteindre les objectifs en matière de sécurité ou de prévenir les cyberincidents, de les détecter et d’y réagir), (4) les systèmes (par exemple, l’utilisation non autorisée des ressources du système ou une capacité réduite de se conformer aux exigences système) ou (5) les éléments propres au système (par exemple, la destruction physique, la corruption, la modification ou la fabrication d’informations).

La cyberrésilience vise à aider les organisations à maintenir un état de préparation éclairé face à l’adversité, à mener à bien les fonctions essentielles liées à la mission ou aux activités en dépit d’incidents négatifs, à rétablir les fonctions liées à la mission ou aux activités durant et après ces incidents et à modifier les fonctions liées à la mission ou aux activités et leurs capacités de soutien advenant des changements prévus dans les environnements techniques, opérationnels et de menace.

Le document SP 800-160 Volume 2 Revision 1 du NIST fournit de l’information additionnelle sur le cadre d’ingénierie de la cyberrésilience, dont des descriptions détaillées des buts, des objectifs, des techniques, des approches de mise en œuvre et des principes de conception de la cyberrésilience. Le document SP 800-160 Volume 1 Revision 1 du NIST fournit de l’information additionnelle sur l’atteinte de la cyberrésilience en tant que propriété émergente d’un système en cours de conception.

Contrôles et activités connexes

CA-07, CP-02, CP-04, CP-09, CP-10, CP-11, CP-12, CP-13, IR-04, IR-05, PE-11, PE-12, PE-17, PL-08, PM-07, PM-16, PM-30, PM-31, RA-03, RA-05, RA-09, SA-03, SA-08, SA-09, SA-17, SC-03, SC-05, SC-07, SC-10, SC-11, SC-29, SC-30, SC-34, SC-35, SC-36, SC-37, SC-39, SC-44, SC-47, SC-48, SC-49, SC-50, SC-51, SI-03, SI-04, SI-14, SI-17, SI-20, SI-21, SI-22, SI-23, SR-03, SR-04, SR-05 et SR-07.

Améliorations

Aucune.

Références

Haut de la page 
 

SA-400 Souveraineté et juridiction

Contrôle

Exiger que les fonctions opérationnelles de l’organisation respectent un processus d’évaluation des menaces et des risques en matière de souveraineté et de juridiction au [Sélection (un choix ou plus) : niveau de l’organisation; niveau de la mission et des activités; niveau du système] qui consiste à

  1. procéder à l’évaluation des préjudices pour déterminer les préjudices potentiels maximaux qui pourraient être causés par une contrainte légale externe imposée aux fonctions organisationnelles ou aux ressources informationnelles en
    1. considérant les besoins opérationnels en matière de sécurité, y compris les lois ou la réglementation qui exigent que les données ne soient pas divulguées ou compromises
    2. mettant à jour la catégorisation de la sécurité des fonctions organisationnelles ou des ressources informationnelles
    3. documentant les conséquences négatives de la contrainte légale
  2. procéder à l’évaluation des menaces propres à la juridiction pour établir la probabilité d’être pris pour cible
  3. effectuer une évaluation des vulnérabilités pour déterminer les moyens potentiels que la juridiction externe pourrait utiliser pour exploiter les fonctions organisationnelles ou les ressources informationnelles
  4. procéder à l’évaluation des risques propres à la juridiction

Discussion

La souveraineté des données concerne le droit du Canada de contrôler l’accès à l’information numérique qui est assujetti à un contrôle prévu par la loi et la divulgation d’une telle information. Par résidence des données, on entend l’emplacement physique ou géographique des données au repos d’une organisation. Par juridiction, on entend le domaine d’autorité qui, dans ce contexte, fait référence à la capacité d’imposer la conformité des entités dans ce domaine comme menace principale.

L’hébergement de données dans une juridiction étrangère suscite des préoccupations dans la mesure où ces données pourraient être observées, modifiées ou refusées dans le cadre d’une contrainte légale, alors que ça ne devrait pas être le cas lorsqu’une organisation jouit de la souveraineté de ses données. L’exposition d’une fonction organisationnelle à une compétence juridique différente peut en fait éliminer les barrières juridiques souveraines qui protègent contre la compromission dans la juridiction d’origine. Par exemple, la protection de la vie privée des citoyennes et citoyens n’est souvent pas accordée aux non-citoyennes et non-citoyens, et les fournisseurs de services peuvent être légalement tenus de fournir l’accès à des données ou à des services qui seraient protégés par la loi dans la juridiction d’origine. Dans le cas des fonctions organisationnelles, on peut donner en exemple la technologie opérationnelle qui contrôle les infrastructures essentielles hébergées dans un nuage qui est modifié ou mis hors service par une juridiction étrangère hostile.

Les techniques employées peuvent être très sophistiquées et seront généralement exécutées avec tous les privilèges d’administrateur des initiées et initiés. La contrainte légale imposée par des juridictions dotées de moyens sophistiqués est extrêmement efficace pour ce qui est de contourner les autres contrôles. Plusieurs juridictions peuvent s’appliquer, par exemple une administration municipale, une ville, un comté, une réserve, un district, une région, une province, un État, un canton, un territoire ou une nation. Tous les niveaux doivent être identifiés pour évaluer les capacités d’imposer des contraintes.

D’autres juridictions peuvent forcer la compromission des fonctions opérationnelles en matière de confidentialité, d’intégrité ou de disponibilité. Une évaluation des préjudices doit documenter les conséquences négatives de la contrainte légale, notamment tout besoin opérationnel en matière de sécurité (par exemple, les lois ou la réglementation qui exigent que les données ne soient pas compromises).

Une organisation pourrait ne pas être en mesure d’adopter une approche à la gestion des risques (notamment en raison d’un mandat prescrit par la loi ou de la souveraineté des données nationales) et devoir éviter d’emblée tout scénario de risque.

Discussion au sein du GC

La Directive sur les services et le numérique du SCT, section 4.4.3.14, exige que l’information ou les données sensibles dont la classification ou la catégorie est PROTÉGÉ B ou PROTÉGÉ C soient stockées dans une juridiction canadienne comme principale option de transmission. Par juridiction canadienne, on entend les frontières géographiques du Canada ou à l’intérieur des limites d’une mission diplomatique ou consulaire du GC à l’étranger. Le Centre pour la cybersécurité recommande que toutes les données et les fonctions opérationnelles de nature hautement sensible soient conservées dans des juridictions canadiennes.

Contrôles et activités connexes

AT-02, CA-02, RA-01 et RA-02.

Améliorations

  • (01) Souveraineté et juridiction : Évaluation des menaces et des risques
    • Exiger que l’organisation effectue des évaluations des menaces et des risques qui pèsent sur la souveraineté des données en tenant compte de sa juridiction et des aspects pour lesquels des contraintes légales pourraient être efficaces.
    • Discussion : L’organisation détermine la valeur du préjudice causé par les fonctions opérationnelles proposées pour occuper d’autres juridictions. Les quatre surfaces (logique, physique, personnel et cycle de vie) abordées dans le document Activités de gestion des risques pour la cybersécurité et la vie privée tout au long du cycle de vie des systèmes (ITSP.10.037) peuvent être vulnérables.
    • Contrôles et activités connexes : CA-02 et RA-03.
  • (02) Souveraineté et juridiction : Évaluation d’ordre juridique et contractuel
    • Évaluer l’assurance de la sécurité des processus opérationnels au moyen de mécanismes juridiques ou de passation de marché.
    • Discussion : Plusieurs juridictions offrent différentes possibilités pour protéger les fonctions opérationnelles contre la contrainte légale à divers niveaux d’assurance. Des accords internationaux et multilatéraux peuvent aider à accroître la protection. Les modalités des marchés conclus avec les fournisseurs peuvent aider à réduire l’exposition à de telles contraintes ou en faire le signalement (il importe de souligner que certaines formes de contrainte peuvent également interdire toute forme de non-divulgation).
      Dans la mesure où la prestation de service comporte des fournisseurs de tierces parties, s’assurer que les documents contractuels font mention de la souveraineté des données et des obligations en matière de juridiction. Si les organisations décident d’aborder les obligations en matière de souveraineté et de juridiction au niveau de l’organisation ou du projet, cette obligation devrait être incluse dans les obligations contractuelles connexes.
      Les organisations devraient obtenir les conseils de spécialistes dans la juridiction cible si des mécanismes juridiques et contractuels sont employés pour prévenir toute contrainte légale étrangère, puisqu’il est probable que toute législation à caractère obligatoire ait préséance sur les mesures législatives ou les contrats de protection. Ce qui constitue une application régulière de la loi dans d’autres juridictions peut être insatisfaisant d’un point de vue canadien.
    • Contrôles et activités connexes : CA-02 et SA-09.
  • (03) Souveraineté et juridiction : Marquage des attributs liés aux processus opérationnels
    • S’assurer que les processus opérationnels fassent l’objet du traitement prévu selon la compétence juridique.
    • Discussion : Les attributs des métadonnées peuvent être définis et liés aux processus opérationnels ou aux données pour aider les processus de gestion à traiter correctement la compétence juridique prévue. Par exemple, la mention « Réservé aux juridictions canadiennes » ou « Données nationales souveraines » peut être apposée sur les documents comme attribut. Le traitement automatisé des attributs de métadonnées peut être d’une grande aide pour les fournisseurs d’infrastructures partagées qui doivent respecter une multiplicité d’exigences en matière de compétences.
    • Contrôles et activités connexes : AC-16 et MP-03.
  • (04) Souveraineté et juridiction : Protection des données au repos
    • Éviter que les données résident dans des territoires qui relèvent d’autres compétences juridiques.
    • Discussion : Permettre aux données au repos de résider dans d’autres juridictions fournit la plus grande occasion d’imposer à tout moment une contrainte sur les données. Héberger les données au repos dans des juridictions canadiennes augmentera le facteur travail et pourrait éliminer certaines capacités. Le chiffrement des données au repos offre une valeur limitée, mais pourrait permettre de prévenir la récupération physique des données avec une certaine efficacité.
      Il n’y a aucun délai minimum après lequel les données sont considérées « au repos ». Si les données doivent être écrites, même momentanément, sur un support non volatile, elles doivent être considérées comme étant au repos. Cela peut notamment avoir une incidence sur les situations d’urgence ou imprévues, comme des vidages de la mémoire, la mise en cache ou la permutation de la mémoire, ainsi que sur les opérations de reprise après sinistre.
      Les considérations relatives aux données au repos doivent également tenir compte de la façon dont les données stockées seront éventuellement mises hors service et éliminées afin de s’assurer que les données ne fassent pas l’objet d’une contrainte étrangère à la fin de la durée de vie du système.
    • Contrôles et activités connexes : CP-06, CP-09, MP-06, MP-08, SA-03, SA-04, SA-22 et SC-28.
  • (05) Souveraineté et juridiction : Protection des données en transit
    • Éviter que les données transitent par des territoires qui relèvent d’autres compétences juridiques.
    • Discussion : Permettre aux données en transit de traverser d’autres juridictions fournit de nombreuses occasions de contraindre les données. Le fait d’acheminer les données dans des juridictions canadiennes uniquement élimine plusieurs capacités de contrainte. Le chiffrement des données en transit peut également s’avérer utile.
    • Contrôles et activités connexes : CP-08 et SC-08.
  • (06) Souveraineté et juridiction : Protection des données en cours d’utilisation
    • Éviter que les données soient utilisées dans des territoires qui relèvent d’autres compétences juridiques.
    • Discussion : Permettre aux données en cours d’utilisation de résider dans d’autres juridictions fournit une occasion de contraindre les données. Le fait de traiter les données dans des juridictions canadiennes uniquement élimine plusieurs capacités de contrainte.
      Aucune méthode de chiffrement n’a encore été approuvée pour protéger les données en cours d’utilisation. En principe, une forme de chiffrement connue sous le nom de « chiffrement homomorphique » pourrait permettre certains types de traitement alors que les données restent chiffrées, mais le Centre pour la cybersécurité ne considère pas pour l’instant que le chiffrement homomorphique est suffisant pour assurer le chiffrement conformément à son document Algorithmes cryptographiques pour l’information NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B (ITSP.40.111). Par conséquent, si le chiffrement homomorphique est employé pour protéger les données en cours d’utilisation, il convient actuellement de l’évaluer en tant que texte en clair (c’est-à-dire n’offrant aucune protection cryptographique selon le contrôle SC-13).
      Il n’y a aucun délai minimum après lequel les données sont considérées en cours d’utilisation. Leur présence dans un système pour un seul cycle d’UCT devrait suffire pour l’imposition d’une contrainte.
    • Contrôles et activités connexes : CP-07, SC-13.
  • (07) Sovereignty and jurisdiction: Protection against extraterritorial compulsion
    • Prévenir la compromission des fonctions opérationnelles par des personnes ou des sociétés assujetties à une autre compétence juridique.
    • Discussion : Les adversaires peuvent avoir des moyens de forcer les personnes et/ou les sociétés à compromettre les fonctions opérationnelles même si l’intégralité de ces fonctions est conservée à l’extérieur de la juridiction de l’adversaire. Il convient de tenir compte de la loyauté des personnes ou des sociétés, des liens directs entre les entités (comme les sociétés affiliées, les membres de la famille, les biens étrangers) et des liens indirects (comme les partenariats et les relations).
      Les personnes résidant au Canada qui détiennent une citoyenneté canadienne et une citoyenneté étrangère peuvent être contraintes par leur autre pays, même si elles sont assujetties aux lois canadiennes, et pourraient être tenues de choisir entre les conséquences juridiques imposées dans l’une ou l’autre des juridictions.
    • Contrôles et activités connexes : MA-05.
  • (08) Souveraineté et juridiction : Protection du cycle de vie des activités
    • Prévenir la compromission des fonctions opérationnelles dans le cadre d’attaques du cycle de vie découlant d’une contrainte légale ou menées depuis une autre compétence juridique.
    • Discussion : L’utilisation de produits ou de services (par exemple, des logiciels, des micrologiciels, du matériel, des services de conception, des services de consultations, etc.) qui ont déjà fait l’objet d’une contrainte peut exposer les fonctions opérationnelles aux compromissions inhérentes à ces produits ou services. La plupart des systèmes actuels comportent des éléments tirés de multiples compétences juridiques et une approche basée sur le risque sera nécessaire pour sélectionner les solutions qui permettent d’atténuer les menaces relevées selon les besoins opérationnels en matière de sécurité.
      Un contrôle compensatoire à mettre en place pour prévenir toute compromission inhérente consiste à assurer une isolation rigoureuse du réseau.
    • Contrôles et activités connexes : SA-03, SA-04 et SC-07.
  • (09) Souveraineté et juridiction : Propriété publique
    • Prévenir la compromission des fonctions opérationnelles lors d’un transfert de propriété des fonctions du cycle de vie à une autre compétence juridique.
    • Discussion : Bien que les dépendances du système puissent être sécurisées contre une contrainte étrangère dès le début de la mise en œuvre, si un transfert de propriété survient au cours de la durée de vie du système, ce dernier pourrait faire l’objet d’attaques du cycle de vie découlant d’une contrainte étrangère. Pour éviter une telle possibilité, les organisations sélectionnent un soutien au cycle de vie et des arrangements en matière d’approvisionnement qui seront régis par une propriété publique canadienne pour toute la durée de vie du système.
    • Contrôles et activités connexes : SA-03, SA-04 et SA-22.

Références

 
Précédent
Date de modification :