Migration mit Hindernissen : Erfahrungen aus der Umsetzung eines IT-Grundschutz-Migrationskonzepts

Von Sebastian Reinhardt, Hussein Baydoun und Tobias Goldschmidt, Berlin

Mit der IT-Grundschutz-Methodik des BSI können Unternehmen und Behörden (im Folgenden kurz: Institutionen) ein Informationssicherheitsmanagementsystem (ISMS) effektiv und effizient aufbauen sowie betreiben. Der seit 2005 existierende IT-Grundschutz (s. a. [1]) wurde vom BSI 2018 offiziell durch den modernisierten IT-Grundschutz ersetzt. Sowohl die BSI-Standards als auch die IT-Grundschutz-Kataloge wurden aktualisiert – Letztere durch das IT-Grundschutz-Kompendium ersetzt. Seit dem 1. Oktober 2018 sind Zertifizierungsanträge auf Basis der Prüfungsgrundlage „IT-Grundschutz-Kataloge“ nicht mehr möglich (vgl. [2]).

Der IT-Grundschutz hat sich methodisch, in Teilen sogar signifikant, verändert (vgl. [3]). Die Risikoanalyse nach BSI-Standard 200-3 weist beispielsweise deutliche Veränderungen im Vergleich zum alten BSI-Standard 100-3 auf – aufgrund der veränderten Bewertungskriterien muss sie vollständig neu durchgeführt werden. Auch den IT-Grundschutz-Check (GSC – vormals „Basis-Sicherheitscheck“) muss man in großen Teilen erneut durchführen, da eine Eins-zu-Eins-Zuordnung des IT-Grundschutz-Maßnahmen-Katalogs auf die Anforderungen des IT-Grundschutz-Kompendiums zumeist nur sehr eingeschränkt möglich ist.

Die IT-Grundschutz-Methodik wird in der Praxis selten vollständig – wie vom BSI vorgegeben – umgesetzt, da Institutionen von individuellen Gegebenheiten geprägt sind. Diese sind von regulatorischen und gesetzlichen Anforderungen sowie marktsituativen und personellen Faktoren abhängig und wirken sich auf sämtliche Bereiche aus. Meist kommt daher eine auf die Anforderungen der Institution angepasste IT-Grundschutz-Vorgehensweise zur Anwendung. Solche Anpassungen erschweren eine standardisierte Migrationsvorgehensweise.

Zeitgleich setzen viele Institutionen ISMS-Software-Tools ein, welche die IT-Grundschutz-Methodik (zumeist nach der Interpretation des Softwareherstellers) abbilden und Anwender in den verschiedenen Phasen des IT-Grundschutzes unterstützen. Am Markt existiert jedoch kein ISMS-Software-Tool, das eine spezifische IT-Grundschutz-Vorgehensweise ohne jegliche Anpassungen an die Institution umsetzen kann. Vor allem bei der Abbildung von sehr großen und komplexen Informationsverbünden sind signifikante Anpassungen unumgänglich.

Anwendungsbeispiel

Der <kes>-Artikel „Praxisbericht: Migration zum IT-Grundschutz-Kompendium“ [4] unterstrich bereits im Juni 2019 die Notwendigkeit eines Migrationskonzepts und bot eine erste Orientierung für bevorstehende Umstellungen. Dem Praxisbeispiel wurde ein Unternehmen zugrunde gelegt, das bereits über eine ISO-27001-Zertifizierung auf Basis von IT-Grundschutz verfügte und sich seit mehreren Jahren im Migrationsprozess befand. Neben der Aufrechterhaltung der bestehenden Zertifizierung waren eine Reihe weiterer regulatorischer Auflagen, beispielsweise die KRITIS-Verordnung (für kritische Infrastrukturen), zu erfüllen. Der Zertifizierungsverbund umfasste den IT-Betrieb mit einer vierstelligen Anzahl an Mitarbeitern in mehreren Standorten sowie IT-Systeme im sechsstelligen Bereich in einer heterogenen IT-Landschaft mit Containerlösungen, Microservices und vielen weiteren im IT-Betrieb eingesetzten Verfahren.

Aufgrund der Komplexität der infrastrukturellen und technischen Gegebenheiten wurde der Zertifizierungsverbund in mehrere Teilinformationsverbünde untergliedert, die sowohl in direkter als auch indirekter Abhängigkeit untereinander stehen. Ein Teilinformationsverbund beschränkt sich dabei auf einen bestimmten definierten Prozess im Geltungsbereich des Zertifizierungsverbunds und ist eindeutig von anderen Teilinformationsverbünden abgegrenzt.

