Step by step: GRC@SAVISCON

Wie wir unser IT-Sicherheits-Management aufsetzen

von Ingo Simon, Geschäftsführer bei der SAVISCON GmbH 

Nachdem wir in unserem letzten Blog-Beitrag „No Risk – more fun!“ der Reihe GRC@SAVISCON über den Start unseres Risiko-Managements berichtet haben, soll es heute um die IT-Sicherheit gehen. Ein kurzer Rückblick: Wir als SAVISCON GmbH haben uns dazu entschieden unser Governance, Risk- und Compliance-Management (GRC-Management) mit unserer eigenen GRC-Software (GRC-COCKPIT) strukturiert und digital abzubilden. Dazu haben wir das Programm GRC@SAVISCON mit den drei Projekten Risiko-Management, IT-Sicherheit sowie Compliance- und Datenschutz-Management aufgesetzt. Lesen Sie hier unseren vollständigen initialen Blog-Beitrag. Aber jetzt zurück zum Thema: IT-Sicherheit. 

IT-Sicherheit: Wo fangen wir an? 

Wie auch beim Risiko-Management brauchen wir bei SAVISCON uns nicht extra der Unterstützung der Geschäftsleitung zu versichern. Das ist ja qua Persona schon gegeben. Aber klar ist: In anderen Unternehmen muss man die Rückendeckung der Unternehmensleitung haben, um die benötigten Ressourcen für die Durchführung des Projekts einfordern zu können. Bei uns kann es also losgehen. 

Noch eine Anmerkung: Im IT-Grundschutz Baustein ISMS Sicherheitsmanagement wird in der Anforderung ISMS.1.A3 eine Leitlinie zur Informationssicherheit und nach ISMS.1.A10 ein Sicherheitskonzept eingefordert, die anfangs erstellt und kommuniziert werden müssen. Das werden wir auch nicht vernachlässigen. Wir haben allerdings entschieden, die Fleißarbeit, wie in den nächsten Absätzen beschrieben, bereits zeitgleich anzugehen. In unserem Fall gehen wir davon aus, dass die Erkenntnisse aus der Strukturanalyse und Schutzbedarfsfeststellung eine gute Indikation darüber geben, was in den Leitlinien zu berücksichtigen ist. Für „unfertige“ Organisationsstrukturen, wie es in den bei uns vorherrschenden Umbruchzeiten gerade der Fall ist, halten wir das für ein sehr vorteilhaftes Vorgehen. Wir werden über die Erstellung der Leitlinien und Sicherheitskonzepte in zukünftigen Blog-Beiträgen berichten.

Klar ist außerdem, dass wir uns über die Tool-Auswahl keine Gedanken machen müssen, das GRC-COCKPIT ist als System für unser ISMS ja prädestiniert. Wir wollen das IT-Sicherheitsmanagement als Teil unseres GRC-Managements durchführen und haben so in einem System den Überblick über die gesamten Unternehmensrisiken und den Compliance-Status inklusive der IT-Sicherheit.

 Nun krempeln wir also die Ärmel hoch und fangen an. Als erstes gibt es drei Kernaufgaben, die erledigt werden müssen: Assets erfassen, diese gruppieren und Abhängigkeiten dokumentieren, sowie deren Schutzbedarf analysieren. 

Assets erfassen 

Was sind überhaupt Assets? Ins Deutsche übersetzt bedeutet das „Vermögenswerte im Unternehmen“. Diese Assets müssen nicht unbedingt reale Güter darstellen, sondern können auch nicht-reale Güter wie Wissen, Patente oder Lizenzen sein. Bei uns ist das zum Beispiel der Source Code unserer Produkte, die wir auch als Assets betrachten. Die sind schließlich eine Basis für unser Geschäftsmodell und somit besonders schützenswert, der IT–Grundschutz spricht hier von den Kronjuwelen. Diese Betrachtung geht genau genommen über das Thema IT-Sicherheit hinaus, und fällt unter den Begriff Informationssicherheit. Es ist für uns jedoch eine bewusste Entscheidung, diese Assets in die Gesamtmethodik des IT-Grundschutz mit einzubinden. Ein weiteres, griffigeres Beispiel für Assets aus der IT-Sicherheit: Es gibt vermutlich in so ziemlich jedem Unternehmen mindestens einen Arbeitsplatz-PC oder Server, der Daten beinhaltet, die für das Unternehmen sehr wichtig sind. Das können beispielsweise Kundeninformationen sein. Somit ist dieser PC oder Server ein Unternehmens-Asset, das für die IT-Sicherheit des Unternehmens relevant ist. 

