LF-Basistestat Hochschulen: Unterschied zwischen den Versionen

Aktuelle Version vom 3. August 2024, 08:20 Uhr

Der Artikel bietet einen Leitfaden zur Basisabsicherung und Testierung von Hochschulen nach BSI IT-Grundschutz. Er beschreibt die notwendigen Schritte und Voraussetzungen, um ein Basis-Testat zu erhalten, das die Mindestanforderungen an die IT-Sicherheit bestätigt. Dabei werden Prozesse wie Strukturanalyse, Modellierung und die Durchführung von Grundschutzchecks detailliert erläutert.

Einleitung

IT-Grundschutz ist eine Methodik des Bundesamtes für Sicherheit in der Informationstechnik (BSI), die Unternehmen und Behörden bei der Absicherung ihrer IT-Systeme und -Prozesse unterstützt. Die Basisabsicherung im IT-Grundschutz umfasst dabei im Wesentlichen die Maßnahmen, die als Mindestanforderungen an die IT-Sicherheit gelten.

Dazu gehören beispielsweise die Einführung von Zugriffsbeschränkungen auf IT-Systeme und Daten, die Umsetzung von Passwortrichtlinien, die regelmäßige Durchführung von Backups sowie der Einsatz von Virenscannern und Firewalls.

Die Basisabsicherung im IT-Grundschutz ist dabei nur ein erster Schritt zu einer umfassenden IT-Sicherheit. In einem weiteren Schritt können weitere Maßnahmen umgesetzt werden, um spezifische Risiken abzudecken und das Sicherheitsniveau zu erhöhen.

Mit dem Testat zur Basisabsicherung kann der durch einen externen Auditor bestätigte Nachweis erbracht werden, dass die Mindestanforderungen für einen sicheren IT-Betrieb erfüllt sind.

Zielsetzung

Ziel dieses Artikels ist es, einen "One Pager" zu schreiben, der in wenigen Schritten zum BSI Basis-Testat der Hochschule führt.

Ok, das realistische Ziel dieses Artikels ist es, einen Leitfaden zu bieten, wie eine Hochschule mit überschaubarem Aufwand zu einem Basis-Testat kommen kann.

Dieser Leitfaden versucht die folgenden Fragen zu beantworten:

Was bringt ein Basis-Testat?
Welche Voraussetzungen sind zu erfüllen?
Wie lange dauert es?
Was kostet es?
Wie wird es durchgeführt?

Was bringt ein Basis-Testat?

Leichter ist die Frage zu beantworten, was es nicht bringt:

Ein Testat oder Zertifikat bringt nicht mehr Sicherheit! Kein Angreifer und kein technischer Defekt wird sich von einem Zertifikat abschrecken lassen. Im Gegenteil, für einen ambitionierten Hacker wird es eher eine zusätzliche Motivation sein, es trotzdem zu versuchen.

Warum also eine Testierung oder Zertifizierung? Hier einige mögliche Gründe, die dafür sprechen:

Ruhigerer Schlaf: Als IT-Verantwortlicher oder Hochschulleitung schläft man ruhiger mit dem Gefühl, nicht nur alles Notwendige getan zu haben, um die Hochschul-IT sicher zu betreiben, sondern dies auch noch von einem externen Dritten (dem Auditor) bestätigt bekommen zu haben.
Außenwirkung: Zertifizierte IT-Sicherheit kann das Vertrauen in die Hochschule stärken, z.B. bei Partnern aus der Wirtschaft, bei der Einwerbung von Forschungsprojekten und Drittmitteln.
Anforderungen: Gesetzliche und politische Vorgaben können für eine Zertifizierung sprechen. So ist z.B. die DSGVO seit einigen Jahren in Kraft und betrifft neben der Verwaltung auch die Hochschulen mit ihren sensiblen personenbezogenen Daten der Studierenden. Erste Bundesländer haben auch schon konkrete Anforderungen an die Hochschul-IT gestellt, für die früher oder später auch ein entsprechender Nachweis verlangt werden wird.