Zur Aufrechterhaltung eines ISMS dieser Größenordnung, wurde zuvor eine eigens angepasste zertifizierungsfähige IT-Grundschutz-Vorgehensweise nach BSI-Standard 100-2 mit einem ebenso angepasstem ISMS Software-Tool eingesetzt. Für die Umsetzung der angepassten IT-Grundschutz-Vorgehensweise wurden verschiedene auf dem Markt erhältliche ISMS Software-Tools evaluiert – das final einzusetzende will man weiterentwickeln, um der individuellen Methodik gerecht zu werden. Das vorhandene ISMS-Software-Tool kann das Unternehmen aufgrund der vielschichtigen Anpassungen sowie der damit einhergehenden Inkompatibilität zur neu veröffentlichten Softwareversion desselben Herstellers nicht länger verwenden.

Ursprüngliches Migrationskonzept

Das im Jahr 2019 vorgestellte Migrationskonzept stellt die einzelnen IT-Grundschutz-Phasen tabellarisch dar, um Unterschiede zwischen den BSI-Standards 100-2/ 100-3 und 200-2/200-3 detailliert aufzuzeigen. Das Ergebnis zeigt die notwendigen Änderungen an der angepassten IT-Grundschutz-Vorgehensweise (vgl. Abb. 1).

Die Umsetzung dieses Migrationskonzepts war sowohl durch Erfolge als auch Misserfolge geprägt – es zeigten sich unerwartete Herausforderungen, die im Vorfeld nicht im notwendigen Detaillierungsgrad berücksichtigt worden sind. Die folgenden Abschnitte erläutern die Vorgehensweise in den einzelnen IT-Grundschutz-Phasen.

Phase „Definition Informationsverbund“

Im direkten Vergleich zwischen dem BSI-Standard 100-2 und 200-2 sind in der Phase der Definition des Informationsverbunds keine gravierenden Unterschiede erkennbar. Lediglich in der Absicherungsvariante bietet der BSI-Standard 200-2 eine Basis-, Kern- und Standard-Absicherung. Im Beispielunternehmen wird ausschließlich die Standard-Absicherung durchgeführt, die mit der Vorgehensweise nach BSI-Standard 100-2 vergleichbar ist.

Der Reifegrad des ISMS im Beispielunternehmen ist dabei soweit fortgeschritten, dass eine andere Absicherungsvariante als nicht sinnvoll betrachtet wird.

Der Informationsverbund umfasst mehrere eigenständige Teilinformationsverbünde (vgl. Abb. 2), die in gegenseitiger Abhängigkeit zueinander stehen. Eine Anpassung der IT-Grundschutz-Vorgehensweise ist somit unumgänglich: Aufgrund der Abhängigkeiten der Teilinformationsverbünde ist es notwendig, dass diese mittels sogenannter Services aufeinander verweisen, da für die Erfüllung eines Sicherheitsprozesses bestimmte Zielobjekte (Anwendungen, IT-Systeme, Räume, Gebäude) benötigt werden. Mithilfe solcher Services kann ein Teilinformationsverbund einem anderen nutzenden Teilinformationsverbund bestimmte Zielobjekte bereitstellen. Der Nutzer bezieht hier nur noch eine Referenz (inkl. der bereits umgesetzten IT-Grundschutz-Anforderungen) für einen definierten Schutzbedarf vom Bereitsteller. Ausschließlich Änderungen am genutzten Service werden durch den Nutzer des Services im eigenen Teilinformationsverbund durch zusätzlich umzusetzende Anforderungen berücksichtigt.

Aufgrund der gleichbleibenden Vorgehensweise ist das Migrationskonzept auf diese Phase unverändert anzuwenden. ISMS-Software-Tool-spezifisch waren jedoch unvorhersehbare signifikante Anpassungen notwendig: Die Zuordnung von unterschiedlichen Teilinformationsverbünden zu den jeweiligen Informationsverbünden erwies sich als besondere Herausforderung und war im eingesetzten ISMS-Software-Tool ohne entsprechende Anpassungen nicht möglich. Erst durch die notwendigen Anpassungen ließ sich die Phase vollständig abschließen.

Phase „Strukturanalyse“

