Control-Map · 2022, Annex A

ISO/IEC 27001

Audit-Pilot buchen Beispielbericht ansehen

16 von 26 Controls für ISO/IEC 27001, die Code belegen kann, mit v1.4.0, plus 2 unterstützend

Code-Nachweis für elf Annex-A-Controls heute; Nachweise zu Änderungen, Code-Zugriff und Einstellungen in v1.4.0.

Live11
Kommt in v1.4.05
Unterstützend2
Geplant10
Ihre Organisation65

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

Ein Zertifizierungs- oder Überwachungsaudit verlangt Nachweise, dass Annex-A-Controls umgesetzt sind und wirken. Für das Engineering heißt das: Änderungsabwicklung und sichere Entwicklung.

Heute liefert der ISO/IEC-27001-Blueprint Code-Nachweise für elf Controls, vom Umgang mit Secrets bis zu sicherem Coding. Ab v1.4.0 ergänzt der Prozessnachweis Änderungsfreigaben, sichere Build-Stufen, Sicherheitstests vor dem Release, Grenzen beim Code-Zugriff und freigegebene Einstellungen. Organisatorische, personelle und physische Controls bleiben bei Ihrem ISMS.

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.

Live11

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 ISO/IEC 27001 prüfen einen Teil davon bei jedem Pull Request.

A.5.15
Zugriffsregeln
A.5 Organisatorische Themen
A.5.17
Umgang mit Secrets
A.5 Organisatorische Themen
A.8.2
Grenzen für mächtige Konten
A.8 Technologische Themen
A.8.3
Grenzen beim Datenlesen
A.8 Technologische Themen
A.8.5
Stärke der Anmeldung
A.8 Technologische Themen
A.8.8
Beheben von Softwarefehlern
A.8 Technologische Themen
A.8.12
Wege für Datenlecks
A.8 Technologische Themen
A.8.20
Netzwerkschutz
A.8 Technologische Themen
A.8.22
Netzwerkzonen
A.8 Technologische Themen
A.8.24
Verschlüsselung und Schlüssel
A.8 Technologische Themen
A.8.28
Gewohnheiten für sicheres Coding
A.8 Technologische Themen

Kommt in v1.4.05

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

A.8.4
Grenzen beim Code-Zugriff
A.8 Technologische Themen
Prozessnachweis: Branch-Schutz, Rulesets und jede Umgehung eines geschützten Branches, als Control-Änderungen versiegelt.
A.8.9
Freigegebene Einstellungen
A.8 Technologische Themen
Prozessnachweis: Änderungen an Repository-Rulesets und Branch-Schutz, mit Zustand davor und danach versiegelt.
A.8.25
Sichere Build-Stufen
A.8 Technologische Themen
Prozessnachweis: Die Reviews und Pflicht-Checks beim Merge zeigen, dass der Entwicklungsprozess bei jeder Änderung lief.
A.8.29
Sicherheitstests vor Release
A.8 Technologische Themen
Prozessnachweis: die beim Merge bestandenen Pflicht-Sicherheitschecks, pro Änderung.
A.8.32
Änderungsfreigaben
A.8 Technologische Themen
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ützend2

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

A.5.3
AufgabentrennungKommt in v1.4.0
A.5 Organisatorische Themen
Aufgabentrennung pro Änderung: der Autor gegenüber den Freigebenden, aus GitHub-Konto-IDs berechnet. Die weitergehende Pflicht bleibt organisatorisch.
A.5.32
Nachweise zu Softwarerechten
A.5 Organisatorische Themen
Unterstützender Nachweis heute: Eine Regel erfasst Nachweise zu dieser Pflicht. Die Pflicht selbst betrifft ein regulatorisches Verfahren.

Geplant10

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

A.5.16
Lebenszyklus von Identitäten
A.5 Organisatorische Themen
A.5.18
Prüfung von Berechtigungen
A.5 Organisatorische Themen
A.8.10
Löschen von Daten
A.8 Technologische Themen
A.8.11
Maskieren sensibler Daten
A.8 Technologische Themen
A.8.13
Backup-Kopien
A.8 Technologische Themen
A.8.15
Aktivitätsaufzeichnung
A.8 Technologische Themen
A.8.26
Sicherheitsanforderungen an Apps
A.8 Technologische Themen
A.8.27
Gewohnheiten für sicheres Design
A.8 Technologische Themen
A.8.31
Trennung von Test und Live
A.8 Technologische Themen
A.8.33
Sorgfalt bei Testdaten
A.8 Technologische Themen

Ihre Organisation65

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

Alle 65 Controls anzeigen

A.5 Organisatorische Themen

