Control-Map · v4.0

PCI DSS

Code-Nachweis für gespeicherte und übertragene Kartendaten, Secrets, Zugriff und sicheren Code sowie Änderungsfreigabe aus jedem Merge.

Audit-Pilot buchen Beispielbericht ansehen

PCI DSS · v4.026 Anforderungen im Umfang · Stand v1.4.1

Code 9
Prozess 1
Geplant 16

Code-Nachweis

9Anforderungen, bei jedem Pull Request geprüft

Live (Prozess)

1aus Merges, Freigaben, Regeländerungen sowie von GitHub erfassten Deployments und Releases

Geplant

16lässt sich aus Code oder GitHub belegen; noch nicht gebaut

Anforderungen auf Organisationsebene

Richtlinien, Personal, Lieferanten, physische Sicherheit und Ähnliches, unten aufgelistet.Von den Abläufen Ihrer Organisation verantwortet

Assessoren prüfen sichere Software und Änderungskontrolle anhand von Änderungstickets, Code-Review-Einträgen und Scan-Ergebnissen.

Der PCI-DSS-Blueprint liefert Code-Nachweise für Anforderungen wie die Verschlüsselung gespeicherter Daten, die Verschlüsselung bei der Übertragung und Secrets von Service-Konten. Jede gemergte Änderung trägt ihre Freigabe als versiegelten Eintrag.

Toevan liefert Nachweise für Controls; es zertifiziert sie nie und behauptet nie, ein Framework sei abgedeckt. Ob die Nachweise genügen, beurteilt Ihr Auditor. Controls stehen mit ihrer ID und Toevans eigenen Kurznamen; die offiziellen Titel und der Anforderungstext gehören dem Herausgeber des Frameworks.

Code-Nachweis9

Bei jedem Pull Request versiegelt. Immer nur teilweise: Das Control verlangt auch Dinge außerhalb des Codes. Regeln im Blueprint PCI DSS prüfen bei jedem Pull Request einen Teil davon.

Req.1.3Grenzen für eingehenden VerkehrReq.1 Regeln für Netzwerkgrenzen
Req.3.3Aufbewahrung von Anmelde-SecretsReq.3 Schutz gespeicherter Daten
Req.3.5Verschlüsselung gespeicherter DatenReq.3 Schutz gespeicherter Daten
Req.3.6Schutz von SchlüsselnReq.3 Schutz gespeicherter Daten
Req.4.2Verschlüsselung bei ÜbertragungReq.4 Verschlüsselung bei Übertragung
Req.6.3Schwachstellen-ScansReq.6 Sichere Softwareentwicklung
Req.7.2Rollenbasierte ZugriffsrechteReq.7 Zugriffsgrenzen
Req.7.3Grenzen beim SystemzugriffReq.7 Zugriffsgrenzen
Req.8.6Secrets von Service-KontenReq.8 Nutzeridentität

Live (Prozess)1

Gemergte Pull Requests, Freigaben, Pflicht-Checks, Branch-Schutz, Rulesets und Umgehungen sowie von GitHub erfasste Deployments und Releases, jeweils versiegelt.

Req.6.5ÄnderungsfreigabeReq.6 Sichere SoftwareentwicklungProzessnachweis: Jeder in den Standard-Branch gemergte Pull Request wird als Änderungseintrag versiegelt, mit seinen Freigaben auf dem finalen Commit, den Pflicht-Checks beim Merge, der mergenden Person, seinen Signaturen und den mitgeführten Code-Urteilen.

Änderungseintrag rec_5b81d4e

Beispieldaten

Pull Request payments-api #1921 · Add tenant check to refund handlerGemeldet + versiegelt

Freigaben 9d07…e3a4, c58f…71d0 · beide auf dem letzten Commit e81b2d0Gemeldet + versiegelt

Unabhängig vom Autor Ja, nach GitHub-Konto-IDNeu berechnet

Pflicht-Checks ci/test ✓ · ci/lint ✓ · toevan/gate ✓Gemeldet + versiegelt

Geltende Regeln main-protection: 2 Freigaben, Pflicht-Checks, signierte CommitsGemeldet + versiegelt

Geplant16

Lässt sich aus Code oder GitHub belegen. Noch keine Regel prüft diese; jedes ist geplant, und keines zählt heute als Nachweis.

