LF-Basistestat Hochschulen

Mustervorlage: "Leitfaden Basistestat Hochschulen"

Einleitung

Der IT-Grundschutz ist ein Methodik des Bundesamts für Sicherheit in der Informationstechnik (BSI), das Unternehmen und Behörden dabei unterstützt, ihre IT-Systeme und -Prozesse abzusichern. Die Basisabsicherung im IT-Grundschutz umfasst dabei diejenigen Maßnahmen, die als Mindestanforderungen für die IT-Sicherheit gelten.

Dazu gehören zum Beispiel die Einführung von Zugriffsbeschränkungen auf IT-Systeme und Daten, die Umsetzung von Passwortrichtlinien, die regelmäßige Durchführung von Backups sowie die Implementierung von Antivirus-Software und Firewalls.

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

Mit dem Testat der Basis-Absicherung 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 ein "One Pager" zu schreiben, der euch in wenigen Schritten zum BSI Basis-Testat eurer Hochschule führt.

Ok, das realistische Ziel dieses Artikels ist es, einen Leitfaden zu bieten, wie man als Hochschule ein Basis-Testat erreichen kann.

Dieser Leitfaden versucht dabei zu folgende Fragen zu beantworten:

• Was bringt ein Basis-Testat?
• Welche Voraussetzungen müssen erfüllen werden?
• Wie lange dauert das?
• Was kostet das?
• Wie geht das?

Was bringt ein Basis-Testat?

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

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

Warum also ein Testierung oder Zertifizierung? Hier ein paar mögliche Gründe die dafür sprechen:

• Ruhigerer Schlaf: Als IT-Verantwortlicher oder Hochschulleiter schläft man entspannter, mit dem Gefühl, dass man nicht nur alles nötige getan hat die Hochschul-IT sicher zu betreiben, sondern dies auch noch durch einen externen dritten (dem Auditor) bestätigt wurde.
• Außenwirkung: Zertifizierte IT-Sicherheit kann das Vertrauen in die Hochschule stärken, insbesondere bei Partnern aus der Wirtschaft bei bei der Anwerbung von Forschungsprojekten und Drittmitteln.
• Anforderungen: Rechtliche und politische Anforderungen können für eine Zertifizierung sprechen. Die DSGVO z.B. geht schon einige Jahre als Gespenst in der Wirtschaft um, trifft aber ebenso die Verwaltung und auch die Hochschulen mit ihren sensiblen personenbezogenen Daten von Studierenden. Erste Bundesländer haben auch schon konkret Anforderungen an die Hochschul-IT gestellt für die früher oder später auch ein Nachweis verlangt werden wird.

Ein weiterer positiver (Neben)Effekt:

Niemand kann ausschließen, dass es zu Sicherheitsvorfällen kommt. Davor schützt auch das teuerste Zertifikat nicht.

Hat ein Sicherheitsvorfall entsprechende Außenwirkung, werden häufig schnell Schuldige gesucht und Versäumnisse angeprangert und jeder Außenstehende weiß sofort, was man alles hätte vorher 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 einer Zertifikat kann die Hochschule -vorausgesetzt der Sicherheitsprozess wird real gelebt- nachweisen, dass es zumindest vorher keine offensichtlichen Versäumnisse gab und die Hochschule auf jeden Fall die Mindestanforderungen für einen ordnungsgemäßen IT-Betrieb erfüllt hat. Durch die für das Zertifikat erforderlichen, klar definierten, Prozesse und Abläufe kann eine 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). Neue Testierung erst nach 2 Jahren nötig.	hoch, 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 anerkannt, wird aber national als Nachweis akzeptiert	Internationale Anerkennung gem. ISO 27001
Ausstellung	Wird vom Auditor ausgestellt.	Wird vom BSI ausgestellt.

Welche Voraussetzungen müssen erfüllen werden?

Kurze Antwort: genau eine: den Willen es zu tun!

Für die erfolgreiche Testierung der Basis-Absicherung sollten folgenden Voraussetzungen erfüllt sein:

• Unterstützung der Leitung: Es ist wichtig, dass die Leitung der Hochschule die Notwendigkeit der Informationssicherheit erkennt und die nötigen Ressourcen bereit stellt. Ohne Rückendeckung von ganz oben, geht gar nichts. Lasst euch einen offiziellen Auftrag von der Hochschulleitung geben, die Testierung voranzutreiben.
• Ressourcen: Die Vorbereitung einer erfolgreichen Testierung erfordert die Zuweisung von ausreichenden Ressourcen, einschließlich Zeit, Personal und Finanzen.
• Prozessorientierung: Ein ISMS basiert auf einem Prozessansatz, daher ist es wichtig, dass die Hochschule generell prozessorientiert arbeitet und dies auch in einem Audit darstellen kann.
• Mitarbeiterbeteiligung: Alle Mitarbeitenden, insbesondere aber die Mitarbeitenden des IT-Betriebs müssen in die Testierung einbezogen werden, Sie müssen für die Strukturanalyse und die Grundschutzchecks als Ansprechpartner zur Verfügung stehen, ggf. offene Anforderungen mit der Umsetzung von Maßnahmen begegnen und die Regeln und Prozesse des ISMS verstehen und einhalten und nicht zuletzt im Audit den Auditor davon überzeugen das Informationssicherheit in der Hochschule gelebt wird.
• Konsolidierung: Eine wichtiger Schritt der Vorbereitung, der den späteren Aufwand erheblich reduzieren kann, ist die Konsolidierung und Homogenisierung der IT. D.h. eine sinnvolle Reduktion unterschiedlicher Systeme und Konfigurationen. Statt hunderte einzeln manuell konfigurierter Individualsysteme, deren Sicherheit ebenfalls individuell betrachtet werden muss, lieber wenige gruppierte Systeme mit jeweils gleichem Betriebssystem, gleicher oder gleichartiger Konfiguration und gleicher Art der Administration. Diese Gruppe von Systemen muss dann nur einmal exemplarisch betrachtet werden.

Wie lange dauert das?

Kurze Antwort: Immer länger als gedacht!

Es hängt natürlich stark davon ab wo ihr steht. Erfahrungsgemäß fängt niemand bei Null an. Viele Basis-Anforderungen des Grundschutz sind bereits erfüllt, wenn auch selten dokumentiert. Die meisten Basis-Anforderungen entsprechen dem, was der natürliche Menschenverstand gebietet und was in den meisten Hochschulen bereits umgesetzt ist. Was oft fehlt, sind klare Prozesse und Dokumentation. Es läuft, irgendwie, auf irgendwelchen Systemen und ist dokumentiert in irgendwelchen Köpfen aber es ist nirgends beschrieben. Der größte Aufwand besteht also darin Abläufe zu strukturieren und zu dokumentieren und damit die Informationen und Konfigurationen in den Köpfen (und auf den Systemen) zu konsolidieren und zu konservieren.

Abhängig von den personellen Ressourcen und deren Motivation müsst ihr realistisch mit mindestens einem Jahr rechnen.

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

Was kostet das?

Kurze Antwort: Viel Zeit und Nerven!

Neben den eigenen Kosten für Zeit und Personal und ggf. noch die eine oder andere technische Lösung, folgen eigentlich nur noch die Kosten des eigentlich Audits. 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)
• Vor-Ort-Prüfung und Abschlussbesprechung (ca. 1-2 PT)
• Erstellung des Prüfberichtes und Ausstellung des Testats nach Basis-Absicherung (ca. 0,5-1 PT)
• Vom BSI nicht aufgeführt aber sinnvoll ist ein Vorgespräch mit dem Auditor (ca. 0,5 PT)

In Summe fallen also ca. 3-5 PT für das Audit an. Als Tagessatz müsst ihr je nach Auditor zwischen 900 und 1.500€ rechnen.

Die reinen (externen) Audit-Kosten liegen also irgendwo zwischen 2.700 und 7.500 €

Bei Bedarf kommen dazu ggf. noch Beraterkosten in der Vorbereitung. Grundsätzlich geht das völlig ohne externe Unterstützung. Das Vorgehensmodell und das Grundschutzkompendium gibt es kostenfrei beim BSI zum Download und es ist kein Hexenwerk (auch wenn es sich manchmal so liest).

Dennoch kann es -gerade bei der ersten Testierung- sinnvoll sein, wenn jemand mit Erfahrung und einem externen Blick drauf schaut. Das kann auch eine Kollegin oder ein Kollege aus einer anderen Hochschule sein.