Ein weiterer positiver (Neben-)Effekt:

Sicherheitsvorfälle kann niemand ausschließen. Davor schützt auch das teuerste Zertifikat nicht.

Wenn ein Sicherheitsvorfall eine entsprechende Außenwirkung hat, werden oft schnell Schuldige gesucht und Versäumnisse angeprangert und jeder Außenstehende weiß sofort, was man alles vorher hätte wissen oder tun müssen. Hier kann ein Zertifikat auch im Nachhinein eine gewisse "Schutzwirkung" entfalten, die nicht unterschätzt werden sollte.

Mit einem Testat oder Zertifikat kann die Hochschule - sofern der Sicherheitsprozess tatsächlich gelebt wird - nachweisen, dass es zumindest vorher keine offensichtlichen Versäumnisse gab und die Hochschule jedenfalls die Mindestanforderungen für einen ordnungsgemäßen IT-Betrieb erfüllt hat.

Durch die klar definierten Prozesse und Abläufe, die für das Zertifikat erforderlich sind, kann die Reaktion auf Vorfälle oft schneller und professioneller erfolgen und so helfen, den Schaden zu minimieren.

Basis-Testat vs. Zertifizierung

Vergleich Testat vs. Zertifizierung
	Testat	Zertifizierung
Aufwand	Mäßig, da nur Basis-Anforderungen erfüllt werden müssen (ca. 1/3 gegenüber Zertifizierung). Erneute Testierung erst nach 2 Jahren erforderlich.	Hoch, vollständige Umsetzung der Grundschutz-Anforderungen, hoher formaler Dokumentationsaufwand, jährliches Überwachungsaudit.
Gültigkeit	2 Jahre nach Ausstellung des Testat, dann muss komplett neu testiert werden.	3 Jahre bei jährlichem Überwachungsaudit, danach Rezertifizierung.
Anerkennung	Nicht formell als Zertifizierung anerkannt, wird aber national als Nachweis akzeptiert.	Internationale Anerkennung gem. ISO 27001
Ausstellung	Wird vom Auditor ausgestellt.	Wird vom BSI ausgestellt.

Hochschulen stehen aufgrund ihrer offenen Strukturen und der Freiheit von Forschung und Lehre vor besonderen Herausforderungen bei der Umsetzung von Sicherheitsmaßnahmen. Die Basis-Absicherung bietet hier einen niederschwelligen und testierbaren Einstieg in den IT-Grundschutz.

Welche Voraussetzungen sind zu erfüllen?

Kurze Antwort: Genau eine: Der Willen es zu tun!

Die folgenden Voraussetzungen müssen erfüllt sein oder erfüllt werden können, damit die Basis-Absicherung erfolgreich testiert werden kann:

Unterstützung durch die Hochschulleitung: Es ist wichtig, dass die Hochschulleitung die Notwendigkeit der Informationssicherheit erkennt und die notwendigen Ressourcen zur Verfügung stellt. Ohne Unterstützung von oben geht nichts. Ein offizielles Mandat der Hochschulleitung, die Testierung voranzutreiben, sollte eingeholt werden.
Ressourcen: Die Vorbereitung einer erfolgreichen Testierung erfordert die Bereitstellung ausreichender Ressourcen, insbesondere Zeit, Personal und Finanzen.
Prozessorientierung: Ein ISMS basiert auf einem Prozessansatz, daher ist es wichtig, dass die Hochschule generell prozessorientiert arbeitet und dies später auch in einem Audit darstellen kann.
Beteiligung der Mitarbeitenden: Alle Mitarbeitenden, insbesondere aber die Mitarbeitenden des IT-Betriebs müssen in die Testierung einbezogen werden, Sie müssen als Ansprechpartner für die Strukturanalyse und die Grundschutzprüfungen zur Verfügung stehen, ggf. offene Anforderungen durch die Umsetzung von Maßnahmen adressieren, die Regeln und Prozesse des ISMS verstehen und einhalten und nicht zuletzt im Audit den Auditor davon überzeugen, dass Informationssicherheit in der Hochschule gelebt wird.
Konsolidierung: Ein wichtiger Schritt in der Vorbereitung ist die Konsolidierung und Homogenisierung der Hochschul-IT. Das bedeutet eine sinnvolle Reduktion unterschiedlicher Systeme und Konfigurationen. Statt hunderter einzeln manuell konfigurierter Einzelsysteme, deren Sicherheit auch einzeln betrachtet werden muss, lieber wenige gruppierte Systeme mit jeweils gleichem Betriebssystem, gleicher oder ähnlicher Konfiguration und gleicher Art der Administration. Diese Gruppe von Systemen muss dann nur einmal exemplarisch betrachtet werden, was den Aufwand erheblich reduziert!