Req.1.2NetzwerkkonfigurationReq.1 Regeln für Netzwerkgrenzen
Req.1.4Vertrauenswürdige NetzwerkränderReq.1 Regeln für Netzwerkgrenzen
Req.2.2Einstellungen zur SystemhärtungReq.2 Gehärtete Systemeinstellungen
Req.3.2Grenzen der DatenspeicherungReq.3 Schutz gespeicherter Daten
Req.3.4Maskierung von KartennummernReq.3 Schutz gespeicherter Daten
Req.6.2Gewohnheiten für sicheren CodeReq.6 Sichere Softwareentwicklung
Req.6.4Schutz vor Web-AngriffenReq.6 Sichere Softwareentwicklung
Req.8.2Lebenszyklus von KontenReq.8 Nutzeridentität
Req.8.3Starke AuthentifizierungReq.8 Nutzeridentität
Req.8.4Einsatz eines zweiten FaktorsReq.8 Nutzeridentität
Req.8.5Einstellungen zum zweiten FaktorReq.8 Nutzeridentität
Req.10.2Inhalt von Audit-LogsReq.10 Audit-Logging
Req.10.3Manipulationsschutz für LogsReq.10 Audit-Logging
Req.10.5Aufbewahrung von LogsReq.10 Audit-Logging
Req.11.3Wiederkehrende ScansReq.11 Sicherheitstests
Req.11.6Integrität der ZahlungsseiteReq.11 Sicherheitstests

Anforderungen auf Organisationsebene

Controls auf Organisationsebene (Richtlinien, Personal, Lieferanten, physische Sicherheit und Ähnliches) bleiben beim eigenen Prozess Ihrer Organisation; Toevan übernimmt sie nicht.

Liste anzeigen

Req.1 Regeln für Netzwerkgrenzen

Req.1.1Netzwerkrichtlinie dokumentiertdie Richtlinien der Organisation

Req.1.5Richtlinie für Endpunkt-Brückendie Richtlinien der Organisation

Req.2 Gehärtete Systemeinstellungen

Req.2.1Härtungsrichtlinie dokumentiertdie Richtlinien der Organisation

Req.2.3Prüfung von WLANeinen betrieblichen Prozess

Req.3 Schutz gespeicherter Daten

Req.3.1Datenschutzrichtliniedie Richtlinien der Organisation

Req.3.7Prozess für Schlüssel-Lebenszykluseinen betrieblichen Prozess

Req.4 Verschlüsselung bei Übertragung

Req.4.1Übertragungsrichtlinie dokumentiertdie Richtlinien der Organisation

Req.5 Malware-Schutz

Req.5.1Malware-Richtlinie dokumentiertdie Richtlinien der Organisation

Req.5.2Malware-Schutz am Endpunkteinen betrieblichen Prozess

Req.5.3Überwachung von Malware-Updateseinen betrieblichen Prozess

Req.5.4Schutz vor Phishingeinen betrieblichen Prozess

Req.6 Sichere Softwareentwicklung

Req.6.1Entwicklungsrichtlinie dokumentiertdie Richtlinien der Organisation

Req.7 Zugriffsgrenzen

Req.7.1Zugriffsrichtlinie dokumentiertdie Richtlinien der Organisation

Req.8 Nutzeridentität

Req.8.1Anmelderichtliniedie Richtlinien der Organisation

Req.9 Physischer Standortzugang

Req.9.1Richtlinie zur physischen Sicherheitdie Richtlinien der Organisation

Req.9.2Zutrittskontrollen zur Anlagedie physische Sicherheit

Req.9.3Besucherprotokolledie physische Sicherheit

Req.9.4Regeln für Datenträgerdie physische Sicherheit

Req.9.5Prüfung von Terminals auf Manipulationdie physische Sicherheit

Req.10 Audit-Logging

Req.10.1Logging-Richtlinie dokumentiertdie Richtlinien der Organisation

Req.10.4Regelmäßige Log-Prüfungeinen betrieblichen Prozess

Req.10.6Zeitsynchronisationeinen betrieblichen Prozess

Req.10.7Prozess zur Fehlererkennungeinen betrieblichen Prozess

Req.11 Sicherheitstests

Req.11.1Testrichtlinie dokumentiertdie Richtlinien der Organisation

Req.11.2Prüfung auf fremdes WLANeinen betrieblichen Prozess

Req.11.4Penetrationstestseine externe Prüfung