Falls noch nicht vorhanden oder über einen Rahmenvertrag abrufbar, ist ein Grundschutz-/ISMS-Tool sehr nützlich. IT-Grundschutz komplett in Word oder Excel umzusetzen ist möglich, führt aber eher zu einer Kündigung der Verantwortlichen Mitarbeitenden als zu einer Testierung der Hochschule. Je nach präferiertem Tool schwanken die Kosten zwischen ~500€ bis mehreren Tausend € pro Jahr.

Wie geht das?

Kurze Antwort: Am Anfang schwer und kompliziert, im Nachhinein leichter als gedacht.

Eine grundsätzliche Anleitung zur Umsetzung des 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 für die Umsetzung einer Basis-Absicherung mit dem Ziel der Testierung.

Das Grundschutz-Profil 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 womit die Schritte Schutzbedarfsfeststellung und Risikoanalyse entfallen. Das entspricht natürlich nicht der Realität an einer Hochschule, ist aber ein pragmatischer Ansatz, sich erst einmal auf die Basis-Anforderungen zu konzentriert. Wenn man davon ausgeht, dass in Hochschulen alle Prozesse ineinander greifen und bildlich dargestellt, die Kette nur so stark ist, wie ihr schwächstes Glied, erscheint es durchaus sinnvoll, erst einmal alles auf ein Basis-Niveau zu bringen als ein Teil nach dem Anderen mit vollständigem Grundschutz zu versorgen und damit zu riskieren das noch nicht betrachtete Teile wesentliche Lücken aufweisen.

Step 1: Einführung eines ISMS

