Control-Map · Rev 5, NIST SP 800-53B

NIST 800-53 Moderate

Code-Nachweis für Controls von der Zugriffsdurchsetzung bis zum Schutz ruhender Daten sowie Konfigurationsänderungskontrolle aus jedem Merge.

Audit-Pilot buchen Beispielbericht ansehen

NIST SP 800-53 Rev 5 · Moderate-Baseline (SP 800-53B)37 Controls im Umfang · Stand v1.4.1

Code 12
Prozess 2
Geplant 23

Code-Nachweis

12Controls, bei jedem Pull Request geprüft

Live (Prozess)

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

Geplant

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

Controls auf Organisationsebene

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

NIST SP 800-53 Moderate ist die Baseline, auf der FedRAMP aufbaut; Toevan bildet die Baseline ohne die Ergänzungen von FedRAMP ab. Die Kontrolle von Konfigurationsänderungen verlangt, dass Änderungen geprüft, freigegeben und dokumentiert werden und nur berechtigte Personen sie vornehmen dürfen.

Der Blueprint NIST 800-53 Moderate liefert Code-Nachweise für Controls von der Zugriffsdurchsetzung bis zum Schutz ruhender Daten. Änderungseinträge liefern Nachweise für CM-3 Configuration Change Control und SA-10 Developer Configuration Management, mit unterstützenden Nachweisen für Aufgabentrennung, Zugriffsbeschränkungen bei Änderungen und Integrität.

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.

Code-Nachweis12

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

AC-2KontoverwaltungAC Zugriffskontrolle
AC-3Durchsetzung des ZugriffsAC Zugriffskontrolle
AC-4Durchsetzung des InformationsflussesAC Zugriffskontrolle
AC-6Minimale RechteAC Zugriffskontrolle
CM-2BasiskonfigurationCM Konfigurationsmanagement
CM-6KonfigurationseinstellungenCM Konfigurationsmanagement
IA-5Verwaltung von AuthentifikatorenIA Identifizierung und Authentifizierung
SA-11Tests und Bewertung durch EntwicklerSA Beschaffung von Systemen und Diensten
SC-7GrenzschutzSC System- und Kommunikationsschutz
SC-8Vertraulichkeit und Integrität der ÜbertragungSC System- und Kommunikationsschutz
SC-28Schutz ruhender InformationenSC System- und Kommunikationsschutz
SI-2Behebung von FehlernSI System- und Informationsintegrität

Live (Prozess)2

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

CM-3Kontrolle von KonfigurationsänderungenCM KonfigurationsmanagementProzessnachweis: 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.
SA-10Konfigurationsmanagement der EntwicklerSA Beschaffung von Systemen und DienstenProzessnachweis: Änderungseinträge und Control-Änderungen für das Quell-Repository.

Ä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ützend4

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

AC-5AufgabentrennungAC ZugriffskontrolleAufgabentrennung pro Änderung: der Autor gegenüber den Freigebenden, aus GitHub-Konto-IDs berechnet. Die weitergehende Pflicht bleibt organisatorisch.
CM-5Zugriffsbeschränkungen für ÄnderungenCM KonfigurationsmanagementWer geschützte Branches ändern darf, und jede Umgehung, als Control-Änderungen versiegelt. Die Zugriffsverwaltung selbst bleibt organisatorisch.
SI-7Integrität von Software, Firmware und InformationenSI System- und InformationsintegritätFakten zur Commit-Signatur an jeder gemergten Änderung.
SR-11Echtheit von KomponentenSR Risikomanagement der LieferketteUnterstützender Nachweis: Eine GitHub-Attestierung, die den Commit benennt. Toevan prüft die Signatur der Attestierung nicht. Die Echtheit von Komponenten Dritter wird nicht gezeigt.

Geplant23

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

