Aller au contenu
toevan
Se connecterRéserver un pilote d’audit
Ouvrir le menuFermer le menu
Réserver un pilote d’audit

Carte des contrôles · 2022, Annexe A

ISO/IEC 27001

Preuve issue du code pour des contrôles de l’Annexe A, de la gestion des secrets à la cryptographie, et preuves de changement, d’accès au code et de paramétrage issues de chaque fusion.

Réserver un pilote d’auditVoir un exemple de rapport
ISO/IEC 27001 · 2022, Annexe A26 contrôles dans le périmètre · selon la correspondance de v1.4.1
  • Code 9
  • Processus 6
  • Prévu 11

Preuve issue du code

9contrôles vérifiés à chaque pull request

Actif (processus)

6issus des fusions, approbations, changements de règle et des déploiements et releases enregistrés par GitHub

Prévu

11peut être prouvé à partir du code ou de GitHub ; pas encore construit

Contrôles au niveau de l’organisation

Politiques, personnes, fournisseurs, sécurité physique et le reste, listés ci-dessous.Toevan apporte une preuve d’appui pour 2 d’entre eux.Gérés par les processus de votre organisation

Un audit de certification ou de surveillance demande la preuve que les contrôles de l’Annexe A sont mis en œuvre et fonctionnent. Pour l’ingénierie, cela touche la gestion des changements et le développement sécurisé.

Le blueprint ISO/IEC 27001 apporte une preuve issue du code pour des contrôles de l’Annexe A, de la gestion des secrets à la cryptographie. La preuve de processus de chaque fusion ajoute les approbations de changements, des étapes de build sûres, des tests de sécurité avant release, des limites d’accès au code et des paramètres approuvés. Les contrôles organisationnels, liés aux personnes et physiques restent dans votre SMSI.

Toevan apporte des preuves pour des contrôles ; il ne les certifie jamais et ne prétend pas qu’un référentiel est couvert. Que les preuves suffisent relève du jugement de votre auditeur. Les contrôles sont affichés par id avec les noms courts propres à Toevan ; les titres officiels et le texte des exigences appartiennent à l’éditeur du référentiel.

Preuve issue du code9

Scellée à chaque pull request. Toujours partielle : le contrôle exige aussi des éléments hors du code. Les règles du blueprint ISO/IEC 27001 vérifient une partie de chacun à chaque pull request.

  • A.5.15Règles d’accèsA.5 Thèmes organisationnels
  • A.5.17Gestion des secretsA.5 Thèmes organisationnels
  • A.8.2Limites des comptes à privilègesA.8 Thèmes technologiques
  • A.8.3Limites de lecture des donnéesA.8 Thèmes technologiques
  • A.8.8Correction des failles logiciellesA.8 Thèmes technologiques
  • A.8.12Voies de fuite de donnéesA.8 Thèmes technologiques
  • A.8.20Garanties réseauA.8 Thèmes technologiques
  • A.8.22Zones réseauA.8 Thèmes technologiques
  • A.8.24Chiffrement et clésA.8 Thèmes technologiques

Actif (processus)6

Pull requests fusionnées, approbations, checks requis, protection de branche, rulesets et contournements, et déploiements et releases enregistrés par GitHub, chacun scellé.

  • A.8.4Limites d’accès au codeA.8 Thèmes technologiquesPreuve de processus : protection de branche, rulesets et chaque contournement d’une branche protégée, scellés comme changements de contrôles.
  • A.8.9Paramètres approuvésA.8 Thèmes technologiquesPreuve de processus : modifications des rulesets et de la protection de branche du dépôt, scellées avec leur état avant et après.
  • A.8.25Étapes de build sûresA.8 Thèmes technologiquesPreuve de processus : les revues et les checks requis à la fusion montrent que le processus de développement a été suivi pour chaque changement.
  • A.8.29Tests de sécurité avant releaseA.8 Thèmes technologiquesPreuve de processus : les checks de sécurité requis réussis à la fusion, par changement.
  • A.8.31Séparation test et productionA.8 Thèmes technologiquesPreuve de processus : un déploiement en production d’un commit déjà déployé avec succès dans un autre environnement. Elle ne montre ni ce qui y a été testé, ni la séparation des accès et des données entre environnements.
  • A.8.32Approbations de changementsA.8 Thèmes technologiquesPreuve de processus : chaque pull request fusionnée dans la branche par défaut est scellée en enregistrement de changement avec ses approbations sur le dernier commit, les checks requis à la fusion, la personne qui l’a fusionnée, ses signatures et les verdicts de code qu’elle portait.

Enregistrement de changement rec_5b81d4e

