Microsoft 365-Zertifizierung – Leitfaden für Beispielnachweise

Übersicht

Dieser Leitfaden wurde erstellt, um ISVs Beispiele für die Art der Nachweise und den Grad der detaillierten Anforderungen für die einzelnen Microsoft 365-Zertifizierungssteuerelemente bereitzustellen. Alle in diesem Dokument freigegebenen Beispiele stellen nicht den einzigen Beweis dar, der verwendet werden kann, um zu zeigen, dass Die Kontrollen erfüllt werden, sondern dienen nur als Richtlinie für die Art der erforderlichen Beweise.

Hinweis: Die tatsächlichen Schnittstellen, Screenshots und Dokumentationen, die zur Erfüllung der Anforderungen verwendet werden, variieren je nach Produktverwendung, Systemeinrichtung und internen Prozessen. Beachten Sie außerdem, dass der ISV, wenn Richtlinien- oder Verfahrensdokumentation erforderlich ist, die TATSÄCHLICHen Dokumente und keine Screenshots senden muss, wie in einigen beispielen gezeigt.

Es gibt zwei Abschnitte in der Zertifizierung, für die Übermittlungen erforderlich sind:

1. Die anfängliche Dokumentübermittlung: eine kleine Gruppe allgemeiner Dokumente, die für die Eingrenzung Ihrer Bewertung erforderlich sind.
2. Die Beweisübermittlung: der vollständige Satz von Nachweisen, die für jede Kontrolle im Gültigkeitsbereich Für Ihre Zertifizierungsbewertung erforderlich sind.

Tipp

Probieren Sie das App Compliance Automation Tool für Microsoft 365 (ACAT) aus, um einen beschleunigten Weg zu erreichen, um die Microsoft 365-Zertifizierung zu erreichen, indem Sie die Beweissammlung und Kontrollüberprüfung automatisieren. Erfahren Sie mehr darüber, welche Steuerung von ACAT vollständig automatisiert wird.

Structure

Dieses Dokument ist direkt den Steuerelementen zugeordnet, die Sie während Ihrer Zertifizierung im Partner Center präsentiert werden. Die in diesem Dokument bereitgestellten Anleitungen sind wie folgt beschrieben:

• Sicherheitsdomäne: Die drei Sicherheitsdomänen, in die alle Kontrollen gruppiert sind: Anwendungssicherheit, Betriebssicherheit und Datensicherheit und Datenschutz.
• Steuerung(en): = Beschreibung der Bewertungsaktivität: Diese Steuerelemente und die zugehörige Nummer (Nein)) werden direkt aus der Microsoft 365-Zertifizierungsprüfliste entnommen.
• Absicht: = Die Absicht, warum die Sicherheitskontrolle in das Programm aufgenommen wird, und das spezifische Risiko, das es mindern soll. Die Hoffnung ist, dass diese Informationen ISVs die Gründe für die Kontrolle liefern, um besser zu verstehen, welche Arten von Beweismitteln gesammelt werden müssen und was ISVs bei der Erstellung ihrer Beweise beachten und wissen müssen.
• Beispielbeweisrichtlinien: = Dies dient als Leitfaden für die Aufgaben zur Beweissammlung in der Microsoft 365-Zertifizierungsprüfliste und ermöglicht es den ISVs, eindeutig Beispiele für die Art von Beweisen zu sehen, die vom Zertifizierungsanalysten verwendet werden können, der ihn verwendet, um eine sichere Feststellung zu treffen, dass ein Steuerelement vorhanden und verwaltet wird – es ist keineswegs vollständiger Natur.
• Beweisbeispiel: = Dieser Abschnitt enthält Beispielscreenshots und Bilder potenzieller Beweise, die für die einzelnen Steuerelemente in der Microsoft 365-Zertifizierungsprüfliste erfasst wurden, insbesondere für die Domänen betriebs- und Datensicherheit und Datenschutzsicherheit (Registerkarten innerhalb der Kalkulationstabelle). Beachten Sie alle Informationen mit roten Pfeilen und Feldern in den Beispielen, um Ihr Verständnis der Anforderungen zu unterstützen, die zum Erfüllen von Steuerelementen erforderlich sind.

Sicherheitsdomäne: Anwendungssicherheit

Steuerelement 1 – Steuerelement 16:

Die Domänensteuerelemente der Anwendungssicherheit können mit einem Penetrationstestbericht zufrieden sein, der innerhalb der letzten 12 Monate ausgegeben wurde und zeigt, dass Ihre App keine ausstehenden Sicherheitsrisiken aufweist. Die einzige erforderliche Übermittlung ist ein sauberer Bericht von einem seriösen unabhängigen Unternehmen.

Sicherheitsdomäne: Betriebssicherheit/Sichere Entwicklung

Die Sicherheitsdomäne "Betriebssicherheit / Sichere Entwicklung" soll sicherstellen, dass ISVs eine reihe von Sicherheitsminderungstechniken gegen eine Vielzahl von Bedrohungen implementieren, denen von Aktivitätsgruppen ausgesetzt ist. Dies ist darauf ausgelegt, die Betriebsumgebung und Softwareentwicklungsprozesse zu schützen, um sichere Umgebungen zu erstellen.

Schutz vor Schadsoftware – Anti-Virus

Steuerung Nr. 1: Stellen Sie Richtliniendokumentation bereit, die Antivirenpraktiken und -verfahren regelt.

• Absicht: Die Absicht dieses Steuerelements besteht darin, das Verständnis eines ISV für die Probleme zu bewerten, mit denen er konfrontiert ist, wenn er die Bedrohung durch Computerviren berücksichtigt. Durch die Einrichtung und Verwendung bewährter Methoden der Branche bei der Entwicklung einer Antivirenrichtlinie und -prozesse stellt ein ISV eine Ressource bereit, die auf die Fähigkeit seiner Organisation zugeschnitten ist, die Risiken durch Schadsoftware zu mindern, und listet bewährte Methoden bei der Virenerkennung und -eliminierung auf und liefert Beweise dafür, dass die dokumentierte Richtlinie vorgeschlagene Sicherheitsleitfäden für die Organisation und ihre Mitarbeiter bereitstellt. Durch die Dokumentation einer Richtlinie und eines Verfahrens, wie der ISV Anti-Malware-Anforderungen bereitstellt, wird dadurch sichergestellt, dass diese Technologie konsistent bereitgestellt und gewartet wird, um das Risiko von Schadsoftware für die Umgebung zu verringern.
• Beispielrichtlinien für Nachweise: Stellen Sie eine Kopie Ihrer Antiviren-/Antischadsoftwarerichtlinie bereit, in der die Prozesse und Verfahren aufgeführt sind, die in Ihrer Infrastruktur implementiert werden, um bewährte Methoden für Antivirus/Schadsoftware zu fördern. Beispielbeweis
• Beispielbeweis:

Anmerkung: Dieser Screenshot zeigt ein Richtlinien-/Prozessdokument. Es wird erwartet, dass ISVs die tatsächliche unterstützende Richtlinien-/Verfahrensdokumentation freigeben und nicht einfach einen Screenshot bereitstellen.

Kontrolle Nr. 2: Stellen Sie nachweisbare Beweise dafür bereit, dass Antivirensoftware in allen abgetasteten Systemkomponenten ausgeführt wird.

• Absicht: Es ist wichtig, dass in Ihrer Umgebung Virenschutz (AV) (oder Antischadsoftwareschutz) ausgeführt wird, um sich vor Cyber-Sicherheitsrisiken zu schützen, die Ihnen möglicherweise bewusst sind oder nicht, da potenziell schädliche Angriffe sowohl hinsichtlich der Komplexität als auch der Anzahl zunimmt. Die Bereitstellung von AV für alle Systemkomponenten, die die Verwendung unterstützen, trägt dazu bei, einige der Risiken zu minimieren, die durch die Einführung von Antischadsoftware in die Umgebung entstehen. Es muss nur ein einzelner Endpunkt ungeschützt sein, um potenziell einen Angriffsvektor für eine Aktivitätsgruppe bereitzustellen, um in der Umgebung Fuß zu fassen. AV sollte daher als eine von mehreren Schutzebenen zum Schutz vor dieser Art von Bedrohung verwendet werden.
• Beispielbeweisrichtlinien: Zum Nachweis, dass eine aktive Instanz von AV in der bewerteten Umgebung ausgeführt wird. Stellen Sie einen Screenshot für jedes Gerät im Beispiel bereit, das die Verwendung von Virenschutz unterstützt. Dies zeigt den ausgeführten Virenschutzprozess, die Antivirensoftware ist aktiv, oder wenn Sie über eine zentrale Verwaltungskonsole für Virenschutz verfügen, können Sie dies möglicherweise über diese Verwaltungskonsole demonstrieren. Wenn Sie die Verwaltungskonsole verwenden, stellen Sie sicher, dass in einem Screenshot nachgewiesen wird, dass die erfassten Geräte verbunden sind und funktionieren.
• Beweisbeispiel 1: Der folgende Screenshot wurde aus Azure Security Center erstellt; Es zeigt, dass eine Antischadsoftwareerweiterung auf dem virtuellen Computer mit dem Namen "MSPGPRODAZUR01" bereitgestellt wurde.

• Beweisbeispiel 2

Der folgende Screenshot wurde von einem Windows 10-Gerät erstellt und zeigt, dass "Echtzeitschutz" für den Hostnamen "CLARANET-SBU-WM" aktiviert ist.

Kontrolle Nr. 3: Liefern Sie nachweisbare Beweise dafür, dass Antivirensignaturen in allen Umgebungen auf dem neuesten Stand sind (innerhalb von 1 Tag).

• Absicht: Jeden Tag werden Hunderttausende neuer Schadsoftware und potenziell unerwünschte Anwendungen (PUA) identifiziert. Um einen angemessenen Schutz vor neu veröffentlichter Schadsoftware zu bieten, müssen AV-Signaturen regelmäßig aktualisiert werden, um neu veröffentlichte Schadsoftware zu berücksichtigen.
• Diese Kontrolle besteht, um sicherzustellen, dass der ISV die Sicherheit der Umgebung und die Auswirkungen berücksichtigt hat, die veraltete AV-Instanzen auf die Sicherheit haben können.
• Beispielrichtlinien für Nachweise: Stellen Sie Antivirenprotokolldateien von jedem erfassten Gerät bereit, um zu zeigen, dass Updates täglich angewendet werden.
• Beispielbeweis: Der folgende Screenshot zeigt, dass Microsoft Defender mindestens täglich aktualisiert wird, indem das Update "Ereignis 2000, Windows Defender" angezeigt wird. Der Hostname wird angezeigt, der zeigt, dass dieser aus dem bereichsinternen System "CLARANET-SBU-WM" stammt.

Anmerkung: Die bereitgestellten Beweise müssten einen Export der Protokolle enthalten, um tägliche Updates über einen längeren Zeitraum anzuzeigen. Einige Antivirenprodukte generieren Updateprotokolldateien, sodass diese Dateien bereitgestellt oder die Protokolle aus der Ereignisanzeige exportiert werden sollten.

Steuerung Nr. 4: Stellen Sie nachweisbare Beweise dafür bereit, dass Virenschutz für die Durchführung von Zugriffsüberprüfungen oder regelmäßigen Überprüfungen für alle erfassten Systemkomponenten konfiguriert ist.

Anmerkung: Wenn die Überprüfung bei Zugriff nicht aktiviert ist, müssen mindestens tägliche Überprüfungen und alerting_ aktiviert _be.

• Absicht: Mit diesem Steuerelement soll sichergestellt werden, dass Schadsoftware schnell identifiziert wird, um die Auswirkungen auf die Umgebung zu minimieren. Wenn Bei-Zugriff-Überprüfungen durchgeführt und mit automatischer Blockierung von Schadsoftware gekoppelt werden, wird dies dazu beitragen, Malware-Infektionen zu stoppen, die der Antivirensoftware bekannt sind. Wenn scans bei Zugriff aufgrund des Risikos falsch positiver Ergebnisse, die Dienstausfälle verursachen, nicht wünschenswert ist, müssen geeignete tägliche Überprüfungs- und Warnungsmechanismen implementiert werden, um eine rechtzeitige Reaktion auf Malware-Infektionen zu gewährleisten, um Schäden zu minimieren.
• Beispielrichtlinien für Nachweise: Stellen Sie einen Screenshot für jedes Gerät im Beispiel bereit, das Virenschutz unterstützt, der zeigt, dass auf dem Gerät Virenschutz ausgeführt wird und für die Überprüfung bei Zugriff (Echtzeitüberprüfung) konfiguriert ist, ODER stellen Sie einen Screenshot bereit, der zeigt, dass die regelmäßige Überprüfung für die tägliche Überprüfung aktiviert ist, warnungen konfiguriert sind und das Datum der letzten Überprüfung für jedes Gerät im Beispiel.
• Beispielbeweis: Der folgende Screenshot zeigt, dass der Echtzeitschutz für den Host aktiviert ist, "CLARANET-SBU-WM".

Steuerung Nr. 5: Stellen Sie nachweisbare Beweise dafür bereit, dass Virenschutz so konfiguriert ist, dass schadsoftware automatisch blockiert oder isoliert und warnungen für alle erfassten Systemkomponenten bereitgestellt werden.

• Absicht: Die Raffinesse von Schadsoftware entwickelt sich ständig weiter, zusammen mit den unterschiedlichen Verwüstungsgraden, die sie mit sich bringen können. Die Absicht dieses Steuerelements besteht darin, entweder die Ausführung von Schadsoftware zu verhindern und sie daher daran zu hindern, ihre potenziell verheerende Nutzlast auszuführen, oder wenn automatisches Blockieren keine Option ist, die Zeitspanne zu begrenzen, die Schadsoftware kann verwüssten, indem sie warnungen und sofort auf die potenzielle Malware-Infektion reagiert.

• Beispielrichtlinien für Nachweise: Stellen Sie einen Screenshot für jedes Gerät im Beispiel bereit, das Virenschutz unterstützt, der zeigt, dass auf dem Computer Virenschutz ausgeführt wird und so konfiguriert ist, dass Schadsoftware automatisch blockiert, warnungen oder unter Quarantäne gestellt und warnungen werden.

• Beispielbeweis 1: Der folgende Screenshot zeigt, dass der Host "CLARANET-SBU-WM" mit Echtzeitschutz für Microsoft Defender Antivirus konfiguriert ist. Wie die Einstellung sagt, wird dadurch verhindert, dass Schadsoftware auf dem Gerät installiert oder ausgeführt wird.

Steuerung Nr. 6: Stellen Sie nachweisbare Beweise dafür bereit, dass Anwendungen vor der Bereitstellung genehmigt wurden.

• Absicht: Mit der Anwendungssteuerung genehmigt die Organisation jede Anwendung/jeden Prozess, der auf dem Betriebssystem ausgeführt werden darf. Mit diesem Steuerelement soll sichergestellt werden, dass ein Genehmigungsprozess vorhanden ist, um zu autorisieren, welche Anwendungen/Prozesse ausgeführt werden können.

• Beispielrichtlinien für Nachweise: Es können Beweise dafür bereitgestellt werden, dass der Genehmigungsprozess befolgt wird. Dies kann mit signierten Dokumenten, der Nachverfolgung innerhalb von Änderungskontrollsystemen oder mithilfe von Azure DevOps oder JIRA bereitgestellt werden, um diese Anforderungen und Autorisierung nachzuverfolgen.

• Beispielbeweis: Der folgende Screenshot zeigt eine Genehmigung durch die Verwaltung, dass jede Anwendung, die in der Umgebung ausgeführt werden darf, einem Genehmigungsprozess folgt. Dies ist ein papierbasierter Prozess bei Contoso, jedoch können andere Mechanismen verwendet werden.

Steuerung Nr. 7: Stellen Sie nachweisbare Beweise bereit, dass eine vollständige Liste genehmigter Anwendungen mit geschäftlicher Begründung vorhanden ist und verwaltet wird.

• Absicht: Es ist wichtig, dass Organisationen eine Liste aller anwendungen verwalten, die genehmigt wurden, zusammen mit Informationen dazu, warum die Anwendung/der Prozess genehmigt wurde. Dadurch wird sichergestellt, dass die Konfiguration aktuell bleibt und anhand einer Baseline überprüft werden kann, um sicherzustellen, dass nicht autorisierte Anwendungen/Prozesse nicht konfiguriert sind.

• Beispielbeweisrichtlinien: Geben Sie die dokumentierte Liste der genehmigten Anträge/Prozesse zusammen mit der geschäftlichen Begründung an.

• Beispielbeweis: Im folgenden Screenshot sind die genehmigten Anwendungen mit geschäftlicher Begründung aufgeführt.

Anmerkung: Dieser Screenshot zeigt ein Dokument. IsVs erwarten, dass sie das tatsächliche Unterstützende Dokument freigeben und keinen Screenshot bereitstellen.

Steuerung Nr. 8: Stellen Sie unterstützende Dokumentation bereit, in der beschrieben wird, dass die Anwendungskontrollessoftware so konfiguriert ist, dass sie bestimmten Anwendungssteuerungsmechanismen entspricht.

• Absicht: Die Konfiguration der Anwendungssteuerungstechnologie sollte zusammen mit einem Prozess dokumentiert werden, bei dem die Technologie verwaltet wird, d. h. Anwendungen/Prozesse hinzugefügt und gelöscht werden. Im Rahmen dieser Dokumentation sollte die Art des verwendeten Mechanismus für jede Anwendung/jeden Prozess detailliert beschrieben werden. Dies wird in das nächste Steuerelement eingefügt, um sicherzustellen, dass die Technologie wie dokumentiert konfiguriert ist.

• Beispielrichtlinien für Nachweise: Stellen Sie eine unterstützende Dokumentation bereit, in der beschrieben wird, wie die Anwendungssteuerung eingerichtet wurde und wie die einzelnen Anwendungen/Prozesse innerhalb der Technologie konfiguriert wurden.

• Beispielbeweis: Der folgende Screenshot zeigt den Steuerungsmechanismus, der zum Implementieren des Anwendungssteuerelements verwendet wird. Sie können unten sehen, dass eine App Zertifikatsteuerelemente und die anderen App den Dateipfad verwendet.

Anmerkung: Dieser Screenshot zeigt ein Dokument. IsVs erwarten, dass sie das tatsächliche Unterstützende Dokument freigeben und keinen Screenshot bereitstellen.

Steuerelement Nr. 9: Stellen Sie einen nachweisbaren Beweis dafür bereit, dass die Anwendungssteuerung so konfiguriert ist, wie sie von allen erfassten Systemkomponenten dokumentiert ist.

• Absicht: Damit soll überprüft werden, ob die Anwendungssteuerung im gesamten Beispiel gemäß der Dokumentation konfiguriert ist.

• Beispielbeweisrichtlinien: Geben Sie einen Screenshot für jedes Gerät im Beispiel an, um zu zeigen, dass Anwendungssteuerelemente konfiguriert und aktiviert sind. Dies sollte Computernamen, die Gruppen, zu denen sie gehören, und die Anwendungssteuerungsrichtlinien anzeigen, die auf diese Gruppen und Computer angewendet werden.

• Beweisbeispiel: Der folgende Screenshot zeigt ein Gruppenrichtlinienobjekt mit aktivierten Softwareeinschränkungsrichtlinien.

Dieser nächste Screenshot zeigt die Konfiguration im Einklang mit dem obigen Steuerelement.

Dieser nächste Screenshot zeigt die Microsoft 365-Umgebung und die Computer, die innerhalb des Bereichs enthalten sind, der auf dieses Gruppenrichtlinienobjekt "Domänencomputereinstellungen" angewendet wird.

Dieser letzte Screenshot zeigt, dass sich der bereichsinterne Server "DBServer1" innerhalb der Organisationseinheit im obigen Screenshot befindet.

Patchverwaltung – Risikorangfolge

Die schnelle Identifizierung und Behebung von Sicherheitsrisiken trägt dazu bei, das Risiko einer Aktivitätsgruppe zu minimieren, die die Umgebung oder Anwendung gefährdet. Die Patchverwaltung ist in zwei Abschnitte unterteilt: Risikoeinstufung und Patchen. Diese drei Kontrollen decken die Identifizierung von Sicherheitsrisiken ab und ordnen sie nach dem von ihnen ausgehenden Risiko ein.

Diese Sicherheitskontrollgruppe gilt für PaaS-Hostingumgebungen (Platform-as-a-Service), da die Anwendung/Add-In-Softwarebibliotheken und codebasis von Drittanbietern basierend auf der Risikobewertung gepatcht werden müssen.

Steuerung Nr. 10: Bereitstellen einer Richtliniendokumentation, die steuert, wie neue Sicherheitsrisiken identifiziert und einer Risikobewertung zugewiesen werden.

• Absicht: Die Absicht dieses Steuerelements besteht darin, über eine unterstützende Dokumentation zu verfügen, um sicherzustellen, dass Sicherheitsrisiken schnell erkannt werden, um das Zeitfenster zu verringern, in dem Aktivitätsgruppen diese Sicherheitsrisiken ausnutzen müssen. Es muss ein robuster Mechanismus eingerichtet werden, um Sicherheitsrisiken zu identifizieren, die alle systeminternen Komponenten abdecken, die von den Organisationen verwendet werden. Beispielsweise Betriebssysteme (Windows Server, Ubuntu usw.), Anwendungen (Tomcat, MS Exchange, SolarWinds usw.), Codeabhängigkeiten (AngularJS, jQuery usw.). Organisationen müssen nicht nur die rechtzeitige Identifizierung von Sicherheitsrisiken innerhalb des Bestandes sicherstellen, sondern auch alle Sicherheitsrisiken entsprechend bewerten, um sicherzustellen, dass die Behebung innerhalb eines geeigneten Zeitrahmens durchgeführt wird, basierend auf dem Risiko, das die Sicherheitslücke darstellt.

Anmerkung Auch wenn Sie in einer reinen Platform-as-a-Service-Umgebung ausgeführt werden, sind Sie dennoch dafür verantwortlich, Sicherheitsrisiken innerhalb Ihrer Codebasis zu identifizieren, d. h. Bibliotheken von Drittanbietern.

• Beispielrichtlinien für Nachweise: Bereitstellen der Supportdokumentation (keine Screenshots)

• Beispielbeweis: Dieser Screenshot zeigt einen Ausschnitt einer Risikorangfolgerichtlinie.

Anmerkung: Dieser Screenshot zeigt ein Richtlinien-/Prozessdokument. Es wird erwartet, dass ISVs die tatsächliche unterstützende Richtlinien-/Verfahrensdokumentation freigeben und keine screenshot._

Kontrolle Nr. 11: Stellen Sie Einen Beweis dafür bereit, wie neue Sicherheitsrisiken identifiziert werden.

• Absicht: Die Absicht dieses Steuerelements besteht darin, sicherzustellen, dass der Prozess befolgt wird und robust genug ist, um neue Sicherheitsrisiken in der gesamten Umgebung zu identifizieren. Dies kann nicht nur die Betriebssysteme sein; Es kann Anwendungen enthalten, die in der Umgebung ausgeführt werden, und codeabhängigkeiten.

