LF-Basistestat Hochschulen: Unterschied zwischen den Versionen

Aus ISMS-Ratgeber WiKi
Zur Navigation springenZur Suche springen
KKeine Bearbeitungszusammenfassung
KKeine Bearbeitungszusammenfassung
 
(5 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
{{#seo:
{{#seo:
|title=Leitfaden zur Umsetzung und Testierung der Basisabsicherung nach BDI IT-Grundschutz an einer Hochschule.
|title=Leitfaden zur Basisabsicherung einer Hochschule.
|keywords=ISMS,Basisabsicherung,Grundschutz,Testat,Hochschulen,Universität,Zertifizierung,BSI
|keywords=ISMS,Basisabsicherung,Grundschutz,Testat,Hochschulen,Universität,Zertifizierung,Testierung,BSI
|description=Leitfaden zur Umsetzung der Basisabsicherung und Testierung nach BSI IT-Grundschutz an einer Hochschule.
|description=Leitfaden zur Basisabsicherung und Testierung nach BSI IT-Grundschutz an einer Hochschule.
}}
}}{{SHORTDESC:Leitfaden zur Vorbereitung einer Testierung zur Basisabsicherung einer Hochschule.}}
Mustervorlage: '''"Leitfaden Basistestat Hochschulen"'''
[[Datei:Testat Logo Muster.jpg|rechts|rahmenlos]]
[[Datei:Testat Logo Muster.jpg|rechts|rahmenlos]]
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==
==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.
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 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.
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 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.
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 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.
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 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 eine Hochschule mit überschaubarem Aufwand ein Basis-Testat erreichen kann.
==Zielsetzung ==
''Ziel dieses Artikels ist es, einen "One Pager" zu schreiben, der in wenigen Schritten zum BSI Basis-Testat der Hochschule führt.''


Dieser Leitfaden versucht dabei zu folgende Fragen zu beantworten:
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?
*Was bringt ein Basis-Testat?
* Welche Voraussetzungen müssen erfüllen werden?
*Welche Voraussetzungen sind zu erfüllen?
*Wie lange dauert das?
*Wie lange dauert es?
*Was kostet das?
*Was kostet es?
*Wie geht das?
*Wie wird es durchgeführt?


== Was bringt ein Basis-Testat?==
==Was bringt ein Basis-Testat? ==
Leichter ist es, die Frage zu beantworten was es <u>nicht</u> bringt:  
Leichter ist 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 ambitionierten Hacker wird es eher noch eine zusätzliche Motivation sein, es trotzdem zu versuchen.  
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 ein Testierung oder Zertifizierung? Hier ein paar mögliche Gründe die dafür sprechen:  
Warum also eine Testierung oder Zertifizierung? Hier einige 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.
* '''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 Anwerbung von Forschungsprojekten und Drittmitteln.
* '''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:''' 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 entsprechender Nachweis verlangt werden wird.
* '''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:  
Ein weiterer positiver (Neben-)Effekt:


Niemand kann ausschließen, dass es zu Sicherheitsvorfällen kommt. Davor schützt auch das teuerste Zertifikat nicht.
Sicherheitsvorfälle kann niemand ausschließen. 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.
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 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.
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 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.
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===
===Basis-Testat vs. Zertifizierung===
Zeile 55: Zeile 56:
!
!
!Testat
!Testat
!Zertifizierung  
!Zertifizierung
|-
|-
!Aufwand
!Aufwand
|mäßig, da nur Basis-Anforderungen erfüllt werden müssen (ca. 1/3 gegenüber Zertifizierung). Erneute Testierung erst nach 2 Jahren nötig.
|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, volle Umsetzung der Grundschutz-Anforderungen, hoher formaler Dokumentationsaufwand, jährliches Überwachungsaudit.
|Hoch, vollständige Umsetzung der Grundschutz-Anforderungen, hoher formaler Dokumentationsaufwand, jährliches Überwachungsaudit.
|-
|-
!Gültigkeit
!Gültigkeit
|2 Jahre nach Ausstellung des Testat, dann muss komplett neu testiert werden.
|2 Jahre nach Ausstellung des Testat, dann muss komplett neu testiert werden.
|3 Jahre bei jährlichem Überwachungsaudit, danach Rezertifizierung.  
|3 Jahre bei jährlichem Überwachungsaudit, danach Rezertifizierung.
|-
|-
!Anerkennung
!Anerkennung
Zeile 71: Zeile 72:
!Ausstellung
!Ausstellung
|Wird vom Auditor ausgestellt.
|Wird vom Auditor ausgestellt.
|Wird vom BSI ausgestellt.
| Wird vom BSI ausgestellt.
|}
|}
Aufgrund ihrer offenen Strukturen und der Freiheit von Forschung und Lehre, haben Hochschulen besonderen Herausforderung bei der Umsetzung von Sicherheitsmaßnahmen zu bewältigen. Hier bietet die Basis-Absicherung einen niederschwelligen testierbaren Einstieg in den IT Grundschutz.
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 müssen erfüllen werden?==
==Welche Voraussetzungen sind zu erfüllen?==
''Kurze Antwort: genau eine: den Willen es zu tun!''
''Kurze Antwort: Genau eine: Der Willen es zu tun!''


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


