Control-Map · v4.0

PCI DSS

Audit-Pilot buchen Beispielbericht ansehen

11 von 26 Controls für PCI DSS, die Code belegen kann, mit v1.4.0, plus 1 unterstützend

Code-Nachweis heute für gespeicherte und übertragene Kartendaten, Secrets, Zugriff und sicheren Code; Änderungsfreigabe in v1.4.0.

Live10
Kommt in v1.4.01
Unterstützend1
Geplant15
Ihre Organisation36

10 mit Code-Nachweis heuteTeilnachweis, bei jedem Pull Request geprüft.
1 weitere in v1.4.0Prozessnachweis aus Merges, Freigaben und Regeländerungen.
36 bleiben bei Ihrer OrganisationUnten vollständig aufgelistet, damit nichts angedeutet wird.

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

Heute liefert der PCI-DSS-Blueprint Code-Nachweise für zehn Anforderungen, darunter Verschlüsselung gespeicherter Daten, Verschlüsselung bei der Übertragung und Secrets von Service-Konten. Ab v1.4.0 trägt jede gemergte Änderung ihre Freigabe als versiegelten Eintrag, und das Review vor dem Merge stärkt den Nachweis für sicheren Code.

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 erscheinen mit ID und Toevans eigenen Kurznamen. Die offiziellen Titel und Anforderungstexte gehören dem Herausgeber des Frameworks.

Live10

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

Req.1.3
Grenzen für eingehenden Verkehr
Req.1 Regeln für Netzwerkgrenzen
Req.3.3
Aufbewahrung von Anmelde-Secrets
Req.3 Schutz gespeicherter Daten
Req.3.5
Verschlüsselung gespeicherter Daten
Req.3 Schutz gespeicherter Daten
Req.3.6
Schutz von Schlüsseln
Req.3 Schutz gespeicherter Daten
Req.4.2
Verschlüsselung bei Übertragung
Req.4 Verschlüsselung bei Übertragung
Req.6.2
Gewohnheiten für sicheren Code
Req.6 Sichere Softwareentwicklung
Gestärkt in v1.4.0: Das Review vor dem Merge wird pro Änderung versiegelt.
Req.6.3
Schwachstellen-Scans
Req.6 Sichere Softwareentwicklung
Req.7.2
Rollenbasierte Zugriffsrechte
Req.7 Zugriffsgrenzen
Req.7.3
Grenzen beim Systemzugriff
Req.7 Zugriffsgrenzen
Req.8.6
Secrets von Service-Konten
Req.8 Nutzeridentität

Kommt in v1.4.01

Prozessnachweis: gemergte Pull Requests, Freigaben, Pflicht-Checks, Branch-Schutz, Rulesets und Umgehungen, pro Änderung versiegelt.

Req.6.5
Änderungsfreigabe
Req.6 Sichere Softwareentwicklung
Prozessnachweis: Jeder 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.

Unterstützend1

Toevan erfasst verwandte Nachweise, heute oder in v1.4.0, doch die Pflicht liegt bei der Organisation und gilt deshalb nie als abgedeckt.

Req.12.10
Incident-Response-Plan
Req.12 Governance-Programm
Unterstützender Nachweis heute: Eine Regel erfasst Nachweise zu dieser Pflicht. Die Pflicht selbst betrifft einen betrieblichen Prozess.

Geplant15

Lässt sich aus Code oder GitHub belegen. Die Regel oder die Zuordnung ist noch nicht gebaut.

Req.1.2
Netzwerkkonfiguration
Req.1 Regeln für Netzwerkgrenzen
Req.1.4
Vertrauenswürdige Netzwerkränder
Req.1 Regeln für Netzwerkgrenzen
Req.2.2
Einstellungen zur Systemhärtung
Req.2 Gehärtete Systemeinstellungen
Req.3.2
Grenzen der Datenspeicherung
Req.3 Schutz gespeicherter Daten
Req.3.4
Maskierung von Kartennummern
Req.3 Schutz gespeicherter Daten
Req.6.4
Schutz vor Web-Angriffen
Req.6 Sichere Softwareentwicklung
Req.8.2
Lebenszyklus von Konten
Req.8 Nutzeridentität
Req.8.3
Starke Authentifizierung
Req.8 Nutzeridentität
Req.8.4
Einsatz eines zweiten Faktors
Req.8 Nutzeridentität
Req.8.5
Einstellungen zum zweiten Faktor
Req.8 Nutzeridentität
Req.10.2
Inhalt von Audit-Logs
Req.10 Audit-Logging
Req.10.3
Manipulationsschutz für Logs
Req.10 Audit-Logging
Req.10.5
Aufbewahrung von Logs
Req.10 Audit-Logging
Req.11.3
Wiederkehrende Scans
Req.11 Sicherheitstests
Req.11.6
Integrität der Zahlungsseite
Req.11 Sicherheitstests

Ihre Organisation36

Richtlinien, Personal, physische Sicherheit, Verträge, regulatorische Verfahren, Betrieb oder externe Prüfung. Diese belegt Ihre Organisation.

Alle 36 Controls 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

Im Audit nutzen

Grundgesamtheit aus den Änderungseinträgen entnehmen (ab v1.4.0)
Jeder Merge in einen geschützten Branch und jeder direkte Push 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 für v1.4.1 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 das Ergebnis, dann Signatur und Platz in der Kette offline.
$ toevan audit verify --path evidence-clone --pub-key toevan.pub

Wie jeder Fakt erhoben wurde

Jeder Fakt in einem Eintrag und einem Bericht trägt eines von sechs Labels, damit Ihr Auditor weiß, wie weit er sich darauf stützen kann.

Neu berechnet: Toevan hat es selbst aus Code oder Git-Historie berechnet.; Mit denselben Eingaben nachvollziehen und dasselbe Ergebnis erhalten.
Gemeldet + versiegelt: GitHub hat es gemeldet; Toevan hat es beim Ereignis erfasst und signiert.; Verlassen Sie sich darauf, soweit Sie GitHub vertrauen. Jede spätere Änderung ist erkennbar.
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.; Sehen Sie, wer was wann erklärt hat, und jede spätere Änderung.
Toevan-Eintrag, nicht versiegelt: In der Datenbank von Toevan gespeichert, aber nicht im Ledger versiegelt, etwa eine Ausnahmegenehmigung heute. Keine Signatur schützt ihn.; Behandeln Sie ihn als Aussage von Toevan und fragen Sie die Organisation nach der Freigabe dahinter.
Übernommen: Aus dem signierten Eintrag eines anderen Systems übernommen, etwa einer Build-Provenienz, und per Commit oder Digest verknüpft. Geplant.; Den Originaleintrag unabhängig prüfen.
Nicht erfasst: Es gab keine verlässliche Quelle. Toevan schließt nichts daraus.; Auf anderem Weg bei der Organisation einholen.

Im Bericht ansehen

Der Beispielbericht zeigt den Nachweis so, wie Ihr Auditor ihn erhält, jeder Fakt mit Label.

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 Auditor durch die Prüfung.