Wie lange dauert es?

Kurze Antwort: Immer länger als man denkt!

Das hängt natürlich sehr davon ab, wo man steht. Die Erfahrung zeigt, dass niemand bei Null anfängt. Viele Basis-Anforderungen des Grundschutzes sind bereits erfüllt, wenn auch selten dokumentiert. Die meisten Basis-Anforderungen entsprechen dem, was der gesunde Menschenverstand gebietet und was in den meisten Hochschulen ohnehin schon umgesetzt ist. Was oft fehlt, sind klare Prozesse und Dokumentationen. Es läuft irgendwie auf irgendwelchen Systemen und ist in irgendwelchen Köpfen dokumentiert, aber es ist nirgends nachvollziehbar beschrieben. Der größte Aufwand besteht also darin, die Prozesse zu strukturieren und zu dokumentieren und damit die Informationen und Konfigurationen aus den Köpfen (und auf den Systemen) zu konsolidieren und in einer klaren Dokumentation zu konservieren.

Abhängig von den personellen Ressourcen und deren Motivation muss realistisch mit mindestens einem Jahr gerechnet werden.

Mit einem motivierten Team und einer "Hau-Ruck-Aktion" kann es auch schneller gehen, wahrscheinlicher ist aber ein ständiger Kampf gegen Windmühlen und eine Projektlaufzeit von 2-3 Jahren.

Was kostet es?

Kurze Antwort: Viel Zeit und Nerven!

Neben den eigenen Kosten für Zeit, Personal und ggf. die eine oder andere technische Lösung fallen eigentlich nur noch die Kosten für das abschließende Audit an. Der Auditor muss dabei nach dem "Prüfschema für die Erteilung eines Testats nach der Basis-Absicherung gemäß IT-Grundschutz" vorgehen.

Dieses sieht folgende Aufwände vor:

Dokumentenprüfung und Erstellung des Prüfplans (ca. 1-2 PT)
Prüfung vor Ort und Abschlussbesprechung (ca. 1-2 PT)
Erstellung des Prüfberichts und Ausstellung des Testats nach Grundschutz (ca. 0,5-1 PT)
Nicht vom BSI aufgeführt, aber sinnvoll ist ein Vorgespräch mit dem Auditor (ca. 0,5 PT).

Insgesamt fallen also ca. 3-5 PT für das Audit an. Als Tagessatz ist je nach Auditor mit 900 bis 1.500 € zu rechnen.

Die reinen (externen) Auditkosten liegen also irgendwo zwischen 2.700 und 7.500 €.

Gegebenenfalls kommen noch Beratungskosten für die Vorbereitung hinzu. Grundsätzlich ist es möglich, ganz auf externe Unterstützung zu verzichten. Das Vorgehensmodell und das Grundschutzkompendium können beim BSI kostenlos heruntergeladen werden und es ist kein Hexenwerk (auch wenn es sich manchmal so liest).

Dennoch kann es - gerade bei der ersten Prüfung - sinnvoll sein, wenn jemand mit Erfahrung und aus Sicht eines Aussenstehenden einen Blick darauf wirft. Das kann auch ein Kollege oder eine Kollegin von einer anderen Hochschule sein.