AC-7Fehlgeschlagene AnmeldeversucheAC Zugriffskontrolle
AC-11GerätesperreAC Zugriffskontrolle
AC-12Beenden von SitzungenAC Zugriffskontrolle
AC-17FernzugriffAC Zugriffskontrolle
AU-2EreignisprotokollierungAU Audit und Rechenschaft
AU-3Inhalt von Audit-EinträgenAU Audit und Rechenschaft
AU-8ZeitstempelAU Audit und Rechenschaft
AU-9Schutz von Audit-InformationenAU Audit und Rechenschaft
AU-11Aufbewahrung von Audit-EinträgenAU Audit und Rechenschaft
AU-12Erzeugung von Audit-EinträgenAU Audit und Rechenschaft
CM-7Minimale FunktionalitätCM Konfigurationsmanagement
CP-9SystemsicherungCP Notfallplanung
IA-2Identifizierung und Authentifizierung (Organisationsnutzer)IA Identifizierung und Authentifizierung
IA-4Verwaltung von KennungenIA Identifizierung und Authentifizierung
IA-6Rückmeldung bei der AuthentifizierungIA Identifizierung und Authentifizierung
IA-8Identifizierung und Authentifizierung (Externe Nutzer)IA Identifizierung und Authentifizierung
RA-5Schwachstellenüberwachung und -scansRA Risikobewertung
SC-12Aufbau und Verwaltung kryptografischer SchlüsselSC System- und Kommunikationsschutz
SC-13Kryptografischer SchutzSC System- und Kommunikationsschutz
SC-23SitzungsauthentizitätSC System- und Kommunikationsschutz
SI-10Validierung von EingabenSI System- und Informationsintegrität
SI-11FehlerbehandlungSI System- und Informationsintegrität
SI-12Informationsverwaltung und AufbewahrungSI System- und Informationsintegrität

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

AC Zugriffskontrolle

AC-1Richtlinien und Verfahrendie Richtlinien der Organisation

AC-8Hinweis zur Systemnutzungeinen betrieblichen Prozess

AC-14Zulässige Aktionen ohne Identifizierung oder Authentifizierungeinen betrieblichen Prozess

AC-18WLAN-Zugriffeinen betrieblichen Prozess

AC-19Zugriffskontrolle für mobile Geräteeinen betrieblichen Prozess

AC-20Nutzung externer Systemeeinen betrieblichen Prozess

AC-21Informationsaustauscheinen betrieblichen Prozess

AC-22Öffentlich zugängliche Inhalteeinen betrieblichen Prozess

AT Bewusstsein und Schulung

AT-1Richtlinien und Verfahrendie Richtlinien der Organisation

AT-2Grundschulung und BewusstseinPersonal und HR

AT-3Rollenbasierte SchulungPersonal und HR

AT-4SchulungsnachweisePersonal und HR

AU Audit und Rechenschaft

AU-1Richtlinien und Verfahrendie Richtlinien der Organisation

AU-4Speicherkapazität für Audit-Logseinen betrieblichen Prozess

AU-5Reaktion auf Ausfälle der Audit-Protokollierungeinen betrieblichen Prozess

AU-6Prüfung, Analyse und Berichte zu Audit-Einträgeneinen betrieblichen Prozess

AU-7Reduktion von Audit-Einträgen und Berichtserstellungeinen betrieblichen Prozess

CA Bewertung, Autorisierung und Überwachung

CA-1Richtlinien und Verfahrendie Richtlinien der Organisation

CA-2Control-Bewertungeneine externe Prüfung

CA-3Informationsaustauscheine externe Prüfung

CA-5Maßnahmenplan mit Meilensteineneine externe Prüfung

CA-6Autorisierungeine externe Prüfung

CA-7Laufende Überwachungeine externe Prüfung

CA-9Interne Systemverbindungeneine externe Prüfung

CM Konfigurationsmanagement

CM-1Richtlinien und Verfahrendie Richtlinien der Organisation

CM-4Auswirkungsanalyseneinen betrieblichen Prozess

CM-8Inventar der Systemkomponenteneinen betrieblichen Prozess

CM-9Konfigurationsmanagementplaneinen betrieblichen Prozess

CM-10Beschränkungen der Softwarenutzungeinen betrieblichen Prozess

CM-11Von Nutzern installierte Softwareeinen betrieblichen Prozess

CM-12Speicherort von Informationeneinen betrieblichen Prozess

CP Notfallplanung