Im Rahmen der Strukturanalyse sind neben den Zielobjektetypen Anwendungen, IT-Systeme oder Räume und Gebäude nach dem BSI-Standard 200-2 auch Prozesse als Zielobjekttyp aufzunehmen sowie Abhängigkeiten untereinander darzustellen. Im Rahmen der angepassten Vorgehensweise nach BSI-Standard 100-2 wurden im Beispielunternehmen ursprünglich die in Tabelle 1 dargestellten Zielobjekttypen aufgenommen.

Im Rahmen der Migration fand eine signifikante Verschlankung der Zielobjekttypen statt. Software-Komponenten und IT-Anwendungen als übergeordnetes Anwendungscluster wurden im Zielobjekttyp Anwendungen zusammengefasst. Der Zielobjekttyp IT-Systeme deckt nun die bisherigen Zielobjekttypen Clients, Server, Notebooks, Drucker, Speichersysteme und aktive Netzwerkgeräte ab. Der zusätzliche Zielobjekttyp Prozesse stellt im Beispielunternehmen den zentralen Fokus des Teilinformationsverbundes dar (Tab. 2).

Der zusammengefasste Zielobjekttyp Anwendungen kann als übergeordnetes Anwendungscluster oder als typische IT-Anwendungen verwendet werden. Übergeordnete Anwendungscluster fungieren als Rahmen für weitere Teil-Anwendungen (siehe Abb. 3). Dieses Konstrukt ist besonders bei modularen Anwendungen oder bei Anwendungen, die durch verschiedene Software-Komponenten realisiert werden, sinnvoll.

Im Rahmen der Strukturanalyse lassen sich die genannten Zielobjekttypen ebenfalls als Services erfassen. Der Service-Bereitsteller muss hierbei eine Servicebeschreibung liefern, damit der Nutzer erfährt, wofür ein bestimmter Service genutzt werden kann.

Das Migrationskonzept lässt sich unverändert auf diese Phase übertragen. In der Umsetzung gibt es keine Abweichungen, weder an der Vorgehensweise noch am ISMS-Software-Tool sind zusätzliche Anpassungen notwendig.

Phase „Schutzbedarfsfeststellung“

Die Schutzbedarfsfeststellung nach BSI-Standard 200-2 basiert auf der grundsätzlichen Frage, welcher Schaden entstehen kann, wenn für ein Zielobjekt die Grundwerte Vertraulichkeit, Integrität oder Verfügbarkeit verletzt werden – die Beantwortung dieser Frage definiert den Schutzbedarf des Zielobjekts. Hierzu empfiehlt der IT-Grundschutz die Verwendung der Schutzbedarfskategorien mit den Ausprägungen normal, hoch und sehr hoch sowie dazugehörige Schadensszenarien.

Schadensszenarien können Verstöße gegen Gesetze, Vorschriften oder Verträge, Beeinträchtigungen des informationellen Selbstbestimmungsrechts, Beeinträchtigungen der persönlichen Unversehrtheit oder der Aufgabenerfüllung, negative Innen- oder Außenwirkung sowie finanzielle Auswirkungen umfassen. Es liegt im Ermessen von Institutionen, selbst definierte oder die vom BSI empfohlenen Schutzbedarfskategorien und/oder Schadensszenarien zu nutzen.

Nach BSI-Standard 100-2 bilden hingegen Anwendungen die Grundlage der Schutzbedarfsfeststellung. Das Zielobjekt Prozesse stellt im Rahmen der Schutzbedarfsfeststellung nach BSI-Standard 200-2 den kleinsten gemeinsamen Nenner dar – und von diesem geht auch der Schutzbedarf aus. Der Schutzbedarf von Prozessen vererbt sich auf den der Anwendungen, IT-Systeme, Netze, Räume und Kommunikationsverbindungen.

Diese Vorgehensweise bewertet und berücksichtigt ausschließlich Prozesse – sowohl im Rahmen der Schutzbedarfsfeststellung als auch bei der Vererbung. Zugehörige Anwendungen erhalten daher den gleichen Schutzbedarf (siehe Abb. 4).

Weil Prozesse weniger feingranular sind als Anwendungen, kann es so zu einer stark undifferenzierten Weitervererbung des Schutzbedarfs kommen. Daher wird im Beispielunternehmen nun eine zusätzliche Schicht Daten als kleinster gemeinsamer Nenner eingefügt, von dem der Schutzbedarf ausgehen soll. So lässt sich eine präzise Weitervererbung des Schutzbedarfs sicherstellen.