• Beispielrichtlinien für Nachweise: Nachweise können durch anzeigen von Abonnements für Mailinglisten, manuelle Überprüfung von Sicherheitsquellen auf neu veröffentlichte Sicherheitsrisiken (müsste angemessen mit Zeitstempeln der Aktivitäten, d. b. mit JIRA oder Azure DevOps), Tools bereitgestellt werden, die veraltete Software finden (z. B. Snyk bei der Suche nach veralteten Softwarebibliotheken sein könnte, oder Nessus mit authentifizierten Scans, die veraltete Software identifizieren.

Anmerkung Wenn Sie Nessus verwenden, müsste dies regelmäßig ausgeführt werden, um Sicherheitsrisiken schnell zu identifizieren. Wir empfehlen mindestens wöchentlich.

• Beispielbeweis: Dieser Screenshot zeigt, dass eine Adressgruppe verwendet wird, um über Sicherheitsrisiken benachrichtigt zu werden.

Kontrolle Nr. 12: Stellen Sie Beweise bereit, die belegen, dass allen Sicherheitsrisiken nach der Identifizierung eine Risikorangfolge zugewiesen wird.

• Absicht: Das Patchen muss auf dem Risiko basieren, je riskanter das Sicherheitsrisiko ist, desto schneller muss es behoben werden. Die Risikoeinstufung identifizierter Sicherheitsrisiken ist ein integraler Bestandteil dieses Prozesses. Mit diesem Steuerelement soll sichergestellt werden, dass es einen dokumentierten Risikorangfolgeprozess gibt, der befolgt wird, um sicherzustellen, dass alle identifizierten Sicherheitsrisiken entsprechend dem Risiko eingestuft werden. Organisationen verwenden in der Regel die CVSS-Bewertung (Common Vulnerability Scoring System), die von Anbietern oder Sicherheitsexperten bereitgestellt wird. Wenn die Organisation auf CVSS angewiesen ist, wird empfohlen, dass ein Mechanismus zur Neubewertung in den Prozess einbezogen wird, damit die Organisation die Rangfolge basierend auf einer internen Risikobewertung ändern kann. Manchmal ist die Sicherheitsanfälligkeit aufgrund der Art und Weise, wie die Anwendung in der Umgebung bereitgestellt wurde, möglicherweise nicht die Anwendung. Beispielsweise kann eine Java-Sicherheitslücke freigegeben werden, die sich auf eine bestimmte Bibliothek auswirkt, die nicht von der Organisation verwendet wird.

• Beispielrichtlinien für Nachweise: Stellen Sie Nachweise mithilfe eines Screenshots oder einer anderen Methode bereit, z. B. DevOps/Jira, die zeigt, dass Sicherheitsrisiken den Prozess der Risikoeinstufung durchlaufen und von der Organisation eine entsprechende Risikorangfolge zugewiesen werden.

• Beispielbeweis: Dieser Screenshot zeigt die Risikorangfolge in Spalte D und eine erneute Rangfolge in den Spalten F und G, wenn die Organisation eine Risikobewertung durchführt und feststellt, dass das Risiko herabgestuft werden kann. Nachweise für eine Neubewertung von Risikobewertungen müssten als Nachweise vorgelegt werden.

Patchverwaltung – Patchen

Die folgenden Steuerelemente gelten für das Patching-Element für die Patchverwaltung. Um eine sichere Betriebsumgebung zu gewährleisten, müssen Anwendungen/Add-Ons und unterstützende Systeme entsprechend gepatcht werden. Es muss ein geeigneter Zeitrahmen zwischen Identifizierung (oder öffentlichem Release) und Patching verwaltet werden, um das Zeitfenster für die Ausnutzung eines Sicherheitsrisikos durch eine "Aktivitätsgruppe" zu verringern. Die Microsoft 365-Zertifizierung sieht kein "Patchfenster" vor. Zertifizierungsanalysten lehnen jedoch nicht angemessene Zeitrahmen ab.

Diese Sicherheitskontrollgruppe gilt für PaaS-Hostingumgebungen (Platform-as-a-Service), da die Anwendung/Add-In-Softwarebibliotheken und codebasis von Drittanbietern basierend auf der Risikobewertung gepatcht werden müssen.

Steuerung Nr. 13: Bereitstellen einer Richtliniendokumentation für das Patchen von systeminternen Komponenten, die einen geeigneten minimalen Patchzeitrahmen für kritische, risikobehaftete und mittlere Sicherheitsrisiken enthält; und Außerbetriebnahme von nicht unterstützten Betriebssystemen und Software.

• Absicht: Patchverwaltung ist für viele Sicherheitscompliance-Frameworks erforderlich, d. h. PCI-DSS, ISO 27001, NIST (SP) 800-53. Die Wichtigkeit einer guten Patchverwaltung kann nicht übermäßig betont werden, da es Sicherheits- und Funktionsprobleme in Software und Firmware beheben und Sicherheitsrisiken entschärfen kann, was dazu beiträgt, die Möglichkeiten zur Nutzung zu verringern. Mit diesem Steuerelement soll das Zeitfenster minimiert werden, in dem eine Aktivitätsgruppe Sicherheitsrisiken ausnutzt, die möglicherweise in der Bereichsumgebung vorhanden sind.

• Beispielrichtlinien für Nachweise: Stellen Sie eine Kopie aller Richtlinien und Verfahren bereit, die den Prozess für die Patchverwaltung detailliert beschreiben. Dies sollte einen Abschnitt zu einem minimalen Patchfenster enthalten, und dass nicht unterstützte Betriebssysteme und Software in der Umgebung nicht verwendet werden dürfen.

• Beispielbeweis: Im Folgenden finden Sie ein Beispiel für ein Richtliniendokument.

Anmerkung: Dieser Screenshot zeigt ein Richtlinien-/Prozessdokument. Es wird erwartet, dass ISVs die tatsächliche unterstützende Richtlinien-/Verfahrensdokumentation freigeben und nicht einfach eine screenshot._

Steuerung Nr. 14: Stellen Sie nachweisbare Beweise dafür bereit, dass alle erfassten Systemkomponenten gepatcht werden.

Anmerkung: Schließen Sie alle Software-/Drittanbieterbibliotheken ein.

• Absicht: Das Patchen von Sicherheitsrisiken stellt sicher, dass die verschiedenen Module, die Teil der IT-Infrastruktur sind (Hardware, Software und Dienste), auf dem neuesten Stand gehalten werden und frei von bekannten Sicherheitsrisiken sind. Das Patchen muss so bald wie möglich durchgeführt werden, um das Potenzial eines Sicherheitsvorfalls zwischen der Veröffentlichung von Sicherheitsrisikodetails und dem Patchen zu minimieren. Dies ist noch wichtiger, wenn die Ausnutzung von Sicherheitsrisiken bekannt ist, dass sie in freier Wildbahn vorhanden sind.

• Beispielbeweisrichtlinien: Stellen Sie einen Screenshot für jedes Gerät im Beispiel und unterstützende Softwarekomponenten bereit, der zeigt, dass Patches gemäß dem dokumentierten Patchprozess installiert werden.

• Beispielbeweis: Der folgende Screenshot zeigt, dass die im Bereich enthaltene Systemkomponente "CLARANET-SBU-WM" Windows-Updates gemäß der Patchrichtlinie ausführt.

Anmerkung: Das Patchen aller systeminternen Systemkomponenten muss ein Beweis dafür sein. Dazu gehören Dinge wie; Betriebssystemupdates, Anwendungs-/Komponentenupdates (i.e__.,_ Apache Tomcat, OpenSSL usw.), Softwareabhängigkeiten (z. B. JQuery, AngularJS usw.) usw.

Steuerung Nr. 15: Stellen Sie nachweisbare Beweise bereit, dass nicht unterstützte Betriebssysteme und Softwarekomponenten in der Umgebung nicht verwendet werden.

• Absicht: Software, die nicht von Anbietern gewartet wird, leidet im Laufe der Zeit unter bekannten Sicherheitsrisiken, die nicht behoben sind. Daher darf die Verwendung nicht unterstützter Betriebssysteme und Softwarekomponenten nicht in Produktionsumgebungen verwendet werden.

• Beispielrichtlinien für Nachweise: Stellen Sie einen Screenshot für jedes Gerät im Beispiel bereit, der die Version des ausgeführten Betriebssystems zeigt (einschließlich des Namens des Servers im Screenshot). Stellen Sie außerdem beweise, dass softwarekomponenten, die in der Umgebung ausgeführt werden, unterstützte Versionen ausführen. Dies kann durch die Bereitstellung der Ausgabe interner Berichte zur Überprüfung auf Sicherheitsrisiken (sofern authentifizierte Überprüfungen enthalten sind) und/oder die Ausgabe von Tools zur Überprüfung von Drittanbieterbibliotheken wie Snyk, Trivy oder NPM Audit erfolgen. Wenn nur in PaaS ausgeführt wird, muss nur das Patchen von Bibliotheken von Drittanbietern von den Patchsteuerelementgruppen abgedeckt werden.

• Beispielbeweis: Der folgende Beweis zeigt, dass die systeminterne Komponente THOR Software ausführt, die vom Anbieter unterstützt wird, da Nessus keine Probleme gekennzeichnet hat.

Anmerkung: Der vollständige Bericht muss für die Zertifizierungsanalysten freigegeben werden.

• Beispielbeweis 2

Dieser Screenshot zeigt, dass die bereichsinterne Systemkomponente "CLARANET-SBU-WM" unter einer unterstützten Windows-Version ausgeführt wird.

• Beispielbeweis 3

Der folgende Screenshot zeigt die Trivy-Ausgabe , in der der vollständige Bericht keine nicht unterstützten Anwendungen auflistet.

Anmerkung: Der vollständige Bericht muss für die Zertifizierungsanalysten freigegeben werden.

Prüfung auf Schwachstellen

Durch die Einführung regelmäßiger Sicherheitsrisikobewertungen können Organisationen Schwachstellen und Unsicherheiten in ihren Umgebungen erkennen, die einen Einstiegspunkt für böswillige Akteure bieten können, um die Umgebung zu kompromittieren. Die Überprüfung auf Sicherheitsrisiken kann helfen, fehlende Patches oder Fehlkonfigurationen in der Umgebung zu identifizieren. Durch die regelmäßige Durchführung dieser Überprüfungen kann eine Organisation geeignete Abhilfemaßnahmen bereitstellen, um das Risiko einer Gefährdung aufgrund von Problemen zu minimieren, die häufig von diesen Tools zur Überprüfung auf Sicherheitsrisiken aufgegriffen werden.

Steuerung Nr. 16: Stellen Sie die vierteljährlichen Berichte zur Überprüfung von Sicherheitsrisiken für Infrastruktur und Webanwendung bereit. Die Überprüfung muss für den gesamten öffentlichen Speicherbedarf (IP-Adressen und URLs) und interne IP-Adressbereiche durchgeführt werden.

Anmerkung: Dies MUSS den vollständigen Bereich der Umgebung umfassen.

• Absicht: Die Überprüfung auf Sicherheitsrisiken sucht nach möglichen Schwachstellen in einem Computersystem, netzwerken und Webanwendungen eines Unternehmens, um Löcher zu identifizieren, die möglicherweise zu Sicherheitsverletzungen und der Offenlegung vertraulicher Daten führen könnten. Die Überprüfung auf Sicherheitsrisiken ist häufig durch Branchenstandards und behördliche Vorschriften erforderlich, z. B. pci DSS (Payment Card Industry Data Security Standard).

• In einem Bericht von Security Metric mit dem Titel "2020 Security Metrics Guide to PCI DSS Compliance" heißt es: "Im Durchschnitt dauerte es 166 Tage, als eine Organisation festgestellt wurde, dass ein Angreifer Sicherheitsrisiken hatte, um das System zu kompromittieren. Nach der Kompromittierung hatten Angreifer durchschnittlich 127 Tage Zugriff auf vertrauliche Daten. Diese Kontrolle zielt daher darauf ab, potenzielle Sicherheitsschwächen innerhalb der Umgebung im Gültigkeitsbereich zu identifizieren.

• Beispielbeweisrichtlinien: Stellen Sie die vollständigen Überprüfungsberichte für die Sicherheitsrisikoüberprüfungen jedes Quartals bereit, die in den letzten 12 Monaten durchgeführt wurden. In den Berichten sollten die Ziele klar angegeben werden, um zu überprüfen, ob der vollständige öffentliche Speicherbedarf und ggf. jedes interne Subnetz enthalten ist. Geben Sie ALLE Überprüfungsberichte für JEDES Quartal an .

• Beispielbeweis: Beispielbeweis wäre die Bereitstellung der Überprüfungsberichte aus dem verwendeten Scantool. Die Überprüfungsberichte jedes Quartals sollten zur Überprüfung bereitgestellt werden. Die Überprüfung muss also die gesamten Systemkomponenten der Umgebung umfassen. jedes interne Subnetz und jede öffentliche IP-Adresse/URL, die für die Umgebung verfügbar ist.

Steuerung Nr. 17: Stellen Sie nachweisbare Beweise dafür bereit, dass die Behebung von Sicherheitsrisiken, die während der Überprüfung auf Sicherheitsrisiken identifiziert wurden, gemäß Ihrem dokumentierten Patchzeitrahmen gepatcht werden.

• Absicht: Wenn Sicherheitsrisiken und Fehlkonfigurationen nicht schnell erkannt, verwaltet und behoben werden, kann dies das Risiko einer Kompromittierung einer Organisation erhöhen, die zu potenziellen Datenschutzverletzungen führt. Die korrekte Identifizierung und Behebung von Problemen wird als wichtig für den allgemeinen Sicherheitsstatus und die Umgebung einer Organisation angesehen, die mit den bewährten Methoden verschiedener Sicherheitsframeworks für entspricht; Beispiel: ISO 27001 und PCI-DSS.

• Beispielrichtlinien für Nachweise: Stellen Sie geeignete Artefakte (d. h. Screenshots) bereit, die zeigen, dass ein Beispiel der entdeckten Sicherheitsrisiken aus der Überprüfung auf Sicherheitsrisiken in Übereinstimmung mit den Patchfenstern behoben werden, die bereits oben in Control 13 bereitgestellt wurden.

• Beispielbeweis: Der folgende Screenshot zeigt eine Nessus-Überprüfung der Bereichsumgebung (ein einzelner Computer mit dem Namen "THOR") mit Sicherheitsrisiken am 2. August 2021.

Der folgende Screenshot zeigt, dass die Probleme behoben wurden, 2 Tage später innerhalb des Patchfensters, das in der Patchrichtlinie definiert ist.

Anmerkung: Für diese Kontrolle müssen Zertifizierungsanalysten Berichte zur Überprüfung von Sicherheitsrisiken und Korrekturen für jedes Quartal der letzten zwölf Monate einsehen.

Firewalls

Firewalls bieten häufig eine Sicherheitsgrenze zwischen vertrauenswürdigen (internen Netzwerken), nicht vertrauenswürdigen (Internet) und halb vertrauenswürdigen Umgebungen (DMZ). Diese sind in der Regel die erste Verteidigungslinie innerhalb einer Sicherheitsstrategie für eine Organisation, die darauf ausgelegt ist, den Datenverkehrsfluss für ein- und ausgehende Dienste zu steuern und unerwünschten Datenverkehr zu blockieren. Diese Geräte müssen streng kontrolliert werden, um sicherzustellen, dass sie effektiv funktionieren und frei von Fehlkonfigurationen sind, die die Umgebung gefährden könnten.

Steuerung Nr. 18: Stellen Sie Richtliniendokumentation bereit, die die Vorgehensweisen und Verfahren der Firewallverwaltung regelt.

• Absicht: Firewalls sind eine wichtige erste Verteidigungslinie in einer mehrstufigen Sicherheitsstrategie (Defense In-Depth), die Umgebungen vor weniger vertrauenswürdigen Netzwerkzonen schützt. Firewalls steuern den Datenverkehrsfluss in der Regel basierend auf IP-Adressen und Protokollen/Ports. Mehr Funktionsreiche Firewalls können auch zusätzliche Schutzmaßnahmen auf "Anwendungsschicht" bereitstellen, indem sie den Anwendungsdatenverkehr überprüfen, um sich vor Missbrauch, Sicherheitsrisiken und Bedrohungen basierend auf den Anwendungen zu schützen, auf die zugegriffen wird. Diese Schutzmaßnahmen sind nur so gut wie die Konfiguration der Firewall. Daher müssen strenge Firewallrichtlinien und Supportverfahren eingerichtet werden, um sicherzustellen, dass sie für einen angemessenen Schutz interner Ressourcen konfiguriert sind. Beispielsweise fungiert eine Firewall mit einer Regel zum Zulassen des GESAMTEN Datenverkehrs von EINER BELIEBIGEN Quelle an EIN BELIEBIGEs Ziel nur als Router.

• Beispielbeweisrichtlinien: Stellen Sie ihre vollständige Dokumentation zur Firewallrichtlinie/-prozedur bereit. In diesem Dokument sollten alle unten aufgeführten Punkte und alle zusätzlichen bewährten Methoden für Ihre Umgebung behandelt werden.

• Beispielbeweis: Im Folgenden finden Sie ein Beispiel für die Art von Firewallrichtliniendokument, das wir benötigen (dies ist eine Demo und ist möglicherweise nicht vollständig).

Steuerung Nr. 19: Geben Sie nachweisbare Beweise dafür an, dass alle standardmäßigen Administratoranmeldeinformationen vor der Installation in Produktionsumgebungen geändert werden.

• Absicht: Organisationen müssen die vom Hersteller bereitgestellten Administratoranmeldeinformationen berücksichtigen, die während der Konfiguration des Geräts oder der Software konfiguriert werden. Standardanmeldeinformationen sind häufig von den Anbietern öffentlich verfügbar und können einer externen Aktivitätsgruppe die Möglichkeit bieten, eine Umgebung zu kompromittieren. Beispielsweise wird bei einer einfachen Suche im Internet nach den Standardanmeldeinformationen für iDrac (Integrated Dell Remote Access Controller) root::calvin als Standardbenutzername und -kennwort hervorgehoben. Dadurch erhält jemand Remotezugriff auf die Remoteserververwaltung. Mit diesem Steuerelement soll sichergestellt werden, dass Umgebungen nicht durch Standardanmeldeinformationen des Anbieters anfällig für Angriffe sind, die während der Geräte-/Anwendungshärtung nicht geändert wurden.

• Beispielrichtlinien für Nachweise

• Dies kann über eine Bildschirmfreigabesitzung nachgewiesen werden, in der der Zertifizierungsanalyst versuchen kann, sich mit Standardanmeldeinformationen bei den geräten im Bereich zu authentifizieren.

• Beispielbeweis

Der folgende Screenshot zeigt, was der Zertifizierungsanalyst aus einem ungültigen Benutzernamen/Kennwort einer WatchGuard Firewall sehen würde.

Steuerung 20: Stellen Sie nachweisbare Beweise dafür bereit, dass Firewalls an der Grenze der bereichsinternen Umgebung und zwischen dem Umkreisnetzwerk (auch als DMZ, demilitarisierte Zone und überprüftes Subnetz bezeichnet) und internen vertrauenswürdigen Netzwerken installiert sind.

• Absicht: Firewalls bieten die Möglichkeit, den Datenverkehr zwischen verschiedenen Netzwerkzonen mit unterschiedlichen Sicherheitsstufen zu steuern. Da alle Umgebungen mit dem Internet verbunden sind, müssen Firewalls an der Grenze installiert werden, d. h. zwischen dem Internet und der bereichsinternen Umgebung. Darüber hinaus müssen Firewalls zwischen den weniger vertrauenswürdigen DMZ-Netzwerken (De-Militarized Zone) und internen vertrauenswürdigen Netzwerken installiert werden. DMZs werden in der Regel verwendet, um Datenverkehr aus dem Internet zu verarbeiten und sind daher ein Angriffsziel. Durch die Implementierung einer DMZ und die Verwendung einer Firewall zum Steuern des Datenverkehrsflusses bedeutet eine Kompromittierung der DMZ nicht unbedingt eine Kompromittierung der internen vertrauenswürdigen Netzwerke und Unternehmens-/Kundendaten. Es sollte eine angemessene Protokollierung und Warnung vorhanden sein, damit Organisationen schnell eine Kompromittierung identifizieren können, um die Möglichkeit der Aktivitätsgruppe zu minimieren, die internen vertrauenswürdigen Netzwerke weiter zu kompromittieren. Mit diesem Steuerelement soll sichergestellt werden, dass es eine angemessene Kontrolle zwischen vertrauenswürdigen und weniger vertrauenswürdigen Netzwerken gibt.

• Beispielrichtlinien für Nachweise: Beweise sollten über Firewallkonfigurationsdateien oder Screenshots bereitgestellt werden, die zeigen, dass eine DMZ vorhanden ist. Dies sollte mit den bereitgestellten Architekturdiagrammen übereinstimmen, die die verschiedenen Netzwerke veranschaulichen, die die Umgebung unterstützen. Ein Screenshot der Netzwerkschnittstellen in der Firewall, gekoppelt mit dem Netzwerkdiagramm, das bereits als Teil der Anfänglichen Dokumentübermittlung bereitgestellt wurde, sollte diesen Beweis liefern.

• Beispielbeweis: Unten sehen Sie einen Screenshot einer WatchGuard-Firewall, die zwei DMZs zeigt, von denen eine für die eingehenden Dienste (namens DMZ) und die andere die Jumpbox (Bastian Host) bedient.

Steuerung 21: Nachweise dafür, dass der gesamte öffentliche Zugriff in der demilitarisierten Zone (DMZ) endet.

• Absicht: Öffentlich zugängliche Ressourcen stehen einer Vielzahl von Angriffen offen. Wie bereits oben erläutert, besteht die Absicht einer DMZ darin, weniger vertrauenswürdige Netzwerke aus vertrauenswürdigen internen Netzwerken zu segmentieren, die möglicherweise vertrauliche Daten enthalten. Eine DMZ gilt als weniger vertrauenswürdig, da das Risiko groß ist, dass hosts, die öffentlich zugänglich sind, durch externe Aktivitätsgruppen kompromittiert werden. Der öffentliche Zugriff sollte in diesen weniger vertrauenswürdigen Netzwerken, die durch die Firewall angemessen segmentiert sind, beendet werden, um interne Ressourcen und Daten zu schützen. Mit diesem Steuerelement soll sichergestellt werden, dass der gesamte öffentliche Zugriff innerhalb dieser weniger vertrauenswürdigen DMZs beendet wird, als wären Ressourcen in den vertrauenswürdigen internen Netzwerken öffentlich zugänglich. Eine Kompromittierung dieser Ressourcen bietet einer Aktivitätsgruppe einen Fuß in das Netzwerk, in dem vertrauliche Daten gespeichert werden.

• Beispielrichtlinien für Nachweise

• Hierfür könnten Firewallkonfigurationen angegeben werden, die die Eingangsregeln anzeigen und an denen diese Regeln beendet werden, entweder durch Weiterleiten öffentlicher IP-Adressen an die Ressourcen oder durch Bereitstellen der NAT (Network Address Translation) des eingehenden Datenverkehrs.

• Beispielbeweis

Im folgenden Screenshot gibt es drei Eingehende Regeln, die jeweils die NAT für die Subnetze 10.0.3.x und 10.0.4.x zeigen, bei denen es sich um die DMZ-Subnetze handelt.

Steuerung 22: Stellen Sie nachweisbare Beweise dafür bereit, dass der gesamte durch die Firewall zugelassene Datenverkehr einen Genehmigungsprozess durchläuft.

• Absicht: Da Firewalls eine defensive Barriere zwischen nicht vertrauenswürdigem Datenverkehr und internen Ressourcen sowie zwischen Netzwerken mit unterschiedlichen Vertrauensebenen darstellen, müssen Firewalls sicher konfiguriert werden und sicherstellen, dass nur Datenverkehr aktiviert wird, der für Geschäftsvorgänge erforderlich ist. Durch das Zulassen eines unnötigen Datenverkehrsflusses oder eines übermäßig freizügigen Datenverkehrsflusses kann dies Schwachstellen innerhalb der Verteidigung an den Grenzen dieser verschiedenen Netzwerkzonen mit sich bringen. Durch die Einrichtung eines robusten Genehmigungsprozesses für alle Firewalländerungen wird das Risiko der Einführung einer Regel reduziert, die ein erhebliches Risiko für die Umgebung darstellt. Verizons Untersuchungsbericht 2020 zur Untersuchung von Datenverletzungen hebt hervor, dass "Error's", der Fehlkonfigurationen enthält, der einzige Aktionstyp ist, der von Jahr zu Jahr ständig zunimmt.

• Beispielrichtlinien für Nachweise: Nachweise können in Form von Dokumentationen vorliegen, die zeigen, dass eine Firewalländerungsanforderung autorisiert ist, die minutenweise von einer CAB-Besprechung (Change Advisor Board) oder von einem Änderungskontrollsystem sein kann, das alle Änderungen nachverfolgt.

• Beispielbeweis: Der folgende Screenshot zeigt eine Änderung der Firewallregel, die mithilfe eines papierbasierten Prozesses angefordert und autorisiert wird. Dies könnte beispielsweise durch DevOps oder Jira erreicht werden.

Steuerung 23: Stellen Sie nachweisbare Beweise dafür bereit, dass die Firewallregelbasis so konfiguriert ist, dass Datenverkehr gelöscht wird, der nicht explizit definiert ist.

• Absicht: Die meisten Firewalls verarbeiten die Regeln in einem Top-Down-Ansatz, um zu versuchen, eine Abgleichsregel zu finden. Wenn eine Regel übereinstimmt, wird die Aktion dieser Regel angewendet, und die weitere Verarbeitung der Regeln wird beendet. Wenn keine übereinstimmenden Regeln gefunden werden, wird der Datenverkehr standardmäßig verweigert. Die Absicht dieses Steuerelements ist, wenn die Firewall den Datenverkehr nicht standardmäßig verwirft, wenn keine übereinstimmende Regel gefunden wird, muss die Regelbasis eine "Alle verweigern"-Regel am Ende aller Firewalllisten enthalten. Dadurch soll sichergestellt werden, dass die Firewall bei der Verarbeitung der Regeln nicht standardmäßig in den Zulassungszustand versetzt wird, sodass Datenverkehr zugelassen wird, der nicht explizit definiert wurde.

• Beispielrichtlinien für Nachweise: Der Nachweis kann über die Firewallkonfiguration oder durch Screenshots mit allen Firewallregeln bereitgestellt werden, die eine "Alle verweigern"-Regel am Ende zeigen, oder wenn die Firewall Datenverkehr abbricht, der standardmäßig nicht mit einer Regel übereinstimmt, geben Sie einen Screenshot aller Firewallregeln und einen Link zu den Administratorhandbüchern des Anbieters an, in dem hervorgehoben wird, dass die Firewall standardmäßig den gesamten Datenverkehr, der nicht übereinstimmt, abbricht.

• Beispielbeweis: Unten ist ein Screenshot der WatchGuard-Firewallregelbasis, die zeigt, dass keine Regeln konfiguriert sind, um den gesamten Datenverkehr zuzulassen. Am Ende gibt es keine Deny-Regel, da der WatchGuard Datenverkehr verlöscht, der standardmäßig nicht übereinstimmt.

Der folgende WatchGuard-Hilfecenter-Link; https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/policies/policies_about_c.html enthält die folgenden Informationen:

Steuerung 24: Stellen Sie nachweisbare Beweise dafür bereit, dass die Firewall nur starke Kryptografie auf allen Verwaltungsschnittstellen unterstützt, die keine Konsolen sind.

• Absicht: Um Man-in-the-Middle-Angriffe auf administrativen Datenverkehr zu minimieren, sollten alle Verwaltungsschnittstellen, die keine Konsolen sind, nur starke Kryptografie unterstützen. Die Hauptabsicht dieses Steuerelements besteht darin, die Administratoranmeldeinformationen zu schützen, wenn die Nicht-Konsolenverbindung eingerichtet wird. Darüber hinaus kann dies auch dazu beitragen, sich vor Lauschangriffen in die Verbindung zu schützen, indem versucht wird, administrative Funktionen zur Neukonfiguration des Geräts oder als Teil der Reconnaissance wiederzuverwenden.

• Beispielrichtlinien für Nachweise: Stellen Sie die Firewallkonfiguration bereit, wenn die Konfiguration die kryptografische Konfiguration der Verwaltungsschnittstellen ohne Konsole bereitstellt (nicht alle Geräte enthalten dies als konfigurierbare Optionen). Wenn dies nicht in der Konfiguration enthalten ist, können Sie möglicherweise Befehle an das Gerät ausgeben, um anzuzeigen, was für diese Verbindungen konfiguriert ist. Einige Anbieter veröffentlichen diese Informationen möglicherweise in Artikeln, sodass dies auch eine Möglichkeit sein kann, diese Informationen zu belegen. Schließlich müssen Sie möglicherweise Tools ausführen, um die unterstützte Verschlüsselung auszugeben.

• Beispielbeweis: Der folgende Screenshot zeigt die Ausgabe von SSLScan für die Web admin-Schnittstelle der WatchGuard-Firewall an TCP-Port 8080. Dies zeigt TLS 1.2 oder höher mit einer Mindestverschlüsselungsverschlüsselung von AES-128bit an.

Hinweis: Die WatchGuard-Firewalls unterstützen auch administrative Funktionen mit SSH (TCP-Port 4118) und WatchGuard System Manager (TCP-Ports 4105 & 4117). Es müssten auch Beweise für diese Verwaltungsschnittstellen bereitgestellt werden, die keine Konsolen sind.

Steuerung 25: Stellen Sie nachweisbare Beweise bereit, dass Sie Firewallregelüberprüfungen mindestens alle 6 Monate durchführen.

• Absicht: Im Laufe der Zeit besteht das Risiko, dass sich die Konfiguration in systemkomponenten in der bereichsinternen Umgebung einschleicht. Dies kann häufig zu Unsicherheiten oder Fehlkonfigurationen führen, die das Risiko einer Gefährdung der Umgebung erhöhen können. Konfigurations-Kriechen kann aus zahlreichen Gründen eingeführt werden, z. B. temporäre Änderungen zur Unterstützung der Problembehandlung, temporäre Änderungen für Ad-hoc-Funktionsänderungen, um schnelle Korrekturen für Probleme einzuführen, die aufgrund des Drucks der Einführung einer schnellen Lösung manchmal übermäßig freizügig sein können. Beispielsweise können Sie eine temporäre Firewallregel "Alle zulassen" einführen, um ein dringendes Problem zu beheben. Die Absicht dieses Steuerelements besteht aus zwei Teilen: Erstens soll ermittelt werden, wo Fehlkonfigurationen vorliegen, die zu Unsicherheiten führen können, und zweitens zur Identifizierung von Firewallregeln, die nicht mehr benötigt werden und daher entfernt werden können, d. h. wenn ein Dienst außer Betrieb genommen wurde, die Firewallregel jedoch zurückgelassen wurde.

• Beispielrichtlinien für Nachweise: Beweise müssen nachweisen können, dass die Überprüfungssitzungen stattgefunden haben. Dies kann geschehen, indem Sie Besprechungsprotokolle der Firewallüberprüfung und alle zusätzlichen Nachweise zur Änderungssteuerung freigeben, die alle aktionen zeigen, die im Rahmen der Überprüfung ausgeführt wurden. Stellen Sie sicher, dass die Datumsangaben vorhanden sind, da mindestens zwei dieser Besprechungen (d. a. alle sechs Monate) angezeigt werden müssen.

• Beispielbeweis: Der folgende Screenshot zeigt den Beweis für eine Firewallüberprüfung im Januar 2021.

Der folgende Screenshot zeigt den Beweis für eine Überprüfung der Firewall im Juli 2021.

Firewalls – WAFs

Es ist optional, eine Web Application Firewall (WAF) in der Lösung bereitzustellen. Wenn eine WAF verwendet wird, wird dies als zusätzliche Gutschrift für die Bewertungsmatrix innerhalb der Sicherheitsdomäne "Betriebssicherheit" gezählt. WAFs können Webdatenverkehr untersuchen, um Webdatenverkehr zwischen dem Internet und veröffentlichten Webanwendungen zu filtern und zu überwachen, um webanwendungsspezifische Angriffe zu identifizieren. Webanwendungen können unter vielen Angriffen leiden, die spezifisch für Webanwendungen sind, z. B. SQL Injection (SQLi), Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF/XSRF) usw., und WAFs sind so konzipiert, dass sie vor diesen Arten bösartiger Nutzlasten schützen, um Webanwendungen vor Angriffen und potenziellen Kompromittierungen zu schützen.

