Sécurité
La sécurité traverse toute la vie d’un service, du premier croquis de conception au jour où il est éteint. Un service sûr au lancement se démode à mesure que les menaces autour de lui changent et que ses logiciels vieillissent : la sécurité est donc un travail qui ne s’arrête jamais tout à fait. Les cinq mêmes questions reviennent sans cesse : savoir ce qui est à risque, bâtir les défenses, repérer vite les ennuis, contenir l’incident, et restaurer et apprendre. Ces cinq questions forment le cycle de vie de la sécurité.
Résumé
La sécurité revient sans cesse. Les cinq fonctions se répètent aussi longtemps que le service fonctionne. Un service qui était sécurisé le jour de son lancement, et qu’on n’a pas réexaminé depuis, a discrètement cessé de l’être.
Ce qui tourne mal est habituellement ordinaire. Un composant non corrigé, un mot de passe par défaut, une permission laissée plus large que nécessaire. Les attaques spectaculaires font les manchettes, mais c’est de là que vient l’essentiel du préjudice.
Protéger le petit nombre de choses qui causeraient un préjudice réel. Protéger tout au même niveau élevé coûte plus cher que ce que la plupart des ministères peuvent se permettre, et cela se termine généralement par une protection trop diluée pour aider où que ce soit. Déterminez quelles parties causeraient un préjudice réel si elles défaillaient, et protégez-les correctement.
Cela coûte bien moins cher à la conception qu’en production. Une faiblesse détectée pendant que quelqu’un dessine encore le service coûte une fraction de ce que coûte la même faiblesse une fois que des gens l’utilisent. Si un fournisseur le construit, c’est l’argument pour inscrire le travail de sécurité au contrat.
Ce sont les cinq fonctions du cycle de vie de la sécurité reconnu, le modèle dans lequel travaille le gouvernement du Canada : l’ITSG-33 du Canada expose le cycle de vie de gestion des risques de sécurité de la TI du GC, le Centre canadien pour la cybersécurité publie les orientations qui en découlent, et les mêmes cinq fonctions constituent le cadre international du NIST Cybersecurity Framework.
À quoi ressemble la réussite
La sécurité est planifiée et financée dès le départ, les risques étant déterminés avant qu’une ligne de code soit écrite.
L’accès suit le principe du moindre privilège, c’est-à-dire que chaque personne et chaque système n’obtient que l’accès nécessaire, et cet accès est vérifié.
Les correctifs sont appliqués selon un calendrier et l’application est testée régulièrement pour déceler les vulnérabilités.
La surveillance et les alertes signalent les activités inhabituelles, parce qu’on ne peut pas tout prévenir et que ce qui compte, c’est la vitesse à laquelle on s’en aperçoit.
Un plan d’intervention en cas d’incident existe et a été répété, pour qu’un problème soit contenu rapidement plutôt que des semaines plus tard.
Le service peut être rétabli après un incident, et la leçon est réintégrée à la conception.
Le niveau de maturité en sécurité du service est connu, avec une prochaine étape claire pour l’améliorer.
Les composants tiers, c’est-à-dire les bibliothèques libres et achetées sur lesquelles repose le service, sont inventoriés et surveillés pour déceler les problèmes connus.
Pourquoi cela compte
Quand la sécurité échoue, un service peut tomber hors ligne ou laisser fuir les renseignements personnels de gens, et la confiance du public est longue à rebâtir. Les causes sont habituellement banales : un composant non corrigé, un mot de passe par défaut, une permission laissée trop large.
Chacune des cinq fonctions protège contre une défaillance différente, et le cycle ne tient que si aucune n’est sautée. Détecter une faille tôt coûte aussi moins cher, parce qu’une faille intégrée à la conception et trouvée tard est la plus coûteuse à défaire.
Le mode d’emploi du gouvernement du Canada pour tout cela est la Ligne directrice sur le développement sécurisé d’applications, qui couvre l’intégration de la sécurité à chaque étape du développement, le codage sécurisé, le traitement des composants tiers, et la gestion des vulnérabilités.
À qui revient ce travail
La sécurité est partagée au sein de l’équipe, chaque rôle en portant une partie différente :
- Développeurs écrivent du code sécurisé et corrigent ce que les analyses révèlent.
- Spécialistes de la sécurité déterminent contre quelles menaces se défendre et examinent la conception.
- Exploitation exploitent et surveillent le service une fois qu’il est en fonction.
- Le responsable opérationnel de l’application veille à ce que la sécurité soit planifiée et payée dès le départ, approuve le plan de traitement des menaces, accepte le risque qui subsiste après les correctifs, et donne le feu vert au déploiement (l’approbation officielle qui permet la mise en service).
Un regard de plus près
- 1Repérer
- 2Protéger
- 3Détecter
- 4Intervenir
- 5Rétablir
Comparaison
Deux façons de faire la sécurité
Pax
Voici Pax, gestionnaire de service. L’équipe a intégré la sécurité au portail de subventions dès la conception :
- a bâti un modèle de menaces pour exposer ce qui pouvait mal tourner, et a choisi des réglages sécurisés par défaut
- n’a donné à chaque personne et à chaque système que l’accès nécessaire, et l’a vérifié
- a appliqué les correctifs selon un calendrier et surveillé les composants tiers pour déceler les problèmes connus
- tenait un plan d’intervention en cas d’incident répété
Le résultat : quand une tentative d’hameçonnage est survenue, elle a été attrapée et contenue rapidement, et les données sont restées en sécurité.
À quoi ressemble la sécurité à chaque phase
Les cinq fonctions sont présentes tout au long, mais leur poids se déplace au fil de la vie d’un service.
C’est ici que les fonctions Identifier et Protéger sont conçues, avant qu’une ligne de code soit écrite. L’équipe construit un modèle de menaces pour exposer ce qui pourrait mal tourner et qui pourrait attaquer le service (le modèle de menaces lui-même se trouve dans le bloc Identifier d’« Un regard de plus près »).
L’équipe choisit ensuite des réglages sécurisés par défaut pour que l’option sûre soit celle par défaut, et détermine comment le service traitera l’identité et les accès. Les exigences de sécurité sont inscrites au contrat pour que le fournisseur y soit tenu. Une faiblesse corrigée à l’étape de la conception coûte bien moins cher qu’une faiblesse trouvée en production.
Les instruments officiels derrière sécurité
Tout ce que ce sujet apporte d’officiel, et à quel moment de la vie d’un service chaque élément survient. Le détail complet, y compris qui fait le travail et ce que le responsable opérationnel fait personnellement, se trouve dans le tableau de la page d’accueil.
Une cote indiquant l’ampleur du préjudice qui suivrait une fuite, une modification non souhaitée de l’information, ou une panne. Elle est établie sur quatre niveaux, de faible à très élevé, et le résultat détermine l’ampleur de l’ensemble de contrôles de sécurité que la construction doit respecter.
- DécouverteRassembler
- AlphaRemplir
- CroissanceTenir à jour
- MaturitéTenir à jour
L’exercice qui énumère ce qui pourrait mal tourner, classe chaque élément selon sa probabilité et l’ampleur du dommage, et énonce le risque qui subsiste une fois les mesures de protection en place. Il couvre autant les menaces délibérées qu’accidentelles et naturelles : il est donc plus large qu’un exercice de cybersécurité.
- AlphaRassemblerRemplir
- BêtaRemplir
- CroissanceTenir à jour
- MaturitéTenir à jour
- Évaluation de la sécurité matérielle et autorisation d’occuper des locauxOnly ifAutorisation
La deuxième filière de sécurité, menée en parallèle et couvrant les bâtiments, l’équipement et l’espace physique. Elle utilise la même méthode harmonisée que l’évaluation des systèmes, menée par d’autres personnes et se terminant par une signature différente.
- AlphaVérifier
- BêtaRemplirSigner ou accepter
- Évaluation et autorisation de sécurité, se terminant par l’autorisation d’exploiter (EAS, AE)Every servicesourceAutorisation
L’autorisation officielle permettant au service de fonctionner en production. Une personne investie du pouvoir lit ce que le travail de sécurité a révélé, accepte le risque qui subsiste, et signe. Pour un système ministériel, ce signataire est normalement le responsable opérationnel.
- DécouverteRassemblerSigner ou accepter
- AlphaSigner ou accepter
- BêtaSigner ou accepter
- CroissanceTenir à jourSigner ou accepter
- MaturitéTenir à jour
- RetraitClore
- Analyse des répercussions sur les activités (ARA)Every serviceÉvaluation
L’exercice qui détermine la criticité du service, et qui produit quatre chiffres : la durée maximale d’interruption admissible, le niveau de service minimal, l’objectif de temps de reprise et l’objectif de point de reprise.
- AlphaRassembler
- BêtaRassembler
- StabilisationTenir à jour
- CroissanceTenir à jour
- MaturitéTenir à jour
- Plan de continuité des activités (PCA)Only ifPlan
Les dispositions écrites pour qu’un service essentiel continue d’être offert à un niveau minimal acceptable pendant une perturbation, et pour le rétablir ensuite. Il y a un seul plan pour le ministère, et ce service y a soit sa propre section, soit une couverture répartie sur plusieurs.
- BêtaRassembler
- StabilisationTenir à jour
- MaturitéTenir à jour
Les dispositions de rétablissement propres à l’équipe du service : comment ce système se relève, dans quel ordre ses composants sont restaurés, et la preuve par les essais que la restauration fonctionne. Le plan de continuité des activités du ministère appartient au ministère; ceci est la partie dont l’équipe est responsable.
- BêtaRemplir
- StabilisationTenir à jour
- MaturitéTenir à jour
L’obligation de disposer d’un moyen de repérer, de contenir et de signaler un incident de cybersécurité avant qu’il survienne, et de le signaler dans la chaîne pangouvernementale quand il survient. Le plan pangouvernemental établit qui est prévenu, dans quel ordre, et comment un événement s’escalade en intervention coordonnée.
- BêtaRemplir
- StabilisationTenir à jour
- CroissanceTenir à jour
- MaturitéTenir à jour
- Rapport d’atteinte substantielle à la vie privéeOnly ifDéclaration
Le rapport qu’un ministère doit produire lorsque des renseignements personnels sont perdus, consultés ou communiqués d’une façon dont on pourrait raisonnablement s’attendre à ce qu’elle cause un préjudice grave. Il est transmis au Commissariat à la protection de la vie privée du Canada et au Secrétariat du Conseil du Trésor du Canada, et les personnes touchées sont avisées.
- BêtaVérifier
- StabilisationSoumettre
- CroissanceTenir à jour
- Liste de vérification des exigences relatives à la sécurité (LVERS, formulaire TBS/SCT 350-103)Only ifsourcePrésentation
Un court formulaire qui énonce, pour un contrat donné, exactement quelle sécurité le fournisseur et son personnel exigent : quel niveau d’information ils toucheront, quel filtrage chaque rôle exige, et si l’entreprise peut détenir de l’information gouvernementale dans ses propres bureaux.
- DécouverteVérifier
- AlphaRemplir
- BêtaSigner ou accepterSoumettre
- CroissanceTenir à jour
- MaturitéTenir à jour
- RetraitTenir à jour
Les attestations qu’une entreprise et ses employés doivent détenir avant de toucher à du travail gouvernemental sensible. Un ministère ne peut pas les délivrer lui-même, et le travail ne peut pas être adjugé tant que l’attestation n’est pas confirmée par écrit.
- AlphaVérifier
- BêtaRassemblerSigner ou accepter
- CroissanceTenir à jour
- MaturitéTenir à jour
Le travail de sécurité supplémentaire que porte un service hébergé dans le nuage : un profil de contrôles prêt à l’emploi sur lequel construire, des garde-fous qui doivent être mis en place, validés et déclarés dans les 30 premiers jours ouvrables suivant l’obtention d’un compte infonuagique, et une évaluation de sécurité qui tient compte du partage entre ce que fait le fournisseur et ce que fait le ministère.
- AlphaVérifierRassembler
- BêtaRemplirSigner ou accepter
- CroissanceTenir à jour
- MaturitéTenir à jour
Deux cotes, de un à quatre, indiquant à quel point le service doit être certain de l’identité d’une personne et quelle doit être la robustesse de l’ouverture de session. Elles contraignent la conception dès le départ, parce qu’elles déterminent ce que l’ouverture de session doit faire avant que quiconque la construise.
- DécouverteVérifier
- AlphaRassemblerRemplir
- CroissanceTenir à jour
Pour aller plus loin
La sécurité au gouvernement du Canada relève de la Politique sur la sécurité du gouvernement, et de sa Directive sur la gestion de la sécurité, qui exige que la sécurité soit gérée sur toute la vie d’un système. Le ministère réunit le tout dans un plan de sécurité ministériel, un plan triennal réexaminé chaque année et approuvé par l’administrateur général, et la posture de sécurité d’un service, ses risques résiduels et ses exigences de continuité s’y intègrent tous.
Le compagnon le plus proche de cette page est la Ligne directrice sur le développement sécurisé d’applications, sur le réseau du GC, sur laquelle ce fil s’appuie tout du long. Il puise aussi dans l’ITSG-33 pour le catalogue de contrôles du GC, et dans l’OWASP Top 10 ouvert et le NIST Secure Software Development Framework, transposés en décisions de responsable opérationnel.
Pour déterminer où la dépense réduit le plus le risque, les 10 principales mesures de sécurité des TI du Centre pour la cybersécurité classent les défenses qui comptent le plus, et ses contrôles de base pour les petites et moyennes organisations constituent un point de départ plus simple pour un service de moindre envergure. Pour l’argument voulant que la sécurité coûte le moins cher quand elle est conçue dès le départ plutôt qu’ajoutée après coup, les principes de sécurité dès la conception de la CISA américaine le présentent en termes de responsable opérationnel.
Voir aussi
Les hypothèses de cette page
Vous travaillez déjà selon les Normes relatives au numérique du gouvernement du Canada : concevoir avec les utilisateurs, itérer et améliorer fréquemment, travailler ouvertement, utiliser des normes et des solutions ouvertes, gérer les risques en matière de sécurité et de protection des renseignements personnels, intégrer l’accessibilité dès le début, permettre au personnel d’offrir de meilleurs services, être de bons gestionnaires de données, concevoir des services éthiques et collaborer largement, ainsi que selon la loi en matière de protection des renseignements personnels, de sécurité, de langues officielles et d’accessibilité. Les normes précisent comment le gouvernement travaille dans le monde numérique. Les six compétences numériques du gouvernement du Canada précisent ce que chaque fonctionnaire doit être capable de faire pour travailler ainsi, et la page sur l’équipe les présente. Le présent guide s’appuie sur elles.