Neben dem Erfassen und Bewerten des Schutzbedarfs individueller Daten werden im Rahmen der Migration zentrale Datencluster mit hinterlegtem Schutzbedarf zur Verfügung gestellt. Datencluster beschreiben typische Datenobjekte, wie Account-Daten oder technische Konfigurationsdaten. Der Schutzbedarf dieser Datencluster wird zentral gesteuert und jeder Teilinformationsverbund kann sich ihrer bedienen, sofern sie für ihn zutreffen. Der Aufwand sowie die Anzahl der Schutzbedarfsfeststellungen lassen sich hiermit signifikant verringern.

Bei der Schutzbedarfsvererbung hat der zugehörige Prozess weiterhin den gleichen Schutzbedarf, die zugehörigen Anwendungen sind jedoch differenzierter eingestuft (siehe Abb. 5). Die weitere Vererbung des Schutzbedarfs geschieht anschließend anhand der klassischen BSI-Schutzbedarfsvererbung. Überdies erwies sich die Darstellung zentraler Datencluster als größere Herausforderung, die zusätzliche Anpassungen am ISMS-Software-Tool nach sich zieht. Das Migrationskonzept lässt sich abgesehen davon auf die Phase der Schutzbedarfsfeststellung unverändert übertragen.

Phase „Modellierung“

Bei der Modellierung werden diejenigen IT-Grundschutz-Bausteine ausgewählt, die man für die Sicherheit der betrachteten Teilinformationsverbünde benötigt. Das Bereitstellen von Services durch die Teilinformationsverbünde hat Auswirkungen auf die Modellierungsphase des IT-Grundschutzes: Der Nutzer der bereitgestellten Services muss keine gesonderte Betrachtung in der Modellierung vornehmen, da diese bereits durch den Bereitsteller mit entsprechenden IT-Grundschutz-Bausteinen modelliert werden. Stattdessen wird nur noch der als Baustein fungierende (bereitstellende) Teilinformationsverbund durch den Nutzer modelliert. Die Dokumentation der Umsetzung der IT-Grundschutz-Anforderungen lässt sich somit nachvollziehen.

Zusätzlich gibt es im Beispielunternehmen auch noch das Sonderkonstrukt von übergreifenden Objekten: Im IT-Grundschutz-Kompendium gibt es Bausteine, die auf den gesamten Informationsverbund einmal anzuwenden sind, aber Auswirkungen auf einzelne Zielobjekte haben können. CON.4 „Standardsoftware“ ist beispielsweise ein solcher IT-Grundschutz-Baustein. Übergeordnete IT-Grundschutz-Bausteine müssen nicht durch die Teilinformationsverbünde gesondert modelliert und betrachtet werden, sondern werden über die übergreifenden Objekte bereits umgesetzt. Aufgrund der Teilinformationsverbünde des Beispielunternehmens ist es jedoch sehr schwierig zu entscheiden, wo solche IT-Grundschutz-Bausteine angesiedelt sind.

Im Rahmen der Modellierung bietet das ISMS-Software-Tool im Beispielunternehmen eine automatische und manuelle Zuordnung von Bausteinen an: Bei der manuellen Modellierung sind die Modellierungsanweisungen im IT-Grundschutz-Kompendium zu beachten – bei der automatischen Modellierung werden diese inhärent unterstützt.

Diese Besonderheiten (Verwendung von Services und übergreifenden Objekten) wurden im Rahmen des Migrationskonzepts berücksichtigt, erschweren jedoch die notwendigen Anpassungen im ISMS-Software-Tool und die vollständige Übertragung des Migrationskonzepts auf diese Phase. Dies führte zu einem höheren Aufwand und Verzögerungen in der Umsetzung der Modellierung.

Phase „Risikoanalyse“

Die neue Risikomanagement-Methodik des IT-Grundschutzes unterscheidet sich signifikant von der zuvor nach BSI-Standard 100-3 etablierten. Anhand der in Tabelle 3 dargestellten Bewertungsmetriken lassen sich die Unterschiede der Methodik des BSI-Standards 100-3 und 200-3 am besten feststellen.

Der BSI-Standard 200-3 stellt für die Vorbereitung der Risikoanalyse drei grundlegende Phasen vor:

• Erstellung einer Gefährdungsübersicht
• Risikoeinstufung
• Behandlung von Risiken