Steuerung 26: Stellen Sie nachweisbare Beweise dafür bereit, dass die Web Application Firewall (WAF) für die aktive Überwachung, Warnung und Blockierung schädlichen Datenverkehrs konfiguriert ist.

• Absicht: Dieses Steuerelement wird eingerichtet, um zu bestätigen, dass die WAF für alle eingehenden Webverbindungen vorhanden ist und dass sie so konfiguriert ist, dass sie entweder schädlichen Datenverkehr blockiert oder warnungen. Um eine zusätzliche Schutzebene für Webdatenverkehr bereitzustellen, müssen WAFs für alle eingehenden Webverbindungen konfiguriert werden. Andernfalls könnten externe Aktivitätsgruppen die WAFs umgehen, die für diese zusätzliche Schutzebene konzipiert sind. Wenn die WAF nicht so konfiguriert ist, dass böswilligen Datenverkehr aktiv blockiert wird, muss die WAF in der Lage sein, mitarbeiter sofort zu benachrichtigen, die schnell auf den potenziellen schädlichen Datenverkehr reagieren können, um die Sicherheit der Umgebung aufrechtzuerhalten und die Angriffe zu stoppen.

• Beispiel-Beweisrichtlinien: Stellen Sie eine Konfigurationsausgabe der WAF bereit, die die eingehenden Webverbindungen hervorhob, die verarbeitet werden, und dass die Konfiguration schädlichen Datenverkehr aktiv blockiert oder überwacht und warnungen ist. Alternativ können Screenshots der spezifischen Einstellungen freigegeben werden, um zu zeigen, dass eine Organisation dieses Steuerelement erfüllt.

• Beispielbeweis: Die folgenden Screenshots zeigen, dass die AZURE Application Gateway-WAF-Richtlinie von Contoso Production aktiviert ist und für den Modus "Prävention" konfiguriert ist, wodurch schädlicher Datenverkehr aktiv gelöscht wird.

Der folgende Screenshot zeigt die Front-End-IP-Konfiguration

Anmerkung: Beweise sollten alle öffentlichen IP-Adressen veranschaulichen, die von der Umgebung verwendet werden, um sicherzustellen, dass alle Eingangspunkte abgedeckt sind, weshalb dieser Screenshot ebenfalls enthalten ist.

Der folgende Screenshot zeigt die eingehenden Webverbindungen, die diese WAF verwenden.

Der folgende Screenshot zeigt die Contoso_AppGW_CoreRules, die zeigt, dass dies für den api.contoso.com-Dienst ist.

Steuerung 27: Stellen Sie nachweisbare Beweise dafür bereit, dass die WAF SSL-Auslagerung unterstützt.

• Absicht: Die Möglichkeit, dass die WAF für die Unterstützung der SSL-Abladung konfiguriert werden kann, ist wichtig, andernfalls kann die WAF den HTTPS-Datenverkehr nicht überprüfen. Da diese Umgebungen HTTPS-Datenverkehr unterstützen müssen, ist dies eine wichtige Funktion für die WAF, um sicherzustellen, dass schädliche Nutzlasten im HTTPS-Datenverkehr identifiziert und beendet werden können.

• Beispielrichtlinien für Nachweise: Stellen Sie einen Konfigurationsbeweis über einen Konfigurationsexport oder Screenshots bereit, die zeigen, dass ssl offloading unterstützt und konfiguriert wird.

• Beispielbeweis: In Azure Application Gateway finden Sie die Microsoft-Dokumentationsseite Übersicht über die TLS-Beendigung und end-to-End-TLS mit Application Gateway . Der folgende Screenshot zeigt die Konfiguration für die Azure Application Gateway-Instanz "Contoso Production".

Steuerung 28: "Stellen Sie nachweisbare Beweise dafür bereit, dass die WAF vor einigen oder allen der folgenden Klassen von Sicherheitsrisiken gemäß dem OWASP-Kernregelsatz (3.0 oder 3.1) schützt:

• Protokoll- und Codierungsprobleme,

• Headereinschleusung, Anforderungsschmuggel und Antwortaufteilung,

• Datei- und Pfaddurchlaufangriffe,

• RFI-Angriffe (Remote File Inclusion),

• Remote-Codeausführungsangriffe,

• PHP-Einschleusungsangriffe,

• Websiteübergreifende Skriptangriffe,

• Angriffe mit Einschleusung von SQL-Befehlen,

• Sitzungsfixierungsangriffe.

• Absicht: WAFs müssen konfiguriert werden, um Angriffsnutzlasten für gängige Klassen von Sicherheitsrisiken zu identifizieren. Diese Kontrolle soll sicherstellen, dass eine angemessene Erkennung von Sicherheitsrisikoklassen durch die Nutzung des OWASP-Kernregelsatzes abgedeckt wird.

• Beispielbeweisrichtlinien: Bereitstellen von Konfigurationsbeweis über einen Konfigurationsexport oder Screenshots zeigen, dass die meisten oben identifizierten Sicherheitsrisikoklassen von der Überprüfung abgedeckt werden.

• Beispielbeweis: Der folgende Screenshot zeigt, dass die AZURE Application Gateway-WAF-Richtlinie für die Contoso-Produktion für die Überprüfung anhand der Version 3.2 des OWASP-Kernregelsatzes konfiguriert ist.

Änderungssteuerung

Ein etablierter und verstandener Change Control-Prozess ist unerlässlich, um sicherzustellen, dass alle Änderungen einen strukturierten Prozess durchlaufen, der wiederholbar ist. Indem sichergestellt wird, dass alle Änderungen einen strukturierten Prozess durchlaufen, können Organisationen sicherstellen, dass Änderungen effektiv verwaltet, peer reviewt und angemessen getestet werden, bevor sie abgemeldet werden. Dies trägt nicht nur dazu bei, das Risiko von Systemausfällen zu minimieren, sondern auch das Risiko potenzieller Sicherheitsvorfälle durch falsche Änderungen zu minimieren.

Steuerung 29: Stellen Sie Richtliniendokumentation bereit, die Änderungskontrollprozesse steuert.

• Absicht: Um eine sichere Umgebung und eine sichere Anwendung aufrechtzuerhalten, muss ein robuster Änderungskontrollprozess eingerichtet werden, um sicherzustellen, dass alle Infrastruktur- und Codeänderungen mit starker Aufsicht und definierten Prozessen durchgeführt werden. Dadurch wird sichergestellt, dass Änderungen dokumentiert werden, Sicherheitsauswirkungen berücksichtigt werden, welche Sicherheitsauswirkungen die Änderung haben wird usw. Die Absicht besteht darin, sicherzustellen, dass der Änderungskontrollprozess dokumentiert ist, um sicherzustellen, dass ein sicherer und konsistenter Ansatz für alle Änderungen innerhalb der Umgebung und der Anwendungsentwicklungsmethoden verwendet wird.

• Beispielbeweisrichtlinien: Die dokumentierten Richtlinien/Verfahren zur Änderungssteuerung sollten mit den Zertifizierungsanalysten geteilt werden.

• Beispielbeweis: Unten zeigt den Beginn einer Beispiel-Änderungsverwaltungsrichtlinie. Bitte geben Sie Ihre vollständigen Richtlinien und Verfahren im Rahmen der Bewertung an.

Anmerkung: Dieser Screenshot zeigt ein Richtlinien-/Prozessdokument. Es wird erwartet, dass ISVs die tatsächliche unterstützende Richtlinien-/Verfahrensdokumentation freigeben und nicht einfach einen Screenshot bereitstellen.

Steuerung 30: Nachweise dafür liefern, dass Entwicklungs- und Testumgebungen die Trennung von Aufgaben von der Produktionsumgebung erzwingen.

• Absicht: Die Entwicklungs-/Testumgebungen der meisten Organisation sind nicht mit der gleichen Stärke wie die Produktionsumgebungen konfiguriert und daher weniger sicher. Darüber hinaus sollten Tests nicht innerhalb der Produktionsumgebung durchgeführt werden, da dies Sicherheitsprobleme mit sich bringen kann oder die Dienstbereitstellung für Kunden beeinträchtigen kann. Durch die Verwaltung separater Umgebungen, die eine Trennung von Aufgaben erzwingen, können Organisationen sicherstellen, dass Änderungen auf die richtigen Umgebungen angewendet werden, wodurch das Risiko von Fehlern verringert wird, indem Änderungen an Produktionsumgebungen implementiert werden, wenn sie für die Entwicklungs-/Testumgebung vorgesehen waren.

• Beispielrichtlinien für Nachweise: Screenshots können bereitgestellt werden, die verschiedene Umgebungen veranschaulichen, die für Entwicklungs-/Testumgebungen und Produktionsumgebungen verwendet werden. In der Regel verfügen Sie über unterschiedliche Personen/Teams mit Zugriff auf jede Umgebung, oder wenn dies nicht möglich ist, verwenden die Umgebungen unterschiedliche Autorisierungsdienste, um sicherzustellen, dass sich Benutzer nicht fälschlicherweise bei der falschen Umgebung anmelden können, um Änderungen anzuwenden.

• Beispielbeweis: Der folgende Screenshot zeigt ein Azure-Abonnement für die TEST-Umgebung von Contoso.

Der nächste Screenshot zeigt ein separates Azure-Abonnement für die Produktionsumgebung von Contoso.

Steuerung 31: Stellen Sie nachweisbare Beweise bereit, dass vertrauliche Produktionsdaten in den Entwicklungs- oder Testumgebungen nicht verwendet werden.

• Absicht: Wie bereits oben erläutert, implementieren Organisationen sicherheitsmaßnahmen einer Entwicklungs-/Testumgebung nicht in der gleichen Stärke wie die Produktionsumgebung. Durch die Verwendung vertraulicher Produktionsdaten in diesen Entwicklungs-/Testumgebungen erhöhen Sie daher das Risiko einer Kompromittierung und müssen die Verwendung von live/vertraulichen Daten in diesen Entwicklungs-/Testumgebungen vermeiden.

Anmerkung: Sie können Livedaten in Entwicklungs-/Testumgebungen verwenden, sofern die Entwicklung/der Test in den Rahmen der Bewertung einbezogen wird, damit die Sicherheit anhand der Microsoft 365-Zertifizierungskontrollen bewertet werden kann.

• Beispielrichtlinien für Nachweise: Der Nachweis kann durch Freigeben von Screenshots der Ausgabe derselben SQL-Abfrage für eine Produktionsdatenbank (Redigieren vertraulicher Informationen) und der Entwicklungs-/Testdatenbank bereitgestellt werden. Die Ausgabe der gleichen Befehle sollte unterschiedliche Datasets erzeugen. Wo Dateien gespeichert werden, sollte beim Anzeigen des Inhalts der Ordner in beiden Umgebungen auch unterschiedliche Datasets veranschaulicht werden.

• Beispielbeweis: Der folgende Screenshot zeigt die top 3 Datensätze (für die Beweisübermittlung bitte die top 20) aus der Produktionsdatenbank.

Der nächste Screenshot zeigt dieselbe Abfrage aus der Entwicklungsdatenbank mit unterschiedlichen Datensätzen.

Dies zeigt, dass sich die Datasets unterscheiden.

Kontrolle 32: Stellen Sie nachweisbare Beweise dafür bereit, dass dokumentierte Änderungsanforderungen Auswirkungen der Änderung, Details der Back-Out-Verfahren und der durchzuführenden Tests enthalten.

• Absicht: Die Absicht dieses Steuerelements besteht darin, sicherzustellen, dass die angeforderte Änderung berücksichtigt wurde. Die Auswirkungen der Änderung auf die Sicherheit des Systems/der Umgebung müssen berücksichtigt und klar dokumentiert werden, alle Back-Out-Verfahren müssen dokumentiert werden, um die Wiederherstellung zu unterstützen, wenn etwas schief geht, und schließlich müssen details der Tests, die erforderlich sind, um zu überprüfen, dass die Änderung erfolgreich war, auch berücksichtigt und dokumentiert werden.

• Beispielrichtlinien für Nachweise: Der Nachweis kann durch Exportieren einer Stichprobe von Änderungsanforderungen, bereitstellen von Papieränderungsanforderungen oder durch Bereitstellen von Screenshots der Änderungsanforderungen mit diesen drei Details in der Änderungsanforderung bereitgestellt werden.

• Beispielbeweis: Die folgende Abbildung zeigt eine neue Cross Site Scripting Vulnerability (XSS), die zugewiesen wird, und ein Dokument für die Änderungsanforderung.

Die folgenden Tickets zeigen die Informationen an, die dem Ticket auf der Reise zur Lösung festgelegt oder hinzugefügt wurden.

Die beiden folgenden Tickets zeigen die Auswirkungen der Änderung am System und alle Back-Out-Verfahren, die im Falle eines Problems erforderlich sein können. Sie können sehen, wie sich Änderungen auswirken und Back-Out-Verfahren einen Genehmigungsprozess durchlaufen haben und zu Testzwecken genehmigt wurden.

Auf der linken Seite des Bildschirms sehen Sie, dass das Testen der Änderungen genehmigt wurde. Auf der rechten Seite sehen Sie, dass die Änderungen jetzt genehmigt und getestet wurden.

Beachten Sie während des gesamten Prozesses, dass die Person, die die Arbeit ausführt, die Person, die darüber berichtet und die Person, die die zu erledigende Arbeit genehmigt, unterschiedliche Personen sind.

Das obige Ticket zeigt, dass die Änderungen jetzt für die Implementierung in der Produktionsumgebung genehmigt wurden. Das rechte Feld zeigt, dass der Test funktionierte und erfolgreich war und dass die Änderungen nun in Prod Environment implementiert wurden.

Steuerung 33: Stellen Sie nachweisbare Beweise dafür bereit, dass Änderungsanforderungen einem Autorisierungs- und Abmeldeprozess unterzogen werden.

• Absicht: Es muss ein Prozess implementiert werden, der die Durchführung von Änderungen ohne ordnungsgemäße Autorisierung verbietet und sich abmeldet. Die Änderung muss vor der Implementierung autorisiert werden, und die Änderung muss nach Abschluss des Vorgangs abgemeldet werden. Dadurch wird sichergestellt, dass die Änderungsanforderungen ordnungsgemäß überprüft wurden und eine zuständige Person die Änderung abgemeldet hat.

• Beispielrichtlinien für Nachweise: Der Nachweis kann durch Exportieren einer Stichprobe von Änderungsanforderungen, Bereitstellen von Papieränderungsanforderungen oder Durchstellen von Screenshots der Änderungsanforderungen erfolgen, die zeigen, dass die Änderung vor der Implementierung autorisiert wurde und dass die Änderung nach Abschluss des Vorgangs abgemeldet wurde.

• Beispielbeweis: Der folgende Screenshot zeigt ein Jira-Beispielticket, das zeigt, dass die Änderung autorisiert werden muss, bevor sie von einer anderen Person als dem Entwickler/Anfordernden implementiert und genehmigt wird. Sie können sehen, dass die Änderungen hier von jemandem mit Autorität genehmigt wurden. Auf der rechten Seite wurde von DP signiert, sobald der Vorgang abgeschlossen ist.

Im ticket unten sehen Sie, dass die Änderung nach Abschluss des Vorgangs abgemeldet wurde und zeigt, dass der Auftrag abgeschlossen und geschlossen wurde.

Sichere Softwareentwicklung/-bereitstellung

Organisationen, die an Softwareentwicklungsaktivitäten beteiligt sind, sind häufig mit konkurrierenden Prioritäten zwischen Sicherheit und TTM-Druck (Time to Market) konfrontiert, aber die Implementierung von sicherheitsbezogenen Aktivitäten während des gesamten Softwareentwicklungslebenszyklus (SDLC) kann nicht nur Geld sparen, sondern auch Zeit sparen. Wenn die Sicherheit im Nachgang bleibt, werden Probleme in der Regel nur während der Testphase des (DSLC) identifiziert, was oft zeitaufwendiger und kostspieliger zu beheben sein kann. In diesem Sicherheitsabschnitt soll sichergestellt werden, dass sichere Methoden für die Softwareentwicklung befolgt werden, um das Risiko von Programmierfehlern zu verringern, die in die entwickelte Software eingeführt werden. Darüber hinaus enthält dieser Abschnitt einige Steuerelemente, die die sichere Bereitstellung von Software unterstützen.

Steuerung 34: Stellen Sie Richtlinien und Verfahren bereit, die eine sichere Softwareentwicklung und -bereitstellung unterstützen, einschließlich bewährter Methoden für die sichere Codierung für gängige Sicherheitsrisikoklassen wie OWASP Top 10 oder SANS Top 25 CWE.

• Absicht: Organisationen müssen alles in ihrer Macht Stehende tun, um sicherzustellen, dass Software sicher entwickelt und frei von Sicherheitsrisiken ist. Um dies zu erreichen, sollten ein robuster SDLC (Secure Software Development Lifecycle) und bewährte Methoden für sichere Codierung eingeführt werden, um sichere Codierungstechniken und sichere Entwicklung während des gesamten Softwareentwicklungsprozesses zu fördern. Die Absicht besteht darin, die Anzahl und den Schweregrad von Sicherheitsrisiken in der Software zu reduzieren.

• Beispielrichtlinien für Nachweise: Stellen Sie die dokumentierte SDLC- und/oder Supportdokumentation bereit, die zeigt, dass ein sicherer Entwicklungslebenszyklus verwendet wird und dass allen Entwicklern Anleitungen zur Förderung bewährter Methoden für sichere Codierung zur Verfügung gestellt werden. Sehen Sie sich OWASP in SDLC und das OWASP Software Assurance Maturity Model (SAMM) an.

• Beispielbeweis: Im Folgenden finden Sie einen Auszug aus dem Verfahren zur sicheren Softwareentwicklung von Contoso, das sichere Entwicklungs- und Programmierpraktiken veranschaulicht.

Anmerkung: Diese Screenshots zeigen das Dokument zur sicheren Softwareentwicklung. Es wird erwartet, dass ISVs die eigentliche unterstützende Dokumentation freigeben und nicht einfach einen Screenshot bereitstellen.

Steuerung 35: Stellen Sie nachweisbare Beweise dafür bereit, dass Codeänderungen einem Überprüfungs- und Autorisierungsprozess durch einen zweiten Prüfer unterzogen werden.

• Absicht: Die Absicht dieses Steuerelements besteht darin, eine Codeüberprüfung durch einen anderen Entwickler durchzuführen, um Programmierfehler zu identifizieren, die zu einem Sicherheitsrisiko in der Software führen könnten. Die Autorisierung sollte eingerichtet werden, um sicherzustellen, dass Code reviews durchgeführt werden, Tests durchgeführt werden usw. vor der Bereitstellung. Der Autorisierungsschritt kann überprüfen, ob die richtigen Prozesse befolgt wurden, was dem oben definierten SDLC zugrunde liegt.

