Projektklassifikation nach TISAX
Das Control 1.2.3 des ISA 6.0.2 des TISAX fordert die Berücksichtigung von Anforderungen der Informationssicherheit in Projekten. Insbesondere müssen Projekte „unter Berücksichtigung der Anforderungen an die Informationssicherheit klassifiziert“ werden. Leider gibt der Fragenkatalog hinsichtlich der Umsetzung kaum konkrete Vorgaben oder Erklärungen zur Umsetzung. Daher wollen wir dieses Thema in diesem Blogbeitrag einmal genauer betrachten.
Kundenprojekte vs. Interne Projekte
Viele unserer Kunden sind Dienstleister, die Projekte für ihre Kunden umsetzen. Sie werden beauftragt, um Marketing-Videos zu erstellen, Webseiten zu entwickeln, Software zu schreiben. Der Begriff „Projekt“ hat bei Ihnen immer nur den Kundenkontext. Interne Projekte hingegen werden selten als ‚Projekte‘ bezeichnet. Man redet hier eher über den konkreten Titel. Daher kommt es hier schon einmal zu der ein oder anderen Verwirrung, die in vielen Fällen aber auch von einem Auditor nicht aufgelöst wurde. Der ISA spricht nämlich in erster Linie ‚interne‘ Projekte an, die Einfluss auf die Informationssicherheit haben. Kundenprojekte als solche fallen (meiner Ansicht) nicht – oder nur bedingt – unter dieses Control, auch wenn ihnen als Informationswerte ebenfalls eine Klassifizierung im Sinne von Control 1.3.2 zugestanden werden muss. Warum dies dennoch wichtig ist, schauen wir uns im weiteren Verlauf dieses Artikels noch einmal an.
Interne Projekte
Fangen wir aber mit den Projekten an, auf die das TISAX-Control 1.2.3 abzielt: den internen Projekten, die Einfluss auf die Informationssicherheit haben. Ein kurzer Blick in die ISO 27002:2022 auf das vom ISA referenziert Control 5.8. zeigt, dass es dort heißt: „Informationssicherheit im Projektmanagement“. Es geht also weniger um die Umsetzung der Informationssicherheit als mehr um die Einhaltung von Anforderungen aus der Informationssicherheit (und des Datenschutzes) und die Bestimmung des Einflusses, die das Projekt auf die Informationssicherheit hat bzw. haben könnte.
Ich erwähne den Datenschutz, weil dieser (zumindest in der europäischen Union) ebenso wie die Informationssicherheit von Anfang an in einem Projekt mitbedacht (und dokumentiert) werden muss. Man erkennt auch eine zunehmende Anzahl an Regularien und Gesetzen, die auf die Stärkung der Cyber-Sicherheit abzielen. Zum Beispiel fordert der Cyber Resilience Act grundlegende Cyber-Sicherheit in der Produktentwicklung. Und wer ein Kinderfahrrad mit integriertem GPS-Tracker entwickelt, sollte sich frühzeitig mit dem Datenschutz beschäftigen (Stichwort: Datenschutz by Design).
Was bedeutet das nun aber für die Klassifikation interner Projekte? Vorschlag des ISA 6: „Projekte können wie folgt klassifiziert werden: […] Vertraulichkeit, Integrität, Verfügbarkeit“. Das hilft nicht wirklich weiter, denn das es in der Informationssicherheit um diese Schutzziele geht, versteht sich von selbst. Und auch: worauf sollen sich diese Schutzziele beziehen? Die Projektinhalte oder -ergebnisse dürften es nicht sein, denn als Informationswerte fallen diese wie eingangs erwähnte Kundenprojekte unter Control 1.3.2. Daher sollte es um den Einfluss des Projektes auf die Informationssicherheit gehen. Oder auf die Umsetzung der Informationssicherheit innerhalb des Projektes. Man sieht schon an diesen Antworten, dass das Control 1.2.3 Projekte sehr allgemein behandelt. Dabei mag die Umsetzung sich von Projektart zu Projektart unterscheiden.
Eine Klassifikation sollte auch nicht für sich alleine stehen. Aus einer Klassifikation müssen sich Anforderungen ableiten lassen oder Maßnahmen, die zu treffen sind. Zu sagen, wir klassifizieren Projekte nach dem Schema „A“, „B“, „C“, sollte immer auch heißen: Projekte der Kategorie „A“ müssen diese Anforderung erfüllen, Projekte der Kategorie „B“ jene Anforderung.
Lassen Sie uns vielleicht ein paar Beispiele betrachten. Die Einführung eines neuen Cloud-Dienstes zur Zeiterfassung ist ein internes Projekt, das in Anbetracht der verarbeiteten Daten aus Sicht der Informationssicherheit besonderer Aufmerksamkeit bedarf. Datenschutz spielt eine Rolle. Wenn Krankheitstage erfasst werden, handelt es sich sogar um eine besondere Kategorie personenbezogener Daten. Je nach Prämienregelung im Unternehmen hängt an diesen Zeiten auch die Lohnbuchhaltung, und natürlich möchte das Controlling wissen, wie gut die Mitarbeiter- oder Projektperformance ist.
Wichtig hier ist es zu wissen, welche Informationswerte das Projekt betrifft. In diesem Fall handelt es sich um Zeiterfassungsdaten, die personenbezogene Daten darstellen. Außerdem soll ein neuer Cloud-Dienst eingeführt werden. Insgesamt betrifft das Projekt einen Kernprozess des Unternehmens. Aus der Verarbeitung personenbezogener Daten ergibt sich, dass der Datenschutzbeauftragte einbezogen werden muss. Cloud-Dienste benötigen die Analyse und Freigabe durch den Informationssicherheitsbeauftragten, und die Anpassung an Kernprozessen bedarf einer speziellen Risikoanalyse, die durch die GF freizugeben ist.
Wir betrachten also nicht ein Kriterium, sondern drei verschiedene Kriterien, die mit den Schutzzielen der Informationssicherheit nur indirekt zu tun haben. Unsere Klassifikation richtet sich nach den betroffenen Informationswerten, der Art von Informationsträgern und der betroffenen Prozesse. Wobei diese durchaus abstrahiert werden können (z.B. auf personenbezogene Daten: Ja/Nein). Die Erfahrung zeigt aber auch: je weiter diese abstrahiert werden, desto schwerer fällt es Mitarbeitern oder Mitarbeiterinnen korrekt zu klassifizieren.
Empfehlenswerter ist es, einen kurzen Fragebogen zu erstellen, der es den verantwortlichen Personen erleichtert, eine Klassifikation vorzunehmen. Insbesondere kann darauf aufbauend im Optimalfall die Erstellung der Projektumgebung oder des Projektantrags automatisiert werden. Inklusive der Umsetzung von Maßnahmen zu Informationssicherheit und Datenschutz. Dies schließt beispielsweise auch die Erstellung von Aufgaben in der Projektmanagement-Software, die Auflistung zu beachtender Maßnahmen oder die Berechtigung des Datenschutzbeauftragten auf die Projektumgebung mit ein.
Kundenprojekte
Der Zweck der Klassifikation ist bei Kunden anders gelagert als bei internen Projekten, aber das macht sie nicht weniger empfehlenswert. Hier kann man auch in jedem Fall mit den klassischen Schutzzielen arbeiten. Denn dann geht es eben (auch) darum, festzulegen wie mit den Projektergebnissen umzugehen ist: wer darf Zugriff haben, welche Sicherheitsmaßnahmen gelten, wie kritisch ist das Einhalten der Deadline? Denken wir uns beispielsweise für die Vertraulichkeit die Schutzbedarfsklassen „normal“, „hoch“ und „sehr hoch“. Dann lassen sich – unter anderem – folgende Anforderungen festlegen:
- „normal“: Es werden immer komplette Teams auf den Projekten berechtigt; das Bearbeiten von Projektinhalten darf auch remote erfolgen; es gelten die Standardregularien für das Übertragen von Daten
- „hoch“: Es werden nur die jeweils benötigten Teammitglieder auf den Projekten berechtigt; das Bearbeiten von Projektinhalten darf nur innerhalb der Büroräumlichkeiten erfolgen; Daten dürfen nur verschlüsselt übertragen werden
- „sehr hoch“: die Auswahl der Teammitglieder ist eingeschränkt und bedarf der Freigabe durch die Geschäftsführung; das Bearbeiten der Projektinhalte darf nur innerhalb speziell gesicherter Räumlichkeiten erfolgen; die Ablage der Daten erfolgt ebenfalls in einem abgetrennten Netzwerksegment; Daten dürfen nicht über das Internet übertragen werden
Darüber hinaus bietet es sich an, Projekte ebenfalls bzgl. der Verarbeitung personenbezogener Daten zu klassifizieren. Daraus ergeben sich gesetzliche Vorgaben bzgl. des Vertragskonstruktes (Stichwort: Auftragsverarbeitung oder gemeinsame Verarbeitung) und die entsprechenden Verpflichtungen: Betroffenenrechte, Meldepflichten, Kontrollrechte, Eintrag ins Verarbeitungsverzeichnis, etc..
Im Sinne von TISAX ist natürlich auch die Klassifizierung nach Prototypenschutz sinnvoll.
"Klassifizierung von Projekten ist ein sehr individuelles Thema, bei dem jeder für sich entscheiden muss, wie welche Ziele am besten erreicht werden können."
Technisch Umsetzung
Jetzt haben wir schon über die inhaltliche Klassifikation gesprochen, aber am Ende stellt sich die Frage: wie macht man das denn technisch? Die Antwort ist genauso individuell wie die Auswahl der Klassen. Am besten orientieren Sie sich daran, was Sie haben und was Sie heute schon haben. Haben Sie einen Prozess für interne Projekte? Dann sollten Sie es dort mit aufnehmen. Je besser sich dies in schon vorhandene Prozesse integriert desto besser. Nutzen Sie SharePoint (oder Teams) für Ihre Projekte? Verwenden Sie Sensitivity Labels für eine technisch Lösung und eine Startseite (Reiter in Teams), um alle notwendigen Maßnahmen und Kennzahlen aufzulisten. Am besten basierend auf einer Vorlage, so dass nicht jeder Projektleiter das Rad neu erfinden muss.
Kundenprojekte dürfen auch gerne im ERP-System direkt beim Kundenauftrag klassifiziert werden. Allerdings muss sichergestellt werden, dass alle Projektmitglieder Einsicht haben, welche konkreten Anforderungen damit verbunden sind.
Fazit
Klassifizierung von Projekten ist ein sehr individuelles Thema, bei dem jeder für sich entscheiden muss, wie welche Ziele am besten erreicht werden können. Wir sehen oft, dass das Thema vernachlässigt wird, weil es auf den ersten Blick wie bürokratischer Overhead aussieht (und die Projekte ja auch einfach so laufen). Aber in vielen Fällen versteckt sich irgendwo eh schon eine Klassifizierung und ein gelebter Prozess, in den man sich einklinken kann. Und dann kann man über eine solche Klassifikation nicht nur die Anforderungen des ISA 6 erfüllen, sondern auch einen echten Mehrwert schaffen.