Req.11.5Prozess zur Angriffserkennungeinen betrieblichen Prozess

Req.12 Governance-Programm

Req.12.1Programm für Sicherheitsrichtliniendie Richtlinien der Organisation

Req.12.2Regeln zur zulässigen Nutzungdie Richtlinien der Organisation

Req.12.3Gezielte Risikoprüfungdie Richtlinien der Organisation

Req.12.4Compliance-Aufsichtdie Richtlinien der Organisation

Req.12.5Nachweis zur Umfangsdefinitiondie Richtlinien der Organisation

Req.12.6Schulung zum BewusstseinPersonal und HR

Req.12.7Überprüfung von MitarbeiternPersonal und HR

Req.12.8Verträge mit DienstleisternVerträge und Lieferanten

Req.12.9Pflichten der DienstleisterVerträge und Lieferanten

Req.12.10Incident-Response-Planeinen betrieblichen Prozess

Im Audit verwenden

Grundgesamtheit aus den Änderungseinträgen entnehmen
Jeder in den Standard-Branch gemergte Pull Request und jeder Push auf einen geschützten Branch, den kein gemergter Pull Request erklärt, im Zeitraum, beim Eintreten aus GitHub erfasst, ist ein versiegelter Eintrag, den Sie für die Stichprobe exportieren können. Die Grundgesamtheit des Standard-Branches können Sie aus der Git-Historie nachvollziehen; festgelegte Produktions-Branches sind geplant.
Code-Nachweise des Zeitraums lesen
Jeder Pull Request trägt versiegelte Code-Ergebnisse zu den Regeln des Blueprints, festgemacht am Commit und an der geltenden Regelsatz-Version.
Stichprobe testen
Prüfen Sie für jeden gezogenen Eintrag zuerst die Ergebnisse und dann offline gegen den veröffentlichten Schlüssel mit openssl und der Shell: Nachweis holen, Schlüssel bestätigen, Eintrag prüfen. Um die ganze Kette nachzuvollziehen, stellt Toevan den toevan-Befehl auf Anfrage bereit; er ist noch nicht öffentlich.
Die drei Schritte, mit den genauen Befehlen

Wie jeder Fakt gewonnen wurde6 Labels

Neu berechnet: Toevan hat es selbst aus Code oder Git-Historie berechnet.
Gemeldet + versiegelt: GitHub hat es gemeldet; Toevan hat es beim Ereignis erfasst und signiert.
Erklärt + versiegelt: Die Organisation hat es erklärt, etwa eine Änderung dessen, was geprüft wird; Toevan hat die Erklärung und ihre Historie signiert.
Toevan-Eintrag, nicht versiegelt: In der Datenbank von Toevan gespeichert, aber nicht im Ledger versiegelt, etwa eine Ausnahmegenehmigung heute. Keine Signatur schützt ihn.
Übernommen: Aus den Deployment- und Release-Einträgen von GitHub übernommen und per Commit oder Digest verknüpft.
Nicht erfasst: Es gab keine verlässliche Quelle. Toevan schließt nichts daraus.

Req.6.5ÄnderungsfreigabenPrüfblatt · Beispieldaten

Grundgesamtheit148 Änderungen: 146 gemergte Pull Requests und 2 direkte Pushes
Neu berechnet aus der Git-Historie aufgelistet und mit den versiegelten Einträgen abgeglichen

Stichprobe25 vom Prüfer gezogen, jeweils ein versiegelter Eintrag

FreigabenGemeldet + versiegelt aus GitHub beim Merge, unabhängig vom Autor

AusnahmenKein PR 2 direkte Pushes am 19. Sep.Lücke Review-Pflicht 29 Minuten lang ausBeide stehen im Eintrag.

Signaturen25 / 25 ✓ Verified OK

Der Beispielbericht zu Änderungsnachweisen zeigt die Nachweise so, wie Ihr Prüfer sie erhält, jeden Fakt mit Herkunft.Beispielbericht öffnen

Testen Sie die Zuordnung an einem echten Audit.

Bringen Sie ein Repository und ein anstehendes Audit mit. Wir richten den Blueprint ein und führen Ihren Prüfer durch die Verifikation.

Audit-Pilot buchen Beispielbericht ansehen

Ein Repository, ein Framework
Nachweise ab dem ersten Pull Request
Prüfbar ohne Toevan-Konto