* '''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.
* '''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 Zuweisung von ausreichenden Ressourcen, insbesodere Zeit, Personal und Finanzen.
* '''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.
* '''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.
* '''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, dass Informationssicherheit in der Hochschule gelebt wird.
* '''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:''' Eine wichtiger Schritt der Vorbereitung ist die Konsolidierung und Homogenisierung der Hochschul-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 und reduziert damit den Auswand erheblich!.
* '''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 das?==
==Wie lange dauert es?==
''Kurze Antwort: Immer länger als gedacht!''
''Kurze Antwort: Immer länger als man denkt!''


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 gesunde Menschenverstand gebietet und was in den meisten Hochschulen ohnehin 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 aus den Köpfen (und auf den Systemen) zu konsolidieren und in Dokumentation zu konservieren.
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 müsst ihr realistisch mit mindestens einem Jahr rechnen.
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 stetiger Kampf gegen Windmühlen und eine Laufzeit des Projekts von 2-3 Jahren.  
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 das?==
==Was kostet es?==
''Kurze Antwort: Viel Zeit und Nerven!''
''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 abschließende Audits. Der Auditor muss dabei nach dem "Prüfschema für die Erteilung eines Testats nach der Basis-Absicherung gemäß IT-Grundschutz" vorgehen.
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:
Dieses sieht folgende Aufwände vor:


*Dokumentenprüfung und Erstellung des Prüfplans (ca. 1-2 PT)
* Dokumentenprüfung und Erstellung des Prüfplans (ca. 1-2 PT)
*Vor-Ort-Prüfung und Abschlussbesprechung (ca. 1-2 PT)
* Prüfung vor Ort und Abschlussbesprechung (ca. 1-2 PT)
*Erstellung des Prüfberichtes und Ausstellung des Testats nach Basis-Absicherung (ca. 0,5-1 PT)
* Erstellung des Prüfberichts und Ausstellung des Testats nach Grundschutz (ca. 0,5-1 PT)
*Vom BSI nicht aufgeführt aber sinnvoll ist ein Vorgespräch mit dem Auditor (ca. 0,5 PT)
* Nicht vom BSI 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.
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) Audit-Kosten liegen also irgendwo zwischen 2.700 und 7.500 €
Die reinen (externen) Auditkosten 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).
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 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.
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 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.
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 geht das?==
==Wie wird es durchgeführt? ==


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