CP-1Richtlinien und Verfahrendie Richtlinien der Organisation

CP-2Notfallplaneinen betrieblichen Prozess

CP-3Notfallschulungeinen betrieblichen Prozess

CP-4Test des Notfallplanseinen betrieblichen Prozess

CP-6Alternativer Speicherstandorteinen betrieblichen Prozess

CP-7Alternativer Verarbeitungsstandorteinen betrieblichen Prozess

CP-8Telekommunikationsdiensteeinen betrieblichen Prozess

CP-10Systemwiederherstellung und Rekonstitutioneinen betrieblichen Prozess

IA Identifizierung und Authentifizierung

IA-1Richtlinien und Verfahrendie Richtlinien der Organisation

IA-3Identifizierung und Authentifizierung von Geräteneinen betrieblichen Prozess

IA-7Authentifizierung kryptografischer Moduleeinen betrieblichen Prozess

IA-11Erneute Authentifizierungeinen betrieblichen Prozess

IA-12Identitätsnachweiseinen betrieblichen Prozess

IR Incident Response

IR-1Richtlinien und Verfahrendie Richtlinien der Organisation

IR-2Schulung zur Incident Responseeinen betrieblichen Prozess

IR-3Test der Incident Responseeinen betrieblichen Prozess

IR-4Behandlung von Incidentseinen betrieblichen Prozess

IR-5Überwachung von Incidentseinen betrieblichen Prozess

IR-6Meldung von Incidentseinen betrieblichen Prozess

IR-7Unterstützung bei Incident Responseeinen betrieblichen Prozess

IR-8Incident-Response-Planeinen betrieblichen Prozess

MA Wartung

MA-1Richtlinien und Verfahrendie Richtlinien der Organisation

MA-2Kontrollierte Wartungdie physische Sicherheit

MA-3Wartungswerkzeugedie physische Sicherheit

MA-4Fernwartungdie physische Sicherheit

MA-5Wartungspersonaldie physische Sicherheit

MA-6Zeitnahe Wartungdie physische Sicherheit

MP Schutz von Datenträgern

MP-1Richtlinien und Verfahrendie Richtlinien der Organisation

MP-2Zugriff auf Datenträgerdie physische Sicherheit

MP-3Kennzeichnung von Datenträgerndie physische Sicherheit

MP-4Lagerung von Datenträgerndie physische Sicherheit

MP-5Transport von Datenträgerndie physische Sicherheit

MP-6Bereinigung von Datenträgerndie physische Sicherheit

MP-7Nutzung von Datenträgerndie physische Sicherheit

PE Physischer Schutz und Umgebungsschutz

PE-1Richtlinien und Verfahrendie Richtlinien der Organisation

PE-2Genehmigung des physischen Zutrittsdie physische Sicherheit

PE-3Kontrolle des physischen Zutrittsdie physische Sicherheit

PE-4Zugriffskontrolle für Übertragungswegedie physische Sicherheit

PE-5Zugriffskontrolle für Ausgabegerätedie physische Sicherheit

PE-6Überwachung des physischen Zutrittsdie physische Sicherheit

PE-8Besucherprotokolledie physische Sicherheit

PE-9Stromgeräte und Verkabelungdie physische Sicherheit

PE-10Notabschaltungdie physische Sicherheit

PE-11Notstromdie physische Sicherheit

PE-12Notbeleuchtungdie physische Sicherheit

PE-13Brandschutzdie physische Sicherheit

PE-14Umgebungskontrollendie physische Sicherheit

PE-15Schutz vor Wasserschädendie physische Sicherheit

PE-16Lieferung und Abtransportdie physische Sicherheit

PE-17Alternativer Arbeitsplatzdie physische Sicherheit

PL Planung

PL-1Richtlinien und Verfahrendie Richtlinien der Organisation

PL-2Sicherheits- und Datenschutzpläne des Systemsdie Richtlinien der Organisation

PL-4Verhaltensregelndie Richtlinien der Organisation

PL-8Sicherheits- und Datenschutzarchitekturendie Richtlinien der Organisation

PL-10Auswahl der Basisdie Richtlinien der Organisation

