GRC@SAVISCON: Datenschutz

Los geht‘s: Wie wir den Datenschutz intern umsetzen

von Karin Selzer, Consultant Compliance und Datenschutz bei der SAVISCON GmbH

Nachdem wir in unserem letzten Blog-Beitrag „Step by step“ der Reihe GRC@SAVISCON über den Start unseres IT-Sicherheitsmanagements berichtet haben, soll es heute um den Datenschutz 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: Datenschutz.

Datenschutz in der Praxis: wie geht das?

Vielleicht geht es Ihnen wie es mir bei meinem vorherigen Arbeitgeber erging, dort habe ich mich als Datenschutzkoordinatorin oft gefragt: was bedeuten die Anforderungen aus der EU-Datenschutz-Grundverordnung (DSGVO) eigentlich für uns in der Praxis? Wie genau ist das alles umzusetzen? Auch heute – nach meiner Ausbildung zur Datenschutzbeauftragten ist das teilweise noch immer so. Ja, ich kenne und verstehe die Hintergründe besser und sammle immer mehr Erfahrung auf dem Gebiet, aber die DSGVO ist in vielen Punkten einfach noch unscharf. In vielen Bereichen fehlen eindeutige Gerichtsurteile und das wird auch noch einige Zeit dauern. Aber: es gibt viele Orientierungshilfen, Kurzpapiere, Leitlinien und Muster u. a. von der deutschen Datenschutzkonferenz und den Aufsichtsbehörden der einzelnen Bundesländer, die sehr hilfreich sind. Auch unterschiedliche Fachliteratur und Fachzeitschriften können weitere Orientierung bringen. Dazu später mehr.

Datenschutz-Management: das Fundament

Das Thema Datenschutz wird oft als unliebsames Thema gesehen, das die Unternehmen mit zig Regelungen immens einschränkt, keine praktikablen Lösungen für die wirkliche Praxis bietet und eigentlich nur Zeit und Geld kostet. Deshalb ist es wichtig, dass die Führungsetage hinter dem Thema steht und die nötigen Ressourcen zur Verfügung stellt. Unser Geschäftsführer, Ingo Simon, hat die Wichtigkeit dieses Themas erkannt und die notwendigen Ressourcen bereitgestellt. Dafür bin ich der lebende Beweis, denn meine Stelle als Consultant Compliance und Datenschutz sowie interne Datenschutzbeauftragte wurde im Januar 2021 neu geschaffen. So steht einem guten Start nichts im Wege. Doch wo fängt man an?

Verzeichnis von Verarbeitungstätigkeiten

Die DSGVO bietet 99 Artikel, da kann man schon mal den Überblick fürs Wesentliche verlieren und scheut sich vielleicht überhaupt erst anzufangen. Hier kann ich empfehlen, kleine Meilensteine / Arbeitspakete zu schnüren. Wir haben uns dazu entschieden, erstmal unser „Verzeichnis von Verarbeitungstätigkeiten“ aufzubauen. Warum? Ein kurzer Einstieg in zwei Artikel der DSGVO: Im Artikel 5 Abs. 1 werden die Grundsätze für die Verarbeitung personenbezogener Daten beschrieben (z. B. Rechtmäßigkeit, Zweckbindung, Datenminimierung). Im Abs. 2 heißt es, dass der Verantwortliche für die Einhaltung des Absatzes 1 verantwortlich ist und dessen Einhaltung nachweisen können muss („Rechenschaftspflicht“). Im Artikel 24 Abs. 1 sind die Pflichten des Verantwortlichen im Hinblick auf die zu ergreifenden technischen und organisatorischen Maßnahmen aufgeführt. Wir als Unternehmen müssen also den Nachweis erbringen können, dass wir die Anforderungen aus der DSGVO umgesetzt haben. Dazu gehört natürlich auch der Nachweis der umgesetzten Maßnahmen.

Das Verzeichnis von Verarbeitungstätigkeiten erfüllt demnach gleich mehrere Funktionen. Zum einen soll mit der Führung des Verzeichnisses der Nachweis zur Einhaltung der Vorgaben gemäß DSGVO erfolgen. Zum anderen ist jeder Verantwortliche bzw. jeder Auftragsverarbeiter verpflichtet, mit der Aufsichtsbehörde zusammenzuarbeiten und auf Anfrage das entsprechende Verzeichnis vorzulegen (Art. 30 DSGVO). Sie können das Verzeichnis auch als „Zentrum/Kern“ des Ganzen sehen, denn die komplette Dokumentation lässt sich um das Verzeichnis herum aufbauen, in dem auf Dokumente, Richtlinien, Vertragswerke, Rechtsgrundlagen verwiesen werden kann.