Eine grundsätzliche Anleitung zur Umsetzung des BSI IT-Grundschutz an einer Hochschule ist im [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Hilfsmittel/Profile/Profil_Hochschulen.html IT-Grundschutz-Profil des ZKI] ausführlich beschrieben.
Eine grundsätzliche Anleitung zur Umsetzung von BSI IT-Grundschutz an einer Hochschule ist im [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Hilfsmittel/Profile/Profil_Hochschulen.html 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.
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 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, es 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, anstatt ein Teil nach dem Anderen mit vollständigem Grundschutz zu versorgen und damit zu riskieren das noch nicht betrachtete Teile wesentliche Lücken aufweisen.
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 ===
===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 [[Informationssicherheitsleitlinie|Leitlinie zur Informationssicherheit]] werden die übergreifenden Ziele und die Strategie der Hochschule in Bezug auf Informationssicherheit festgelegt.
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 [[Informationssicherheitsleitlinie|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 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.  
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 man ein ISMS in der Organisation einführt, findet ihr im Artikel [[ISMS-Einführung]].
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 Mindestanforderung für eine Testierung findet ihr im Artikel [[Referenzdokumente#Referenzdokumente_zur_Basisabsicherung|Referenzdokumente]].
Grundlegende Dokumente für die Einführung eines ISMS und Mindestanforderungen für eine Zertifizierung finden sich im Artikel [[Referenzdokumente#Referenzdokumente_zur_Basisabsicherung|Referenzdokumente]].


=== Step 2: Definition des Geltungsbereichs (Informationsverbund) ===
===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.  
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 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 und Klimatisierung.
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 ===
===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.
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äftsprozesse und der Hilfsprozesse
* Liste der Geschäfts- und Hilfsprozesse
* Liste der Anwendungen
* Liste der Anwendungen
* Liste der IT-Systeme
* Liste der IT-Systeme
* Liste der Netzsegmente (Netzbereiche, VLAN's etc.)
* Liste der Netzwerksegmente (Netzwerkbereiche, VLAN's etc.)
* Liste der Clientsysteme (PC's, Notebooks, Terminals, mobile Geräte)
* Liste der Client-Systeme (PCs, Notebooks, Terminals, mobile Geräte)
* Liste der Administratoren und deren Zuständigkeiten
* Liste der Administratoren und deren Verantwortlichkeiten
* Liste der relevanten Räume und Gebäude (vom Rechenzentrum bis zu Büros von Administratoren und Nutzern)
* Liste der relevanten Räume und Gebäude (vom Rechenzentrum bis zu den Büros der Administratoren und Benutzer)


Im Wiki gibt es hierfür eine [[Strukturanalyse|Mustervorlage für eine Strukturanalyse]].
Im Wiki gibt es dazu eine [[Strukturanalyse|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.
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 ===
===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).
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 ===
===Step 5: Grundschutzchecks===
Die Hauptarbeit steckt in den [[LF-Grundschutzcheck|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.
Der Hauptteil der Arbeit besteht in der Überprüfung der grundlegenden Schutzmaßnahmen [[LF-Grundschutzcheck|(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 ===
=== 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.  
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 ===
===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. Die Grundschutzchecks dürfen zum Zeitpunkt der Auditierung nicht älter als ein Jahr sein.
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 ===
===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 [https://www.bsi.bund.de/dok/6617482 Liste der vom BSI zertifizierten Auditoren].
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 [https://www.bsi.bund.de/dok/6617482 Liste der vom BSI zertifizierten Auditoren].


Folgende Dokumente sind für eine erfolgreiche Testierung mindestens erforderlich:
Folgende Dokumente sind für eine erfolgreiche Testierung mindestens erforderlich:
Zeile 177: Zeile 178:
*[[RiLi-InterneAuditierung|Richtlinie zur internen ISMS-Auditierung]]
*[[RiLi-InterneAuditierung|Richtlinie zur internen ISMS-Auditierung]]
*[[RiLi-KVP|Richtlinie zur Lenkung von Korrektur- und Vorbeugungsmaßnahmen]]
*[[RiLi-KVP|Richtlinie zur Lenkung von Korrektur- und Vorbeugungsmaßnahmen]]
*[[Strukturanalyse]]
*[[Strukturanalyse]]  
*Aktueller Report der Grundschutzchecks
*Aktueller Report der Grundschutzchecks
Der Auditor prüft im Audit zuerst die Dokumente und im Anschluss -vor Ort- ausgewählte Bausteine des Grundschutz-Kompendiums (ca. 10% der Bausteine, mindestens sechs) auf die ausreichende Umsetzung der enthaltenden 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.
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 ===
===Step 9: Party===
Dieser Punkt erscheint vielleicht etwas spaßig, ist aber wichtig für das weitere Vorgehen.
Dieser Punkt klingt vielleicht etwas lustig, ist aber wichtig für das weitere Vorgehen.


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


Nach dem Audit ist vor den Audit. Ein Testat ist nur zwei Jahre gültig, eine Zertifizierung erforder ein jährliches Audit. die erbrachte Leistung sollte von der Leitung anerkannt und angemessen gewürdigt werden, um die Motivation auch für das nächste Audit aufrecht zu erhalten.
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 ===
===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:  
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.
* Für den Baustein ISMS.1 Sicherheitsmanagement auch die Standard-Anforderungen 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.
* Durchführung einer Schutzbedarfsfeststellung und Risikoanalyse (z.B. nach Standard 200-3) für die Kerngeschäftsprozesse, um risikobasiert weiteren Handlungsbedarf zu identifizieren.
* Die Standard-Anforderungen für alle modellierten R1-Bausteine umsetzen.
* Umsetzung der Standardanforderungen für alle modellierten R1-Bausteine.
* Einführung eines Notfallmanagements, zumindest bezogen auf aktuelle Gefährdungen wie z.B. Ransomware.
* Einführung eines Notfallmanagements, zumindest bezogen auf aktuelle Bedrohungen wie z.B. Ransomware.
* Umsetzung einer Kernabsicherung für kritische Geschäftsprozesse und Verfahren.
* Umsetzung einer Kernabsicherung für kritische Geschäftsprozesse und -verfahren.


== Weiterführende Literatur ==
==Weiterführende Literatur==


[https://www.bsi.bund.de/dok/10027834 BSI Standard 200-1 Managementsysteme für Informationssicherheit (ISMS)]
[https://www.bsi.bund.de/dok/10027834 BSI Standard 200-1 Managementsysteme für Informationssicherheit (ISMS)]

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

Testat Logo Muster.jpg

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:

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