PL-11Anpassung der Basisdie Richtlinien der Organisation

PS Personalsicherheit

PS-1Richtlinien und Verfahrendie Richtlinien der Organisation

PS-2Risikoeinstufung von PositionenPersonal und HR

PS-3Überprüfung von PersonalPersonal und HR

PS-4Beendigung von BeschäftigungPersonal und HR

PS-5Versetzung von PersonalPersonal und HR

PS-6ZugriffsvereinbarungenPersonal und HR

PS-7Sicherheit bei externem PersonalPersonal und HR

PS-8Sanktionen für PersonalPersonal und HR

PS-9StellenbeschreibungenPersonal und HR

RA Risikobewertung

RA-1Richtlinien und Verfahrendie Richtlinien der Organisation

RA-2Sicherheitseinstufungdie Richtlinien der Organisation

RA-3Risikobewertungdie Richtlinien der Organisation

RA-7Risikoreaktiondie Richtlinien der Organisation

RA-9Kritikalitätsanalysedie Richtlinien der Organisation

SA Beschaffung von Systemen und Diensten

SA-1Richtlinien und Verfahrendie Richtlinien der Organisation

SA-2Zuteilung von Ressourcendie Richtlinien der Organisation

SA-3Lebenszyklus der Systementwicklungdie Richtlinien der Organisation

SA-4BeschaffungsprozessVerträge und Lieferanten

SA-5Systemdokumentationdie Richtlinien der Organisation

SA-8Prinzipien für Sicherheits- und Datenschutz-Engineeringdie Richtlinien der Organisation

SA-9Externe SystemdiensteVerträge und Lieferanten

SA-15Entwicklungsprozess, Standards und Werkzeugedie Richtlinien der Organisation

SA-22Nicht unterstützte Systemkomponentendie Richtlinien der Organisation

SC System- und Kommunikationsschutz

SC-1Richtlinien und Verfahrendie Richtlinien der Organisation

SC-2Trennung von System- und Nutzerfunktioneneinen betrieblichen Prozess

SC-4Informationen in geteilten Systemressourceneinen betrieblichen Prozess

SC-5Schutz vor Denial-of-Serviceeinen betrieblichen Prozess

SC-10Netzwerktrennungeinen betrieblichen Prozess

SC-15Geräte und Anwendungen für Zusammenarbeiteinen betrieblichen Prozess

SC-17Zertifikate der Public-Key-Infrastruktureinen betrieblichen Prozess

SC-18Mobiler Codeeinen betrieblichen Prozess

SC-20Sicherer Namensauflösungsdienst (autoritative Quelle)einen betrieblichen Prozess

SC-21Sicherer Namensauflösungsdienst (rekursiv oder Cache)einen betrieblichen Prozess

SC-22Architektur und Bereitstellung der Namensauflösungeinen betrieblichen Prozess

SC-39Prozessisolierungeinen betrieblichen Prozess

SI System- und Informationsintegrität

SI-1Richtlinien und Verfahrendie Richtlinien der Organisation

SI-3Schutz vor Schadcodeeinen betrieblichen Prozess

SI-4Systemüberwachungeinen betrieblichen Prozess

SI-5Sicherheitswarnungen, Hinweise und Weisungeneinen betrieblichen Prozess

SI-8Spam-Schutzeinen betrieblichen Prozess

SI-16Speicherschutzeinen betrieblichen Prozess

SR Risikomanagement der Lieferkette

SR-1Richtlinien und Verfahrendie Richtlinien der Organisation

SR-2Risikomanagementplan für die LieferketteVerträge und Lieferanten

SR-3Controls und Prozesse der LieferketteVerträge und Lieferanten

SR-5Beschaffungsstrategien, Werkzeuge und MethodenVerträge und Lieferanten

SR-6Bewertungen und Prüfungen von LieferantenVerträge und Lieferanten

SR-8BenachrichtigungsvereinbarungenVerträge und Lieferanten

SR-10Prüfung von Systemen oder KomponentenVerträge und Lieferanten

SR-12Entsorgung von KomponentenVerträge und Lieferanten

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.

CM-3Ä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