Falls noch nicht vorhanden oder über einen Rahmenvertrag abrufbar, ist ein Grundschutz-/ISMS-Tool sehr hilfreich. IT-Grundschutz komplett in Word oder Excel umzusetzen ist möglich, führt aber eher zur Kündigung der verantwortlichen Mitarbeitenden als zu einer Zertifizierung der Hochschule. Die Kosten liegen je nach Tool zwischen ~500 € und mehreren Tausend € pro Jahr.

Wie wird es durchgeführt?

Kurze Antwort: Am Anfang schwierig und kompliziert, im Nachhinein einfacher als gedacht.

Eine grundsätzliche Anleitung zur Umsetzung von BSI IT-Grundschutz an einer Hochschule ist im IT-Grundschutz-Profil des ZKI ausführlich beschrieben.

Die folgende Anleitung hier beschränkt sich auf eine kurze Zusammenfassung der einzelnen Schritte zur Umsetzung einer Basis-Absicherung mit dem Ziel der Testierung.

Das Grundschutzprofil des ZKI für Hochschulen beschreibt die vollständige Umsetzung von BSI IT-Grundschutz (Standard). Im Gegensatz dazu verfolgt die Basis-Absicherung einen Minimalansatz. Die Basis-Absicherung geht grundsätzlich von einem normalen Schutzbedarf in den Werten Verfügbarkeit, Vertraulichkeit und Integrität aus, wodurch die Schritte Schutzbedarfsfeststellung und Risikoanalyse entfallen. Dies entspricht natürlich nicht der Realität an einer Hochschule, ist aber ein pragmatischer Ansatz, sich zunächst auf die Basis-Anforderungen zu konzentrieren. Wenn man davon ausgeht, dass in Hochschulen alle Prozesse ineinander greifen und bildlich gesprochen die Kette nur so stark ist wie ihr schwächstes Glied, erscheint es durchaus sinnvoll, zunächst alles auf ein Basisniveau zu bringen, anstatt einen Teil nach dem anderen mit einem vollständigen Grundschutz auszustatten und damit zu riskieren, dass die noch nicht betrachteten Teile erhebliche Lücken aufweisen.

Step 1: Einführung eines ISMS

Falls noch nicht vorhanden, muss der Informationssicherheitsprozess (das ISMS) initiiert werden. D.h. die Hochschulleitung bekennt sich zur Informationssicherheit als ein zentrales Ziel der Hochschule und sie übernimmt die Gesamtverantwortung für die Informationssicherheit. Dazu wird ein Informationssicherheitsbeauftragter bestellt, der als Stabsstelle direkt der Hochschulleitung unterstellt ist. In einer Leitlinie zur Informationssicherheit werden die übergeordneten Ziele und die Strategie der Hochschule zur Informationssicherheit festgelegt.

Der Informationssicherheitsbeauftragte (ISB) muss unabhängig arbeiten können und direkt der Leitung unterstellt sein (Stabsstelle Informationssicherheit). Er muss mit ausreichenden zeitlichen und finanziellen Ressourcen ausgestattet sein. Der ISB muss über fundierte Kenntnisse auf dem Gebiet der Informationssicherheit und des BSI IT-Grundschutzes verfügen bzw. die Mittel haben, sich entsprechend fortzubilden.

Eine grobe Vorstellung, wie ein ISMS in der Organisation eingeführt werden kann, findet sich im Artikel ISMS-Einführung.

Grundlegende Dokumente für die Einführung eines ISMS und Mindestanforderungen für eine Zertifizierung finden sich im Artikel Referenzdokumente.

Step 2: Definition des Geltungsbereichs (Informationsverbund)

Ein entscheidender Punkt für eine erfolgreiche Testierung ist die Definition des Informationsverbundes. Der Zuschnitt des Informationsverbundes bestimmt, was Bestandteil des Audits wird und vor allem, was nicht (Abgrenzung). Gerade Hochschulen haben hier besondere Herausforderungen durch eine oft sehr heterogene Struktur und unterschiedliche Verantwortlichkeiten. Zu Beginn und für das erste Audit sollte der Verbund nicht zu groß gewählt werden, aber auch nichts Wesentliches vergessen werden. Wenn ein Bereich abgegrenzt werden soll, muss diese Abgrenzung klar definierbar sein. Schnittstellen sind vollständig zu beschreiben und an den Grenzen durch technische und organisatorische Maßnahmen abzusichern.