In der Vorbereitungsphase werden relevante Zielobjekte für eine Risikoanalyse vorgemerkt. Eine Risikoanalyse ist zwingend durchzuführen,

• wenn Zielobjekte in mindestens einem der Grundwerte einen hohen oder sehr hohen Schutzbedarf aufweisen,
• wenn sich Zielobjekte mit existierenden Bausteinen des IT-Grundschutz-Kompendiums nicht hinreichend modellieren lassen und/oder
• wenn Zielobjekte in Einsatzszenarien betrieben werden, die im Rahmen des eingesetzten Bausteins nicht vorgesehen sind.

Der BSI-Standard 200-3 empfiehlt zwar ausdrücklich eine Risikoanalyse – bei stichhaltiger Begründung und in Ausnahmefällen ist es jedoch möglich, diese nicht vollständig durchzuführen, auch wenn eines der genannten Kriterien erfüllt wird. Dies ist besonders praktisch, wenn eine Institution eine hohe Anzahl an Risikoanalysen durchführt und diese gruppieren möchte.

Die Begründung der Notwendigkeit einer Risikoanalyse (ehemals „ergänzende Sicherheitsanalyse“) entfällt nach BSI-Standard 200-3. Im Beispielunternehmen wird trotzdem die Phase „Vorbereitung der Risikoanalyse“ sowohl in der angepassten IT-Grundschutz-Vorgehensweise als auch im ISMS-Software-Tool eingeführt, um die Notwendigkeit der Risikoanalyse begründen zu können – hiervon wird besonders oft Gebrauch gemacht. So werden beispielsweise Anwendungscluster gebildet, damit ein Teilinformationsverbund nicht viele Risikoanalysen durchführen muss: Die Cluster fassen mehrere Anwendungen zusammen, die man anschließend in einer einzelnen Risikoanalyse betrachtet. Die Teil-Anwendungen müssen dann lediglich auf die bereits für den Anwendungscluster durchgeführte Risikoanalyse verweisen.

In der Phase „Gefährdungsübersicht“ werden alle relevanten Gefährdungen für die Zielobjekte aufgelistet, die einer Risikoanalyse unterzogen werden müssen. Diese Auflistung generiert das eingesetzte ISMS-Software-Tool im Beispielunternehmen automatisch. Grundsätzlich setzt sich die Gefährdungsübersicht aus den Gefährdungen aller modellierten Bausteine zusammen. Wurden keine Bausteine modelliert, ist die Gefährdungsübersicht manuell um weitere elementare Gefährdungen (aus der Liste der 47 elementaren Gefährdungen) zu erweitern.

Nach der Erstellung der Gefährdungsübersicht sind die Gefährdungen in der Risikoeinstufung nach Eintrittswahrscheinlichkeit und Schadenshöhe zu bewerten. Hierbei ließen sich aus den vorliegenden Ergebnissen der nach BSI-Standard 100-3 erstellten Risikoanalysen im Beispielunternehmen zwar kleinere Rückschlüsse ziehen, jedoch keineswegs übertragen – diese Einstufung musste somit vollständig neu durchgeführt werden.

Auf Basis der Risikoeinstufung wird die weitere Risikobehandlung definiert – das BSI definiert dabei vier unterschiedliche Risikobehandlungsmethoden:

• Risikovermeidung
• Risikoreduktion
• Risikotransfer
• Risikoakzeptanz

Im Beispielunternehmen wurde hauptsächlich Risikoreduktion ausgewählt – an einigen Stellen auch Risikoakzeptanz. In der Risikoanalyse nach BSI-Standard 100-3 werden bei der Auswahl der Risikoreduktion entsprechende Maßnahmen ausgewählt. Im IT-Grundschutz-Kompendium gibt es keine verbindlichen Maßnahmen mehr, sondern nur noch Anforderungen, weswegen sich die Ergebnisse aus der früheren Risikoanalyse nicht übertragen lassen.

Aufgrund der genannten Unterschiede waren im Beispielunternehmen sämtliche Risikoanalysen nach BSI-Standard 200-3 vollständig neu durchzuführen. Die Risikoanalyse nach dem BSI-Standard 200-3 ist insgesamt sehr zeitaufwendig und sollte sofern möglich konsolidiert durchgeführt werden.

Phase „IT-Grundschutz-Check“