A.5.1Schriftliche Richtliniendie Richtlinien der Organisation
A.5.2Inhaber von Sicherheitsrollendie Richtlinien der Organisation
A.5.4Rückhalt der Leitungdie Richtlinien der Organisation
A.5.5Kontakte zu Behördendie Richtlinien der Organisation
A.5.6Kontakte zu Fachgruppendie Richtlinien der Organisation
A.5.7Beobachtung von Angreifer-Newseinen betrieblichen Prozess
A.5.8Sicherheitsschritte im Projektdie Richtlinien der Organisation
A.5.9Liste der Assets mit Inhaberdie Richtlinien der Organisation
A.5.10Regeln zur Asset-Nutzungdie Richtlinien der Organisation
A.5.11Rückgabe von Assetsdie Richtlinien der Organisation
A.5.12Sortierung nach Schutzbedarfdie Richtlinien der Organisation
A.5.13Kennzeichnung nach Schutzbedarfdie Richtlinien der Organisation
A.5.14Regeln zur Datenübertragungdie Richtlinien der Organisation
A.5.19Sicherheitsanforderungen an LieferantenVerträge und Lieferanten
A.5.20Klauseln in LieferantenverträgenVerträge und Lieferanten
A.5.21Controls in der LieferketteVerträge und Lieferanten
A.5.22Prüfung von LieferantenleistungenVerträge und Lieferanten
A.5.23Regeln zur Cloud-Nutzungdie Richtlinien der Organisation
A.5.24Incident-Bereitschafteinen betrieblichen Prozess
A.5.25Einstufung von Ereignisseneinen betrieblichen Prozess
A.5.26Schritte der Incident Responseeinen betrieblichen Prozess
A.5.27Lernen aus Incidentseinen betrieblichen Prozess
A.5.28Sicherung von Incident-Nachweiseneinen betrieblichen Prozess
A.5.29Sicherheitspläne bei Ausfälleneinen betrieblichen Prozess
A.5.30Bereitschaft zur Wiederherstellungeinen betrieblichen Prozess
A.5.31Verfolgung rechtlicher Pflichtenein regulatorisches Verfahren
A.5.33Sichere Aufbewahrung von Aufzeichnungenein regulatorisches Verfahren
A.5.34Datenschutzpflichtenein regulatorisches Verfahren
A.5.35Unabhängige Prüfungeine externe Prüfung
A.5.36Prüfung der Richtlinientreueeine externe Prüfung
A.5.37Schriftliche Betriebsschrittedie Richtlinien der Organisation

A.6 Personelle Themen

A.6.1Hintergrundprüfung bei EinstellungPersonal und HR
A.6.2Schriftliche SicherheitspflichtenPersonal und HR
A.6.3Schulung zum SicherheitsbewusstseinPersonal und HR
A.6.4Folgen von RegelverstößenPersonal und HR
A.6.5Pflichten nach dem AusscheidenPersonal und HR
A.6.6Zusagen zur GeheimhaltungPersonal und HR
A.6.7Schutz bei Remote-Arbeitdie Richtlinien der Organisation
A.6.8Meldung von Problemen durch Mitarbeitereinen betrieblichen Prozess

A.7 Physische Themen

A.7.1Sichere Standortgrenzendie physische Sicherheit
A.7.2Zutrittskontrollen zum Standortdie physische Sicherheit
A.7.3Verschlossene Räumedie physische Sicherheit
A.7.4Überwachung der Räumlichkeitendie physische Sicherheit
A.7.5Schutz vor Feuer und Wasserdie physische Sicherheit
A.7.6Regeln für sichere Bereichedie physische Sicherheit
A.7.7Aufgeräumte Schreibtischedie physische Sicherheit
A.7.8Aufstellung von Gerätendie physische Sicherheit
A.7.9Schutz von Assets außer Hausdie physische Sicherheit
A.7.10Umgang mit Datenträgerndie physische Sicherheit
A.7.11Notstrom bei Stromausfalldie physische Sicherheit
A.7.12Schutz der Verkabelungdie physische Sicherheit
A.7.13Wartung von Gerätendie physische Sicherheit
A.7.14Sicheres Löschen von Gerätendie physische Sicherheit

A.8 Technologische Themen

A.8.1Schutz von Endgeräteneinen betrieblichen Prozess
A.8.6Kapazitätsplanungeinen betrieblichen Prozess
A.8.7Schutz vor Schadsoftwareeinen betrieblichen Prozess
A.8.14Reservekapazitäteinen betrieblichen Prozess
A.8.16Überwachung ungewöhnlichen Verhaltenseinen betrieblichen Prozess
A.8.17Uhrenabgleicheinen betrieblichen Prozess
A.8.18Grenzen für Hilfsprogrammeeinen betrieblichen Prozess
A.8.19Freigabe von Live-Softwareeinen betrieblichen Prozess
A.8.21Regeln für Netzwerkdiensteeinen betrieblichen Prozess
A.8.23Filterung von Web-Verkehreinen betrieblichen Prozess
A.8.30Aufsicht über externe EntwicklerVerträge und Lieferanten
A.8.34Schutz bei Auditseine externe Prüfung

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.