Carte des contrôles · v4.0

PCI DSS

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

11 contrôles PCI DSS sur 26 que le code peut prouver, avec v1.4.0, plus 1 en appui

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é aujourd’hui ; approbation des changements dans v1.4.0.

Actif10
Prévu pour v1.4.01
En appui1
Prévu15
Votre organisation36

10 avec preuve issue du code aujourd’huiPreuve partielle, vérifiée à chaque pull request.
1 de plus dans v1.4.0Preuve de processus issue des fusions, approbations et changements de règles.
36 restent à votre organisationListés en entier ci-dessous, pour que rien ne soit sous-entendu.

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.

Aujourd’hui, le blueprint PCI DSS apporte une preuve issue du code pour dix exigences, dont le chiffrement des données stockées, le chiffrement en transit et les secrets des comptes de service. À partir de v1.4.0, chaque changement fusionné porte son approbation sous forme d’enregistrement scellé, et la revue avant fusion renforce la preuve de code sécurisé.

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.

Actif10

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

Req.1.3
Limites du trafic entrant
Req.1 Règles de frontière réseau
Req.3.3
Conservation des secrets d’accès
Req.3 Protection des données stockées
Req.3.5
Chiffrement des données stockées
Req.3 Protection des données stockées
Req.3.6
Protection des clés
Req.3 Protection des données stockées
Req.4.2
Chiffrement en transit
Req.4 Chiffrement en transit
Req.6.2
Pratiques de code sécurisé
Req.6 Travail logiciel sécurisé
Renforcé dans v1.4.0 : la revue avant fusion est scellée par changement.
Req.6.3
Analyse des vulnérabilités
Req.6 Travail logiciel sécurisé
Req.7.2
Droits d’accès par rôle
Req.7 Limites d’accès
Req.7.3
Limites d’accès aux systèmes
Req.7 Limites d’accès
Req.8.6
Secrets des comptes de service
Req.8 Identité des utilisateurs

Prévu pour v1.4.01

Preuve de processus : pull requests fusionnées, approbations, checks requis, protection de branche, rulesets et contournements, scellés par changement.

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

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.

Req.12.10
Plan de réponse aux incidents
Req.12 Programme de gouvernance
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’un processus opérationnel.

Prévu15

Peut être prouvé à partir du code ou de GitHub. La règle ou la correspondance n’est pas encore construite.

Req.1.2
Configuration réseau
Req.1 Règles de frontière réseau
Req.1.4
Frontières réseau de confiance
Req.1 Règles de frontière réseau
Req.2.2
Paramètres de durcissement système
Req.2 Paramètres système durcis
Req.3.2
Limites de conservation des données
Req.3 Protection des données stockées
Req.3.4
Masquage des numéros de carte
Req.3 Protection des données stockées
Req.6.4
Défenses contre les attaques web
Req.6 Travail logiciel sécurisé
Req.8.2
Cycle de vie des comptes
Req.8 Identité des utilisateurs
Req.8.3
Authentification forte
Req.8 Identité des utilisateurs
Req.8.4
Usage du second facteur
Req.8 Identité des utilisateurs
Req.8.5
Paramètres du second facteur
Req.8 Identité des utilisateurs
Req.10.2
Contenu des journaux d’audit
Req.10 Journalisation d’audit
Req.10.3
Protection des journaux
Req.10 Journalisation d’audit
Req.10.5
Conservation des journaux
Req.10 Journalisation d’audit
Req.11.3
Analyses récurrentes
Req.11 Tests de sécurité
Req.11.6
Intégrité des pages de paiement
Req.11 Tests de sécurité

Votre organisation36

Politique, personnes, sécurité physique, contrats, procédure réglementaire, exploitation ou audit externe. Votre organisation en apporte la preuve.

Afficher les 36 contrôles

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

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 rapport

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