Zum Inhalt springen
toevan
AnmeldenAudit-Pilot buchen
Menü öffnenMenü schließen
Audit-Pilot buchen

Control-Map · 2022, Annex A

ISO/IEC 27001

Code-Nachweis für Annex-A-Controls vom Umgang mit Secrets bis zur Kryptografie sowie Nachweise zu Änderungen, Code-Zugriff und Einstellungen aus jedem Merge.

Audit-Pilot buchenBeispielbericht ansehen
ISO/IEC 27001 · 2022, Annex A26 Controls im Umfang · Stand v1.4.1
  • Code 9
  • Prozess 6
  • Geplant 11

Code-Nachweis

9Controls, bei jedem Pull Request geprüft

Live (Prozess)

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

Geplant

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

Controls auf Organisationsebene

Richtlinien, Personal, Lieferanten, physische Sicherheit und Ähnliches, unten aufgelistet.Für 2 davon liefert Toevan unterstützende Nachweise.Von den Abläufen Ihrer Organisation verantwortet

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.

Der ISO/IEC-27001-Blueprint liefert Code-Nachweise für Annex-A-Controls vom Umgang mit Secrets bis zur Kryptografie. Der Prozessnachweis aus jedem Merge ergänzt Ä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 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 ISO/IEC 27001 prüfen bei jedem Pull Request einen Teil davon.

  • A.5.15ZugriffsregelnA.5 Organisatorische Themen
  • A.5.17Umgang mit SecretsA.5 Organisatorische Themen
  • A.8.2Grenzen für mächtige KontenA.8 Technologische Themen
  • A.8.3Grenzen beim DatenlesenA.8 Technologische Themen
  • A.8.8Beheben von SoftwarefehlernA.8 Technologische Themen
  • A.8.12Wege für DatenlecksA.8 Technologische Themen
  • A.8.20NetzwerkschutzA.8 Technologische Themen
  • A.8.22NetzwerkzonenA.8 Technologische Themen
  • A.8.24Verschlüsselung und SchlüsselA.8 Technologische Themen

Live (Prozess)6

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

  • A.8.4Grenzen beim Code-ZugriffA.8 Technologische ThemenProzessnachweis: Branch-Schutz, Rulesets und jede Umgehung eines geschützten Branches, als Control-Änderungen versiegelt.
  • A.8.9Freigegebene EinstellungenA.8 Technologische ThemenProzessnachweis: Änderungen an Repository-Rulesets und Branch-Schutz, mit Zustand davor und danach versiegelt.
  • A.8.25Sichere Build-StufenA.8 Technologische ThemenProzessnachweis: Die Reviews und Pflicht-Checks beim Merge zeigen, dass der Entwicklungsprozess bei jeder Änderung lief.
  • A.8.29Sicherheitstests vor ReleaseA.8 Technologische ThemenProzessnachweis: die beim Merge bestandenen Pflicht-Sicherheitschecks, pro Änderung.
  • A.8.31Trennung von Test und LiveA.8 Technologische ThemenProzessnachweis: Ein Produktions-Deployment eines Commits, der zuvor erfolgreich in eine andere Umgebung ausgerollt wurde. Es zeigt nicht, was dort getestet wurde, und nicht die Trennung von Zugriff und Daten zwischen den Umgebungen.
  • A.8.32ÄnderungsfreigabenA.8 Technologische ThemenProzessnachweis: 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

Unterstützend2

Toevan erfasst verwandte Nachweise, doch die Pflicht liegt bei der Organisation und gilt deshalb nie als abgedeckt.

  • A.5.3AufgabentrennungA.5 Organisatorische ThemenAufgabentrennung pro Änderung: der Autor gegenüber den Freigebenden, aus GitHub-Konto-IDs berechnet. Die weitergehende Pflicht bleibt organisatorisch.
  • A.5.32Nachweise zu SoftwarerechtenA.5 Organisatorische ThemenUnterstützender Nachweis: Eine Regel erfasst Nachweise zu dieser Pflicht. Die Pflicht selbst betrifft ein regulatorisches Verfahren.

Geplant11

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

  • A.5.16Lebenszyklus von IdentitätenA.5 Organisatorische Themen
  • A.5.18Prüfung von BerechtigungenA.5 Organisatorische Themen
  • A.8.5Stärke der AnmeldungA.8 Technologische Themen
  • A.8.10Löschen von DatenA.8 Technologische Themen
  • A.8.11Maskieren sensibler DatenA.8 Technologische Themen
  • A.8.13Backup-KopienA.8 Technologische Themen
  • A.8.15AktivitätsaufzeichnungA.8 Technologische Themen
  • A.8.26Sicherheitsanforderungen an AppsA.8 Technologische Themen
  • A.8.27Gewohnheiten für sicheres DesignA.8 Technologische Themen
  • A.8.28Gewohnheiten für sicheres CodingA.8 Technologische Themen
  • A.8.33Sorgfalt bei TestdatenA.8 Technologische Themen

Controls auf Organisationsebene

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

Liste 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 verwenden

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

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

  3. 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.
A.8.4Ä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 buchenBeispielbericht ansehen
  • Ein Repository, ein Framework
  • Nachweise ab dem ersten Pull Request
  • Prüfbar ohne Toevan-Konto