données d’exemple
Pull request  payments-api #1921 · Add tenant check to refund handlerRapporté + scellé
Approbations  9d07…e3a4, c58f…71d0 · toutes deux sur le commit final e81b2d0Rapporté + scellé
Indépendant de l’auteur  Oui, par identifiant de compte GitHubRecalculé
Checks requis  ci/test ✓ · ci/lint ✓ · toevan/gate ✓Rapporté + scellé
Règles en vigueur  main-protection : 2 approbations, checks requis, commits signésRapporté + scellé

En appui2

Toevan enregistre des preuves connexes, mais l’obligation relève de l’organisation : elle n’est donc jamais comptée comme couverte.

  • A.5.3Séparation des tâchesA.5 Thèmes organisationnelsSéparation des tâches par changement : l’auteur face aux approbateurs, calculée à partir des identifiants de compte GitHub. L’obligation plus large reste organisationnelle.
  • A.5.32Registre des droits logicielsA.5 Thèmes organisationnelsPreuve d’appui : une règle enregistre des preuves liées à cette obligation. L’obligation elle-même relève d’une procédure réglementaire.

Prévu11

Peut être prouvé à partir du code ou de GitHub. Aucune règle ne les vérifie encore ; chacun est prévu, et aucun ne compte aujourd’hui comme preuve.

  • A.5.16Cycle de vie des identitésA.5 Thèmes organisationnels
  • A.5.18Revue des permissionsA.5 Thèmes organisationnels
  • A.8.5Robustesse de la connexionA.8 Thèmes technologiques
  • A.8.10Suppression des donnéesA.8 Thèmes technologiques
  • A.8.11Masquage des données sensiblesA.8 Thèmes technologiques
  • A.8.13Copies de sauvegardeA.8 Thèmes technologiques
  • A.8.15Enregistrement de l’activitéA.8 Thèmes technologiques
  • A.8.26Exigences de sécurité applicativeA.8 Thèmes technologiques
  • A.8.27Pratiques de conception sécuriséeA.8 Thèmes technologiques
  • A.8.28Pratiques de codage sécuriséA.8 Thèmes technologiques
  • A.8.33Soin des données de testA.8 Thèmes technologiques

Contrôles au niveau de l’organisation

Les contrôles au niveau de l’organisation (politiques, personnes, fournisseurs, sécurité physique et le reste) restent dans le processus propre à votre organisation ; Toevan ne s’en charge pas.

Afficher la liste

A.5 Thèmes organisationnels

A.5.1Ensemble de politiques écritesde la politique de l’organisation
A.5.2Responsables des rôles de sécuritéde la politique de l’organisation
A.5.4Soutien de la directionde la politique de l’organisation
A.5.5Contacts avec les autoritésde la politique de l’organisation
A.5.6Contacts avec les groupes d’expertsde la politique de l’organisation
A.5.7Veille sur les attaquantsd’un processus opérationnel
A.5.8Étapes de sécurité des projetsde la politique de l’organisation
A.5.9Inventaire des actifsde la politique de l’organisation
A.5.10Règles d’usage des actifsde la politique de l’organisation
A.5.11Restitution des actifsde la politique de l’organisation
A.5.12Classement par sensibilitéde la politique de l’organisation
A.5.13Marquage de sensibilitéde la politique de l’organisation
A.5.14Règles de transfert de donnéesde la politique de l’organisation
A.5.19Exigences de sécurité fournisseurdes contrats et des fournisseurs
A.5.20Clauses des accords fournisseursdes contrats et des fournisseurs
A.5.21Contrôles de la chaîne fournisseursdes contrats et des fournisseurs
A.5.22Revue des services fournisseursdes contrats et des fournisseurs
A.5.23Règles d’usage du cloudde la politique de l’organisation
A.5.24Préparation aux incidentsd’un processus opérationnel
A.5.25Classement des événements par gravitéd’un processus opérationnel
A.5.26Étapes de réponse aux incidentsd’un processus opérationnel
A.5.27Retour d’expérience sur incidentsd’un processus opérationnel
A.5.28Collecte de preuves d’incidentd’un processus opérationnel
A.5.29Plans de sécurité en cas de panned’un processus opérationnel
A.5.30Préparation à la reprised’un processus opérationnel
A.5.31Suivi des obligations légalesd’une procédure réglementaire
A.5.33Conservation des enregistrementsd’une procédure réglementaire
A.5.34Obligations de confidentialitéd’une procédure réglementaire
A.5.35Revue indépendanted’une évaluation externe
A.5.36Revue du respect des politiquesd’une évaluation externe
A.5.37Procédures d’exploitation écritesde la politique de l’organisation

A.6 Thèmes liés aux personnes

A.6.1Vérification des antécédentsdes personnes et des RH
A.6.2Obligations de sécurité écritesdes personnes et des RH
A.6.3Sensibilisation à la sécuritédes personnes et des RH
A.6.4Conséquences des manquementsdes personnes et des RH
A.6.5Obligations après le départdes personnes et des RH
A.6.6Engagements de confidentialitédes personnes et des RH
A.6.7Garanties du travail à distancede la politique de l’organisation
A.6.8Signalement par le personneld’un processus opérationnel

