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é.
Aujourd’hui, le blueprint ISO/IEC 27001 apporte une preuve issue du code pour onze contrôles, de la gestion des secrets au codage sécurisé. À partir de v1.4.0, la preuve de processus 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 présentés par identifiant avec les noms courts propres à Toevan. Les titres officiels et le texte des exigences appartiennent à l’éditeur du référentiel.
Actif11
Preuve issue du code dès aujourd’hui, scellée à chaque pull request. Toujours partielle : le contrôle exige aussi des éléments hors du code. Preuve issue du code dès aujourd’hui : les règles du blueprint ISO/IEC 27001 vérifient une partie de ce point à chaque pull request.
A.5.15Règles d’accès
A.5 Thèmes organisationnels
A.5.17Gestion des secrets
A.5 Thèmes organisationnels
A.8.2Limites des comptes à privilèges
A.8 Thèmes technologiques
A.8.3Limites de lecture des données
A.8 Thèmes technologiques
A.8.5Robustesse de la connexion
A.8 Thèmes technologiques
A.8.8Correction des failles logicielles
A.8 Thèmes technologiques
A.8.12Voies de fuite de données
A.8 Thèmes technologiques
A.8.20Garanties réseau
A.8 Thèmes technologiques
A.8.22Zones réseau
A.8 Thèmes technologiques
A.8.24Chiffrement et clés
A.8 Thèmes technologiques
A.8.28Pratiques de codage sécurisé
A.8 Thèmes technologiques
Prévu pour v1.4.05
Preuve de processus : pull requests fusionnées, approbations, checks requis, protection de branche, rulesets et contournements, scellés par changement.
A.8.4Limites d’accès au code
A.8 Thèmes technologiques
Preuve 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és
A.8 Thèmes technologiques
Preuve 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ûres
A.8 Thèmes technologiques
Preuve 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 release
A.8 Thèmes technologiques
Preuve de processus : les checks de sécurité requis réussis à la fusion, par changement.
A.8.32Approbations de changements
A.8 Thèmes technologiques
Preuve de processus : chaque pull request fusionnée 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.
En appui2
Toevan enregistre des preuves connexes, aujourd’hui ou dans v1.4.0, mais l’obligation relève de l’organisation : elle n’est donc jamais comptée comme couverte.
A.5.3Séparation des tâchesPrévu pour v1.4.0
A.5 Thèmes organisationnels
Sé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 logiciels
A.5 Thèmes organisationnels
Preuve d’appui dès aujourd’hui : une règle enregistre des preuves liées à cette obligation. L’obligation elle-même relève d’une procédure réglementaire.
Prévu10
Peut être prouvé à partir du code ou de GitHub. La règle ou la correspondance n’est pas encore construite.
A.5.16Cycle de vie des identités
A.5 Thèmes organisationnels
A.5.18Revue des permissions
A.5 Thèmes organisationnels
A.8.10Suppression des données
A.8 Thèmes technologiques
A.8.11Masquage des données sensibles
A.8 Thèmes technologiques
A.8.13Copies de sauvegarde
A.8 Thèmes technologiques
A.8.15Enregistrement de l’activité
A.8 Thèmes technologiques
A.8.26Exigences de sécurité applicative
A.8 Thèmes technologiques
A.8.27Pratiques de conception sécurisée
A.8 Thèmes technologiques
A.8.31Séparation test et production
A.8 Thèmes technologiques
A.8.33Soin des données de test
A.8 Thèmes technologiques
Votre organisation65
Politique, personnes, sécurité physique, contrats, procédure réglementaire, exploitation ou audit externe. Votre organisation en apporte la preuve.
Afficher les 65 contrôles
A.5 Thèmes organisationnels
A.5.1Ensemble de politiques écritesde la politique de l’organisationA.5.2Responsables des rôles de sécuritéde la politique de l’organisationA.5.4Soutien de la directionde la politique de l’organisationA.5.5Contacts avec les autoritésde la politique de l’organisationA.5.6Contacts avec les groupes d’expertsde la politique de l’organisationA.5.7Veille sur les attaquantsd’un processus opérationnelA.5.8Étapes de sécurité des projetsde la politique de l’organisationA.5.9Inventaire des actifsde la politique de l’organisationA.5.10Règles d’usage des actifsde la politique de l’organisationA.5.11Restitution des actifsde la politique de l’organisationA.5.12Classement par sensibilitéde la politique de l’organisationA.5.13Marquage de sensibilitéde la politique de l’organisationA.5.14Règles de transfert de donnéesde la politique de l’organisationA.5.19Exigences de sécurité fournisseurdes contrats et des fournisseursA.5.20Clauses des accords fournisseursdes contrats et des fournisseursA.5.21Contrôles de la chaîne fournisseursdes contrats et des fournisseursA.5.22Revue des services fournisseursdes contrats et des fournisseursA.5.23Règles d’usage du cloudde la politique de l’organisationA.5.24Préparation aux incidentsd’un processus opérationnelA.5.25Classement des événements par gravitéd’un processus opérationnelA.5.26Étapes de réponse aux incidentsd’un processus opérationnelA.5.27Retour d’expérience sur incidentsd’un processus opérationnelA.5.28Collecte de preuves d’incidentd’un processus opérationnelA.5.29Plans de sécurité en cas de panned’un processus opérationnelA.5.30Préparation à la reprised’un processus opérationnelA.5.31Suivi des obligations légalesd’une procédure réglementaireA.5.33Conservation des enregistrementsd’une procédure réglementaireA.5.34Obligations de confidentialitéd’une procédure réglementaireA.5.35Revue indépendanted’une évaluation externeA.5.36Revue du respect des politiquesd’une évaluation externeA.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 RHA.6.2Obligations de sécurité écritesdes personnes et des RHA.6.3Sensibilisation à la sécuritédes personnes et des RHA.6.4Conséquences des manquementsdes personnes et des RHA.6.5Obligations après le départdes personnes et des RHA.6.6Engagements de confidentialitédes personnes et des RHA.6.7Garanties du travail à distancede la politique de l’organisationA.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é physiqueA.7.2Contrôles d’entrée du sitede la sécurité physiqueA.7.3Locaux verrouillésde la sécurité physiqueA.7.4Surveillance des locauxde la sécurité physiqueA.7.5Protection incendie et inondationde la sécurité physiqueA.7.6Règles des zones sécuriséesde la sécurité physiqueA.7.7Bureaux dégagésde la sécurité physiqueA.7.8Emplacement des équipementsde la sécurité physiqueA.7.9Protection des actifs hors sitede la sécurité physiqueA.7.10Soin des supports de stockagede la sécurité physiqueA.7.11Secours en cas de coupurede la sécurité physiqueA.7.12Protection du câblagede la sécurité physiqueA.7.13Maintenance des équipementsde la sécurité physiqueA.7.14Effacement sûr des équipementsde la sécurité physique
A.8 Thèmes technologiques
A.8.1Protection des terminaux utilisateurd’un processus opérationnelA.8.6Planification de la capacitéd’un processus opérationnelA.8.7Défense antimalwared’un processus opérationnelA.8.14Capacité de réserved’un processus opérationnelA.8.16Suivi des comportements inhabituelsd’un processus opérationnelA.8.17Alignement des horlogesd’un processus opérationnelA.8.18Limites des programmes utilitairesd’un processus opérationnelA.8.19Approbation des logiciels en productiond’un processus opérationnelA.8.21Règles des services réseaud’un processus opérationnelA.8.23Filtrage du trafic webd’un processus opérationnelA.8.30Supervision des développeurs externesdes contrats et des fournisseursA.8.34Garanties pendant les auditsd’une évaluation externe
L’utiliser dans un audit
Prenez la population dans les enregistrements de changement (à partir de v1.4.0)
Chaque fusion dans une branche protégée et chaque push direct de 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 pour v1.4.1.
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.
Testez un échantillon
Pour chaque enregistrement échantillonné, vérifiez ses résultats, puis sa signature et sa place dans la chaîne, hors ligne.
toevan audit verify --path evidence-clone --pub-key toevan.pub
Comment chaque fait a été obtenu
Chaque fait d’un enregistrement et d’un rapport porte l’une de six étiquettes, pour que votre auditeur sache dans quelle mesure s’y fier.
- Recalculé
- Toevan l’a calculé lui-même à partir du code ou de l’historique git.
- Le refaire à partir des mêmes entrées et obtenir le même résultat.
- Rapporté + scellé
- GitHub l’a rapporté ; Toevan l’a capturé au moment de l’événement et signé.
- S’y fier dans la mesure où vous vous fiez à GitHub. Toute modification ultérieure est détectable.
- 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.
- Voir qui a déclaré quoi, quand, et chaque modification ultérieure.
- 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.
- Le considérer comme une déclaration de Toevan et demander à l’organisation l’approbation qui la fonde.
- Consommé
- Repris de l’enregistrement signé d’un autre système, comme une provenance de build, et relié par commit ou empreinte. Prévu.
- Vérifier l’enregistrement d’origine de façon indépendante.
- Non capturé
- Aucune source fiable n’était disponible. Toevan ne le déduit pas.
- L’obtenir auprès de l’organisation par d’autres moyens.
Le voir dans un rapport
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 rapportTestez la correspondance sur un vrai audit.
Apportez un dépôt et un audit à venir. Nous configurons le blueprint et guidons votre auditeur dans la vérification.