• Beispielbeweisrichtlinien: Stellen Sie den Nachweis bereit, dass Code einer Peer-Überprüfung unterzogen wird und autorisiert werden muss, bevor er auf die Produktionsumgebung angewendet werden kann. Dies kann durch einen Export von Änderungstickets erfolgen, der nachweist, dass Code reviews durchgeführt und die Änderungen autorisiert wurden, oder es kann über Code Reviews-Software wie Crucible (https://www.atlassian.com/software/crucible) erfolgen.

• Beispielbeweis

Im Folgenden finden Sie ein Ticket, das zeigt, dass Codeänderungen einem Überprüfungs- und Autorisierungsprozess durch eine andere Person als den ursprünglichen Entwickler unterzogen werden. Es zeigt, dass vom Zugewiesenen eine Codeüberprüfung angefordert wurde und einer anderen Person für die Codeüberprüfung zugewiesen wird.

Die folgende Abbildung zeigt, dass die Codeüberprüfung einer anderen Person als dem ursprünglichen Entwickler zugewiesen wurde, wie im hervorgehobenen Abschnitt auf der rechten Seite der Abbildung unten gezeigt. Auf der linken Seite sehen Sie, dass der Code überprüft wurde und vom Codeprüfer den Status "PASSED CODE REVIEW" erhalten hat.

Das Ticket muss nun von einem Vorgesetzten genehmigt werden, bevor die Änderungen in den Produktionssystemen in Betrieb genommen werden können.

Die abbildung oben zeigt, dass der überprüfte Code für die Implementierung in den Liveproduktionssystemen genehmigt wurde.

Nachdem die Codeänderungen vorgenommen wurden, wird der endgültige Auftrag wie in der Abbildung oben dargestellt abgemeldet.

Beachten Sie, dass während des gesamten Prozesses drei Personen beteiligt sind: der ursprüngliche Entwickler des Codes, der Codeprüfer und ein Manager, der die Genehmigung erteilt und sich abmeldet. Um die Kriterien für dieses Steuerelement zu erfüllen, wäre es eine Erwartung, dass Ihre Tickets diesem Prozess folgen. Mindestens drei Personen, die am Änderungskontrollprozess für Ihre Code reviews beteiligt sind.

Kontrolle 36: Stellen Sie nachweisbare Beweise dafür bereit, dass Entwickler jährlich eine sichere Softwareentwicklungsschulung durchlaufen.

• Absicht: Für alle Programmiersprachen gibt es bewährte Methoden und Techniken für die Codierung, um sicherzustellen, dass Code sicher entwickelt wird. Es gibt externe Schulungskurse, die Entwicklern die verschiedenen Arten von Softwaresicherheitsklassen und die Programmiertechniken vermitteln, die verwendet werden können, um die Einführung dieser Sicherheitsrisiken in die Software zu beenden. Die Absicht dieses Steuerelements besteht darin, diese Techniken allen Entwicklern beizubringen und sicherzustellen, dass diese Techniken nicht vergessen oder neuere Techniken erlernt werden, indem dies jährlich durchgeführt wird.

• Beispielbeweisrichtlinien: Stellen Sie Nachweise durch Zertifikate bereit, die von einem externen Schulungsunternehmen durchgeführt werden, oder indem Sie Screenshots der Schulungstagebücher oder anderer Artefakte bereitstellen, die zeigen, dass Entwickler an schulungen teilgenommen haben. Wenn diese Schulung über interne Ressourcen durchgeführt wird, stellen Sie auch den Nachweis des Schulungsmaterials bereit.

• Beispielbeweis: Unten ist die E-Mail mit der Bitte, dass Mitarbeiter im DevOps-Team für die jährliche OWASP Top Ten Training-Schulung registriert werden

Die folgende Abbildung zeigt, dass schulungen mit geschäftlicher Begründung und Genehmigung angefordert wurden. Anschließend folgen Screenshots aus der Schulung und ein Abschlussdatensatz, der zeigt, dass die Person die jährliche Schulung abgeschlossen hat.

Steuerung 37: Stellen Sie nachweisbare Beweise dafür bereit, dass Coderepositorys mit mehrstufiger Authentifizierung (Multi-Factor Authentication, MFA) geschützt sind.

• Absicht: Wenn eine Aktivitätsgruppe auf die Codebasis einer Software zugreifen und diese ändern kann, könnte sie Sicherheitsrisiken, Backdoors oder schädlichen Code in die Codebasis und damit in die Anwendung einführen. Es gab bereits mehrere Fälle davon, wobei wahrscheinlich der am meisten bekannt gemachte NotPetya Ransomware-Angriff ist, der angeblich durch ein kompromittiertes Update der ukrainischen Steuersoftware namens M.E.Doc infiziert ist (siehe Was ist nichtPetya).

• Beispielrichtlinien für Nachweise: Stellen Sie anhand von Screenshots aus dem Coderepository den Beweis bereit, dass für ALLE Benutzer MFA aktiviert ist.

• Beispielbeweis: Der folgende Screenshot zeigt, dass MFA für alle 8 GitLab-Benutzer aktiviert ist.

Steuerung 38: Stellen Sie nachweisbare Beweise dafür bereit, dass Zugriffssteuerungen zum Sichern von Coderepositorys vorhanden sind.

• Absicht: Ausgehend von der vorherigen Steuerung sollten Zugriffssteuerungen implementiert werden, um den Zugriff nur auf einzelne Benutzer zu beschränken, die an bestimmten Projekten arbeiten. Indem Sie den Zugriff einschränken, begrenzen Sie das Risiko, dass nicht autorisierte Änderungen vorgenommen werden, und führen dadurch unsichere Codeänderungen ein. Es sollte ein Ansatz mit den geringsten Rechten verwendet werden, um das Coderepository zu schützen.

• Beispielrichtlinien für Nachweise: Stellen Sie anhand von Screenshots aus dem Coderepository den Beweis bereit, dass der Zugriff auf erforderliche Personen beschränkt ist, einschließlich verschiedener Berechtigungen.

• Beispielbeweis: Der folgende Screenshot zeigt Mitglieder des Projekts "Customers" in GitLab, dem Contoso-Kundenportal. Wie im Screenshot zu sehen ist, haben Benutzer unterschiedliche "Rollen", um den Zugriff auf das Projekt einzuschränken.

Kontoverwaltung

Sichere Kontoverwaltungsverfahren sind wichtig, da Benutzerkonten die Grundlage für den Zugriff auf Informationssysteme, Systemumgebungen und Daten bilden. Benutzerkonten müssen ordnungsgemäß geschützt werden, da eine Kompromittierung der Anmeldeinformationen des Benutzers nicht nur einen Fuß in die Umgebung und den Zugriff auf vertrauliche Daten bieten kann, sondern auch administrative Kontrolle über die gesamte Umgebung oder Schlüsselsysteme bieten kann, wenn die Anmeldeinformationen des Benutzers Über Administratorrechte verfügen.

Steuerung 39: Stellen Sie Richtliniendokumentation bereit, die die Methoden und Verfahren für die Kontoverwaltung regelt.

• Absicht: Benutzerkonten werden weiterhin von Aktivitätsgruppen bestimmt und sind häufig die Quelle einer Datenkompromittierung. Durch die Konfiguration von übermäßig freizügigen Konten erhöhen Organisationen nicht nur den Pool von "privilegierten" Konten, die von einer Aktivitätsgruppe zum Ausführen einer Datenschutzverletzung verwendet werden können, sondern können auch das Risiko der erfolgreichen Ausnutzung einer Sicherheitslücke erhöhen, die für den Erfolg bestimmte Berechtigungen erfordern würde.

• BeyondTrust erstellt jedes Jahr einen "Microsoft-Sicherheitsrisikobericht", in dem Microsoft-Sicherheitsrisiken für das vorjahre Jahr analysiert werden und die Prozentsätze dieser Sicherheitsrisiken aufgeführt werden, die davon abhängen, dass das Benutzerkonto über Administratorrechte verfügt. In einem kürzlich veröffentlichten Blogbeitrag "New Microsoft Vulnerabilities Reports Reveals a 48% Increase of Vulnerabilities & How They Could Be Mitigated with Least Privilege" (Neuer Microsoft-Bericht über Sicherheitsrisiken von Microsoft zeigt einen Anstieg von 48 % im Jahresvergleich & Wie sie mit den geringsten Rechten entschärft werden könnten) wären 90 % der kritischen Sicherheitsrisiken in Internet Explorer, 85 % der kritischen Sicherheitsrisiken in Microsoft Edge und 100 % der kritischen Sicherheitsrisiken in Microsoft Outlook durch entfernen von Administratorrechten entschärft worden. Um die sichere Kontoverwaltung zu unterstützen, müssen Organisationen sicherstellen, dass unterstützende Richtlinien und Verfahren, die bewährte Sicherheitsmethoden fördern, vorhanden sind und befolgt werden, um diese Bedrohungen zu mindern.

• Beispielbeweisrichtlinien: Stellen Sie die dokumentierten Richtlinien und Verfahrensdokumente zur Verfügung, die Ihre Kontoverwaltungspraktiken abdecken. Die behandelten Themen sollten mindestens den Steuerelementen innerhalb der Microsoft 365-Zertifizierung entsprechen.

• Beispielbeweis: Der folgende Screenshot zeigt ein Beispiel für eine Kontoverwaltungsrichtlinie für Contoso.

Anmerkung: Dieser Screenshot zeigt ein Richtlinien-/Prozessdokument. Es wird erwartet, dass ISVs die tatsächliche unterstützende Richtlinien-/Verfahrensdokumentation freigeben und nicht einfach einen Screenshot bereitstellen.

Steuerung 40: Stellen Sie nachweisbare Beweise dafür bereit, dass Standardanmeldeinformationen für die erfassten Systemkomponenten entweder deaktiviert, entfernt oder geändert werden.

• Absicht: Obwohl dies immer weniger populär wird, gibt es immer noch Instanzen, in denen Aktivitätsgruppen standardmäßige und gut dokumentierte Benutzeranmeldeinformationen nutzen können, um Produktionssystemkomponenten zu kompromittieren. Ein beliebtes Beispiel hierfür ist Dell iDRAC (Integrated Dell Remote Access Controller). Dieses System kann verwendet werden, um einen Dell Server remote zu verwalten, der von einer Aktivitätsgruppe verwendet werden kann, um die Kontrolle über das Betriebssystem des Servers zu erlangen. Die Standardanmeldeinformationen von root::calvin sind dokumentiert und können häufig von Aktivitätsgruppen verwendet werden, um Zugriff auf Systeme zu erhalten, die von Organisationen verwendet werden. Mit diesem Steuerelement soll sichergestellt werden, dass diese Standardanmeldeinformationen entweder deaktiviert oder entfernt werden.

• Beispielbeweisrichtlinien: Es gibt verschiedene Möglichkeiten, wie Beweise gesammelt werden können, um dieses Steuerelement zu unterstützen. Screenshots von konfigurierten Benutzern in allen Systemkomponenten können hilfreich sein, d. h. Screenshots der Linux-Dateien "/etc/shadow" und "/etc/passwd" zeigen, ob Konten deaktiviert wurden. Beachten Sie, dass die Datei "/etc/shadow" erforderlich wäre, um zu veranschaulichen, dass Konten wirklich deaktiviert sind, indem sie beobachten, dass der Kennworthash mit einem ungültigen Zeichen wie "!" beginnt, das angibt, dass das Kennwort nicht verwendet werden kann. Der Rat würde sein, nur wenige Zeichen des Kennworts zu deaktivieren und den Rest zu bearbeiten. Andere Optionen wären für screensharing-Sitzungen, bei denen der Bewerter die Standardanmeldeinformationen manuell testen konnte. In der obigen Diskussion auf Dell iDRAC muss der Bewerter beispielsweise versuchen, sich mit den Standardanmeldeinformationen bei allen Dell iDRAC-Schnittstellen zu authentifizieren.

• Beispielbeweis: Der folgende Screenshot zeigt Benutzerkonten, die für die bereichsinterne Systemkomponente "CLARANET-SBU-WM" konfiguriert sind. Zeigt mehrere Standardkonten an. Administrator, DefaultAccount und Gast, die folgenden Screenshots zeigen jedoch, dass diese Konten deaktiviert sind.

Der nächste Screenshot zeigt, dass das Administratorkonto für die bereichsinterne Systemkomponente "CLARANET-SBU-WM" deaktiviert ist.

Der nächste Screenshot zeigt, dass das Gastkonto für die bereichsinterne Systemkomponente "CLARANET-SBU-WM" deaktiviert ist.

Dieser nächste Screenshot zeigt, dass defaultAccount für die bereichsinterne Systemkomponente "CLARANET-SBU-WM" deaktiviert ist.

Steuerung 41: Stellen Sie nachweisbare Beweise dafür bereit, dass die Erstellung, Änderung und Löschung eines Kontos einen etablierten Genehmigungsprozess durchläuft.

• Absicht: Die Absicht besteht darin, über einen eingerichteten Prozess zu verfügen, um sicherzustellen, dass alle Kontoverwaltungsaktivitäten genehmigt werden, um sicherzustellen, dass Kontoberechtigungen die Prinzipien der geringsten Rechte beibehalten und dass Kontoverwaltungsaktivitäten ordnungsgemäß überprüft und nachverfolgt werden können.

• Beispielrichtlinien für Nachweise: Der Nachweis erfolgt in der Regel in Form von Änderungsanforderungstickets, ITSM-Anforderungen (IT Service Management) oder Papierarbeiten, die zeigen, dass Anforderungen für Konten, die erstellt, geändert oder gelöscht werden sollen, einen Genehmigungsprozess durchlaufen haben.

• Beispielbeweis: Die folgenden Abbildungen zeigen die Kontoerstellung für einen neuen Starter für das DevOps-Team, das über eine rollenbasierte Zugriffssteuerungseinstellung basierend auf den Berechtigungen der Produktionsumgebung ohne Zugriff auf die Entwicklungsumgebung und standardmäßigen nicht privilegierten Zugriff auf alles andere verfügen muss.

Die Kontoerstellung hat den Genehmigungsprozess und den Abmeldeprozess durchlaufen, nachdem das Konto erstellt und das Ticket geschlossen wurde.

Steuerung 42: Stellen Sie nachweisbare Beweise bereit, dass ein Prozess vorhanden ist, um Konten zu deaktivieren oder zu löschen, die nicht innerhalb von drei Monaten verwendet werden.

• Absicht: Inaktive Konten können manchmal kompromittiert werden, weil sie auf Brute-Force-Angriffe abzielen, die möglicherweise nicht gekennzeichnet werden, da der Benutzer nicht versucht, sich bei den Konten anzumelden, oder aufgrund einer Kennwortdatenbankverletzung, bei der das Kennwort eines Benutzers wiederverwendet wurde und in einem Benutzernamen-/Kennwortabbild im Internet verfügbar ist. Nicht verwendete Konten sollten deaktiviert/entfernt werden, um die Angriffsfläche zu verringern, die eine Aktivitätsgruppe zum Ausführen von Kontokompromittierungsaktivitäten hat. Diese Konten können darauf zurückzuführen sein, dass ein Abgängerprozess nicht ordnungsgemäß durchgeführt wird, ein Mitarbeiter, der langfristig krank ist, oder ein Mitarbeiter, der mutterschafts-/vaterschaftsurlaub geht. Durch die Implementierung eines vierteljährlichen Prozesses zur Identifizierung dieser Konten können Organisationen die Angriffsfläche minimieren.

• Beispielhinweisrichtlinien: Die Beweise sollten zweifach sein. Zunächst ein Screenshot oder Dateiexport, der die "letzte Anmeldung" aller Benutzerkonten in der Bereichsumgebung anzeigt. Dies kann sowohl lokale Konten als auch Konten innerhalb eines zentralisierten Verzeichnisdiensts sein, z. B. Microsoft Entra ID. Dies zeigt, dass keine Konten aktiviert sind, die älter als 3 Monate sind. Zweitens der Nachweis des vierteljährlichen Überprüfungsprozesses, der dokumentarische Beweise für die Aufgabe sein kann, die innerhalb von ADO-Tickets (Azure DevOps) oder JIRA-Tickets oder durch Papieraufzeichnungen abgeschlossen wird, die abgemeldet werden sollten.

• Beispielbeweis: Dieser erste Screenshot zeigt die Ausgabe des Skripts, das vierteljährlich ausgeführt wird, um das Attribut für die letzte Anmeldung für Benutzer innerhalb der Microsoft Entra-ID anzuzeigen.

Wie im obigen Screenshot zu sehen ist, zeigen zwei Benutzer an, dass sie sich seit einiger Zeit nicht angemeldet haben. Die folgenden beiden Screenshots zeigen, dass diese beiden Benutzer deaktiviert sind.

Steuerung 43: Stellen Sie einen nachweisbaren Beweis dafür bereit, dass eine Richtlinie für sichere Kennwörter oder andere geeignete Maßnahmen zum Schutz von Benutzeranmeldeinformationen vorhanden sind. Folgendes sollte als Mindestrichtlinie verwendet werden:

• Minimale Kennwortlänge von 8 Zeichen

• Kontosperrungsschwellenwert von maximal 10 Versuchen

• Kennwortverlauf mit mindestens 5 Kennwörtern

• Erzwingung der Verwendung eines sicheren Kennworts

• Absicht: Wie bereits erwähnt, sind Benutzeranmeldeinformationen häufig das Ziel eines Angriffs von Aktivitätsgruppen, die versuchen, Zugriff auf die Umgebung einer Organisation zu erhalten. Die Absicht einer Richtlinie für sichere Kennwörter besteht darin, Benutzer zur Auswahl sicherer Kennwörter zu zwingen, um die Wahrscheinlichkeit zu verringern, dass Aktivitätsgruppen sie in der Lage sind, sie mit Brute-Force zu versehen. Die Absicht, die "oder andere geeignete Gegenmaßnahmen" hinzuzufügen, besteht darin, zu erkennen, dass Organisationen andere Sicherheitsmaßnahmen implementieren können, um Benutzeranmeldeinformationen basierend auf Branchenentwicklungen wie "NIST Special Publication 800-63B" zu schützen.

• Beispiel-Beweisrichtlinien: Der Beweis für eine Richtlinie für sichere Kennwörter kann in Form eines Screenshots eines Gruppenrichtlinienobjekts einer Organisation oder einer lokalen Sicherheitsrichtlinie "Kontorichtlinien à Kennwortrichtlinie" und "Kontorichtlinien à Kontosperrungsrichtlinie" vorliegen. Die Beweise hängen von den verwendeten Technologien ab; Das heißt, für Linux könnte es sich um die Konfigurationsdatei /etc/pam.d/common-password, für BitBucket um den Abschnitt "Authentifizierungsrichtlinien" im Verwaltungsportal (https://support.atlassian.com/security-and-access-policies/docs/manage-your-password-policy/) usw. handeln.

• Beispielbeweis: Der folgende Beweis zeigt die Kennwortrichtlinie, die in der "Lokalen Sicherheitsrichtlinie" der bereichsinternen Systemkomponente "CLARANET-SBU-WM" konfiguriert wurde.

Der folgende Screenshot zeigt die Einstellungen für die Kontosperrung für eine WatchGuard-Firewall.

Im Folgenden finden Sie ein Beispiel für eine minimale Passphrasenlänge für die WatchGaurd-Firewall.

Steuerung 44: Stellen Sie nachweisbare Beweise bereit, dass eindeutige Benutzerkonten für alle Benutzer ausgestellt werden.

• Absicht: Die Absicht dieses Steuerelements ist die Verantwortlichkeit. Indem Benutzer ihre eigenen eindeutigen Benutzerkonten ausstellen, sind Benutzer für ihre Aktionen verantwortlich, da Benutzeraktivitäten für einen einzelnen Benutzer nachverfolgt werden können.

• Beispiel-Beweisrichtlinien: Der Beweis dafür wäre durch Screenshots, die konfigurierte Benutzerkonten in den systeminternen Komponenten zeigen, die Server, Coderepositorys, Cloudverwaltungsplattformen, Active Directory, Firewalls usw. umfassen können.

• Beispielbeweis: Der folgende Screenshot zeigt Benutzerkonten, die für die bereichsinterne Systemkomponente "CLARANET-SBU-WM" konfiguriert sind.

Der nächste Screenshot zeigt, dass das Administratorkonto für die bereichsinterne Systemkomponente "CLARANET-SBU-WM" deaktiviert ist.

Der nächste Screenshot zeigt, dass das Gastkonto für die bereichsinterne Systemkomponente "CLARANET-SBU-WM" deaktiviert ist.

Dieser nächste Screenshot zeigt, dass defaultAccount für die bereichsinterne Systemkomponente "CLARANET-SBU-WM" deaktiviert ist.

Steuerung 45: Stellen Sie nachweisbare Beweise dafür bereit, dass prinzipien der geringsten Rechte innerhalb der Umgebung befolgt werden.

• Absicht: Benutzern sollten nur die Berechtigungen zur Verfügung gestellt werden, die zur Erfüllung ihrer Aufgaben erforderlich sind. Dies soll das Risiko begrenzen, dass ein Benutzer absichtlich oder unbeabsichtigt auf Daten zugreift, die er nicht verwenden sollte, oder dass er eine böswillige Handlung ausführt. Durch die Anwendung dieses Prinzips wird auch die potenzielle Angriffsfläche (d. h. privilegierte Konten) reduziert, auf die eine böswillige Aktivitätsgruppe abzielen kann.

• Beispielrichtlinien für Nachweise: Die meisten Organisationen verwenden Gruppen, um Berechtigungen basierend auf Teams innerhalb der Organisation zuzuweisen. Ein Beweis könnten Screenshots sein, die die verschiedenen privilegierten Gruppen und nur Benutzerkonten aus den Teams zeigen, die diese Berechtigungen benötigen. In der Regel wird dies mit unterstützenden Richtlinien/Prozessen gesichert, die jede definierte Gruppe mit den erforderlichen Berechtigungen und geschäftlichen Begründungen definieren, und eine Hierarchie von Teammitgliedern, um zu überprüfen, ob die Gruppenmitgliedschaft ordnungsgemäß konfiguriert ist.

• Beispiel: Innerhalb von Azure sollte die Gruppe Besitzer eingeschränkt sein, daher sollte dies dokumentiert werden und dieser Gruppe eine begrenzte Anzahl von Personen zugewiesen sein. Ein weiteres Beispiel wäre eine begrenzte Anzahl von Mitarbeitern mit der Möglichkeit, Codeänderungen vorzunehmen. Eine Gruppe kann mit dieser Berechtigung mit den Mitarbeitern eingerichtet werden, die diese Berechtigung benötigen. Dies sollte dokumentiert werden, damit der Zertifizierungsanalyst auf das Dokument mit den konfigurierten Gruppen usw. verweisen kann.

• Beispielbeweis: Der folgende Screenshot zeigt, dass die Umgebung mit Gruppen konfiguriert ist, die gemäß der Auftragsfunktion zugewiesen werden.

Der folgende Screenshot zeigt, dass Benutzer basierend auf ihrer Auftragsfunktion Gruppen zugeordnet werden.

Steuerung 46: Stellen Sie nachweisbare Beweise bereit, dass ein Prozess zum Sichern oder Absichern von Dienstkonten vorhanden ist und der Prozess befolgt wird.

• Absicht: Dienstkonten werden häufig von Aktivitätsgruppen bestimmt, da sie häufig mit erhöhten Berechtigungen konfiguriert sind. Diese Konten folgen möglicherweise nicht den Standardkennwortrichtlinien, da der Ablauf von Dienstkontokennwörtern häufig die Funktionalität beeinträchtigt. Daher können sie mit schwachen Kennwörtern oder Kennwörtern konfiguriert werden, die innerhalb der Organisation wiederverwendet werden. Ein weiteres potenzielles Problem, insbesondere in einer Windows-Umgebung, kann sein, dass das Betriebssystem den Kennworthash zwischenspeichert. Dies kann ein großes Problem sein, wenn entweder das Dienstkonto innerhalb eines Verzeichnisdiensts konfiguriert ist. Da dieses Konto auf mehreren Systemen mit konfigurierten Berechtigungen verwendet werden kann, oder wenn das Dienstkonto lokal ist, besteht die Wahrscheinlichkeit, dass dasselbe Konto/Kennwort auf mehreren Systemen innerhalb der Umgebung verwendet wird. Die oben genannten Probleme können dazu führen, dass eine Aktivitätsgruppe Zugriff auf mehr Systeme innerhalb der Umgebung erhält, und zu einer weiteren Erhöhung der Berechtigungen und/oder lateralen Verschiebungen führen. Die Absicht besteht daher darin, sicherzustellen, dass Dienstkonten ordnungsgemäß gehärtet und gesichert sind, um sie vor der Übernahme durch eine Aktivitätsgruppe zu schützen, oder indem das Risiko begrenzt wird, wenn eines dieser Dienstkonten kompromittiert wird.

• Beispielrichtlinien für Nachweise: Es gibt viele Anleitungen im Internet, um Dienstkonten zu härten. Der Beweis kann in Form von Screenshots vorliegen, die zeigen, wie die Organisation eine sichere Härtung des Kontos implementiert hat. Einige Beispiele (es wird davon ausgegangen, dass mehrere Techniken verwendet werden) umfassen:

• Beschränken der Konten auf eine Gruppe von Computern in Active Directory,

• Festlegen des Kontos, sodass die interaktive Anmeldung nicht zulässig ist,

• Festlegen eines äußerst komplexen Kennworts,

• Aktivieren Sie für Active Directory das Flag "Konto ist vertraulich und kann nicht delegiert werden". Diese Techniken werden im folgenden Artikel "Segmentation and Shared Active Directory for a Cardholder Data Environment" (Segmentierung und freigegebenes Active Directory für eine Karteninhaberdatenumgebung) erläutert.

• Beispielbeweis: Es gibt mehrere Möglichkeiten zum Härten eines Dienstkontos, die von jeder einzelnen Umgebung abhängig sind. Die für Ihre Umgebung geeigneten Mechanismen, die verwendet werden, werden weiter oben im Dokument "Richtlinie/Verfahren für die Kontoverwaltung" dokumentiert, um diese Beweise zu überprüfen. Im Folgenden finden Sie einige der Mechanismen, die verwendet werden können:

Der folgende Screenshot zeigt, dass die Option "Konto ist vertraulich und verbindung delegiert" für das Dienstkonto "_Prod SQL-Dienstkonto" ausgewählt ist.

Der nächste Screenshot zeigt, dass das Dienstkonto "_Prod SQL-Dienstkonto" für SQL Server gesperrt ist und sich nur bei diesem Server anmelden kann.

Der nächste Screenshot zeigt, dass das Dienstkonto "_Prod SQL-Dienstkonto" nur als Dienst angemeldet werden darf.

Steuerung 47: Stellen Sie nachweisbare Beweise dafür bereit, dass MFA für alle Remotezugriffsverbindungen und alle Verwaltungsschnittstellen ohne Konsole konfiguriert ist.

Begriffe, die wie folgt definiert sind:

• Remotezugriff : In der Regel bezieht sich dies auf Technologien, die für den Zugriff auf die unterstützende Umgebung verwendet werden. Beispiel: REMOTE Access IPSec VPN, SSL VPN oder Jumpbox/Bastian Host.

• Verwaltungsschnittstellen ohne Konsole : Dies bezieht sich in der Regel auf Netzwerkadministratorverbindungen mit Systemkomponenten. Dies kann über Remotedesktop, SSH oder eine Webschnittstelle erfolgen.

• Absicht: Die Absicht dieses Steuerelements besteht darin, Gegenmaßnahmen gegen Brute-Erzwingung privilegierter Konten und Konten mit sicherem Zugriff auf die Umgebung bereitzustellen. Durch die Bereitstellung der mehrstufigen Authentifizierung (Multi-Factor Authentication, MFA) sollte ein kompromittiertes Kennwort weiterhin vor einer erfolgreichen Anmeldung geschützt werden, da der MFA-Mechanismus weiterhin geschützt werden sollte. Dadurch wird sichergestellt, dass alle Zugriffs- und Verwaltungsaktionen nur von autorisierten und vertrauenswürdigen Mitarbeitern durchgeführt werden.

• Beispielbeweisrichtlinien: Beweise müssen zeigen, dass MFA für alle Technologien aktiviert ist, die in die oben genannten Kategorien passen. Dies kann ein Screenshot sein, der zeigt, dass MFA auf Systemebene aktiviert ist. Auf Systemebene benötigen wir Einen Nachweis, dass es für alle Benutzer aktiviert ist, und nicht nur ein Beispiel für ein Konto mit aktivierter MFA. Wenn die Technologie auf eine MFA-Lösung zurückgesichert wird, benötigen wir den Nachweis, dass sie aktiviert und verwendet wird. Was damit gemeint ist, ist; Wenn die Technologie für die Radius-Authentifizierung eingerichtet ist, die auf einen MFA-Anbieter verweist, müssen Sie auch nachweisen, dass der Radius-Server, auf den sie verweist, eine MFA-Lösung ist und dass Konten für die Verwendung konfiguriert sind.

• Beispielbeweis 1: Die folgenden Screenshots zeigen die in Pulse Secure konfigurierten Authentifizierungsbereiche, die für den Remotezugriff auf die Umgebung verwendet werden. Die Authentifizierung wird vom Duo SaaS Service for MFA-Support gesichert.

Dieser Screenshot zeigt, dass ein zusätzlicher Authentifizierungsserver aktiviert ist, der auf "Duo-LDAP" für den Authentifizierungsbereich "Duo - Standardroute" verweist.

Dieser letzte Screenshot zeigt die Konfiguration für den Duo-LDAP-Authentifizierungsserver, der zeigt, dass dieser auf den Duo SaaS-Dienst für MFA verweist.

Beispielbeweis 2: Die folgenden Screenshots zeigen, dass für alle Azure-Benutzer MFA aktiviert ist.

Hinweis: Sie müssen Beweise für alle Verbindungen bereitstellen, die keine Konsolenverbindungen sind, um zu zeigen, dass MFA für sie aktiviert ist. Beispielsweise, wenn Sie RDP oder SSH mit Servern oder anderen Systemkomponenten (d. b. Firewalls) herstellen.

Steuerung 48: Stellen Sie nachweisbare Beweise dafür bereit, dass die starke Verschlüsselung für alle Remotezugriffsverbindungen und alle Verwaltungsschnittstellen ohne Konsole konfiguriert ist, einschließlich des Zugriffs auf Coderepositorys und Cloudverwaltungsschnittstellen.

Begriffe, die wie folgt definiert sind:

• Coderepositorys : Die Codebasis der App muss vor böswilligen Änderungen geschützt werden, die Schadsoftware in die App einführen könnten. MFA muss im Coderepository konfiguriert werden.

• Cloudverwaltungsschnittstellen : Wo eine oder die gesamte Umgebung innerhalb des Clouddienstanbieters (Cloud Service Provider, CSP) gehostet wird, ist hier die Verwaltungsschnittstelle für die Cloudverwaltung enthalten.

• Absicht: Mit dieser Kontrolle soll sichergestellt werden, dass der gesamte administrative Datenverkehr entsprechend verschlüsselt ist, um sich vor Man-in-the-Middle-Angriffen zu schützen.

• Beispielrichtlinien für Nachweise: Der Beweis könnte durch Screenshots bereitgestellt werden, die Verschlüsselungseinstellungen für Remotezugriffstechnologien, RDP, SSH und Webadministratorschnittstellen zeigen. Für Webadministratorschnittstellen kann qualys SSL Labs-Scanner (sofern öffentlich zugänglich, d. h. Cloudverwaltungsschnittstellen, SaaS-Coderepositorys oder SSL-VPN-Verbindungen) verwendet werden.

• Beispielbeweis: Der folgende Beweis zeigt, dass die RDP-Verschlüsselungsstufe für "Webserver01" mit der Einstellung "High Level" konfiguriert ist. Wie der Hilfetext zeigt, wird hierbei eine starke 128-Bit-Verschlüsselung verwendet (die höchste Stufe für Microsoft Windows RDP.

Der folgende Beweis zeigt auch, dass die RDP-Transportsicherheit für die Verwendung von TLS 1.0 auf "Webserver01" (die höchste für Windows Server) konfiguriert ist.

Steuerung 49: Stellen Sie nachweisbare Beweise dafür bereit, dass MFA zum Schutz des Verwaltungsportals verwendet wird, das Sie zum Verwalten und Verwalten aller DNS-Einträge (Public Domain Name Service) verwenden.

• Absicht: Wenn eine böswillige Aktivitätsgruppe Zugriff auf öffentliche DNS-Einträge erhalten kann, besteht das Risiko, dass sie die von der App verwendeten URLs ändern kann, oder dass die Manifestdatei darauf verweist, schädlichen Code einzuführen oder Den Benutzerdatenverkehr an einen Endpunkt unter der Kontrolle der Akteure weiterzuleiten. Dies kann zu einem Verlust von Benutzerdaten oder zu Schadsoftware-/Ransomware-Infektionen in der gesamten Benutzerbasis der App führen.

• Beispielrichtlinien für Nachweise: Stellen Sie Beweise bereit, die zeigen, dass öffentliche DNS-Verwaltungsportale durch MFA geschützt sind. Selbst wenn öffentliches DNS auf Servern innerhalb der Bereichsumgebung gehostet wird (d. h. steuern und von der Organisation betrieben wird), gibt es möglicherweise immer noch ein Verwaltungsportal an einem Ort, an dem der Domänenname registriert wurde, und die DNS-Einträge wurden verwaltet, um die DNS-Server auf Ihre eigene Infrastruktur zu verweisen. Wenn dies der Fall ist, sollte MFA auf der Verwaltungsschnittstelle der Domänenregistrierungsstelle aktiviert werden, wenn die DNS-Einträge der Domänen geändert werden können. Es sollte ein Screenshot bereitgestellt werden, der zeigt, dass die Verwaltungsschnittstelle für MFA auf Systemebene aktiviert ist (d. b. alle privilegierten Konten).

• Beispielbeweis: Der folgende Screenshot zeigt die contoso.com DNS in Microsoft Azure für Contoso Corporation verwaltet wird.

Anmerkung: Bei den IP-Adressen handelt es sich um private RFC 1918-Adressen, die nicht öffentlich weitergeleitet werden. Dies dient nur zu Demonstrationszwecken.

Die folgenden Screenshots zeigen, dass für alle Azure-Benutzer MFA aktiviert ist.

Angriffserkennung und -verhinderung (optional)

Intrusion Detection and Prevention Systems (IDPS) am Gateway können eine zusätzliche Schutzebene vor einer Vielzahl von internetbasierten und internen Bedrohungen bieten. Diese Systeme können dazu beitragen, zu verhindern, dass diese Bedrohungen erfolgreich sind, und können wichtige Warnungsfunktionen bereitstellen, um Organisationen bei Live-Kompromittierungsversuchen zu warnen, damit Organisationen zusätzliche Defensivesstrategien implementieren können, um die Umgebung vor diesen aktiven Bedrohungen weiter zu schützen.

Dieser Abschnitt dient als zusätzliche Gutschrift und ist daher optional. Dies ist keine Voraussetzung, aber wenn Sie die Bewertung abschließen, wird ein umfassenderes Bild Ihrer Umgebung und der von Ihnen eingerichteten Kontrollen und Standards angezeigt.

Steuerung 50: Stellen Sie nachweisbare Beweise dafür bereit, dass Intrusion Detection and Prevention Systems (IDPS) im Umkreis der bereichsinternen Umgebungen bereitgestellt werden.

• Absicht: Obwohl einige Quellen Insider-Bedrohungen so beschreiben, dass sie die Bedrohungen durch externe Aktivitätsgruppen jetzt übertreffen, beinhalten Insider-Bedrohungen auch Fahrlässigkeit, wobei menschliche Fehler im Prozentsatz von Jahr zu Jahr zunimmt. Die Installation von IDPS im Umkreis der umgebungsinternen Umgebung(en) besteht darin, dass externe Bedrohungen aufgrund der Art und der Techniken, die von diesen Bedrohungstypen verwendet werden, häufig über IDPS-Mechanismen erkannt werden können.

• Beispielrichtlinien für Nachweise: Es sollten Nachweise bereitgestellt werden, die zeigen, dass IDPS im Umkreis installiert ist. Dies kann sich direkt in der Firewall befinden, wenn eine NextGen-Firewall ausgeführt wird, oder durch bereitstellungs-IDPS-Sensoren, die an Spiegelungsswitchports konfiguriert sind, um sicherzustellen, dass der gesamte Datenverkehr von den bereitgestellten Sensoren erkannt wird. Wenn IDPS-Sensoren verwendet werden, müssen möglicherweise zusätzliche Beweise bereitgestellt werden, um zu zeigen, dass die Sensoren in der Lage sind, alle externen Datenverkehrsflüsse zu sehen.

• Beispielbeweis: Der folgende Screenshot zeigt, dass die IDPS-Funktionalität in der WatchGuard Firewall aktiviert ist.

Der folgende zusätzliche Screenshot zeigt, dass IDPS für alle Regeln in der Konfiguration der WatchGuard Firewall aktiviert ist.

Steuerung 51: Stellen Sie nachweisbare Beweise dafür bereit, dass IDPS-Signaturen (innerhalb von 24 Stunden) auf dem neuesten Stand gehalten werden.

• Absicht: Es gibt mehrere Betriebsmodi für IDPS. Die häufigste ist die Verwendung von Signaturen zum Identifizieren des Angriffsdatenverkehrs. Wenn Angriffe weiterentwickelt und neuere Sicherheitsrisiken erkannt werden, ist es wichtig, dass IDPS-Signaturen auf dem neuesten Stand sind, um angemessenen Schutz zu bieten. Mit diesem Steuerelement soll sichergestellt werden, dass IDPS beibehalten werden.

• Beispielbeweisrichtlinien: Der Beweis wird wahrscheinlich mit einem Screenshot angezeigt, der zeigt, dass der IDPS so konfiguriert ist, dass Signaturen mindestens täglich aktualisiert werden und das letzte Update angezeigt wird.

• Beispielbeweis: Obwohl dieser Screenshot nicht zeigt, dass die IDPS-Signaturen innerhalb der letzten 24 Stunden aktualisiert wurden, zeigt er, dass die neueste Version installiert ist, die vor einer Woche liegt (Beweise, die am 18__th Mai gesammelt wurden). Dies zeigt in Kombination mit dem folgenden Screenshot, dass Signaturen innerhalb eines Zeitraums von 24 Stunden auf dem neuesten Stand sind.

Steuerung 52: Stellen Sie einen nachweisbaren Beweis dafür bereit, dass IDPS so konfiguriert ist, dass die TLS-Überprüfung des gesamten eingehenden Webdatenverkehrs unterstützt wird.

• Absicht: Da IDPS auf Signaturen angewiesen ist, muss es in der Lage sein, alle Datenverkehrsflüsse zu überprüfen, um den Angriffsdatenverkehr zu identifizieren. TLS-Datenverkehr ist verschlüsselt, sodass IDPS den Datenverkehr nicht ordnungsgemäß überprüfen können. Dies ist wichtig für HTTPS-Datenverkehr, da es eine Vielzahl von Bedrohungen gibt, die für Webdienste üblich sind. Mit diesem Steuerelement soll sichergestellt werden, dass verschlüsselte Datenverkehrsflüsse auch auf IDPS überprüft werden können.

• Beispielrichtlinien für Nachweise: Der Nachweis sollte anhand von Screenshots bereitgestellt werden, die zeigen, dass verschlüsselter TLS-Datenverkehr auch von der IDPS-Lösung überprüft wird.

• Beispielbeweis: Dieser Screenshot zeigt die HTTPS-Regeln in der Firewall.

Dieser nächste Screenshot zeigt, dass IDPS für diese Regeln aktiviert ist.

Der folgende Screenshot zeigt, dass eine "Proxyaktion" auf die Regel "Inbound_Bot_Traffic" angewendet wird, die zum Aktivieren der Inhaltsüberprüfung verwendet wird.

Der folgende Screenshot zeigt, dass die Inhaltsuntersuchung aktiviert ist.

Steuerung 53: Stellen Sie nachweisbare Beweise dafür bereit, dass IDPS für die Überwachung aller eingehenden Datenverkehrsflüsse konfiguriert ist.

• Absicht: Wie bereits erwähnt, ist es wichtig, dass alle eingehenden Datenverkehrsflüsse von IDPS überwacht werden, um jede Form von Angriffsdatenverkehr zu identifizieren.

• Beispielrichtlinien für Nachweise: Anhand von Screenshots sollte nachgewiesen werden, dass alle eingehenden Datenverkehrsflüsse überwacht werden. Dies kann die NextGen-Firewall sein, die anzeigt, dass alle eingehenden Regeln für IDPS aktiviert sind, oder die Verwendung von IDPS-Sensoren und der Veranschaulichung, dass der gesamte Datenverkehr für den IDPS-Sensor konfiguriert ist.

• Beispielbeweis: Dieser Screenshot zeigt, dass IDPS für alle Regeln (Richtlinien) der WatchGuard Firewall konfiguriert ist.

Steuerung 54: Stellen Sie nachweisbare Beweise dafür bereit, dass IDPS für die Überwachung aller ausgehenden Datenverkehrsflüsse konfiguriert ist.

• Absicht: Wie bereits erwähnt, ist es wichtig, dass alle ausgehenden Datenverkehrsflüsse von IDPS überwacht werden, um jede Form von Angriffsdatenverkehr zu identifizieren. Einige IDPS-Systeme können auch potenzielle interne Sicherheitsverletzungen identifizieren, indem sie den gesamten ausgehenden Datenverkehr überwachen. Dies kann durch Identifizieren des Datenverkehrs erfolgen, der für Befehls- und Steuerungsendpunkte bestimmt ist.

• Beispielrichtlinien für Nachweise: Anhand von Screenshots sollte nachgewiesen werden, dass alle ausgehenden Datenverkehrsflüsse überwacht werden. Dies kann die NextGen-Firewall sein, die anzeigt, dass alle ausgehenden Regeln für IDPS aktiviert sind, oder die Verwendung von IDPS-Sensoren und der Veranschaulichung, dass der gesamte Datenverkehr so konfiguriert ist, dass er den IDPS-Sensor erreicht.

• Beispielbeweis: Dieser Screenshot zeigt, dass IDPS für alle Regeln (Richtlinien) der WatchGuard Firewall konfiguriert ist.

• Beispielbeweis 2: Azure bietet IDPS über Drittanbieter-Apps an. Im folgenden Beispiel wurde die Netwatcher-Paketerfassung zum Erfassen von Paketen verwendet und zusammen mit Suricata verwendet, einem Open-Source IDS-Tool.

Durch die Kombination der von Network Watcher bereitgestellten Paketerfassung und Open-Source-IDS-Tools wie Suricata können Sie die Erkennung von Netzwerkangriffen für eine Vielzahl von Bedrohungen durchführen. Die folgende Abbildung zeigt die Suricata-Schnittstelle.

Signaturen werden verwendet, um Warnungen auszulösen, die problemlos installiert und aktualisiert werden können. Die folgende Abbildung zeigt eine Momentaufnahme einiger Signaturen.

Die folgende Abbildung zeigt, wie Sie Ihre IDPS-Einrichtung von Netwatcher- und Suricata-Drittanbietersoftware mithilfe von Sentinel SIEM/SOAR überwachen würden.

• Beispielbeweis 3: Die folgende Abbildung zeigt, wie Sie eine Außerkraftsetzungs-Angriffssignatur oder eine Umgehungsregel für die Angriffserkennung mithilfe der CLI hinzufügen.

Die folgende Abbildung zeigt, wie Sie die gesamte Konfiguration der Angriffserkennung mithilfe der CLI auflisten.

• Beispielbeweis 4: Azure hat kürzlich damit begonnen, IDPS mit dem Namen Azure Firewall Premium anzubieten, die die Konfiguration von TLS, Threat Intelligence und IDPS über Richtlinien ermöglichen. Beachten Sie jedoch, dass Sie weiterhin Front Door oder Application Gateway für die SSL-Auslagerung eingehenden Datenverkehrs verwenden müssen, da Azure Firewall Premium IDPS für eingehende SSL-Verbindungen nicht unterstützt.

Im folgenden Beispiel wurden die Premium-Standardeinstellungen für die Konfiguration von Richtlinienregeln und TLS-Überprüfung, IDPS-Modus und Threat Intelligence zusammen mit dem Schutz des VNET aktiviert.

Protokollierung von Sicherheitsereignissen

Die Protokollierung von Sicherheitsereignissen ist ein integraler Bestandteil des Sicherheitsprogramms einer Organisation. Eine angemessene Protokollierung von Sicherheitsereignissen in Verbindung mit optimierten Warnungs- und Überprüfungsprozessen hilft Organisationen dabei, Sicherheitsverletzungen oder versuchte Sicherheitsverletzungen zu identifizieren, die von der Organisation verwendet werden können, um Die Sicherheit und defensive Sicherheitsstrategien zu verbessern. Darüber hinaus ist eine angemessene Protokollierung von entscheidender Bedeutung für die Reaktion auf Vorfälle in Organisationen, die in andere Aktivitäten einfließen können, z. B. in der Lage zu sein, genau zu identifizieren, welche daten kompromittiert wurden, den Zeitraum der Kompromittierung, die Bereitstellung detaillierter Analyseberichte für Regierungsbehörden usw.

Steuerung 55: Stellen Sie Richtliniendokumentation für bewährte Methoden und Verfahren bereit, die die Protokollierung von Sicherheitsereignissen regeln.

• Absicht: Die Protokollierung von Sicherheitsereignissen ist eine wichtige Funktion des Sicherheitsprogramms jeder Organisation. Richtlinien und Verfahren müssen eingerichtet werden, um Klarheit und Konsistenz zu schaffen, um sicherzustellen, dass Organisationen Protokollierungskontrollen im Einklang mit den empfohlenen Methoden des Anbieters und der Branche implementieren. Auf diese Weise wird sichergestellt, dass relevante und detaillierte Protokolle verwendet werden, die nicht nur bei der Identifizierung potenzieller oder tatsächlicher Sicherheitsereignisse nützlich sind, sondern auch einer Reaktion auf Vorfälle helfen können, das Ausmaß einer Sicherheitsverletzung zu identifizieren.

• Beispiel-Beweisrichtlinien: Stellen Sie den Organisationen dokumentierte Richtlinien- und Prozedurdokumente zur bewährten Methode zur Protokollierung von Sicherheitsereignissen zur Verfügung.

• Beispielbeweis: Im Folgenden finden Sie einen Auszug aus der Protokollierungsrichtlinie/-prozedur.

Anmerkung: Dieser Screenshot zeigt ein Richtlinien-/Prozessdokument. Es wird erwartet, dass ISVs die tatsächliche unterstützende Richtlinien-/Verfahrensdokumentation freigeben und nicht einfach einen Screenshot bereitstellen.

Steuerung 56: Stellen Sie nachweisbare Beweise bereit, die zeigen, dass die Protokollierung von Sicherheitsereignissen für alle erfassten Systemkomponenten eingerichtet ist, um die folgenden Ereignisse zu protokollieren:

• Benutzerzugriff auf Systemkomponenten und die Anwendung

• Alle Aktionen, die von einem Benutzer mit hohen Berechtigungen ausgeführt werden

• Ungültige logische Zugriffsversuche

• Erstellen oder Ändern privilegierter Konten

• Manipulation des Ereignisprotokolls

• Deaktivieren von Sicherheitstools, z. B. Antischadsoftware oder Ereignisprotokollierung

• Antischadsoftwareprotokollierung, z. B. Updates, Schadsoftwareerkennung und Überprüfungsfehler

• IDPS- und WAF-Ereignisse, falls konfiguriert

• Absicht: Um versuchte und tatsächliche Sicherheitsverletzungen zu identifizieren, ist es wichtig, dass von allen Systemen, aus denen die Umgebung besteht, angemessene Sicherheitsereignisprotokolle gesammelt werden. Mit diesem Steuerelement soll sichergestellt werden, dass die richtigen Arten von Sicherheitsereignissen erfasst werden, die dann in Überprüfungs- und Warnungsprozesse einfließen können, um diese Ereignisse zu identifizieren und darauf zu reagieren.

• Beispielbeweisrichtlinien: Der Nachweis anhand von Screenshots oder Konfigurationseinstellungen sollte für alle erfassten Geräte und alle relevanten Systemkomponenten bereitgestellt werden, um zu veranschaulichen, wie die Protokollierung so konfiguriert ist, dass gewährleistet ist, dass diese Arten von Sicherheitsereignissen erfasst werden.

• Beispielbeweis 1: Der folgende Screenshot zeigt die Konfigurationseinstellungen eines der erfassten Geräte namens "VICTIM1-WINDOWS". Die Einstellungen zeigen verschiedene Überwachungseinstellungen an, die in den Einstellungen "Lokale Sicherheitsrichtlinie  Lokale Richtlinien  Überwachungsrichtlinie" aktiviert sind.

Der nächste Screenshot zeigt ein Ereignis, bei dem ein Benutzer ein Ereignisprotokoll von einem der erfassten Geräte mit dem Namen "VICTIM1-WINDOWS" gelöscht hat.

Dieser letzte Screenshot zeigt die Protokollmeldung, die in der zentralen Protokollierungslösung angezeigt wird.

Hinweis: Screenshots sind für alle erfassten Systemkomponenten erforderlich undmüssen alle oben beschriebenen Sicherheitsereignisse belegen.

Steuerung 57: Stellen Sie nachweisbare Beweise bereit, dass protokollierte Sicherheitsereignisse die folgenden Mindestinformationen enthalten:

• Benutzer

• Ereignistyp

• Datum und Uhrzeit

• Erfolgs- oder Fehlerindikatoren

• Bezeichnung, die das betroffene System identifiziert

• Absicht: Protokollierte Sicherheitsereignisse müssen genügend Informationen bereitstellen, um festzustellen, ob der Angriffsdatenverkehr erfolgreich war, auf welche Informationen zugegriffen wurde, auf welcher Ebene, wer verantwortlich war, wo er stammt usw.

• Beispielrichtlinien für Nachweise: Beweise sollten Beispiele von Protokollen aus allen Systemkomponenten mit diesen Arten von Sicherheitsereignissen enthalten. Die Protokolle sollten alle oben aufgeführten Informationen enthalten.

• Beispielbeweis: Der folgende Screenshot zeigt die Informationen aus den Sicherheitsereignissen in der Windows-Ereignisanzeige aus der bereichsinternen Systemkomponente "SEGSVR02".

Hinweis: Screenshots sind für alle erfassten Systemkomponenten erforderlich und müssen alle sicherheitsrelevanten Ereignisse belegen, die im obigen Steuerelement beschrieben sind. Es ist wahrscheinlich, dass die für das obige Steuerelement gesammelten Beweise auch dieses Steuerelement erfüllen und angemessene Details der Protokollierungsinformationen bereitstellen.

Steuerung 58: Stellen Sie nachweisbare Beweise dafür bereit, dass alle erfassten Systemkomponenten mit denselben primären und sekundären Servern zeitsynchronisiert sind.

• Absicht: Eine wichtige Komponente der Protokollierung besteht darin, sicherzustellen, dass Protokolle auf allen Systemen über Systemuhren verfügen, die alle synchronisiert sind. Dies ist wichtig, wenn eine Untersuchung erforderlich ist, um eine Kompromittierung und/oder Datenverletzung nachzuverfolgen. Das Nachverfolgen der Ereignisse über verschiedene Systeme kann nahezu unmöglich werden, wenn die Protokolle unterschiedliche Zeitstempel aufweisen, da wichtige Protokolle möglicherweise übersehen werden und es schwierig ist, sie nachzuverfolgen.

• Beispielbeweisrichtlinien: Idealerweise sollte eine Zeitsynchronisierungstopologie beibehalten werden, die zeigt, wie die Zeit im gesamten Bestand synchronisiert wird. Der Nachweis kann dann mithilfe von Screenshots der Zeitsynchronisierungseinstellungen für die erfassten Systemkomponenten bereitgestellt werden. Dies sollte zeigen, dass die gesamte Zeitsynchronisierung mit demselben primären Server (oder, falls vorhanden) sekundären Server erfolgt.

• Beispielbeweis: Dieses Diagramm zeigt die verwendete Zeitsynchronisierungstopologie.

Der nächste Screenshot zeigt die WatchGuard-Instanz, die als NTP-Server konfiguriert ist und auf time.windows.com als Zeitquelle verweist.

Dieser letzte Screenshot zeigt die bereichsinterne Systemkomponente "CLARANET-SBU-WM", die für NTP konfiguriert ist, um auf den primären Server zu verweisen, der WatchGuard Firewall (10.0.1.1).

Steuerung 59: Stellen Sie nachweisbare Beweise bereit, wenn öffentliche Systeme verwendet werden, dass Sicherheitsereignisprotokolle an eine zentralisierte Protokollierungslösung gesendet werden, die sich nicht innerhalb des Umkreisnetzwerks befindet.

• Absicht: Die Absicht dieses Steuerelements besteht darin, eine logische oder physische Trennung zwischen der DMZ und dem Protokollierungsendpunkt sicherzustellen. Da die DMZ öffentlich zugänglich ist, ist dies für externe Aktivitätsgruppen verfügbar und daher einem größeren Risiko ausgesetzt als andere Komponenten innerhalb der Umgebung. Wenn eine DMZ-Komponente kompromittiert wird, muss die Integrität der Protokollierungsdaten aufrechterhalten werden, um nicht nur zu verhindern, dass die Aktivitätsgruppe die Protokolle manipuliert, um die Kompromittierung zu verbergen, sondern auch, um bei forensischen Untersuchungen zu helfen, die möglicherweise erforderlich sind. Durch die Protokollierung bei Systemen außerhalb der DMZ sollten Sicherheitskontrollen, die zum Einschränken des Datenverkehrs von der DMZ zu diesen Sicherheitssystemen verwendet werden, dazu beitragen, sie vor böswilligen Aktivitäten und Manipulationsversuchen zu schützen.

• Beispielrichtlinien für Nachweise: Der Nachweis sollte mit Screenshots oder Konfigurationseinstellungen bereitgestellt werden, die zeigen, dass Protokolle so konfiguriert sind, dass sie sofort (oder unmittelbar nahe) an eine zentralisierte Protokollierungslösung gesendet werden, die sich außerhalb der DMZ befindet. Wir suchen nach fast sofortigem Versand von Protokollen, denn je länger es dauert, bis Protokolle an die zentralisierte Protokollierungslösung gesendet werden, desto mehr Zeit hätte ein Behandeln-Akteur, um die lokalen Protokolle vor dem Versand zu manipulieren.

• Beispielbeweis: Die Contoso DMZ-Systeme verwenden NXLog für den Versand von Protokolldateien. Der folgende Screenshot zeigt den Dienst "nxlog", der auf der DMZ-Jumpbox "DESKTOP-7S65PN" ausgeführt wird, die zum Verwalten aller DMZ-Server verwendet wird.

Der folgende Screenshot zeigt einen Extrakt aus der Datei nxlog.conf, der zeigt, dass das Ziel ein interner Protokollsammler innerhalb des Anwendungssubnetzes unter 10.0.1.250 ist, der für den Versand an AlienVault verwendet wird.

Die folgende URL für NXLog (https://nxlog.co/documentation/nxlog-user-guide/modes.html) zeigt, dass der Protokollversand durch den folgenden Extrakt in Echtzeit erfolgt:

Steuerung 60: Stellen Sie nachweisbare Beweise bereit, die zeigen, dass die zentralisierte Protokollierungslösung vor unbefugter Manipulation von Protokollierungsdaten geschützt ist.

• Absicht: Obwohl zwischen Protokollierungsgeräten und der zentralisierten Protokollierungslösung häufig eine logische/physische Trennung besteht, besteht immer noch das Risiko, dass jemand versucht, die Protokolle zu manipulieren, um seine Aktivitäten zu verbergen. Mit diesem Steuerelement soll sichergestellt werden, dass geeignete Autorisierungsmechanismen vorhanden sind, um die Anzahl der Benutzer zu begrenzen, die administrative Aktionen für die zentralisierte Protokollierungslösung ausführen können.

• Beispielrichtlinien für Nachweise: Der Beweis dafür wäre in der Regel mit Screenshots, die die Autorisierungs- und Authentifizierungskonfiguration der zentralisierten Protokollierungslösung zeigen, die zeigen, dass Benutzer auf diejenigen beschränkt sind, die für ihre Rolle/Funktion erforderlich sind.

• Beispielbeweis: Das ausgelagerte SOC von Contoso verwendet AlienVault als zentralisierte SIEM-Tools. AlienVault wurde 2018 von AT&T aufgekauft und geht jetzt von USM Anywhere. Auf der folgenden Webseite (https://cybersecurity.att.com/documentation/usm-anywhere/deployment-guide/admin/usm-anywhere-data-security.htm) wird erläutert, wie USM Anywhere die Daten vor unbefugter Manipulation schützt. Der folgende Link (https://cybersecurity.att.com/documentation/usm-appliance/raw-logs/raw-log-management.htm) zeigt, wie das USM Anywhere-Produkt auch die Integrität archivierter Protokolle sicherstellt.

Anmerkung: Wenn das SIEM intern ist, müssen Nachweise bereitgestellt werden, um zu zeigen, dass der Zugriff auf die Protokollierungsdaten auf eine ausgewählte Anzahl von Benutzern basierend auf ihrem Auftragsbedarf beschränkt ist und dass die Plattform selbst vor Manipulationen geschützt ist (die meisten Lösungen integrieren dies in die Funktionalität der Protokollierungslösung).

Steuerung 61: Stellen Sie nachweisbare Beweise dafür bereit, dass daten zur Protokollierung von Sicherheitsereignissen für mindestens 30 Tage sofort verfügbar sind, wobei 90 Tage lang Sicherheitsereignisprotokolle aufbewahrt werden.

• Absicht: Manchmal gibt es einen Zeitlichen Unterschied zwischen einem Kompromittierungs- oder Sicherheitsereignis und einer Organisation, die es identifiziert. Mit diesem Steuerelement soll sichergestellt werden, dass die Organisation Zugriff auf historische Ereignisdaten hat, um die Reaktion auf Vorfälle und forensische Untersuchungen zu unterstützen, die möglicherweise erforderlich sind.

• Beispielbeweisrichtlinien: Der Beweis liegt in der Regel darin, dass die Konfigurationseinstellungen der zentralen Protokollierungslösung zeigen, wie lange Die Daten aufbewahrt werden. Daten zur Protokollierung von Sicherheitsereignissen im Wert von 30 Tagen müssen innerhalb der Lösung sofort verfügbar sein. Wenn Daten jedoch archiviert werden, muss dies nachweisen, dass 90 Tage im Wert von 90 Tagen verfügbar sind. Dies kann sein, indem Archivordner mit Datumsangaben der exportierten Daten angezeigt werden.

• Beispielbeweis 1: Die folgenden Screenshots zeigen, dass Protokolle im Wert von 30 Tagen in AlienVault verfügbar sind.

Hinweis: Da es sich um ein öffentlich zugängliches Dokument handelt, wurde die Seriennummer der Firewall bearbeitet. IsVs sollten jedoch keine bearbeiteten Screenshots unterstützen, es sei denn, es enthält personenbezogene Informationen.

Dieser nächste Screenshot zeigt, dass Protokolle verfügbar sind, indem ein Protokollextrakt angezeigt wird, der 5 Monate zurückgeht.

Hinweis: Da es sich um ein öffentlich zugängliches Dokument handelt, wurden die öffentlichen IP-Adressen bearbeitet. IsVs sollten jedoch keine bearbeiteten Screenshots unterstützen, es sei denn, es enthält personenbezogene Informationen.

• Beispielbeweis 2: Der folgende Screenshot zeigt, dass Protokollereignisse 30 Tage lang live verfügbar und 90 Tage in Cold Storage in Azure aufbewahrt werden.

Sicherheitsereignisprotokollüberprüfung

Das Überprüfen von Sicherheitsprotokollen ist eine wichtige Funktion, um Organisationen bei der Identifizierung von Sicherheitsereignissen zu unterstützen, die auf eine Sicherheitsverletzung oder Reconnaissance-Aktivitäten hindeuten können, die ein Hinweis auf eine bevorstehende Aktion sein können. Dies kann entweder über einen manuellen Prozess auf täglicher Basis oder mithilfe einer SIEM-Lösung (Security Information and Event Management) erfolgen, die bei der Analyse von Überwachungsprotokollen hilft, nach Korrelationen und Anomalien zu suchen, die für eine manuelle Überprüfung gekennzeichnet werden können.

Steuerung 62: Stellen Sie Richtliniendokumentation bereit, die die Verfahren und Verfahren der Protokollüberprüfung regelt.

• Absicht: Ein Bericht von IBM mit dem Titel "Cost of a data breach Report 2020" (Kosten einer Datenverletzungsbericht 2020) hebt hervor, dass die durchschnittliche Zeit für die Identifizierung und Eindämmung einer Datenverletzung 280 Tage dauern kann. Dies ist größer, wenn die Sicherheitsverletzung von einer böswilligen Aktivitätsgruppe als 315 Tage gemeldet wird. Da die durchschnittlichen Kosten einer Datenverletzung in Millionen von Dollar liegen, ist es wichtig, dass dieser Lebenszyklus von Datenverletzungen reduziert wird, um nicht nur das Datenrisikofenster zu minimieren, sondern auch den Zeitrahmen zu verkürzen, den eine Aktivitätsgruppe zum Exfiltrieren von Daten aus der Umgebung hat. Durch die Reduzierung dieses Zeitfensters können Organisationen die Gesamtkosten einer Datenverletzung reduzieren.

• Durch die Implementierung eines robusten Überprüfungs- und Warnungsprozesses sind Organisationen besser dafür gerüstet, Sicherheitsverletzungen früher im Lebenszyklus von Datenverletzungen zu erkennen, um deren Auswirkungen auf die Organisation zu minimieren. Darüber hinaus kann ein starker Prozess helfen, Sicherheitsverletzungen zu identifizieren, sodass Organisationen Sicherheitsmechanismen stärken können, um diese erhöhte Bedrohung zu mindern, um die Wahrscheinlichkeit einer Kompromittierung durch die Angriffskampagne weiter zu verringern.

• Beispielbeweisrichtlinien: Stellen Sie den Organisationen dokumentierte Richtlinien- und Verfahrensdokumente zur bewährten Methode der Protokollüberprüfung zur Verfügung.

• Beispielbeweis: Im Folgenden finden Sie einen Auszug aus der Protokollüberprüfungsrichtlinie/-prozedur.

Anmerkung: Dieser Screenshot zeigt ein Richtlinien-/Prozessdokument. Es wird erwartet, dass ISVs die tatsächliche unterstützende Richtlinien-/Verfahrensdokumentation freigeben und nicht einfach einen Screenshot bereitstellen.

Steuerung 63: Stellen Sie nachweisbare Beweise bereit, dass Protokolle täglich von einem Menschen oder automatisierten Tools überprüft werden, um potenzielle Sicherheitsereignisse zu identifizieren.

• Absicht: Mit diesem Steuerelement soll sichergestellt werden, dass tägliche Protokollüberprüfungen durchgeführt werden. Dies ist wichtig, um Anomalien zu identifizieren, die möglicherweise nicht von den Warnungsskripts/Abfragen erfasst werden, die für die Bereitstellung von Sicherheitsereigniswarnungen konfiguriert sind.

• Beispielrichtlinien für Nachweise: Der Beweis wird in der Regel durch einen Screenshot oder eine Bildschirmfreigabe bereitgestellt, die zeigt, dass Protokollüberprüfungen durchgeführt werden. Dies kann über Formulare erfolgen, die täglich ausgefüllt werden, oder über ein JIRA- oder DevOps-Ticket mit entsprechenden Kommentaren, die zeigen, dass dies täglich durchgeführt wird. Beispielsweise kann ein wöchentliches JIRA-Ticket "Daily Log Review W/C 26th Juni 2021" erstellt werden, an dem jeden Tag jemand die Ergebnisse der täglichen Protokollüberprüfung veröffentlicht. Wenn Anomalien gekennzeichnet werden, kann dies in diesem Ticket dokumentiert werden, um das nächste Steuerelement in einem einzelnen JIRA zu veranschaulichen.

• Wenn automatisierte Tools verwendet werden, können Screenshot-Beweise bereitgestellt werden, um die konfigurierte Automatisierung zu veranschaulichen und zusätzliche Beweise bereitzustellen, um zu zeigen, dass die Automatisierung ausgeführt wird und jemand die automatisierte Ausgabe überprüft.

• Beispielbeweis: Contoso nutzt einen SOC-Drittanbieter, Claranet Cyber Security, für Protokollkorrelationen und Überprüfungen. AlienVault wird vom SOC-Anbieter verwendet, der über die Funktionen verfügt, automatisierte Protokollanalysen für anomale Protokolle und verkettete Ereignisse bereitzustellen, die ein potenzielles Sicherheitsereignis hervorheben könnten. Die folgenden drei Screenshots zeigen Korrelationsregeln in AlienVault.

Dieser erste Screenshot zeigt, wo ein Benutzer der Gruppe "Domänenadministratoren" hinzugefügt wurde.

Dieser nächste Screenshot zeigt, wo auf mehrere fehlgeschlagene Anmeldeversuche dann eine erfolgreiche Anmeldung folgt, die einen erfolgreichen Brute-Force-Angriff hervorheben kann.

Dieser letzte Screenshot zeigt, wo eine Kennwortrichtlinie geändert wurde, die die Richtlinie festlegt, sodass Kontokennwörter nicht ablaufen.

Der nächste Screenshot zeigt, dass im ServiceNow-Tool des SOC automatisch ein Ticket ausgelöst wird, wodurch die oben genannte Regel ausgelöst wird.

Kontrolle 64: Stellen Sie nachweisbare Beweise dafür bereit, dass potenzielle Sicherheitsereignisse und Anomalien untersucht und behoben werden.

• Absicht: Die Absicht besteht darin, alle Anomalien, die während des täglichen Protokollüberprüfungsprozesses identifiziert werden, zu untersuchen und geeignete Korrekturen oder Maßnahmen durchzuführen. Dies umfasst in der Regel einen Selektierungsprozess, um zu ermitteln, ob die Anomalien eine Aktion erfordern, und dann kann es erforderlich sein, den Prozess zur Reaktion auf Vorfälle aufzurufen.

• Beispielrichtlinien für Nachweise: Der Screenshot zeigt, dass Anomalien, die im Rahmen der täglichen Protokollüberprüfung identifiziert wurden, nachgegangen werden. Wie bereits oben erwähnt, kann dies durch JIRA-Tickets sein, die eine Anomalie zeigen, die gekennzeichnet wird, und dann detailliert, welche Aktivitäten danach durchgeführt wurden. Dies kann dazu führen, dass ein bestimmtes JIRA-Ticket erhoben wird, um alle ausgeführten Aktivitäten nachzuverfolgen, oder es kann einfach im täglichen Protokollüberprüfungsticket dokumentiert werden. Wenn eine Reaktion auf Vorfälle erforderlich ist, sollte dies im Rahmen des Reaktionsprozesses für Vorfälle dokumentiert werden, und es sollten Beweise bereitgestellt werden, um dies zu veranschaulichen.

• Beispielbeweis: Das folgende Screenshotbeispiel zeigt eine Sicherheitswarnung, die in ServiceNow vom Claranet Cyber Security MDR (Managed Detection and Response) SOC nachverfolgt wird.

Dieser nächste Screenshot zeigt die Bestätigung, dass dies von David Ashton @ Contoso durch ein Update im ServiceNow-Kundenportal behoben wurde.

Sicherheitsereigniswarnungen

Kritische Sicherheitsereignisse müssen sofort untersucht werden, um die Auswirkungen auf die Daten- und Betriebsumgebung zu minimieren. Warnungen tragen dazu bei, potenzielle Sicherheitsverletzungen für mitarbeiter sofort hervorzuheben, um eine rechtzeitige Reaktion sicherzustellen, damit die Organisation das Sicherheitsereignis so schnell wie möglich eindämmen kann. Indem sichergestellt wird, dass Warnungen effektiv funktionieren, können Organisationen die Auswirkungen einer Sicherheitsverletzung minimieren und so die Wahrscheinlichkeit einer schwerwiegenden Sicherheitsverletzung verringern, die die Marke des Unternehmens beschädigen und finanzielle Verluste durch Geldbußen und Reputationsschäden verursachen könnte.

Steuerung 65: Stellen Sie Richtliniendokumentation bereit, die die Vorgehensweisen und Verfahren zur Warnung von Sicherheitsereignissen regelt.

• Absicht: Warnungen sollten für wichtige Sicherheitsereignisse verwendet werden, die eine sofortige Reaktion von einer Organisation erfordern, da das Ereignis möglicherweise auf eine Sicherheitsverletzung in der Umgebung und/oder eine Datenverletzung hindeutet. Ein starker Prozess rund um den Warnungsprozess sollte dokumentiert werden, um sicherzustellen, dass dies auf konsistente und wiederholbare Weise erfolgt. Dies wird hoffentlich dazu beitragen, den Lebenszyklus von Datenverletzungen zu verkürzen.

• Beispielbeweisrichtlinien: Stellen Sie den Organisationen dokumentierte Richtlinien- und Verfahrensdokumente zur bewährten Methode für Sicherheitsereigniswarnungen zur Verfügung.

• Beispielbeweis: Im Folgenden finden Sie einen Auszug aus der Richtlinie/Prozedur für Sicherheitsereigniswarnungen. Bitte geben Sie die vollständigen Richtlinien- und Verfahrensdokumente an, um Ihre Bewertung zu unterstützen.

Anmerkung: Dieser Screenshot zeigt ein Richtlinien-/Prozessdokument. Es wird erwartet, dass ISVs die tatsächliche unterstützende Richtlinien-/Verfahrensdokumentation freigeben und nicht einfach einen Screenshot bereitstellen.

Steuerung 66: Stellen Sie nachweisbare Beweise dafür bereit, dass Warnungen für die sofortige Selektierung für die folgenden Arten von Sicherheitsereignissen ausgelöst werden:

• Erstellen oder Ändern privilegierter Konten

• Viren- oder Schadsoftwareereignisse

• Manipulation des Ereignisprotokolls

• IDPS- oder WAF-Ereignisse, falls konfiguriert

• Absicht: Oben ist eine Liste mit einigen Arten von Sicherheitsereignissen aufgeführt, die ein Sicherheitsereignis hervorheben können, das auf eine Sicherheitsverletzung in der Umgebung und/oder eine Datenverletzung hinweisen kann.

• Beispielrichtlinien für Nachweise: Der Nachweis sollte mit Screenshots der Warnungskonfiguration UND dem Nachweis der empfangenen Warnungen bereitgestellt werden. Die Konfigurationsscreenshots sollten die Logik zeigen, die die Warnungen auslöst, und wie die Warnungen gesendet werden. Warnungen können über SMS, E-Mail, Teams-Kanäle, Slack-Kanäle usw. gesendet werden.

• Beispielbeweis: Contoso nutzt einen SOC eines Drittanbieters, der von Claranet Cyber Security bereitgestellt wird. Das folgende Beispiel zeigt, dass warnungen in AlienVault, die vom SOC verwendet werden, so konfiguriert sind, dass eine Warnung an ein Mitglied des SOC-Teams, Dan Turner von Claranet Cyber Security, gesendet wird.

Dieser nächste Screenshot zeigt eine Warnung, die von Dan empfangen wird.

Kontrolle 67: Stellen Sie nachweisbare Beweise bereit, die zeigen, dass Mitarbeiter den ganzen Tag, jeden Tag zur Verfügung stehen, um auf Sicherheitswarnungen zu reagieren.

• Absicht: Es ist wichtig, dass Sicherheitswarnungen so schnell wie möglich selektiert werden, um die Gefährdung der Umgebung und/oder der Daten zu begrenzen. Die Mitarbeiter müssen immer zur Verfügung stehen, um auf Warnungen zu reagieren und kritische Ermittlungsarbeiten zu leisten, wenn ein Sicherheitsverstoß erkannt wird. Je schneller dieser Prozess gestartet wird, desto schneller kann der Sicherheitsvorfall eingedämmt werden, um die Daten zu schützen oder die Auswirkungen der Sicherheitsverletzung zu begrenzen.
• Beispielrichtlinien für Nachweise: Es sollten Nachweise bereitgestellt werden, die belegen, dass Mitarbeiter 24 Stunden am Tag verfügbar sind, um auf Sicherheitswarnungen zu reagieren. Dies kann bei einer Rota auf Abruf der Fall sein.
• Beispielbeweis: Der folgende Screenshot zeigt einen Rota-Termin für Dezember 2020 für Contoso. Das SoC-Team von Claranet Cyber Security benachrichtigt die Mitglieder des Contoso-Bereitschaftsteams.

Informationssicherheits-Risikomanagement

Das Informationssicherheits-Risikomanagement ist eine wichtige Aktivität, die alle Organisationen mindestens jährlich durchführen sollten. Organisationen müssen ihre Bedrohungen und Risiken verstehen, um diese Bedrohungen effektiv zu mindern. Ohne effektives Risikomanagement können Organisationen bewährte Sicherheitsmethoden in Bereichen implementieren, die sie als wichtig betrachten, und daher Ressourcen, Zeit und Geld in diese Bereiche investieren, wenn andere Bedrohungen viel wahrscheinlicher sind und daher abgeschwächt werden sollten. Ein effektives Risikomanagement hilft Organisationen, sich auf Risiken zu konzentrieren, die die größte Bedrohung für das Unternehmen darstellen. Dies sollte jährlich durchgeführt werden, da sich die Sicherheitslandschaft ständig ändert und sich daher Bedrohungen und Risiken im Laufe der Zeit ändern können. Ein gutes Beispiel hierfür ist COVID-19, das eine massive Zunahme von Phishing-Angriffen und die massenhafte (und schnelle) Einführung der Remotearbeit für Hunderte oder Tausende von Mitarbeitern sah.

Kontrolle 68: Stellen Sie nachweisbare Beweise dafür bereit, dass ein formaler Prozess für das Risikomanagement der Informationssicherheit eingerichtet wurde.

• Absicht: Wie bereits erwähnt, ist ein robuster Risikomanagementprozess für die Informationssicherheit wichtig, um Organisationen dabei zu helfen, Risiken effektiv zu verwalten. Dies hilft Organisationen bei der Planung effektiver Maßnahmen gegen Bedrohungen für die Umgebung.

Es ist wichtig, dass die Risikobewertung das Informationssicherheitsrisiko und nicht nur allgemeine "Geschäftsrisiken" umfasst.

• Beispielbeweisrichtlinien: Der formal dokumentierte Prozess zur Risikomanagementverwaltung sollte bereitgestellt werden.
• Beispielbeweis: Der folgende Beweis ist ein Screenshot eines Teils des Risikobewertungsprozesses von Contoso.

Anmerkung: Dieser Screenshot zeigt ein Richtlinien-/Prozessdokument. Es wird erwartet, dass ISVs die tatsächliche unterstützende Richtlinien-/Verfahrensdokumentation freigeben und nicht einfach einen Screenshot bereitstellen.

Kontrolle 69: Nachweise dafür liefern, dass mindestens einmal jährlich eine formale Risikobewertung erfolgt.

• Absicht: Sicherheitsbedrohungen ändern sich ständig, basierend auf Änderungen an der Umgebung, Änderungen der angebotenen Dienste, externen Einflüssen, der Entwicklung der Sicherheitsbedrohungslandschaft usw. Organisationen müssen diesen Prozess mindestens jährlich durchlaufen. Es wird empfohlen, dass dieser Prozess auch bei wichtigen Änderungen durchgeführt wird, da sich Bedrohungen ändern können.

• Beispiel-Beweisrichtlinien: Der Beweis kann durch Versionsnachverfolgung oder datierte Beweise erfolgen. Es sollten Nachweise vorgelegt werden, die das Ergebnis der Bewertung des Informationssicherheitsrisikos und KEINE Daten zum Prozess der Informationssicherheitsrisikobewertung selbst enthalten.

• Beispielbeweis: Dieser Screenshot zeigt eine Risikobewertungsbesprechung, die alle sechs Monate geplant ist.

Diese beiden Screenshots zeigen die Besprechungsminuten von zwei Risikobewertungssitzungen.

Kontrolle 70: Stellen Sie nachweisbare Beweise dafür bereit, dass die Bewertung des Informationssicherheitsrisikos Bedrohungen, Sicherheitsrisiken oder gleichwertige Informationen umfasst.

• Absicht: Risikobewertungen der Informationssicherheit sollten gegen Bedrohungen für die Umgebung und daten sowie gegen mögliche Sicherheitsrisiken durchgeführt werden, die vorhanden sein können. Dies wird Organisationen helfen, die Vielzahl von Bedrohungen/Sicherheitsrisiken zu identifizieren, die ein erhebliches Risiko darstellen können.
• Beispielrichtlinien für Nachweise: Die Nachweise sollten nicht nur im Rahmen des bereits bereitgestellten Prozesses zur Risikobewertung der Informationssicherheit, sondern auch durch das Ergebnis der Risikobewertung (über ein Risikoregister/Risikobehandlungsplan) bereitgestellt werden, das Risiken und Sicherheitsrisiken umfassen sollte.
• Beispielbeweis: Der folgende Screenshot zeigt das Risikoregister, das zeigt, dass Bedrohungen und Sicherheitsrisiken enthalten sind.

Anmerkung: Anstelle eines Screenshots sollte die vollständige Dokumentation zur Risikobewertung bereitgestellt werden.

Kontrolle 71: Stellen Sie nachweisbare Beweise dafür bereit, dass die Bewertung des Informationssicherheitsrisikos Auswirkungen, Wahrscheinlichkeitsrisikomatrix oder das Entsprechende umfasst.

• Absicht: Risikobewertungen der Informationssicherheit sollten Auswirkungen und Wahrscheinlichkeitsbewertungen dokumentieren. Diese Matrizen werden in der Regel verwendet, um einen Risikowert zu identifizieren, der von der Organisation verwendet werden kann, um die Risikobehandlung zu priorisieren, um den Risikowert zu verringern.
• Beispielrichtlinien für Nachweise: Die Nachweise sollten nicht nur im Rahmen des bereits bereitgestellten Prozesses zur Risikobewertung der Informationssicherheit, sondern auch durch das Ergebnis der Risikobewertung (im Wege eines Risikoregisters/Risikobehandlungsplans) bereitgestellt werden, das Auswirkungen- und Wahrscheinlichkeitsbewertungen umfassen sollte.
• Beispielbeweis: Der folgende Screenshot zeigt das Risikoregister, in dem die Auswirkungen und Die Wahrscheinlichkeiten enthalten sind.

Anmerkung: Das vollständige Risiko assessment_ _document__ation sollte anstelle eines Screenshots bereitgestellt werden.

Kontrolle 72: Nachweise dafür liefern, dass die Risikobewertung der Informationssicherheit ein Risikoregister und einen Behandlungsplan enthält.

• Absicht: Organisationen müssen Risiken effektiv verwalten. Dies muss ordnungsgemäß nachverfolgt werden, um entweder eine der vier angewendeten Risikobehandlungen zu erfassen. Risikobehandlungen sind:
• Vermeiden/Beenden : Das Unternehmen kann bestimmen, dass die Kosten für die Behandlung des Risikos höher sind als die Einnahmen, die mit dem Dienst generiert werden. Das Unternehmen kann sich daher dafür entscheiden, die Ausführung des Diensts einzustellen.
• Übertragung/Freigabe : Das Unternehmen kann das Risiko auf einen Dritten übertragen, indem es die Verarbeitung an einen Drittanbieter überträgt.
• Akzeptieren/Tolerieren/Beibehalten : Das Unternehmen kann entscheiden, dass das Risiko akzeptabel ist. Dies hängt stark vom Risikoappetit des Unternehmens ab und kann je nach Organisation variieren.
• Behandeln/Entschärfen/Ändern : Das Unternehmen beschließt, Risikominderungskontrollen zu implementieren, um das Risiko auf ein akzeptables Niveau zu reduzieren.
• Mit dieser Kontrolle soll gewährleistet werden, dass die Organisation die Risikobewertung durchführt und entsprechend handelt.
• Beispielbeweisrichtlinien: Der Risikobehandlungsplan/ das Risikoregister (oder etwas Gleichwertiges) sollte bereitgestellt werden, um nachzuweisen, dass der Risikobewertungsprozess ordnungsgemäß durchgeführt wird.
• Beispielbeweis: Im Folgenden finden Sie ein Risikoregister für Contoso.

Anmerkung: Anstelle eines Screenshots sollte die vollständige Dokumentation zur Risikobewertung bereitgestellt werden.

Der folgende Screenshot zeigt einen Risikobehandlungsplan.

Reaktion auf Sicherheitsvorfälle

Eine Reaktion auf Sicherheitsvorfälle ist für alle Organisationen wichtig, da dies die Zeit reduzieren kann, die eine Organisation für die Eindämmung eines Sicherheitsvorfalls aufwendet und die Exposition der Organisation durch Datenexfiltration begrenzt. Durch die Entwicklung eines umfassenden und detaillierten Plans zur Reaktion auf Sicherheitsvorfälle kann diese Exposition vom Zeitpunkt der Identifizierung bis zum Zeitpunkt der Eindämmung reduziert werden.

Ein Bericht von IBM mit dem Titel "Cost of a Data Breach Report 2020" (Kosten einer Datenverletzungsbericht 2020) hebt hervor, dass die durchschnittlich benötigte Zeit für die Eindämmung einer Sicherheitsverletzung 73 Tage betrug. Darüber hinaus identifiziert derselbe Bericht die größte Kostenersparnis für Organisationen, die eine Sicherheitsverletzung erlitten haben, war die Bereitschaft zur Reaktion auf Vorfälle, was eine durchschnittliche Kosteneinsparung von 2.000.000 USD ermöglicht.

Organisationen sollten bewährte Methoden für die Sicherheitskonformität unter Verwendung von Branchenstandardframeworks wie ISO 27001, NIST, SOC 2, PCI DSS usw. befolgen.

Steuerung 73: Stellen Sie den Plan zur Reaktion auf Sicherheitsvorfälle (Security Incident Response Plan, IRP) bereit.

• Absicht: Wie bereits erläutert, besteht die Absicht dieser Kontrolle darin, einen formal dokumentierten Plan zur Reaktion auf Vorfälle zu erfordern. Dies wird dazu beitragen, eine effizientere Reaktion auf Sicherheitsvorfälle zu verwalten, was letztendlich die Offenlegung von Datenverlusten in Organisationen begrenzen und die Kosten der Kompromittierung reduzieren kann.
• Beispielbeweisrichtlinien: Geben Sie die vollständige Version des Plans/Verfahrens zur Reaktion auf Vorfälle an. Dies sollte einen dokumentierten Kommunikationsprozess umfassen, der im nächsten Steuerelement behandelt wird.
• Beispielbeweis: Der folgende Screenshot zeigt den Beginn des Plans zur Reaktion auf Vorfälle von Contoso. Im Rahmen Ihrer Beweisübermittlung müssen Sie den gesamten Plan zur Reaktion auf Vorfälle bereitstellen.

Anmerkung: Dieser Screenshot zeigt ein Richtlinien-/Prozessdokument. Es wird erwartet, dass ISVs die tatsächliche unterstützende Richtlinien-/Verfahrensdokumentation freigeben und nicht einfach einen Screenshot bereitstellen.

Kontrolle 74: Nachweise dafür liefern, dass das Sicherheits-IRP einen dokumentierten Kommunikationsprozess umfasst, um eine rechtzeitige Benachrichtigung an wichtige Interessenträger wie Zahlungsmarken und Erwerber, Aufsichtsbehörden, Aufsichtsbehörden, Direktoren und Kunden sicherzustellen.

• Absicht: Organisationen haben möglicherweise Benachrichtigungspflichten aufgrund des Landes/der Länder, in denen sie tätig sind (z. B. die Datenschutz-Grundverordnung; DSGVO) oder basierend auf angebotenen Funktionen (z. B. PCI-DSS, wenn Zahlungsdaten verarbeitet werden). Wenn eine rechtzeitige Benachrichtigung nicht erfolgt, kann dies schwerwiegende Auswirkungen haben. Um sicherzustellen, dass die Benachrichtigungspflichten erfüllt sind, sollten Die Pläne zur Reaktion auf Vorfälle einen Kommunikationsprozess beinhalten, der die Kommunikation mit allen Beteiligten, Medienkommunikationsprozesse und wer mit den Medien sprechen kann und wer nicht mit den Medien sprechen kann.
• Beispielbeweisrichtlinien: Geben Sie die vollständige Version des Plans/Verfahrens zur Reaktion auf Vorfälle an, die einen Abschnitt zum Kommunikationsprozess enthalten sollte.
• Beispielbeweis: Der folgende Screenshot zeigt einen Auszug aus dem Plan zur Reaktion auf Vorfälle, der den Kommunikationsprozess zeigt.

Kontrolle 75: Stellen Sie nachweisbare Beweise bereit, dass alle Mitglieder des Incident Response-Teams ein jährliches Training oder eine Table Top-Übung absolviert haben.

• Absicht: Je länger es dauert, bis eine Organisation eine Kompromittierung eingeht, desto größer ist das Risiko der Datenexfiltration, was möglicherweise zu einer größeren Menge exfiltrierter Daten und desto höher sind die Gesamtkosten der Kompromittierung. Es ist wichtig, dass die Teams der Organisation für die Reaktion auf Vorfälle in der Lage sind, rechtzeitig auf Sicherheitsvorfälle zu reagieren. Durch regelmäßige Schulungen und Die Durchführung von Tischübungen wird das Team so ausgestattet, sicherheitsrelevante Vorfälle schnell und effizient zu behandeln.

• Die Empfehlung besteht darin, sowohl interne Schulungen zur Reaktion auf Vorfälle für das Incident-Reaktionsteam durchzuführen als auch regelmäßige Tabletop-Übungen durchzuführen, die mit der Bewertung des Informationssicherheitsrisikos verknüpft sind, um die wahrscheinlichsten Sicherheitsvorfälle zu identifizieren. Auf diese Weise weiß das Team, welche Schritte unternommen werden müssen, um die wahrscheinlichsten Sicherheitsvorfälle schnell einzudämmen und zu untersuchen.

• Beispielrichtlinien für Nachweise: Es sollten Beweise bereitgestellt werden, die belegen, dass die Schulung mit der Freigabe der Schulungsinhalte durchgeführt wurde, und Aufzeichnungen, die zeigen, wer teilgenommen hat (die das gesamte Team für die Reaktion auf Vorfälle umfassen sollte). Alternativ können sie oder auch Datensätze enthalten, die zeigen, dass eine Tabletop-Übung durchgeführt wurde. All dies muss innerhalb eines Zeitraums von 12 Monaten ab dem Zeitpunkt der Beweisaufnahme abgeschlossen worden sein.

• Beispielbeweis: Contoso hat eine Tabletop-Übung zur Reaktion auf Vorfälle mit einem externen Sicherheitsunternehmen namens Claranet Cyber Security durchgeführt. Im Folgenden finden Sie ein Beispiel des Berichts, der im Rahmen der Beratung generiert wurde.

Anmerkung: Der vollständige Bericht müsste freigegeben werden. Diese Übung könnte auch intern durchgeführt werden, da es keine Microsoft 365-Anforderung gibt, die von einem Drittanbieter durchgeführt werden muss.

Steuerung 76: Stellen Sie nachweisbare Beweise bereit, um zu zeigen, dass die Sicherheits-IRP basierend auf gewonnenen Erkenntnissen oder organisatorischen Änderungen aktualisiert wird.

• Absicht: Im Laufe der Zeit sollte sich der Plan zur Reaktion auf Vorfälle (Incident Response Plan, IRP) basierend auf organisatorischen Änderungen oder auf der Grundlage von Erkenntnissen entwickeln, die bei der Umsetzung des IRP gelernt wurden. Änderungen an der Betriebsumgebung erfordern möglicherweise Änderungen am IRP, da sich die Bedrohungen ändern oder sich die gesetzlichen Anforderungen ändern können. Darüber hinaus können bei der Durchführung von Tabellenübungen und tatsächlichen Reaktionen auf Sicherheitsvorfälle häufig Bereiche des IRP identifiziert werden, die verbessert werden können. Dies muss in den Plan integriert werden, und die Absicht dieses Steuerelements besteht darin, sicherzustellen, dass dieser Prozess im IRP enthalten ist.

• Beispielrichtlinien für Nachweise: Dies wird häufig durch die Überprüfung der Ergebnisse von Sicherheitsvorfällen oder Tabellenübungen belegt, bei denen die gewonnenen Erkenntnisse identifiziert und im Rahmen einer Aktualisierung des IRP erzielt wurden. Das IRP sollte ein Änderungsprotokoll verwalten, das auch auf Änderungen verweisen sollte, die basierend auf gewonnenen Erkenntnissen oder organisatorischen Änderungen implementiert wurden.

• Beispielbeweis: Die folgenden Screenshots stammen aus dem bereitgestellten IRP, der einen Abschnitt zum Aktualisieren des IRP basierend auf gewonnenen Erkenntnissen und/oder Organisationsänderungen enthält.

Das IRP-Änderungsprotokoll zeigt ein Update, das auf der Rückseite der Im Juli 2021 durchgeführten Tabletop-Übung vorgenommen wird.

Sicherheitsdomäne: Sicherheit und Datenschutz für die Datenverarbeitung

Diese Sicherheitsdomäne ist enthalten, um sicherzustellen, dass alle von Microsoft 365 genutzten Daten sowohl während der Übertragung als auch im Ruhezustand angemessen geschützt sind. Dieser Bereich stellt auch sicher, dass die Datenschutzbedenken der Verbraucher (betroffene Personen) vom ISV im Einklang mit der Datenschutz-Grundverordnung (DSGVO) erfüllt werden, die sich mit der Privatsphäre der EU-Bürger befasst.

Daten während der Übertragung

Aufgrund der Konnektivitätsanforderungen von von Microsoft 365 entwickelten Apps/Add-Ins erfolgt die Kommunikation über öffentliche Netzwerke, nämlich das Internet. Aus diesem Grund müssen Daten während der Übertragung angemessen geschützt werden. Dieser Abschnitt behandelt den Schutz der Datenkommunikation über das Internet.

Steuerung 1: Stellen Sie nachweisbare Beweise bereit, dass die TLS-Konfiguration die Verschlüsselungsanforderungen der TLS-Profilkonfigurationsanforderungen erfüllt oder überschreitet.

• Absicht: Mit diesem Steuerelement soll sichergestellt werden, dass Microsoft 365-Daten, die von Ihrer Organisation genutzt werden, sicher übertragen werden. Die TLS-Profilkonfiguration definiert TLS-spezifische Anforderungen, um sicherzustellen, dass der Datenverkehr vor Man-in-the-Middle-Angriffen geschützt ist.

• Beispielbeweisrichtlinien: Die einfachste Möglichkeit, dies nachzuweisen, besteht darin, das Qualys SSL Server Test-Tool für ALLE Weblistener auszuführen, einschließlich aller, die auf nicht standardmäßigen Ports ausgeführt werden.

• Denken Sie daran, die Option "Ergebnisse nicht auf den Boards anzeigen" zu aktivieren, die verhindert, dass die URL der Website hinzugefügt wird.

• Sie können auch Nachweise bereitstellen, um die einzelnen Überprüfungen innerhalb der TLS-Profilkonfigurationsanforderungen zu veranschaulichen. Konfigurationseinstellungen können zusammen mit Skripts und Softwaretools verwendet werden, um Nachweise für einige der spezifischen Einstellungen zu liefern, d. h. die TLS-Komprimierung ist deaktiviert.

• Beispielbeweis: Der folgende Screenshot zeigt die Ergebnisse für den www.clara.net:443 Weblistener.

Hinweis: Die Zertifizierungsanalysten überprüfen die vollständige Ausgabe, um zu bestätigen, dass alle Anforderungen der TLS-Profilkonfigurationsanforderungen erfüllt sind (Bitte geben Sie Screenshots der vollständigen Scanausgabe an). Depending_ auf _what Beweise bereitgestellt wurden, können die Analysten einen eigenen Qualys-Scan durchführen.

• Beispielbeweis 2: Der folgende Screenshot zeigt, dass TLS 1.2 im Speicher konfiguriert ist.

Anmerkung: Dieser Screenshot allein kann diese Anforderung nicht erfüllen.

• Beispielbeweis 3: Die folgenden Screenshots zeigen, dass TLS V1.3 nur auf dem Server aktiviert ist.

In diesem Beispiel werden die Registrierungsschlüssel verwendet, um ein Protokoll zu deaktivieren oder zu aktivieren, indem die Werte wie folgt angepasst werden:

Binärdatei: 0 - off 1 - ein

Hexadezimal: 0x00000000 – aus 0xffffffff – Ein

Bitte beachten Sie : Verwenden Sie diese Methodik nicht, wenn Sie sie nicht verstehen, da wir (Microsoft) nicht dafür verantwortlich sind, dass Sie dieses Beispiel verwenden oder befolgen oder auswirkungen, die seine Verwendung auf Ihre Systeme haben kann. Hier wird lediglich eine andere Möglichkeit veranschaulicht, um zu zeigen, ob TLS aktiviert oder deaktiviert ist.

Hinweis: Diese Screenshots allein könnten diese Anforderung nicht erfüllen.

Steuerung 2: Stellen Sie nachweisbare Beweise dafür bereit, dass die TLS-Komprimierung für alle öffentlichen Dienste, die Webanforderungen verarbeiten, deaktiviert ist.

• Absicht: Es gibt ein bestimmtes TLS-Sicherheitsrisiko, CRIME (CVE-2012-4929), die sich auf die TLS-Komprimierung auswirkt. Aus diesem Grund sind Branchenempfehlungen, diese Funktionalität zu deaktivieren.

• Beispielrichtlinien für Nachweise: Dies kann ein Beweis über das Qualys SSL Labs-Tool sein.

• Beispielbeweis: Der folgende Screenshot zeigt dies mithilfe des Qualys SSL Labs-Tools.

Steuerung 3: Stellen Sie nachweisbare Beweise dafür bereit, dass tls http strict transport security (TLS HTTP strict transport security) aktiviert und auf >= 15552000 an allen Standorten konfiguriert ist.

• Absicht: HTTP Strict Transport Security (HSTS) ist ein Sicherheitsmechanismus, der Websites vor Man-in-the-Middle-Angriffen schützt, indem TLS-Verbindungen über ein HTTPS-Antwortheaderfeld namens "Strict-Transport-Security" erzwungen werden.

• Beispielrichtlinien für Nachweise: Dies kann ein Beweis über das Qualys SSL Labs-Tool oder andere Tools und Webbrowser-Add-Ins sein.

• Beispielbeweis: Der folgende Screenshot zeigt dies über ein Webbrowser-Add-In namens "HTTP Header Spy" für die www.microsoft.com Website.

Ruhende Daten

Wenn daten, die von der Microsoft 365-Plattform genutzt werden, von ISVs gespeichert werden, müssen die Daten entsprechend geschützt werden. In diesem Abschnitt werden die Schutzanforderungen von Daten behandelt, die in Datenbanken und Dateispeichern gespeichert sind.

Steuerung 4: Stellen Sie nachweisbare Beweise dafür bereit, dass ruhende Daten inline mit den Anforderungen des Verschlüsselungsprofils verschlüsselt werden, indem Verschlüsselungsalgorithmen wie AES, Blowfish, TDES und Verschlüsselungsschlüsselgrößen von 128-Bit und 256-Bit verwendet werden.

• Absicht: Einige ältere Verschlüsselungsalgorithmen enthalten bekanntermaßen kryptografische Schwachstellen, was die Wahrscheinlichkeit erhöht, dass eine Aktivitätsgruppe die Daten ohne Kenntnis des Schlüssels entschlüsseln kann. Aus diesem Grund soll mit dieser Kontrolle sichergestellt werden, dass nur branchenweit akzeptierte Verschlüsselungsalgorithmen verwendet werden, um gespeicherte Microsoft 365-Daten zu schützen.

• Beispielrichtlinien für Nachweise: Beweise können mithilfe von Screenshots bereitgestellt werden, die zeigen, dass die Verschlüsselung verwendet wird, um Microsoft 365-Daten in Datenbanken und anderen Speicherorten zu schützen. Der Beweis sollte zeigen, dass die Verschlüsselungskonfiguration mit den Konfigurationsanforderungen für das Verschlüsselungsprofil der Microsoft 365-Zertifizierung im Einklang steht.

• Beispielbeweis: Der folgende Screenshot zeigt, dass TDE (Transparent Data Encryption) für die Contoso-Datenbank aktiviert ist. Der zweite Screenshot zeigt die Microsoft-Dokumentationsseite "Transparente Datenverschlüsselung für SQL-Datenbank, SQL Managed Instance und Azure Synapse Analytics", die zeigt, dass die AES 256-Verschlüsselung für Azure TDE verwendet wird.

• Beispielbeweis 2: Der folgende Screenshot zeigt Azure Storage, der mit Verschlüsselung für Blobs und Dateien konfiguriert ist. Der folgende Screenshot zeigt die Microsoft-Dokumentationsseite "Azure Storage-Verschlüsselung für ruhende Daten", die zeigt, dass Azure Storage AES-256 für die Verschlüsselung verwendet.

Steuerung 5: Stellen Sie nachweisbare Beweise dafür bereit, dass die Hashfunktion oder Nachrichtenauthentifizierung (HMAC-SHA1) nur verwendet wird, um ruhende Daten inline mit den Anforderungen des Verschlüsselungsprofils zu schützen.

• Absicht: Wie bei Verschlüsselungsalgorithmen basieren einige Hashfunktionen und Nachrichtenauthentifizierungsalgorithmen auf Algorithmen mit kryptografischen Schwächen. Mit diesem Steuerelement soll sichergestellt werden, dass Microsoft 365-Daten mit starken Hashfunktionen geschützt werden, wenn Hashing als Datenschutzmechanismus verwendet wird. Wenn dies nicht von der Umgebung und/oder Anwendung verwendet wird, müssen Beweise bereitgestellt werden, die dies bestätigen können.

• Beispiel-Beweisrichtlinien: Der Beweis kann in Form von Screenshots vorliegen, die Codeausschnitte zeigen, in denen die Hashfunktion funktioniert.

• Beispielbeweis: Contoso nutzt Hashingfunktionen innerhalb seiner Anwendung. Der folgende Screenshot zeigt, dass SHA256 als Teil der Hashfunktion verwendet wird.

Steuerung 6: Stellen Sie einen Bestand aller gespeicherten Daten bereit, einschließlich des Speicherorts und der Verschlüsselung, die zum Schutz der Daten verwendet werden.

• Absicht: Um Daten ordnungsgemäß zu schützen, müssen Organisationen wissen, welche Daten ihre Umgebung/Systeme verbrauchen und wo die Daten gespeichert werden. Sobald dies vollständig verstanden und dokumentiert ist, sind Organisationen in der Lage, nicht nur einen angemessenen Datenschutz zu implementieren, sondern auch in der Lage zu konsolidieren, wo sich die Daten befinden, um den Schutz effektiver zu implementieren. Wenn Daten an so wenigen Stellen wie möglich konsolidiert werden, ist es außerdem einfacher, eine angemessene rollenbasierte Zugriffssteuerung (rollenbasierte Zugriffssteuerung) zu implementieren, um den Zugriff auf so wenige Mitarbeiter wie nötig zu beschränken.

• Beispielrichtlinien für Nachweise: Der Nachweis sollte über ein Dokument oder einen Export aus einem internen System, d. h. SharePoint oder Confluence, bereitgestellt werden, wobei alle verbrauchten Daten, alle Speicherorte und die implementierte Verschlüsselungsebene detailliert beschrieben werden.

• Beispielbeweis: Der folgende Screenshot zeigt ein Beispiel dafür, wie ein Dokument mit Datentypen aussehen könnte.

Datenaufbewahrung und -entsorgung

Wenn ISVs Microsoft 365-Daten nutzen und speichern, besteht das Risiko einer Datenkompromittierung, wenn eine Aktivitätsgruppe die ISV-Umgebung kompromittiert. Um dieses Risiko zu minimieren, sollten Organisationen nur Daten aufbewahren, die sie für die Bereitstellung von Diensten benötigen, und nicht Daten, die in Zukunft "von Nutzen sein" könnten. Darüber hinaus sollten Daten nur so lange aufbewahrt werden, wie es für die Bereitstellung der Dienste erforderlich ist, für die die Daten erfasst wurden. Die Datenaufbewahrung sollte definiert und mit Benutzern kommuniziert werden. Sobald die Daten den definierten Aufbewahrungszeitraum überschreiten, muss diese sicher gelöscht werden, damit die Daten nicht wiederhergestellt oder wiederhergestellt werden können.

Kontrolle 7: Stellen Sie nachweisbare Beweise bereit, dass ein genehmigter und dokumentierter Datenaufbewahrungszeitraum formal festgelegt wurde.

• Absicht: Eine dokumentierte und befolgte Aufbewahrungsrichtlinie ist nicht nur wichtig, um einige gesetzliche Verpflichtungen zu erfüllen, z. B. Datenschutzvorschriften wie, aber nicht beschränkt auf die Datenschutz-Grundverordnung (EU-DSGVO) und den Datenschutzgesetz (UK DPA 2018), sondern auch, um das Risiko einer Organisation zu begrenzen. Indem Sie die Datenanforderungen der Organisationen verstehen und verstehen, wie lange daten benötigt werden, damit das Unternehmen seine Funktionen ausführt, können Organisationen sicherstellen, dass Daten ordnungsgemäß gelöscht werden, sobald ihre Nützlichkeit abläuft. Indem die Menge der gespeicherten Daten reduziert wird, verringern Organisationen die Datenmenge, die bei einer Datenkompromittierung verfügbar gemacht würde. Dadurch wird die Gesamtwirkung begrenzt.

• Häufig speichern Organisationen Daten einfach, weil es "schön ist, nur für die Fälle zu haben". Wenn die Organisation die Daten jedoch nicht benötigt, um ihre Dienst- oder Geschäftsfunktion auszuführen, sollten die Daten nicht gespeichert werden, da dies die Risiken der Organisation unnötig erhöht.

• Beispielbeweisrichtlinien: Geben Sie die vollständige Datenaufbewahrungsrichtlinie an, die genau beschreibt, wie lange Daten (die alle Datentypen abdecken müssen) aufbewahrt werden sollen, damit das Unternehmen seine Geschäftsfunktionen ausführen kann.

• Beispielbeweis: Der folgende Screenshot zeigt die Datenaufbewahrungsrichtlinie von Contoso.

Anmerkung: Dieser Screenshot zeigt ein Richtlinien-/Prozessdokument. Es wird erwartet, dass ISVs die tatsächliche unterstützende Richtlinien-/Verfahrensdokumentation freigeben und nicht einfach einen Screenshot bereitstellen.

Steuerung 8: Stellen Sie nachweisbare Beweise dafür bereit, dass beibehaltene Daten dem definierten Aufbewahrungszeitraum entsprechen.

• Absicht: Die Absicht dieses Steuerelements besteht darin, einfach zu überprüfen, ob die definierten Datenaufbewahrungszeiträume eingehalten werden. Wie bereits erwähnt, haben Organisationen möglicherweise eine rechtliche Verpflichtung, dies zu erfüllen, aber auch durch die Aufbewahrung von Daten, die erforderlich sind und so lange wie erforderlich sind, trägt dies dazu bei, das Risiko für die Organisation im Falle einer Datenverletzung zu verringern.

• Beispielrichtlinien für Nachweise: Stellen Sie einen Screenshot-Beweis (oder über eine Bildschirmfreigabe) bereit, der zeigt, dass gespeicherte Daten (an allen verschiedenen Speicherorten, d. h. Datenbanken, Dateifreigaben, Archiven usw.) die definierte Datenaufbewahrungsrichtlinie nicht überschreiten. Beispiele wären Screenshots von Datenbankdatensätzen mit einem Datumsfeld, das in der ältesten Datensatzreihenfolge durchsucht wurde, und/oder Dateispeicherorte mit Zeitstempeln, die innerhalb des Aufbewahrungszeitraums liegen.

Anmerkung: Alle persönlichen/sensiblen Kundendaten sollten im Screenshot redigiert werden.

• Beispielbeweis: Der folgende Beweis zeigt eine SQL-Abfrage, die den Inhalt der Datenbanktabelle in aufsteigender Reihenfolge im Feld "DATE_TRANSACTION" sortiert zeigt, um die ältesten Datensätze in der Datenbank anzuzeigen. Diese Daten sollten zwei Monate alt sein und den definierten Aufbewahrungszeitraum nicht überschreiten.

Anmerkung: Dies ist eine Testdatenbank, daher sind nicht viele Verlaufsdaten darin enthalten.

Steuerung 9: Stellen Sie nachweisbare Beweise dafür bereit, dass Prozesse vorhanden sind, um Daten nach der Aufbewahrungsdauer sicher zu löschen.

• Absicht: Die Absicht dieses Steuerelements besteht darin, sicherzustellen, dass der Mechanismus zum Löschen von Daten, die den Aufbewahrungszeitraum überschreiten, dies sicher tut. Gelöschte Daten können manchmal wiederhergestellt werden. Daher muss der Löschvorgang robust genug sein, um sicherzustellen, dass Daten nach dem Löschen nicht wiederhergestellt werden können.

• Beispielrichtlinien für Nachweise: Wenn der Löschvorgang programmgesteuert erfolgt, geben Sie einen Screenshot des Skripts an, das dazu verwendet wird. Wenn sie nach einem Zeitplan ausgeführt wird, geben Sie einen Screenshot mit dem Zeitplan an. Beispielsweise kann ein Skript zum Löschen von Dateien innerhalb einer Dateifreigabe als CRON-Auftrag konfiguriert werden. Screenshot des CRON-Auftrags mit dem Zeitplan und Skript, die ausgeführt werden, und Bereitstellen des Skripts mit dem verwendeten Befehl.

• Beispielbeweis 1: Dies ist ein einfaches Skript, das verwendet werden kann, um alle Datensätze zu löschen, die basierend auf dem Datum aufbewahrt werden –, wobei DateAdd -30 Tage ist, wodurch alle aufbewahrten Datensätze gelöscht werden, die älter als 30 Tage nach dem ausgewählten Datenaufbewahrungsdatum sind. Beachten Sie, dass wir das Skript, aber auch Beweise für die Ausführung des Auftrags und Ergebnisse benötigen.

• Beispielbeweis 2: Der folgende wurde aus dem Contoso-Datenaufbewahrungsplan in Control 7 übernommen– Dies zeigt die Verfahren, die für die Datenvernichtung verwendet werden.

Anmerkung: Dieser Screenshot zeigt ein Richtlinien-/Prozessdokument. Es wird erwartet, dass ISVs die tatsächliche unterstützende Richtlinien-/Verfahrensdokumentation freigeben und nicht einfach einen Screenshot bereitstellen.

• Beispielbeweis 3: In diesem Beispiel wurden ein Runbook und ein entsprechender Zeitplan in Azure erstellt, um Datensätze sicher zu löschen, deren Enddatum 30 Tage nach Ablauf der Aufbewahrungsrichtlinie für Datensätze erstellt wurde. Dieser Auftrag wird so festgelegt, dass er jeden Monat am letzten Tag des Monats ausgeführt wird.

Das folgende Fenster zeigt, dass das Runbook bearbeitet wurde, um Datensätze zu finden, und Löschbefehle enthält, die nicht wie das Skript angezeigt werden. Beachten Sie, dass die vollständige URL und der Benutzername für diese Screenshots angezeigt werden müssen, und ISVs müssen einen Screenshot der Datensatzanzahl vor dem Löschvorgang und einen Screenshot der Anzahl der Datensätze nach dem Löschen anzeigen. Diese Screenshots sind reine Beispiele für die verschiedenen Möglichkeiten, mit denen dies angegangen werden kann.

Datenzugriffsverwaltung

Der Datenzugriff muss auf so wenige Personen wie erforderlich beschränkt werden, um die Wahrscheinlichkeit zu verringern, dass Daten entweder böswillig oder versehentlich kompromittiert werden. Der Zugriff auf Daten und Verschlüsselungsschlüssel sollte auf Benutzer beschränkt sein, die einen legitimen geschäftlichen Bedarf an Zugriff haben, um ihre Berufliche Rolle zu erfüllen. Dies sollte gut dokumentiert sein und ein gut etablierter Prozess zum Anfordern des Zugriffs sollte implementiert werden. Der Zugriff auf Daten und Verschlüsselungsschlüssel sollte dem Prinzip der geringsten Rechte folgen.

Steuern Sie 10:P Eine Liste aller Personen genehmigen, die Zugriff auf Daten oder Verschlüsselungsschlüssel haben, einschließlich der geschäftlichen Begründung.

• Absicht: Organisationen sollten den Zugriff auf Daten und Verschlüsselungsschlüssel auf so wenige Mitarbeiter wie möglich beschränken. Mit dieser Kontrolle soll sichergestellt werden, dass der Zugriff der Mitarbeiter auf Daten und/oder Verschlüsselungsschlüssel auf Mitarbeiter beschränkt ist, die einen eindeutigen geschäftlichen Bedarf für diesen Zugriff haben.

• Beispielbeweisrichtlinien: Dokumentation oder Screenshots interner Systeme, die alle Mitarbeiter mit Zugriff auf Daten und/oder Verschlüsselungsschlüssel dokumentieren, zusammen mit der geschäftlichen Begründung, warum diese Personen Zugriff haben, sollten bereitgestellt werden. Diese Liste wird vom Zertifizierungsanalysten verwendet, um Benutzer für die nächsten Steuerelemente zu testen.

• Beispielbeweis: Das folgende Dokument zeigt die dokumentierte Liste der Benutzer mit Zugriff auf Daten und die geschäftliche Begründung.

Steuerung 11: Geben Sie nachweisbare Beweise dafür an, dass die personen, die in der Stichprobe Zugriff auf Daten oder Verschlüsselungsschlüssel haben, formal genehmigt wurden, wobei die für ihre Funktion erforderlichen Berechtigungen detailliert beschrieben werden.

• Absicht: Der Prozess zum Gewähren des Zugriffs auf Daten und/oder Verschlüsselungsschlüssel muss eine Genehmigung enthalten, um sicherzustellen, dass der Zugriff einer Person für ihre Funktion erforderlich ist. Dadurch wird sichergestellt, dass Mitarbeiter ohne echten Zugriffsgrund keinen unnötigen Zugriff erhalten.

• Beispielrichtlinien für Nachweise: In der Regel können die für das vorherige Steuerelement bereitgestellten Beweise dieses Steuerelement unterstützen. Wenn es keine formelle Genehmigung für die bereitgestellte Dokumentation gibt, kann der Beweis darin bestehen, dass eine Änderungsanforderung ausgelöst und für den Zugriff innerhalb eines Tools wie Azure DevOps oder Jira genehmigt wird.

• Beispielbeweis: Dieser Satz von Bildern zeigt Jira Tickets, die für die obige Liste in Control 10 erstellt und genehmigt wurden, um den Zugriff auf vertrauliche Daten und/oder Verschlüsselungsschlüssel zu gewähren oder zu verweigern.

Diese Abbildung zeigt, dass eine Anforderung in Jira erstellt wurde, um sam daily genehmigung für Verschlüsselungsschlüssel in der Back-End-Umgebung des Systems zu erhalten. Dies erfolgt als nächster Schritt, um 10 oben zu steuern, wo eine schriftliche Autorisierung erhalten wurde.

Dies zeigt, dass die Anforderung, Sam Daily Zugriff zu gewähren, von Jon Smith einer Person aus der Geschäftsleitung genehmigt wurde, die in Steuerung 10 zu sehen ist. (Bitte beachten Sie, dass die Genehmigung von einer Person mit ausreichender Autorität erfolgen muss, um die Änderungsanforderung zuzulassen, es darf sich nicht um einen anderen Entwickler handeln).)

Das obige Beispiel zeigt einen Workflow in Jira für diesen Prozess. Beachten Sie, dass nichts als Erledigt hinzugefügt werden kann, es sei denn, es wurde der Genehmigungsprozess durchlaufen, der automatisiert ist, kann daher nicht übergeben werden.

Im obigen Project Board wird nun gezeigt, dass Sam Dailys Zugriff auf Verschlüsselungsschlüssel genehmigt wurde. Unter dem Backlog werden die Anforderungsgenehmigung von Sam Daily und die Person angezeigt, die für die Arbeit zugewiesen wurde.

Um die Anforderungen dieses Steuerelements zu erfüllen, müssen Sie alle diese Screenshots oder ähnliches mit einer Erklärung anzeigen, um zu zeigen, dass Sie die Steuerungsanforderung erfüllt haben.

• Beispielbeweis 2: Im folgenden Beispiel wurden Administratorzugriff und Vollzugriffsberechtigungen für einen Benutzer für die Produktionsdatenbank angefordert. Die Anforderung wurde zur Genehmigung gesendet, wie auf der rechten Seite des Bilds zu sehen ist, und dies wurde genehmigt, wie Sie auf der linken Seite sehen können.

Oben sehen Sie, dass der Zugriff genehmigt und als erledigt abgemeldet wurde.

Steuerung 12: Stellen Sie einen nachweisbaren Beweis dafür bereit, dass die abgetasteten Personen, die Zugriff auf Daten oder Verschlüsselungsschlüssel haben, nur über die in der Genehmigung enthaltenen Berechtigungen verfügen.

• Absicht: Die Absicht dieses Steuerelements besteht darin, zu bestätigen, dass der Zugriff auf Daten und/oder Verschlüsselungsschlüssel gemäß der Dokumentation konfiguriert ist.

• Beispiel-Beweisrichtlinien: Der Nachweis könnte durch einen Screenshot bereitgestellt werden, der die Zugriffsberechtigungen für Daten und/oder Verschlüsselungsschlüssel zeigt, die den stichprobenierten Personen gewährt wurden. Nachweise müssen alle Speicherorte abdecken.

• Beispielbeweis: Dieser Screenshot zeigt die Berechtigungen, die dem Benutzer "John Smith" gewährt wurden, auf die mit der Genehmigungsanforderung für denselben Benutzer als Beweis für das vorherige Steuerelement verwiesen wird.

Steuerung 13: Stellen Sie eine Liste aller Drittanbieter bereit, für die Kundendaten freigegeben werden.

• Absicht: Wenn Drittanbieter für die Speicherung oder Verarbeitung von Microsoft 365-Daten verwendet werden, können diese Entitäten ein erhebliches Risiko darstellen. Organisationen sollten einen guten Due Diligence- und Managementprozess von Drittanbietern entwickeln, um sicherzustellen, dass diese Dritten Daten sicher speichern/verarbeiten, und um sicherzustellen, dass sie alle gesetzlichen Verpflichtungen einhalten, die sie möglicherweise haben, z. B. als Datenverarbeiter im Rahmen der DSGVO.

• Organisationen sollten eine Liste aller Drittanbieter führen, mit denen sie Daten mit einigen oder allen folgenden Teilen teilen:

• welche Dienste bereitgestellt werden(werden),

• welche Daten freigegeben werden,

• warum die Daten freigegeben werden,

• Wichtige Kontaktinformationen (d. h. Hauptkontakt, Kontakt zur Benachrichtigung von Sicherheitsverletzungen, DPO usw.),

• Vertragsverlängerung/Ablauf

• Rechtliche/Compliance-Verpflichtungen (d. h. DSGVO, HIPPA, PCI DSS, FedRamp usw.)

• Beispielrichtlinien für Nachweise: Stellen Sie eine Dokumentation bereit, die alle Drittanbieter enthält, für die Microsoft 365-Daten freigegeben werden.

Anmerkung: Wenn Dritte nicht in Gebrauch sind, muss dies schriftlich (E-Mail) von einem Mitglied der Geschäftsleitung bestätigt werden.

• Beispielbeweis 1

• Beispielbeweis 2: Dieser Screenshot zeigt ein E-Mail-Beispiel für ein Mitglied des Leitenden Führungsteams, das bestätigt, dass keine Drittanbieter zur Verarbeitung von Microsoft 365-Daten verwendet werden.

Kontrolle 14: Stellen Sie nachweisbare Beweise dafür bereit, dass alle Drittanbieter, die Kundendaten nutzen, über Freigabevereinbarungen verfügen.

• Absicht: Wenn Microsoft 365-Daten für Dritte freigegeben werden, ist es wichtig, dass Die Daten angemessen und sicher verarbeitet werden. Vereinbarungen zur Datenfreigabe müssen eingerichtet werden, um sicherzustellen, dass Dritte Daten nur nach Bedarf verarbeiten und dass sie ihre Sicherheitsverpflichtungen verstehen. Die Sicherheit einer Organisation ist nur so stark wie das schwächste Glied. Mit dieser Kontrolle soll sichergestellt werden, dass Dritte nicht zu einem schwachen Glied einer Organisation werden.

• Beispielbeweisrichtlinien: Teilen Sie die Vereinbarungen zur Datenfreigabe, die mit den Drittanbietern bestehen.

• Beispielbeweis: Der folgende Screenshot zeigt ein einfaches Beispiel für die Datenfreigabevereinbarung.

Anmerkung: Die vollständige Vereinbarung sollte geteilt werden und kein Screenshot.

DSGVO

Die meisten Organisationen werden Daten verarbeiten, bei denen es sich potenziell um Daten eines europäischen Bürgers (betroffene Personen) handelt. Wenn Daten einer betroffenen Person verarbeitet werden, müssen Organisationen die Datenschutz-Grundverordnung (DSGVO) einhalten. Dies gilt sowohl für Datenverantwortliche (Sie erfassen diese Daten direkt) als auch für Datenverarbeiter (Sie verarbeiten diese Daten im Auftrag eines Datenverantwortlichen). Obwohl in diesem Abschnitt nicht die gesamte Verordnung behandelt wird, werden einige der wichtigsten Elemente der DSGVO behandelt, um zu gewährleisten, dass die Organisation die DSGVO ernst nimmt.

Kontrolle 15: Stellen Sie einen dokumentierten Antrag auf Antragstellerzugriff (Subject Access Request, SAR) bereit, und stellen Sie Beweise bereit, die belegen, dass die betroffenen Personen in der Lage sind, SARs zu erheben.

• Absicht: Die DSGVO enthält bestimmte Verpflichtungen, die von Organisationen erfüllt werden müssen, die Daten betroffener Personen verarbeiten. Die Verpflichtung für Organisationen zur Verwaltung von Anträgen auf Zugang zu Antragstellern (Subject Access Requests, SARs) ist in Artikel 12 enthalten, der gemäß Artikel 12.3 einem Datenverantwortlichen einen Monat nach Erhalt der SAR zur Beantwortung des Ersuchens gewährt. Eine Verlängerung ist bei Bedarf um weitere zwei Monate zulässig. Auch wenn Ihre Organisation als Datenverarbeiter fungiert, ist dies weiterhin erforderlich, um Ihren Kunden (dem Datenverantwortlichen) bei der Erfüllung ihrer SARs-Verpflichtungen zu helfen.

• Beispielbeweisrichtlinien: Geben Sie den dokumentierten Prozess für die Behandlung von SARs an.

• Beispielbeweis: Das folgende Beispiel zeigt einen dokumentierten Prozess für die Behandlung von SARs.

Anmerkung: Dieser Screenshot zeigt ein Richtlinien-/Prozessdokument. Es wird erwartet, dass ISVs die tatsächliche unterstützende Richtlinien-/Verfahrensdokumentation freigeben und nicht einfach einen Screenshot bereitstellen.

Steuerung 16: Stellen Sie nachweisbare Beweise bereit, dass Sie alle Speicherorte der Daten betroffener Personen identifizieren können, wenn Sie auf eine SAR reagieren.

• Absicht: Mit diesem Steuerelement soll sichergestellt werden, dass die Organisation über einen stabilen Mechanismus verfügt, um die Daten aller betroffenen Personen zu identifizieren. Dies kann ein manueller Prozess sein, da die gesamte Datenspeicherung gut dokumentiert ist oder andere Tools verwendet werden können, um sicherzustellen, dass alle Daten im Rahmen des SARs-Prozesses gespeichert werden.

• Beispielbeweisrichtlinien: Der Nachweis kann über eine Liste aller Datenspeicherorte und einen dokumentierten Prozess zum Durchsuchen aller Speicherorte nach Daten bereitgestellt werden. Dies würde alle erforderlichen Befehle zum Suchen nach Daten umfassen, d. h., wenn SQL-Speicherorte eingeschlossen sind, werden bestimmte SQL-Anweisungen detailliert beschrieben, um sicherzustellen, dass die Daten ordnungsgemäß gefunden werden.

• Beispielbeweis: Der folgende Screenshot ist ein Codeausschnitt aus der obigen SAR-Prozedur, der zeigt, wie Daten gefunden werden.

Die folgenden vier Abbildungen zeigen, wie die ISV-Datenspeicherorte abgefragt wurden, und dann der Storage-Explorer verwendet, um einen Drilldown zu den Dateien oder Blobs auszuführen, die aus dem Speicher entfernt werden mussten, um die SARs-Anforderung zu erfüllen.

Diese Abfrage bestätigt die verwendeten Speicherkonten. Sie können Speicher, Blobs und/oder Dateien mithilfe von Resource Graph-Explorer (Kusto) oder PowerShell (siehe unten) abfragen und entfernen.

Die obige Abbildung zeigt die Daten, die im Blobcontainer für den Client gefunden wurden, der entfernt werden muss, und unten die Aktion zum Löschen oder vorläufigen Löschen der Informationen im Blob.

Steuerung 17: Geben Sie einen Link zum Datenschutzhinweis an, der alle erforderlichen Elemente wie folgt enthalten sollte:

• Firmendetails (Name, Adresse usw.).

• Details zu den Arten von personenbezogenen Daten, die verarbeitet werden.

• Details zur Rechtmäßigkeit der Verarbeitung personenbezogener Daten.

• Details zu den Rechten der betroffenen Person:

  • Auskunftsrecht,
  • Auskunftsrecht der betroffenen Person,
  • Recht auf Löschung,
  • Recht auf Einschränkung der Verarbeitung,
  • Recht auf Datenübertragbarkeit,
  • Widerspruchsrecht,
  • Rechte im Zusammenhang mit automatisierter Entscheidungsfindung, einschließlich Profilerstellung.

• Gibt an, wie lange personenbezogene Daten aufbewahrt werden.

• Absicht: Artikel 13 der DSGVO enthält spezifische Informationen, die betroffenen Personen zum Zeitpunkt des Erhalts personenbezogener Daten zur Verfügung gestellt werden müssen. Mit dieser Kontrolle soll sichergestellt werden, dass die Datenschutzhinweise der Organisationen den betroffenen Personen einige der wichtigsten Informationen in Artikel 13 zur Verfügung stellen.

• Beispielbeweisrichtlinien: Dies wird in der Regel durch Die Bereitstellung des Datenschutzhinweises bereitgestellt. Zertifizierungsanalysten überprüfen dies, um sicherzustellen, dass alle informationen, die innerhalb der Kontrolle bereitgestellt werden, in den Datenschutzhinweisen aufgenommen werden.

• Beispielbeweis

Die Bilder einer obigen und angrenzenden Datenschutzerklärung zeigen ein Beispiel für eine Online-Datenschutzrichtlinie mit Artikel 13 der DSGVO.

Nachfolgend finden Sie eine Datenschutzrichtlinie, die in Verbindung mit dem zuvor gezeigten Datenschutzhinweis verwendet werden kann.

Die obige Abbildung von Azure zeigt, wie Azure so konfiguriert wurde, dass es die Complianceanforderungen der DSGVO für Daten erfüllt, die in einer Back-End-Umgebung gespeichert sind. Die Richtlinie (die benutzerdefinierte oder aus Azure Blueprints erstellt werden kann) ermöglicht es dem ISV, sicherzustellen, dass die Daten des Clients ordnungsgemäß gespeichert werden und dass nur durch die festgelegten Metriken und Warnungen darauf zugegriffen werden kann, um die Konformität sicherzustellen, und zeigt nicht kompatible Daten oder den Benutzerzugriff auf dem Compliance Manager-Dashboard an.

Bücher

Murdoch D. (2018) Blue Team Handbook: Incident Response Edition: A condensed field guide for the Cyber Security Incident Responder. 2. Auflage, Herausgeber: CreateSpace Independent Publishing Platform.

Verweise

• Action Fraud Cyber Crime Reporting Verfügbar unter: https://www.actionfraud.police.uk/ (Zugriff am 08/02/21).
• EU. (2021) DSGVO-Checkliste für Datenverantwortliche Verfügbar unter: https://gdpr.eu/checklist/ (Zugriff am 02.01.21).
• Microsoft. (2018) Ereignisprotokollierung (Windows Installer) Verfügbar unter: Ereignisprotokollierung (Windows Installer) (Zugriff: 23/12/20).
• Positive Technologien. (2020) Vorgehensweise bei der sicheren Softwareentwicklung Verfügbar unter: https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/(Zugriff: 21/12/20).
• Verordnung (EU) 2016/679 des Europäischen Parlaments und des Rates vom 27. April 2016 zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten und zum freien Verkehr dieser Daten und zur Aufhebung der Richtlinie 95/46/EG (Datenschutz-Grundverordnung) (Text von Bedeutung für den EWR) (2016) Verfügbar unter: https://www.legislation.gov.uk/eur/2016/679/contents (Zugriff: 01.11.2021).
• Sicherheitsmetriken. (2020) Leitfaden zu Sicherheitsmetriken zur PCI-DSS-Compliance. Verfügbar unter: https://info.securitymetrics.com/pci-guide-2020(Zugriff: 06.01.21).
• Williams J. OWASP Risk Ranking Verfügbar unter: https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (Zugriff: 08/12/20).
• Qualys. (2014) SSL Labs: New Grades for Trust (T) and Mismatch (M) Issues Available at: https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-mismatch-m-issues (Zugriff: 29/01/21).
• NIST SP800-61r2: Leitfaden zur Behandlung von Computersicherheitsvorfällen Verfügbar unter:https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (Zugriff am 24.01.21).

Bilder aus Microsoft-Dokumenten

• https://www.sans.org/information-security-policy/(Aufgerufen am 18/02/21). unter Get behavior analytics and anomaly detection (Get behavior analytics and anomaly detection (Zugriff am 16/02/21). in Was sind Azure Monitor-Warnungen? (Zugriff am 17.02.21). in Abrufen von Verhaltensanalysen und Anomalieerkennung (Zugriff am 22/02/21). unter Verwalten und Reagieren auf Sicherheitswarnungen in Microsoft Defender für Cloud (Zugriff am 24.02.21). unter Verwalten und Reagieren auf Sicherheitswarnungen in Microsoft Defender für Cloud (Zugriff am 24.02.21).
• https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html in Was ist Azure Information Protection? in Transparent Data Encryption for SQL Database, SQL Managed Instance und Azure Synapse Analytics in Schnellstart: Erstellen einer Richtlinienzuweisung zum Identifizieren nicht konformer Ressourcen unter Konfigurieren von Advanced Threat Protection für Azure SQL-Datenbank