Übrigens: Die Datenschutzkonferenz hat hier ein Kurzpapier zum Verzeichnis von Verarbeitungstätigkeiten (Kurzpapier Nr. 1 – Stand 17.12.2018) herausgegeben, um eine einheitliche Handhabung bei der Führung des Verzeichnisses zu erreichen. Alle Kurzpapiere sind im Internet auf der Seite der Datenschutzkonferenz veröffentlicht: Datenschutzkonferenz (datenschutzkonferenz-online.de).

Wie setze ich das Verzeichnis von Verarbeitungstätigkeiten auf?

Zum Start des Verzeichnisses habe ich erstmal sämtliche Kolleginnen/Kollegen mit „ins Boot“ geholt. Ich allein kann unmöglich alle Verarbeitungstätigkeiten im Haus kennen, deshalb bin ich auf die Mithilfe der anderen Mitarbeiter angewiesen. Dazu habe ich mit allen Kollegen virtuell gesprochen, alle Tätigkeiten gesammelt und grob beschrieben. Wir bilden das im GRC-COCKPIT in der Prozessdokumentation der Stammdaten ab. Ein Prozess oder Teilprozess, der eine Verarbeitungstätigkeit darstellt, bekommt eine entsprechende Markierung. Dadurch werden die spezifischen Detailfelder, die ich im nächsten Abschnitt erwähne, aktiviert und können gefüllt werden. Aus den eingegebenen Daten kann per Knopfdruck ein Bericht erstellt werden, der alle diese markierten Prozesse enthält und damit unser Verzeichnis der Verarbeitungstätigkeiten darstellt. Dieser Bericht kann dann der Aufsichtsbehörde zur Verfügung gestellt werden.
Übrigens: unser Entwicklungsteam wird hier permanent mit eingebunden. Wenn sich neue oder verbesserte Funktionen aus der Praxis ergeben und bei unserer Nutzung bewähren, übernehmen wir sie auch in das GRC-COCKPIT für unsere Kunden. Unser Ansporn ist es, das GRC-COCKPIT stetig zu verbessern, sodass wir unseren Kunden eine Software aus der Praxis, für die Praxis bieten können!

Verzeichnis von Verarbeitungstätigkeiten mit Details verfeinern

Im nächsten Schritt (dort stehen wir aktuell) wird jede einzelne Verarbeitungstätigkeit im GRC-COCKPIT erfasst und zur weiteren Erhebung von Details an den jeweils verantwortlichen Mitarbeiter geschickt. Das bedeutet, dass jeder verantwortliche Mitarbeiter über das Tool eine Aufgabe mit einer Deadline erhält. Über den „Health Check“ im System kann ich mir anzeigen lassen, wie viele Aufgaben zur Detailerfassung der Verarbeitungstätigkeiten noch offen sind. So kann ich nichts vergessen. In den Details werden z. B. die Betroffenengruppen, die Datenkategorien, die Empfänger und Löschfristen hinterlegt sowie Risikobewertungen durchgeführt. Selbstverständlich werden dort auch Verknüpfungen zu den technischen und organisatorischen Maßnahmen hergestellt, z. B. Verweis auf IT-Sicherheitskonzept, Berechtigungskonzept, Richtlinien, etc. Hierbei wird klar erkennbar, dass die Themenfelder Datenschutz, IT-Sicherheit und Risiko-Management sich überlappen bzw. eng miteinander verbunden sind. Demnach ist der Austausch mit meinen Kollegen aus den Projekten Risiko-Management und IT-Sicherheit zwingend notwendig, um auch Doppelarbeit zu vermeiden. Die Kommunikation ist aber auch wichtig, um ein gemeinsames Verständnis von Definitionen zu erhalten. Immer wieder stolpern wir darüber, was eigentlich eine Anforderung und was eine Maßnahme ist und, wie detailliert ein Risiko formuliert sein sollte.

