Carte des contrôles · v4.0

PCI DSS

Preuve issue du code pour les données de carte stockées et en transit, les secrets, l’accès et le code sécurisé, et approbation des changements issue de chaque fusion.

Réserver un pilote d’audit Voir un exemple de rapport

PCI DSS · v4.026 exigences dans le périmètre · selon la correspondance de v1.4.1

Code 9
Processus 1
Prévu 16

Preuve issue du code

9exigences vérifiés à chaque pull request

Actif (processus)

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

Prévu

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

Exigences au niveau de l’organisation

Politiques, personnes, fournisseurs, sécurité physique et le reste, listés ci-dessous.Gérés par les processus de votre organisation

Les évaluateurs testent le logiciel sécurisé et le contrôle des changements à partir de tickets de changement, d’enregistrements de revue de code et de résultats de scans.

Le blueprint PCI DSS apporte une preuve issue du code pour des exigences comme le chiffrement des données stockées, le chiffrement en transit et les secrets des comptes de service. Chaque changement fusionné porte son approbation sous forme d’enregistrement scellé.

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 PCI DSS vérifient une partie de chacun à chaque pull request.

Req.1.3Limites du trafic entrantReq.1 Règles de frontière réseau
Req.3.3Conservation des secrets d’accèsReq.3 Protection des données stockées
Req.3.5Chiffrement des données stockéesReq.3 Protection des données stockées
Req.3.6Protection des clésReq.3 Protection des données stockées
Req.4.2Chiffrement en transitReq.4 Chiffrement en transit
Req.6.3Analyse des vulnérabilitésReq.6 Travail logiciel sécurisé
Req.7.2Droits d’accès par rôleReq.7 Limites d’accès
Req.7.3Limites d’accès aux systèmesReq.7 Limites d’accès
Req.8.6Secrets des comptes de serviceReq.8 Identité des utilisateurs

Actif (processus)1

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

Req.6.5Approbation des changementsReq.6 Travail logiciel sécuriséPreuve 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é

Prévu16

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.

Req.1.2Configuration réseauReq.1 Règles de frontière réseau
Req.1.4Frontières réseau de confianceReq.1 Règles de frontière réseau
Req.2.2Paramètres de durcissement systèmeReq.2 Paramètres système durcis
Req.3.2Limites de conservation des donnéesReq.3 Protection des données stockées
Req.3.4Masquage des numéros de carteReq.3 Protection des données stockées
Req.6.2Pratiques de code sécuriséReq.6 Travail logiciel sécurisé
Req.6.4Défenses contre les attaques webReq.6 Travail logiciel sécurisé
Req.8.2Cycle de vie des comptesReq.8 Identité des utilisateurs
Req.8.3Authentification forteReq.8 Identité des utilisateurs
Req.8.4Usage du second facteurReq.8 Identité des utilisateurs
Req.8.5Paramètres du second facteurReq.8 Identité des utilisateurs
Req.10.2Contenu des journaux d’auditReq.10 Journalisation d’audit
Req.10.3Protection des journauxReq.10 Journalisation d’audit
Req.10.5Conservation des journauxReq.10 Journalisation d’audit
Req.11.3Analyses récurrentesReq.11 Tests de sécurité
Req.11.6Intégrité des pages de paiementReq.11 Tests de sécurité

Exigences 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

Req.1 Règles de frontière réseau

Req.1.1Politique réseaude la politique de l’organisation

Req.1.5Politique de pontage des terminauxde la politique de l’organisation

Req.2 Paramètres système durcis

Req.2.1Politique de durcissementde la politique de l’organisation

Req.2.3Revue du sans-fild’un processus opérationnel

Req.3 Protection des données stockées

Req.3.1Politique de protection des donnéesde la politique de l’organisation

Req.3.7Processus de cycle de vie des clésd’un processus opérationnel

Req.4 Chiffrement en transit

Req.4.1Politique de transitde la politique de l’organisation

Req.5 Défense antimalware

Req.5.1Politique antimalwarede la politique de l’organisation

Req.5.2Défense antimalware des terminauxd’un processus opérationnel

Req.5.3Suivi des mises à jour antimalwared’un processus opérationnel

Req.5.4Défenses contre l’hameçonnaged’un processus opérationnel

Req.6 Travail logiciel sécurisé

Req.6.1Politique de développementde la politique de l’organisation

Req.7 Limites d’accès

Req.7.1Politique d’accèsde la politique de l’organisation

Req.8 Identité des utilisateurs

Req.8.1Politique de connexionde la politique de l’organisation

Req.9 Accès physique au site

Req.9.1Politique physiquede la politique de l’organisation

Req.9.2Contrôles d’entrée des locauxde la sécurité physique

Req.9.3Registre des visiteursde la sécurité physique

Req.9.4Règles de manipulation des supportsde la sécurité physique

Req.9.5Revue de l’altération des terminauxde la sécurité physique

Req.10 Journalisation d’audit

Req.10.1Politique de journalisationde la politique de l’organisation

Req.10.4Revue régulière des journauxd’un processus opérationnel

Req.10.6Synchronisation des horlogesd’un processus opérationnel

Req.10.7Processus de détection des défaillancesd’un processus opérationnel

Req.11 Tests de sécurité

Req.11.1Politique de testde la politique de l’organisation

Req.11.2Revue des accès sans fil non autorisésd’un processus opérationnel

Req.11.4Tests d’intrusiond’une évaluation externe

Req.11.5Processus de détection d’intrusiond’un processus opérationnel

Req.12 Programme de gouvernance

Req.12.1Programme de politique de sécuritéde la politique de l’organisation

Req.12.2Règles d’usage acceptablede la politique de l’organisation

Req.12.3Analyse de risque cibléede la politique de l’organisation

Req.12.4Suivi de la conformitéde la politique de l’organisation

Req.12.5Définition du périmètrede la politique de l’organisation

Req.12.6Formation de sensibilisationdes personnes et des RH

Req.12.7Vérification du personneldes personnes et des RH

Req.12.8Contrats avec les prestatairesdes contrats et des fournisseurs

Req.12.9Assistance des prestatairesdes contrats et des fournisseurs

Req.12.10Plan de réponse aux incidentsd’un processus opérationnel

L’utiliser dans un audit

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.
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 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.

Req.6.5Approbations 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’audit Voir 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