Der IT-Grundschutz-Check (GSC) beschreibt den Soll-Ist-Vergleich zwischen Anforderungen und tatsächlich umgesetzten Sicherheitsmaßnahmen. Im BSI-Standard 100-2 wird dieser noch Basis-Sicherheitscheck (BSC) genannt – methodisch hat sich jedoch an dieser Phase nichts verändert.

Wesentlich ist lediglich der Umstieg von Maßnahmen auf Anforderungen im IT-Grundschutz-Kompendium: Im GSC werden nun keine spezifischen Maßnahmen mehr abgefragt, sondern nur Anforderungen. Erfahrungsgemäß lassen sich etwa 20 % der Ergebnisse aus dem BSC direkt übernehmen, der Rest muss – wie auch im Beispielunternehmen – erneut abgefragt werden. Jede Anforderung im IT-Grundschutz-Kompendium besteht aus mehreren Teilanforderungen, die im GSC in geeigneter Weise berücksichtigt werden und auf die dazugehörigen Nachweisdokumente verweisen müssen. In bisherigen ISO-27001-Zertifizierungen auf Basis von IT-Grundschutz wurden die erforderlichen Referenzdokumente ausschließlich durch den Auditor geprüft. Zukünftig muss im Rahmen der Zertifizierung das A4-Referenzdokument (Ergebnisse des IT-GrundschutzChecks) der Zertifizierungsstelle zur Prüfung vorgelegt werden. Daher ist für die Durchführung des GSC ein einheitlicher Qualitätsstandard in der Dokumentation der Ergebnisse einzuführen und zu forcieren. Diese Vorgehensweise wurde im Rahmen der Umsetzung des GSC im Beispielunternehmen integriert und durchgehend angewendet.

Fazit

Das im Beispiel betrachtete Unternehmen hält seit mehreren Jahren erfolgreich eine ISO27001-Zertifizierung auf Basis von IT-Grundschutz aufrecht. Bereits vor der Modernisierung des IT-Grundschutzes wurde aufgrund von vielschichtigen regulatorischen Anforderungen eine stark angepasste IT-Grundschutz-Vorgehensweise eingesetzt. Diese galt es im Rahmen der Migration weiter anzupassen, um die Änderungen an der Vorgehensweise nach BSI-Standard 200-2 wirtschaftlich zu integrieren sowie notwendige Anpassungen am einzusetzenden ISMS-Software-Tool auf ein Mindestmaß zu beschränken.

Die Migration auf die neuen BSI-Standards 200-1, 200-2 und 200-3 bewirkte eine Reihe spezifischer Herausforderungen, die in der Praxis individuelle Lösungen erfordern. Aufgrund der komplexen Gegebenheiten traten Hindernisse auf, die im Vorfeld nicht in der notwendigen Tiefe identifiziert werden konnten. Die Migration selbst stellt einen erheblichen Ressourcenaufwand dar – nicht zuletzt aufgrund eines zu parallelisierenden ISMS. Mittels eines zuvor definierten Migrationskonzepts, das sämtliche IT-Grundschutz-Phasen abdeckt, und eines entsprechend dediziert angepassten ISMS-Software-Tools konnte die Migration dennoch erfolgreich unternehmensweit umgesetzt werden.

Sebastian Reinhardt, Hussein Baydoun und Tobias Goldschmidt sind Berater der HiSolutions AG im Bereich Security Consulting.

Literatur

[1] Holger Schildt, 25 Jahre IT-Grundschutz 1994–2019, Vortragsfolien, Oktober 2019, www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/4GS_Tag_2019/Schildt_4GSTag_25Jahre.pdf?__blob=publicationFile
[2] Bundesamt für Sicherheit in der Informationstechnik (BSI), Prüfgrundlage für Zertifizierungen nach ISO 27001 auf der Basis von IT-Grundschutz nach dem ITGrundschutz-Kompendium, Version 4.3, Februar 2020, www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Zertifikat/Veroeffentl/Pruefgrundlagen_Kompendium.pdf?__blob=publicationFile
[3] Bundesamt für Sicherheit in der Informationstechnik (BSI), Anleitung zur Migration von Sicherheitskonzepten, Hilfsmittel zum modernisierten IT-Grundschutz, Version 1.1, Oktober 2018, www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium/Anleitung_zur_Migration.pdf?__blob=publicationFile
[4] Sebastian Reinhardt, Hussein Baydoun, Tobias Goldschmidt, Praxisbericht: Migration zum IT-Grundschutz- Kompendium, <kes> 2019#3, S. 43