Alle wesentlichen Teile für den Betrieb der Systeme innerhalb des Informationsverbundes müssen berücksichtigt werden. Dies betrifft den Client für die Administration ebenso wie das genutzte Netzwerk, die Räume und Gebäude, in denen die Systeme betrieben werden, deren Sicherheitseinrichtungen (Zugangsschutz) und die elektrotechnische Versorgung und Klimatisierung.

Step 3: Strukturanalyse

Nach der Definition des Informationsverbundes folgt die Strukturanalyse. Dies ist quasi die Bestandsaufnahme des Informationsverbundes. Alle Komponenten innerhalb des Informationsverbundes müssen erfasst werden. Dazu gehört ein detaillierter Netzplan. Er verschafft einen Überblick über den Verbund, hilft nichts zu vergessen und die Abgrenzung des Verbundes sowie die Schnittstellen sauber zu beschreiben. Ebenso gehören zur Strukturanalyse viele Komponentenlisten, also das Inventurverzeichnis des Verbundes.

Liste der Geschäfts- und Hilfsprozesse
Liste der Anwendungen
Liste der IT-Systeme
Liste der Netzwerksegmente (Netzwerkbereiche, VLAN's etc.)
Liste der Client-Systeme (PCs, Notebooks, Terminals, mobile Geräte)
Liste der Administratoren und deren Verantwortlichkeiten
Liste der relevanten Räume und Gebäude (vom Rechenzentrum bis zu den Büros der Administratoren und Benutzer)

Im Wiki gibt es dazu eine Mustervorlage für eine Strukturanalyse.

Der nächste wichtige Teilschritt zur Reduzierung des Aufwands ist eine sinnvolle Gruppierung. Dabei werden gleiche Systeme zu einem "Zielobjekt" zusammengefasst und gemeinsam betrachtet. Dies reduziert den Aufwand für die nächsten Schritte erheblich, erfordert aber eine gute Vorbereitung und einige Kompromisse. Die (nachvollziehbare) Gruppierung in Zielobjekte ist auch Bestandteil der Strukturanalyse. Das Prinzip der Gruppierung funktioniert nicht nur für Server oder Clients, sondern natürlich auch für alle anderen Objekte wie Anwendungen, Netze, Benutzer, Räume und Gebäude. Immer vorausgesetzt, dass sie sich in allen Sicherheitsaspekten nicht oder nicht wesentlich unterscheiden.

Step 4: Modellierung

Bei der Modellierung werden allen zuvor definierten Zielobjekten Bausteine aus dem IT-Grundschutz-Kompendium (in der jeweils gültigen Fassung) zugeordnet. Welche Bausteine welchem Zielobjekt zuzuordnen sind, ergibt sich aus der Bezeichnung der Bausteine und den Modellierungshinweisen in den jeweiligen Bausteinen (zu finden in Kapitel 1.3 Abgrenzung und Modellierung).

Step 5: Grundschutzchecks

Der Hauptteil der Arbeit besteht in der Überprüfung der grundlegenden Schutzmaßnahmen (Grundschutzchecks). Jeder Baustein enthält ca. 15-30 Anforderungen, die für jeden modellierten Baustein jedes Zielobjektes geprüft werden müssen. Obwohl für ein Testat nur die Basisanforderungen (ca. 1/3 der Anforderungen) zu prüfen sind, kann der Aufwand je nach Anzahl der Zielobjekte und modellierten Bausteine erheblich sein. Für jeden zu prüfenden Baustein ist bei der Ersterfassung mit einem Zeitaufwand von 1-2 Stunden für die Basis-Anforderungen zu rechnen. Mit zunehmender Routine reduziert sich der Aufwand etwas.

Step 6: Umsetzungs-/Realisierungsplan

Alle nicht oder nur teilweise umgesetzten Basis-Anforderungen werden in einen Umsetzungs- oder Realisierungsplan aufgenommen. Dieser Plan legt den weiteren zeitlichen Ablauf bis zum Audit fest. Eine Testierung ist erst nach vollständiger Umsetzung der Basis-Anforderungen möglich.

Step 7: Konsolidierung Grundschutzchecks

Nach Umsetzung aller offenen Basis-Anforderungen sind diese in den Grundschutzchecks zu dokumentieren, so dass ein vollständiger Bericht über alle umgesetzten Basis-Anforderungen erstellt werden kann. Dieser Bericht dient u.a. als Prüfgrundlage für den Auditor. Die Grundschutzchecks dürfen zum Zeitpunkt des Audits nicht älter als ein Jahr sein.

Step 8: Audit

Wenn alles erledigt ist, kann ein Auditor gesucht und beauftragt werden. Nur ein vom BSI zertifizierter Auditor kann ein Testat ausstellen. Diese findet ihr in der Liste der vom BSI zertifizierten Auditoren.

Folgende Dokumente sind für eine erfolgreiche Testierung mindestens erforderlich:

Leitlinie zur Informationssicherheit
Richtlinie zur Lenkung von Dokumenten und Aufzeichnungen
Richtlinie zur internen ISMS-Auditierung
Richtlinie zur Lenkung von Korrektur- und Vorbeugungsmaßnahmen
Strukturanalyse
Aktueller Report der Grundschutzchecks

Der Auditor prüft im Audit zunächst die Dokumente und anschließend - vor Ort - ausgewählte Bausteine des Grundschutzkompendiums (ca. 10% der Bausteine, mindestens sechs) auf die ausreichende Umsetzung der darin enthaltenen Basis-Anforderungen. Kommt er zu dem Ergebnis, dass die Dokumente und die Umsetzung der Anforderungen der ausgewählten Bausteine ausreichend sind, erteilt er das Testat.

Step 9: Party

Dieser Punkt klingt vielleicht etwas lustig, ist aber wichtig für das weitere Vorgehen.

Nach einer erfolgreichen Testierung durch den Auditor sollte der Erfolg auch entsprechend kommuniziert und gefeiert werden!

Nach dem Audit ist vor dem Audit. Ein Testat ist nur zwei Jahre gültig, eine Zertifizierung erfordert ein jährliches Audit. Die erbrachte Leistung sollte von der Leitung anerkannt und entsprechend gewürdigt werden, um die Motivation für das nächste Audit aufrecht zu erhalten.

Empfehlungen

Unabhängig von der Testierung nach der Basisabsicherung empfiehlt es sich, parallel oder direkt im Anschluss weitere Schritte zu unternehmen, um das Sicherheitsniveau über den reinen Mindeststandard hinaus zu erhöhen:

Für den Baustein ISMS.1 Sicherheitsmanagement auch die Standard-Anforderungen bearbeiten, um das ISMS vollständig zu etablieren.
Durchführung einer Schutzbedarfsfeststellung und Risikoanalyse (z.B. nach Standard 200-3) für die Kerngeschäftsprozesse, um risikobasiert weiteren Handlungsbedarf zu identifizieren.
Umsetzung der Standardanforderungen für alle modellierten R1-Bausteine.
Einführung eines Notfallmanagements, zumindest bezogen auf aktuelle Bedrohungen wie z.B. Ransomware.
Umsetzung einer Kernabsicherung für kritische Geschäftsprozesse und -verfahren.

Weiterführende Literatur

BSI Standard 200-1 Managementsysteme für Informationssicherheit (ISMS)

BSI Standard 200-2 IT-Grundschutz-Methodik

BSI IT-Grundschutz-Kompendium

ZKI IT-Grundschutz Profil für Hochschulen

BSI Leitfaden zur Basis-Absicherung nach IT-Grundschutz

Testat nach der Basis-Absicherung

Ablauf Testat-Verfahren nach der Basis-Absicherung

Prüfschema für die Erteilung eines Testats nach der Basis-Absicherung