Wo fängt man an, wo hört man auf? 

Was sind Assets bei der SAVISCON GmbH, die unsere IT-Sicherheit betreffen? Das ist genau die Frage, die wir uns zu Beginn gestellt haben. Theoretisch muss man jedes IT-Gerät mit in die Assets aufnehmen und dort abbilden. Doch hier gilt es ein gesundes Maß zu finden, welche Geräte einzeln aufgenommen werden sollen und welche z. B. als Gruppe abstrahiert werden können. Führe ich jeden Laptop einzeln auf? Oder führe ich nur einen Laptop auf, der in der Schutzbedarfsanalyse als Prototyp für alle anderen steht. Diese Fragen lassen sich leider nicht pauschal für jedes Unternehmen beantworten. Daher kann man beliebig viel Zeit darauf verwenden ein Konzept zu entwickeln, welche Assets wie erstellt und gruppiert werden sollen und welche nicht. Oder:

Einfach loslegen: sammeln, strukturieren, (aus)sortieren  

Man fängt einfach an! Unsere Erfahrung hat gezeigt, dass es wichtig ist einfach zu starten und die Assets festzuhalten, die uns gleich in den Sinn gekommen sind. Wir haben uns zum Beispiel entschieden alle Laptops einzeln zu erfassen, nicht „den Laptop“ als solches. Warum? Weil jeder Laptop in unserer übersichtlichen Organisation einem bestimmten Rolleninhaber gehört, der wiederum unterschiedliche Informationen mit dem Laptop bearbeitet. Fällt einer der Entwicklungs-Laptops aus, so dauert es eine längere Zeit, die gesamte Entwicklungsumgebung auf einem Ersatzgerät wieder einzurichten. Ein Consulting Laptop, der im Wesentlichen über Remote Zugriff die relevanten Informationen in den Kundenwelten verarbeitet, kann ich im Prinzip mit jedem Gerät ersetzen, auf dem ein Citrix Receiver installiert werden kann. Damit unterscheidet sich die Anforderung an die notwendige Verfügbarkeit für diese Laptops. Deswegen erfassen wir alle Laptops einzeln. 

Die erfassten Assets haben wir dann in eine grobe Struktur gebracht. Keine Sorge, wenn die zu Beginn etwas verwirrend aussieht. Das ist ganz normal und sie wird sich im Prozess vermutlich noch viele Male ändern. In unserem Prozess haben wir sogar nach und nach Assets wieder entfernt, verschoben oder sogar ihre gesamte Gruppierung verworfen, weil sie obsolet geworden sind. Das ist aber in unserem GRC-COCKPIT gar kein Problem. Wenn man das auf verteilten Excel-Listen versuchen würde, an denen mehrere MitarbeiterInnen arbeiten, wäre die Koordination der Änderungen sehr viel aufwändiger und fehleranfällig. 

Für uns als Software-Unternehmen sind die folgenden Assets relevant: Gebäude und Räume, IT-Geräte, Lizenzen, gemietete Server, Produktions- oder auch Testinstanzen, die wir unseren Kunden zur Verfügung stellen. Beim Erstellen mehrerer Assets haben wir diese nach Typen aufgeteilt und gruppiert. Zur Ableitung der Schutzbedarfe haben wir dann die Abhängigkeiten von Assets zu anderen Assets hergestellt, indem wir sie im GRC-COCKPIT miteinander verknüpft haben. Die Abhängigkeiten sind nach IT-Grundschutz Methodik: „Nötig für“ bzw. „Benötigt“ oder „Befindet sich in“ bzw. „Beinhaltet“

An dieser Stelle merkt man bereits, ob man sich mit der Struktur wohl fühlt und ob sich Assets bzw. Gruppierungen noch nicht so „rund“ anfühlen. In diesem Fall kann man versuchen ein Asset aufzusplitten oder mehrere zusammenzufassen. Wir haben festgestellt, dass die Identifizierung von Assets sehr gut in einer Gruppe funktioniert, da jeder eine andere Sicht auf die Dinge hat und man diskutieren kann, welche Assets aufgenommen werden sollten und warum. Aus den unterschiedlichen Perspektiven konnten wir häufig weitere Assets ableiten, die wir direkt in unser GRC-COCKPIT aufgenommen haben.  