A.7 Thèmes physiques

A.7.1Périmètres de site sécurisésde la sécurité physique
A.7.2Contrôles d’entrée du sitede la sécurité physique
A.7.3Locaux verrouillésde la sécurité physique
A.7.4Surveillance des locauxde la sécurité physique
A.7.5Protection incendie et inondationde la sécurité physique
A.7.6Règles des zones sécuriséesde la sécurité physique
A.7.7Bureaux dégagésde la sécurité physique
A.7.8Emplacement des équipementsde la sécurité physique
A.7.9Protection des actifs hors sitede la sécurité physique
A.7.10Soin des supports de stockagede la sécurité physique
A.7.11Secours en cas de coupurede la sécurité physique
A.7.12Protection du câblagede la sécurité physique
A.7.13Maintenance des équipementsde la sécurité physique
A.7.14Effacement sûr des équipementsde la sécurité physique

A.8 Thèmes technologiques

A.8.1Protection des terminaux utilisateurd’un processus opérationnel
A.8.6Planification de la capacitéd’un processus opérationnel
A.8.7Défense antimalwared’un processus opérationnel
A.8.14Capacité de réserved’un processus opérationnel
A.8.16Suivi des comportements inhabituelsd’un processus opérationnel
A.8.17Alignement des horlogesd’un processus opérationnel
A.8.18Limites des programmes utilitairesd’un processus opérationnel
A.8.19Approbation des logiciels en productiond’un processus opérationnel
A.8.21Règles des services réseaud’un processus opérationnel
A.8.23Filtrage du trafic webd’un processus opérationnel
A.8.30Supervision des développeurs externesdes contrats et des fournisseurs
A.8.34Garanties pendant les auditsd’une évaluation externe

L’utiliser dans un audit

  1. Prenez la population dans les enregistrements de changement

    Chaque pull request fusionnée dans la branche par défaut et chaque push vers une branche protégée qu’aucune pull request fusionnée n’explique, sur la période, capturés depuis GitHub au fil de l’eau, forment un enregistrement scellé que vous pouvez exporter pour échantillonner. Vous pouvez refaire la population de la branche par défaut à partir de l’historique git ; les branches de production désignées sont prévues.

  2. Lisez les preuves issues du code pour la période

    Chaque pull request porte des résultats de code scellés par rapport aux règles du blueprint, rattachés au commit et à la version du jeu de règles en vigueur.

  3. Testez un échantillon

    Pour chaque enregistrement échantillonné, vérifiez ses résultats, puis vérifiez-le hors ligne avec la clé publiée, avec openssl et le shell : récupérez la preuve, confirmez la clé, contrôlez l’enregistrement. Pour rejouer toute la chaîne, Toevan fournit la commande toevan sur demande ; elle n’est pas encore publique.

    Les trois étapes, avec les commandes exactes

Comment chaque fait a été obtenu6 étiquettes
Recalculé
Toevan l’a calculé lui-même à partir du code ou de l’historique git.
Rapporté + scellé
GitHub l’a rapporté ; Toevan l’a capturé au moment de l’événement et signé.
Déclaré + scellé
L’organisation l’a déclaré, par exemple un changement de ce qui est vérifié ; Toevan a signé la déclaration et son historique.
Enregistrement Toevan, non scellé
Conservé dans la base de données de Toevan mais non scellé dans le registre, comme une dérogation aujourd’hui. Aucune signature ne le protège.
Consommé
Repris des enregistrements de déploiement et de release de GitHub et relié par commit ou empreinte.
Non capturé
Aucune source fiable n’était disponible. Toevan ne le déduit pas.
A.8.4Approbations de changementsFeuille de test · données d’exemple
Population148 changements : 146 pull requests fusionnées et 2 pushes directs
Recalculé listée à partir de l’historique git et rapprochée des enregistrements scellés
Échantillon25 tirés par l’auditeur, chacun un enregistrement scellé
ApprobationsRapporté + scellé depuis GitHub à la fusion, indépendantes de l’auteur
ExceptionsSans PR 2 pushes directs le 19 sept.Écart exigence de revue désactivée pendant 29 minutesLes deux figurent dans l’enregistrement.
Signatures25 / 25 ✓ Verified OK
L’exemple de rapport de preuves de changement montre les preuves telles que votre auditeur les reçoit, chaque fait étant étiqueté.Ouvrir l’exemple de rapport

Testez la correspondance sur un vrai audit.

Venez avec un dépôt et un audit à venir. Nous configurerons le blueprint et guiderons votre auditeur dans la vérification.

Réserver un pilote d’auditVoir un exemple de rapport
  • Un dépôt, un référentiel
  • Des preuves dès la première pull request
  • Vérifiable sans compte Toevan