Falls noch nicht vorhanden, muss der Prozess der Informationssicherheit (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 in Funktion einer Stabsstelle direkt der Leitung unterstellt ist. In einer Leitlinie zur Informationssicherheit werden die übergreifenden Ziele und die Strategie der Hochschule in Bezug auf Informationssicherheit festgelegt.

Der Informationssicherheitsbeauftragte (ISB) muss unabhängig arbeiten können und direkt der Leitung unterstellt sein (Stabsstelle Informationssicherheit). Er muss mit ausreichen zeitlichen und finanziellen Ressourcen ausgestattet sein. Der ISB muss über fundierte Kenntnisse im Bereich Informationssicherheit und BSI IT-Grundschutz verfügen bzw. über die Mittel sich hier angemessen fortzubilden.

Eine grobe Vorstellung wie man ein ISMS in der Organisation einführt, findet ihr im Artikel ISMS-Einführung.

Grundlegende Dokumente für die Einführung eines ISMS und Mindestanforderung für eine Testierung findet ihr im Artikel Referenzdokumente.

Step 2: Definition des Geltungsbereichs (Informationsverbund)

Ein entscheidender Punkt für eine erfolgreiche Testierung ist die Definition des Informationsverbunds. Der Zuschnitt des Informationsverbunds bestimmt, was Bestandteil der Auditierung wird und vor allem, was nicht (Abgrenzung). Gerade Hochschulen haben hier durch eine oft sehr heterogene Struktur und unterschiedliche Verantwortlichkeiten besondere Herausforderungen. Am Anfang und für die erste Testierung sollte der Verbund nicht zu groß gewählt werden, es darf aber auch nichts wesentliches vergessen werden. Wenn ihr einen Bereich abgrenzen wollt, muss diese Abgrenzung klar definierbar sein. Schnittstellen müssen vollständig beschrieben werden und an den Grenzen auch durch technische und organisatorische Maßnahmen abgesichert sein.

Alle wesentlichen Teile zum Betrieb der Systeme innerhalb des Informationsverbunds müssen mit betrachtet werden. Das betrifft den Client für die Administration genauso, wie das genutzte Netzwerk, die Räume und Gebäude in denen die Systeme betrieben werden, deren Sicherheitseinrichtungen (Zutrittsschutz) und die elektrotechnische Versorgung.

Step 3: Strukturanalyse

Wenn der Informationsverbund definiert ist, folgt die Strukturanalyse. Das ist Quasi die Inventur über den Informationsverbund. Alle Komponenten innerhalb des Informationsverbunds müssen erfasst werden. Dazu gehört ein detaillierter Netzplan. Er verschafft einen Überblick über den Verbund, hilft dabei nichts zu vergessen und die Abgrenzung des Verbunds, sowie die Schnittstellen sauber zu beschreiben. Ebenso gehören zur Strukturanalyse viele Komponentenlisten, also das Inventarverzeichnis des Verbunds.

• Liste der Geschäftsprozesse und der Hilfsprozesse
• Liste der Anwendungen
• Liste der IT-Systeme
• Liste der Netzsegmente (Netzbereiche, VLAN's etc.)
• Liste der Clientsysteme (PC's, Notebooks, Terminals, mobile Geräte)
• Liste der Administratoren und deren Zuständigkeiten
• Liste der relevanten Räume und Gebäude (vom Rechenzentrum bis zu Büros von Administratoren und Nutzern)

Im Wiki gibt es hierfür 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 zusammen gefasst und gemeinsam betrachtet. Das reduziert den Aufwand der nächsten Schritte erheblich, erfordert aber eine gute Vorbereitung und ein paar Kompromisse. Auch die (nachvollziehbare) Gruppierung in Zielobjekte ist Bestandteil der Strukturanalyse. Das Prinzip der Gruppierung funktioniert nicht nur bei Servern oder Clients sonder natürlich auch bei allen anderen Objekten wie Anwendungen, Netzen, Nutzern, Räumen und Gebäuden. 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) zugewiesen. Welche Bausteine welchem Zielobjekt zuzuweisen 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

Die Hauptarbeit steckt in den Grundschutzchecks. Jeder Baustein enthält ca. 15-30 Anforderungen die jeden modellierten Baustein jedes Zielobjekts abgeprüft werden müssen. Für ein Basis-Testat sind zwar nur die Basis-Anforderungen (ca. 1/3 der Anforderungen) zu prüfen, Abhängig von der Zahl der Zielobjekte und modellierten Bausteine, kann der Aufwand aber schon erheblich sein. Für jeden zu prüfenden Baustein muss für die Ersterfassung mit einem Zeitaufwand von 1-2 Stunden für die Basis-Anforderungen gerechnet werden. Mit zunehmender Routine reduziert sich der Aufwand etwas.

Step 6: Umsetzungs-/Realisierungsplan

Alle nicht oder teilweise umgesetzten Basis-Anforderungen werden in einen Umsetzungs- oder Realisierungsplan aufgenommen. Dieser Plan bestimmt den weiteren zeitliche Verlauf bis zum Audit. Eine Testierung ist erst möglich wenn die Anforderungen vollständig umgesetzt sind.

Step 7: Konsolidierung Grundschutzchecks

Nach der Umsetzung aller offenen Basis-Anforderungen müssen diese in den Grundschutzchecks nach dokumentiert werden, damit ein vollständiger Report aller umgesetzten Basis-Anforderungen erstellt werden kann. Dieser Report ist u.a. Prüfgrundlage für den Auditor.

Step 8: Audit

Ist bis hierhin alles erledigt, kann ein Auditor gesucht und beauftragt werden. Ein Testat kann nur von einem BSI zertifizierten Auditor ausgestellt werden. Diese findet ihn der Liste der vom BSI zertifizierten Auditoren.

Folgende Dokumente sind eine erfolgreiche Testierung 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
• Report der Grundschutzchecks

Empfehlungen

Unabhängig von der Testierung nach Basis-Absicherung, empfehlen sich parallel oder direkt anschließend ein paar weitere Schritte um das Sicherheitsniveau über den reinen Mindeststandard hinaus zu erhöhen:

• Für den Baustein ISMS.1 Sicherheitsmanagement auch die Standard-Anforderungen zu bearbeiten um das ISMS vollständig zu etablieren.
• Eine Schutzbedarfsfeststellung und Risikoanalyse (z.B. nach Standard 200-3) für die Kern-Geschäftsprozesse durchführen, um risikobasiert weiteren Handlungsbedarf zu erkennen.
• Die Standard-Anforderungen für alle modellierten R1-Bausteine umsetzen.
• Einführung eines Notfallmanagements, zumindest bezogen auf aktuelle Gefährdungen 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

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