Hier habe ich ein konkretes Beispiel zum besseren Verständnis herausgesucht:

Norm: EU-Datenschutz-Grundverordnung
Anforderung_1: Führen des Verzeichnisses von Verarbeitungstätigkeiten (gemäß Art. 30 DSGVO
Anforderung_2: Erfüllung der Rechenschaftspflicht (gemäß Art. 5 Abs. 2 DSGVO)
Anforderung_3: Beschreibung der technischen und organisatorischen Maßnahmen (gemäß Art. 24 Abs. 1 + Art. 32 Abs. 1 DSGVO)
Maßnahme_a: Erfassen aller Verarbeitungstätigkeiten mit allen geforderten Pflichtangaben im GRC-COCKPIT
Maßnahme_b: Regelmäßige Pflege und Aktualisierung der Verarbeitungstätigkeiten mit allen geforderten Pflichtangaben im GRC-COCKPIT
Risiko: Sanktionen (Geldbuße) bei fehlendem bzw. nicht vollständigem Verzeichnis von Verarbeitungstätigkeiten (gemäß Art. 83 Abs. 4 lit. a DSGVO)

Das ist natürlich nur ein Auszug an Anforderungen, Maßnahmen und Risiken. Zur vollständigen Erfüllung der Rechenschaftspflicht sind z. B. noch viele weitere Maßnahmen notwendig. Unser Ziel ist es, alle Anforderungen aus der EU-DSGVO mit den jeweils notwendigen Maßnahmen und den entsprechenden Risikobewertungen (inkl. Datenschutz-Folgenabschätzungen) im GRC-COCKPIT abzubilden und zu dokumentieren. Bei Maßnahmen, die regelmäßig durchgeführt werden müssen, kann uns das Tool ebenso unterstützen, und zwar in Form von Erinnerungen/Überwachungen.
Wie Sie sehen, haben wir noch eine ganze Menge Arbeit vor uns, aber der Grundstein ist gelegt und jetzt müssen wir dranbleiben. Und das werden wir auch!

…to be continued:

Hier die Zusammenfassung der bisher wichtigsten Erkenntnisse aus dem Projekt Datenschutz:

  • Kleine Meilensteine / Arbeitspakete schnüren
  • Einfach mal loslegen mit einem Thema, z. B. Verzeichnis von Verarbeitungstätigkeiten
  • Mitarbeiter unbedingt mit „ins Boot holen“, denn sie liefern wichtigen Input
  • Gemeinsames Verständnis durch Beispiele schaffen
  • Nicht verzweifeln, wenn zu Beginn nicht alle Details vorliegen, sondern weiter recherchieren und im Nachgang ergänzen
  • Kurzpapiere der DSK und weitere Handlungsempfehlungen aus dem Netz zur Orientierung heranziehen
  • Austausch mit anderen Datenschutzbeauftragten

In unserem nächsten Blog-Beitrag geht es um das Thema Compliance und die Frage: Zu klein für Compliance?

Über die Autorin:

Porträtfoto Karin Selzer

Karin Selzer (Consultant Compliance & Datenschutz) im Büro der SAVISCON GmbH.

Karin Selzer ist Consultant für Compliance & Datenschutz und interne Datenschutzbeauftragte bei der SAVISCON GmbH. Seit Januar 2021 kümmert sie sich um maßgebliche Richtlinien und die Umsetzung aller relevanten Themen rund um Compliance und Datenschutz. Zusätzlich steht sie unseren GRC-COCKPIT Kunden und Interessenten mit Rat und Tat zur Seite. Kontakt: 040 80 90 81 446 oder karin.selzer@saviscon.de

Revisionskalender & OdG-Prüfungen

Der Caritasverband Meschede e. V. setzt auf das GRC-COCKPIT der SAVISCON GmbH. Mit der Professional Version der webbasierten Software organisiert der Verband sein Risiko- und Compliance-Management. „Für uns war ausschlaggebend, dass wir mit der Software alles abdecken können: Neben dem klassischen Risiko- und Compliance-Management eben auch unsere speziellen Themen Revisionskalender und die Prüfung der Ordnungsmäßigkeit der Geschäftsführung (OdG)“, erklärt Marion Becker, Fachbereichsleitung Finanzen & IT beim Caritasverband Meschede.  

Clubhouse und die DSGVO

Hype-App: Viele wollen rein, doch um welchen Preis?

von Karin Selzer, Consultant für Compliance & Datenschutz bei der SAVISCON GmbH

Haben Sie schon von Clubhouse gehört? Bei der kostenlosen App handelt es sich um eine neue Social-Media-Plattform, die ausschließlich die Audio-Kommunikation zulässt – keine Videos, keine Fotos, keine Textnachrichten, nur Ton. Die App der US-Firma Alpha Exploration Co. Inc. gibt es aktuell ausschließlich im App-Store für iPhone-Nutzer. Der Zugang ist nur mit einer Einladung von Freunden möglich, die diese App bereits nutzen. Ist man dann mal drin, können verschiedene virtuelle Räume besucht werden, in denen dann über diverse Themen gesprochen wird. Ähnlich einer Telefonkonferenz oder einem Podcast. Viele bekannte Persönlichkeiten sind schon drin: Thomas Gottschalk, Joko Winterscheidt, Mario Götze und Ashton Kutscher. Klingt erstmal total hip und cool. Passt gut in die aktuelle Lockdown-Zeit. Oder? Bestimmt! Doch der neue Social-Media-Hype ist datenschutzrechtlich sehr heikel:

Übertragung des Adressbuches

Das eigene Adressbuch wird an Clubhouse übertragen, wenn man das Einverständnis dazu gibt. Das ist zwar nicht verpflichtend, aber eigentlich notwendig, um die App in vollem Umfang nutzen zu können. Ohne Adressbuchfreigabe hat man z. B. keine Einladungsoption. Stimmt man der Übertragung des Adressbuches zu, findet diese aber ohne Zustimmung der betroffenen Personen statt, d.h. bei jedem einzelnen Kontakt müsste vorab eine Zustimmung eingeholt werden. Da dies nicht passiert, liegt hier ein Verstoß gegen die Rechtmäßigkeit der Verarbeitung vor (Art. 6 DSGVO). Zudem auch ein Verstoß gegen Art. 14 DSGVO: der Verantwortliche hat eine Informationspflicht gegenüber der betroffenen Person. Auch dieser kommen die Betreiber von Clubhouse nicht nach.

Speicherung diverser Daten

Die Audiobeiträge werden temporär aufgezeichnet. Laut Clubhouse, um bei Verstößen/Beschwerden reagieren zu können. Außerdem werden weitere Daten gesammelt, wie z. B. Interessen an den unterschiedlichen Themen/Beiträgen, Ortsdaten, Interaktionen mit anderen App-Nutzern. Die Speicherung der Beiträge und der sonstigen Daten sind aber zur Nutzung der App nicht wirklich notwendig und dies widerspricht den Grundsätzen für die Verarbeitung personenbezogener Daten (Art. 5 Abs. 1b DSGVO „Zweckbindung“ und Art. 5 Abs. 1c DSGVO „Datenminimierung“).

Fehlende Transparenz

Aus den Nutzungsbedingungen und aus der Datenschutzerklärung geht nicht hervor, inwieweit und zu welchen konkreten Zwecken die personenbezogenen Daten von Clubhouse genutzt werden. Die Art und der Umfang der Verwendung sind wenig transparent und unklar. Gemäß Art. 12 DSGVO ist der Verantwortliche aber verpflichtet, alle Informationen gemäß den Artikeln 13 und 14 und allen Mitteilungen gemäß den Artikeln 15 bis 22 und Artikel 34 in präziser, transparenter, verständlicher und leicht zugänglicher Form in einer klaren und einfachen Sprache zu übermitteln. Die Dokumente sind nur in englischer Sprache vorhanden, was demnach nicht DSGVO-konform ist, denn sie müssten auch in deutscher Sprache zur Verfügung gestellt werden. Zwischenzeitlich hat das Unternehmen zumindest den Anfang der Datenschutzerklärung ins Deutsche übersetzt, aber ab den Internetaktivitätsdaten sind die Inhalte wieder nur in Englisch verfügbar (Stand 09.02.2021). Aufgrund der sehr allgemein gehaltenen Angaben gehe ich davon aus, dass sämtliche personenbezogene Daten der Nutzer auch umfassend für Marketingzwecke genutzt sowie an Dritte weitergegeben werden.

Hat Clubhouse Zukunft?

Es bleibt abzuwarten, ob der Hype rund um die App Clubhouse bestehen bleibt und vor allem, ob das Unternehmen die datenschutzrechtlichen Mängel zeitnah ausmerzen wird angekündigt haben sie es jedenfalls. Was meinen Sie: Sollten Apps, die gegen die DSGVO verstoßen, überhaupt in deutschen App-Stores erhältlich sein? Diskutieren Sie mit uns in den Kommentaren, wir sind gespannt auf Ihre Meinung!

Über die Autorin:

Porträtfoto Karin Selzer

Karin Selzer (Consultant Compliance & Datenschutz) im Büro der SAVISCON GmbH.

Karin Selzer ist Consultant für Compliance & Datenschutz und interne Datenschutzbeauftragte bei der SAVISCON GmbH. Seit Januar 2021 kümmert sie sich um maßgebliche Richtlinien und die Umsetzung aller relevanten Themen rund um Compliance und Datenschutz. Zusätzlich steht sie unseren GRC-COCKPIT Kunden und Interessenten mit Rat und Tat zur Seite. Kontakt: 040 80 90 81 446 oder karin.selzer@saviscon.de

 

 

Step by step: GRC@SAVISCON

Wie wir unser IT-Sicherheits-Management aufsetzen

von Ingo SimonGeschä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-ManagementIT-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 ITGrundschutz 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 sindDas 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 anwo 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 loslegensammeln, 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 sindWir 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. 

Screenshot der Asset Übersicht aus dem GRC-COCKPIT

Hier sehen Sie die Übersicht unserer Assets im GRC-COCKPIT.

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 gruppiertZur 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“

Screenshot der Abhängigkeiten aus dem GRC-COCKPIT

Blick ins GRC-COCKPIT: So werden die Abhängigkeiten für Assets dargestellt.

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 Ideenwelche geeigneten Maßnahmen sich für das Asset ableiten lassenHierbei wird jeder eine etwas andere Meinung haben, welche Assets besonders schützenswert sind und warum. Auch hier keine Scheu zeigeneinfach 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? 

Screenshot der GRC-COCKPIT-Funktion Schutzbedarfsfeststellung

Auf dieser Abbildung ist die GRC-COCKPIT-Funktion Schutzbedarfsfeststellung zu sehen.

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 Assetspotenzielle 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: 

Foto Ingo Simon

Ingo Simon (Geschäftsführer SAVISCON GmbH)

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 

IT-Sicherheitsmanagement für KRITIS-Betreiber

Qualität steigern, Aufwand senken: Transparenz und Effizienz mit digitalen Werkzeugen optimieren

Von Ingo Simon, Geschäftsführer der SAVISCON GmbH

KRITIS-Betreiber stehen seit jeher vor großen Herausforderungen, was das Management der IT-Sicherheit betrifft. Der Dokumentationsaufwand ist zuweilen kaum mit den vorhandenen Ressourcen zu leisten, und eine tagesgenaue Transparenz über den aktuellen Stand der gesamten IT-Sicherheit ist aus der Gesamtheit der Anforderungen, Risiken und Maßnahmen nur schwer zu konsolidieren. In diesem Beitrag zeigen wir einen Weg, wie Transparenz und Effizienz im Kontext der IT-Sicherheit, aber auch darüber hinaus, geschaffen werden kann.

Die erste Transparenzhürde besteht in der Regel darin, dass der Umfang und die Anzahl der Anforderungen nur schwer zu erfassen sind. Für KRITIS-Betreiber ist eines der wichtigsten Dokumente das vom Bundesamt für Sicherheit in der Informationstechnik (BSI) herausgegebene Dokument „Konkretisierung der Anforderungen an die gemäß § 8a Absatz 1 BSIG umzusetzenden Maßnahmen“. Hier sind genau 100 Anforderungen formuliert, denen der KRITIS-Betreiber gerecht werden muss. Die Anforderungen verweisen wiederum auf andere Dokumente, wie zum Beispiel dem „Kriterienkatalog Cloud Computing C5:2020“, in dem weitere 127 detaillierte Anforderungen niedergeschrieben sind. Von hier gibt es eine Kreuzreferenztabelle mit Verweisen auf die IT-Grundschutzbausteine – da verliert man schon bei den Anforderungen leicht die Übersicht. Wie kann man als KRITIS-Betreiber also die Herausforderungen Transparenz und Effizienz meistern?

Herausforderung Transparenz

Nähert man sich dem Thema Transparenz an, so bedarf es der Strukturanalyse und der Schutzbedarfsfeststellung für mehrere zig bis gern mal hunderte Assets, die bewertet werden müssen – je nach Größe der Organisation. Auf die Schutzbedarfsfeststellung folgt die Risikoanalyse, die entsprechend der Anzahl der Assets zu einer recht hohen Anzahl von Risiken führen kann. Für alle Risiken, deren Bruttorisikobewertung den Risikoappetit der Organisation übersteigt, müssen entsprechende Maßnahmen zur Minimierung des Risikos abgeleitet werden. Damit diese Maßnahmen auch umgesetzt werden, müssen passende Durchführungs- und Überwachungstermine festgelegt werden, die sicherstellen und belegen, dass die Maßnahmen nicht nur Lippenbekenntnisse darstellen. Alle genannten Objekte, also Anforderung, Asset, Risiko, Maßnahme und Überwachung, hängen in diversen Beziehungen miteinander zusammen. Viele Organisationen versuchen, diese Abhängigkeiten in einer Tabellenkalkulation abzubilden. Das scheitert irgendwann zwangsläufig, weil die Nachpflege bei Änderungen in den Objekten und deren Abhängigkeiten zu fehleranfällig ist. Das führt dann zu Dateninkonsistenzen, die entweder gar nicht auffallen, oder erst in der Berichtsführung ans Tageslicht kommen. Dann ist aber meist keine Zeit mehr, den Fehler in der Dokumentation nachzupflegen. Am Ende weiß man nicht wirklich, wo die Organisation in Sachen IT-Sicherheit steht.

Herausforderung Effizienz

Wie zuvor erläutert unterliegt das gesamte Setup eines vollständigen IT-Sicherheitsmanagements einer nicht zu unterschätzenden Komplexität. Um Fehler zu vermeiden, müssen die Mitarbeiter entsprechend in ihren Tätigkeiten geführt werden. Das betrifft sowohl die Aktionen, die zu tun sind, als auch die Daten, die zu erfassen sind. Das leisten die Tabellenkalkulationen in der Regel nicht. Daher werden dann komplexe Arbeitsanweisungen geschrieben, die mit zunehmendem Umfang immer weniger gelesen werden. So entstehen viele Datenfehler auch durch mangelnde Nutzerführung. Des Weiteren ist gerade das Thema Berichtswesen oft extrem aufwendig und vor allem fehleranfällig, wenn die Daten jedes Mal aus verschiedenen Quellen zusammengesucht und konsolidiert werden müssen.

Das passende Werkzeug

Was muss nun geschehen, um aus dem Dilemma herauszukommen? Der KRITIS-Betreiber tut gut daran, ein entsprechend geeignetes Werkzeug zu beschaffen, das die erforderlichen Objekte abbilden und miteinander in Beziehung bringen kann. Die Bearbeitung muss prozessorientiert an einem Objekt möglich sein, sodass die Auswirkung auf ein weiteres Objekt vom System gleich mit aktualisiert wird. Der Nachweis der Bearbeitung muss revisionssicher sein und Zusatzdokumente, wie Prüfprotokolle, müssen im System ablegbar sein oder aber zu externen Ablageorten verlinkt werden können. Zum Schluss muss auf der Basis der Daten im System ein möglichst automatisierter Bericht erzeugt werden können, der auf die relevanten Adressatengruppen (Management, Prüfer, Behörden etc.) zugeschnitten ist.  Das A und O eines solchen Systems ist aus unserer Sicht die Verlinkung der verschiedenen Objekte miteinander und damit die Möglichkeit, von einem Objekt per Mausklick auf das nächste Objekt zu navigieren – und das in jede Richtung. Mit dem SAVISCON GRC-COCKPIT gibt es ein Werkzeug, das genau diese „Traceability“ bietet. Nachfolgend möchten wir ein paar mögliche Szenarien nennen.

Beispiel 1: Konsolidieren der Anforderungen

Mit dem SAVISCON GRC-COCKPIT stehen alle relevanten Anforderungen an einem Ort zentral zur Verfügung. Da mehrere Quelldokumente oft identische Anforderungen formulieren, kann hier eine einzige, konsolidierte Anforderung abgeleitet werden. Diese ist im Hintergrund mit allen entsprechenden Quelldokumenten beziehungsweise -Anforderungen verlinkt. Damit hat der IT-Sicherheitsverantwortliche nur noch eine Anforderung, statt vieler, die mit den dazu gehörigen Risiken und den Maßnahmen in Beziehung gebracht werden muss. Trotzdem kann beispielsweise in einem Audit per Mausklick auf die Quellanforderung gesprungen werden, um damit nachvollziehbar die Erfüllung der Anforderung nachzuweisen.

Beispiel 2: Verknüpfen von Risiken mit Assets und Partnern

Wenn Unternehmen mit einer Grundgefährdung des IT-Grundschutzes, beispielsweise „G0.11 Ausfall oder Störung von Dienstleistern“, ein Risiko begründen, ist es wichtig, das Risiko mit einem Asset oder auch einem Partner zu verknüpfen. Das Risiko des Ausfalls eines Wartungsunternehmens ist sicher anders zu bewerten als das Risiko des Ausfalls eines Transportunternehmens. Also müssen das Risiko und seine Bewertung den Asset-Kontext und auch den Partner-Kontext erhalten. Ändert sich die Vertragslage und es kommt ein neuer Dienstleister mit einer anderen Leistungsfähigkeit, ändert sich in der Regel auch das Risiko für das Asset.

Beispiel 3: Verknüpfen von Risiken, Maßnahmen und Überwachungen

Eine der wichtigsten Aufgaben ist es, hoch bewertete Risiken mit entsprechenden Maßnahmen zu minimieren. Die Maßnahmen, zu denen man sich entschlossen hat, muss man zur Sicherstellung der Effektivität zwingend in der Durchführung überwachen. Dazu verknüpft man die Maßnahme mit einer oder mehreren Überwachungen. In den Überwachungen werden die Termine verwaltet und bei Terminüberschreitung Erinnerungen und Eskalations-Workflows angestoßen. Damit wird über die Überwachung der Maßnahmen auch die Minimierung des Risikos automatisch mit überwacht.

Fazit

Wenn man eine Anforderung mit einem Risiko verknüpft und dieses Risiko mit mehreren Maßnahmen zur Minimierung verknüpft, die dann mit diversen Überwachungen verknüpft sind, so hat man eine Grundlage für Transparenz: Sind sämtliche Überwachungen termingerecht durchgeführt und die Maßnahmen als wirksam eingestuft, so bekommen die Überwachungen einen grünen Status. Sind alle Überwachungen an einer verknüpften Maßnahme grün, so wird auch die Maßnahme grün, damit dann auch das verknüpfte Risiko und in Folge auch die verknüpfte Anforderung. Als Ergebnis sieht man in seiner Cockpit-Übersicht viel Grün. Wird aber zum Beispiel bei wiederholenden Maßnahmen und deren Überwachungen ein Termin überschritten – beispielsweise bei der jährlichen IT-Sicherheitseinweisung der Mitarbeiter – dann ist nicht nur der Termin in der Überwachung rot, sondern auch die Maßnahme, und damit das Risiko und die Anforderung. Und das fällt in der Cockpit-Übersicht sofort auf. Zu guter Letzt führt die Ablage, Verknüpfung und Pflege aller Daten in einem System dazu, dass automatisch generierte Berichte immer den aktuellen Stand und immer dieselbe Form haben. Das führt zu einer hohen Effizienz, Qualität und damit Transparenz auch für die Adressaten, die das Cockpit im Tool nicht jeden Tag vor Augen haben. Das SAVISCON GRC-COCKPIT ist genau dafür entwickelt worden, die beschriebenen Vorteile für den Anwender zur Verfügung zu stellen und ist damit ein wertvolles Hilfsmittel für KRITIS-Betreiber. Dieser Ansatz ist über die IT-Sicherheit hinaus auch auf das gesamte Compliance-Management und Risiko-Management anwendbar.

Ü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

SAVISCON GmbH | Heegbarg 16 | 22391 Hamburg | Geschäftsführer: Ingo Simon, Marian Grzabel