Schutzbedarf feststellen 

Für alle Assets muss dann der Schutzbedarf festgestellt werden. In der Diskussion darüber kommt man meist zwangsläufig zu Ideen, welche geeigneten Maßnahmen sich für das Asset ableiten lassen. Hierbei wird jeder eine etwas andere Meinung haben, welche Assets besonders schützenswert sind und warum. Auch hier keine Scheu zeigen: einfach starten und die Assets bewerten. Zu Beginn haben wir eher „vorsichtiger“ bewertet, sprich den Schutzbedarf höher angesetzt. Denn wir können die Bewertung im Laufe der Zeit noch etwas abschwächen, wenn wir neue Erkenntnisse gewonnen haben. Während der Schutzbedarfsfeststellung haben wir uns schon gleich die Fragen gestellt: Welche Assets sind besonders schützenswert? Warum? Was können wir tun, um dem Schutzbedarf gerecht zu werden? 

Maßnahmen ableiten 

Mit den Antworten auf die Fragen aus der Schutzbedarfsanalyse fällt es uns leicht mögliche Maßnahmen abzuleiten. Wenn beispielsweise ein Arbeits-Laptop besonders schützenswert ist, da er wichtige Daten enthält, so könnten sich bezüglich des Schutzbedarfes für die Vertraulichkeit die Maßnahme „Festplatten verschlüsseln“ anbieten, sowie für die Verfügbarkeit die Maßnahme „regelmäßige Backups erstellen“. Wir werden darüber in den folgenden Blog-Beiträgen noch ausführlicher berichten.

Denn auch hier ist es wichtig, einen Schritt nach dem anderen zu gehen. Solange die Assets nicht erfasst und die Schutzbedarfe nicht fertig analysiert sind, sollte man sich davor hüten, schon in die Dokumentation der Maßnahmen abzudriften. Sonst läuft man Gefahr, sich zu verrennen. Deswegen erst die Strukturanalyse und Schutzbedarfsfeststellung beenden, dann erst die Risikobetrachtung und die Maßnahmen angehen. Oft ergeben sich Ideen zu Risiken und Maßnahmen in der gemeinsamen Diskussion. Dann muss man sich aber disziplinieren und den Schritt zurück machen, um, wie oben beschrieben, die ersten Schritte erst einmal vollständig abzuarbeiten. 

 …to be continued: 

Hier die Zusammenfassung der bisher wichtigsten Erkenntnisse aus dem Projekt IT-Sicherheit:  

• Einfach erst einmal anfangen alle Assets zu sammeln, (aus)sortieren kann man in einem späteren Schritt noch immer 
• Die gesammelten Assets typisieren und gruppieren 
• Danach die Abhängigkeiten der Assets voneinander dokumentieren 

• Der nächste Schritt ist die Festlegung des Schutzbedarfs  
• Wichtig: Sparringspartner suchen! in der Diskussion in Gruppen ergeben sich wichtige Erkenntnisse und differenziertere Sichten über relevante Assets, potenzielle Gruppierungen und Schutzbedarfe 
• Bei der Schutzbedarfsfeststellung zu Beginn den „Worst Case“ annehmen – abschwächen geht immer noch 
• Nicht scheuen auch mal einen Schritt zurück zu gehen, um zwei voran zu kommen! 

Im nächsten Blog-Beitrag der Reihe schauen wir gemeinsam mit unserer internen Datenschutzbeauftragten Karin Selzer in das Projekt Datenschutz: Los geht‘s: Wie wir den Datenschutz intern umsetzen.

Über den Autor: 

Ingo Simon ist Geschäftsführer der SAVISCON GmbH. Er hat das Unternehmen im Jahr 2010 gegründet und war bis 2018 größtenteils mit einigen Beratern in Kundenprojekten auf Basis von Dienstleistungsverträgen unterwegs. Ende 2018 übernahmen er die Software des heutigen GRC-COCKPITs und weitete das Geschäftsfeld von Corporate Communication und Enterprise Content Management auf das GRC-Management aus. Kontakt: 040 80 90 81 446 oder ingo.simon@saviscon.de