Die ersten Überprüfungen der vom § 8a Absatz 1a BSIG und §11 EnWG geforderten System zur Angriffserkennung (SzA) sind mittlerweile auch für uns gelaufen und es gab bereits einige Rückmeldungen vom BSI zu den daraus resultierenden Meldungen.

Aus unserer Sicht genau der richtige Zeitpunkt, um ein erstes Resümee zu ziehen.

Vorweg sei gesagt, dass wir bei keiner Überprüfung auf „katastrophale“ Zustände gestoßen sind, aber auch den Heiligen Gral bei der Umsetzung haben wir (noch) nicht gefunden.

Verschiedene Wege der Umsetzung eines SzA

Wir konnten verschiedene Wege der Umsetzung erkennen, sowohl im technischen Ansatz als auch bei der Wahl der Produkte. Im Großen und Ganzen engt sich der Kreis der genutzten Systemarten allerdings auf folgende Systemkategorien ein:

  • SIEM (Security Information and Event Management)
  • IDS/IPS (Intrusion Detection System / Intrusion Prevention System)
  • Firewall
  • Anomalie-Erkennung

Die technischen Systeme taten in der Regel, was sie sollten, und haben nur geringes Mangel- oder Empfehlungspotential geboten.

Das Gros der Mängel und Empfehlungen fand sich auf organisatorischer Seite.

Hier ist klar im Vorteil, wer sein ISMS lebt und kontinuierlich pflegt und verbessert.

Besonders die Kommunikation und Dokumentation mit dem Datenschutzbeauftragten und den Interessenvertretern (z.B. Betriebsrat) im Zuge der SzA Implementierung war oft nur nach tiefgreifenden Nachfragen und Prüfen nachzuvollziehen. Weitere Punkte, die oft Klärung bedurften waren z.B. die Benennung von Verantwortlichen, das Patchmanagement und die Updateversorgung (in Bezug auf SzA) und die Kategorisierung und Aufbewahrungsfristen der Protokoll- und Protokollierungsdaten.

Wir haben viele Empfehlungen geschrieben und hoffen, dass die jeweiligen Verantwortlichen sich diese zu Herzen nehmen und umsetzen.

Die Verpflichtung zum Einsatz eines Systems zur Angriffserkennung ist nach den ersten Überprüfungen betrachtet kein falscher Schritt.

Allerdings – und das ist meine persönliche Meinung als Schreiber dieser Zeilen – ist die Art und Weise, wie diese umgesetzt wurde eher unglücklich.
Meine Kritik hieran zielt auf die für die Einführung eines solchen Systems recht kurze Zeitspanne zwischen Veröffentlichung der Orientierungshilfe des BSI im September letzten Jahres und der Meldepflicht im Mai diesen Jahres. Auch gibt es einige Anforderungen, die im Nachhinein noch eine Anpassung seitens der verantwortlichen Stellen erfordern.

In den beiden bisherigen Blogartikel wurde deutlich, dass sich hinter den Forderungen nach einem System zur Angriffserkennung (SzA) im IT-SiG 2.0 und im EnWG sehr viel mehr verbirgt als nur ein Stück Software. Daher hat das BSI (Bundesamt für Informationssicherheit) als federführende Stelle für alle Verpflichteten eine Orientierungshilfe erstellt, die eine strukturierte Hilfestellung liefert. In diesem Artikel soll es um die Systematik in den Veröffentlichungen des BSI gehen.

Formulierung MUSS, SOLL, KANN

Das BSI nutzt in seinen Publikationen die Formulierungen „MUSS“, „SOLL“ und „KANN“. Dabei muss man alle „MUSS“-Anforderungen umsetzen, um eine Konformität zu erreichen, es gibt bei diesen Anforderungen keinen Ermessensspielraum. Etwas anders sieht es bei den „SOLL“-Anforderungen aus. Ähnlich den „MUSS“, ist bei den „SOLL“ davon auszugehen, dass auch diese immer umgesetzt sind – es sei denn, es gibt stichhaltige Gründe, von diesen Anforderungen abzusehen. Diese Gründe müssen dann aber auch sorgfältig abgewogen, fachlich nachvollziehbar und dokumentiert dargelegt werden. „KANN“-Anforderungen liefern sinnvolle Ergänzungen und Verschärfungen, ihre Umsetzung ist allerdings nicht zwingend notwendig, um eine Konformität zu erreichen. Die Untersuchung, in welchem Umfang „MUSS“, „SOLL“ und „KANN“ im Unternehmen umgesetzt sind, liefert den Reifegrad des Systems zur Angriffserkennung.
Das genutzte Reifegradmodell enthält 6 Reifegrade, beginnend beim niedrigsten Reifegrad „0“. Bei diesem Reifegrad wurden noch keinerlei Maßnahmen umgesetzt, und es gibt auch keine Planungen hierfür. Beim Reifegrad „1“ gibt es immerhin schon Planungen, sie sind aber noch nicht in allen Bereichen zu 100% umgesetzt. Beim Reifegrad „2“ wurde bereits mit der Umsetzung begonnen, es sind aber noch nicht alle „MUSS“-Anforderungen umgesetzt.

Reifegrad

Für die erfolgreiche Nachweiserbringung sieht das BSI bei der ersten Prüfung im Frühjahr 2023 mindestens den Reifegrad „3“ vor: alle „MUSS“-Anforderungen sind in allen Bereichen erfüllt, und an der Umsetzung der „SOLL“-Anforderungen wird kontinuierlich gearbeitet. In den folgenden Prüfzyklen, also erstmalig im Frühjahr 2025, wird dann der Reifegrad „4“ als Minimum verlangt. Zu diesem Zeitpunkt müssen alle „MUSS“-Anforderungen umgesetzt sein, und zusätzlich alle „SOLL“-Anforderungen, sofern diese nicht nachvollziehbar und begründet ausgeschlossen wurden.
Beim Reifegrad „5“ schließlich werden neben allen „MUSS“-Anforderungen auch die nicht ausgeschlossenen „SOLL“- und „KANN“-Anforderungen erfüllt. Zusätzliche sinnvolle eigene Maßnahmen, die in der Orientierungshilfe nicht genannt wurden, dürfen auch umgesetzt werden.

Nach diesem Überblick über die Methodik des BSI wird es im nächsten Artikel darum gehen, welche Fragestellungen bei einem System zur Angriffserkennung betrachtet werden müssen.

Die durch das IT-SiG 2.0 und EnBW geforderte Einführung von Systeme n zur Angriffserkennung (SzA) führt neben den eigentlichen technischen Anforderungen auch zu vielen organisatorischen Maßnahmen.

Die Schaffung der organisatorischen Rahmenbedingungen für die Protokollierung, Detektion und Reaktion auf Ereignisse gehört genauso dazu, wie die Planung und Sicherstellung von technischen, finanziellen und personellen Ressourcen. Eine Planung der Protokollierung sollte zum Beispiel durch eine schrittweise Vorgehensweise, basierend auf einer Risikoanalyse und unter Einbeziehung der kritischen Geschäftsprozesse, umgesetzt werden.

Weiterhin stehen strategische Entscheidungen an: Gibt die derzeitige IT-Infrastruktur eine OnPremise Lösung her? Muss die Infrastruktur vergrößert werden, um die Datenmengen, die durch das Logging und die Auswertung anfallen, aufzunehmen oder wird eine Cloudlösung präferiert?
Vielleicht wird auch entschieden, diese Aufgaben an einen Dienstleister auszulagern, weil es sowohl an personellen als auch an technischen Ressourcen mangelt.

Mit Blick auf das Personal stehen organisatorische Maßnahmen an. Es muss ein Verantwortlicher benannt werden, der die Auswertung der Protokoll- und Protokollierungsdaten übernimmt. Mitarbeiter, die in der Detektion eingesetzt werden, müssen festgelegt und geschult werden. Hierbei ist dem BSI wichtig, dass die Auswertung für das Personal Priorität vor eventuell anderen Tätigkeitsfeldern haben muss.

Bei allen Anforderungen für Systeme zur Angriffserkennung darf auch ein Blick auf weitergehende gesetzliche oder regulatorische Anforderungen an die Protokollierung nicht ausbleiben. Gerade bei der Protokollierung von personenbezogenen Daten darf die DS-GVO nicht außer Acht gelassen werden. Bei der Planung sollte daher frühzeitig mit einem Datenschutzspezialisten zusammengearbeitet und – wenn vorhanden – der Betriebsrat informiert werden.

Zum Thema Systeme zur Angriffserkennung:

Unsere Beratungsleistungen zum Thema SzA im Überblick (PDF)

Orientierungshilfe des BSI (PDF)

Der 1. Mai 2023 ist ein Datum, dass bei vielen Energieversorgern und Anlagenbetreibern wohl derzeit ein mulmiges Gefühl auslöst. Es geht hierbei selbstverständlich um den ab Mai 2023 für KRITIS-Unternehmen verpflichtenden Einsatz von Systemen zur Angriffserkennung.

Diese Verpflichtung gilt auch für Betreiber von Energieversorgungsnetzen und Energieanlagen, die nicht unter die KRITIS-Regelung fallen. Grundsätzlich ist es an dieser Stelle leider auch nicht damit getan, ein „Stück Software“ zu kaufen. Die vom BSI geforderten Maßnahmen zur Umsetzung umfassen weit über 80 Anforderungen, die sich aus technischen und organisatorischen Maßnahmen zusammensetzen und bei ihrer Komplexität in der Anforderung enden, automatisch auf bestimmte Vorfälle zu reagieren.

Dass es sich bei der Einführung dieser Systeme um ein langwieriges Projekt handelt, ist allerdings auch dem BSI bekannt. Offen bleibt an dieser Stelle aber, wie ab Mai letztendlich damit umgegangen wird. Zurzeit bringt dieses Thema sehr viel Unruhe in die betreffenden Unternehmen und Prüforganisationen. Eines ist aber gewiss: Die Zeit zu handeln ist jetzt gekommen!

In den kommenden Artikeln werden wir uns damit befassen, worauf es im Kern ankommt, wie so ein System zur Angriffserkennung eingeführt werden kann und wie die ANMATHO AG Sie dabei unterstützen kann.

Wenn es ein Thema schafft, in der Tagesschau, auf fast allen Nachrichtenseiten und auch beim Bundesamt für Sicherheit in der Informationstechnik (BSI) präsent zu sein, muss es sich schon um etwas Besonderes handeln – die Schwachstelle in der weit verbreiteten Javabibliothek „log4j“ hat dieses Kunststück geschafft.

Schwachstellen in Softwareprodukten sind keine Seltenheit. Sie werden entdeckt, meist schließt der Hersteller der Software die Lücke und stellt ein Update zur Verfügung, „business as usual“. Doch im Fall von „log4j“ ist es leider nicht so einfach …

Es beginnt damit, dass Java-Anwendungen meist als Paket bereitgestellt werden – und die problematische Bibliothek vom Hersteller in dem Paket mitgeliefert wird. Ein Update des betreffenden Betriebssystems allein reicht meist nicht, da die Java-Anwendung die mitgelieferte, problematische Version von log4j weiterhin nutzt und nicht etwa die aktualisierte Version des Betriebssystems. Mit anderen Worten: Betriebssystem aktualisieren allein reicht oft nicht aus, auch der Hersteller der Java-Anwendung muss eine Aktualisierung liefern.

… und zwar jeder Hersteller von Anwendungssoftware, die auf Java basiert und die „log4j“ einsetzt. Java ist weit verbreitet, und oftmals ist es für einen Anwender nicht einfach zu erkennen, ob diese Programmiersprache eingesetzt wird. Bei der enormen Masse an weltweit existierenden Anwendungen ist es schwer einzuschätzen, in wie vielen Produkten diese Schwachstelle schlummert. Und dann sind da ja noch die selbst entwickelten Java-Anwendungen, die man im Unternehmen einsetzt, … Viel Arbeit für die IT-Abteilungen.

Wenn es einem Angreifer gelingt, die Protokollinformationen auf seinen eigenen Server verweisen zu lassen, kann er bei der Interpretation des Protokolleintrags schädliche Informationen an die Java-Anwendung zurück liefern, welche dann ungefragt ausgeführt werden – und die Infektion ist geschehen. Ja, wirklich: Ohne Rückfrage, einfach so. Und vermutlich existiert diese Schwachstelle seit ca. 2016.

Was kann man gegen Log4j tun?

  • Sich informieren. Das BSI stellt den aktuellen Erkenntnisstand auf seiner Webseite zur Verfügung. Mittlerweile gibt es auch ständig wachsende Übersichten, ob oder ob nicht populäre Produkte betroffen sind. Hier mal die von Github.
  • Aufmerksam bleiben. Wir halten es für denkbar, dass die Berichterstattung und Paketaktualisierungen auch für Angriffe über Social Engineering und Phishing genutzt werden.
  • Aktualisieren. Und zwar sowohl das Betriebssystem als auch die Java-Anwendungen, die eingesetzt werden – dazu muss der Hersteller der Java-Anwendung allerdings aktiv werden.
  • Künftig die Risiken bei komplexen Softwarekonstellationen gründlicher abwägen. Aber das ist ein anderes Thema …

Was Sie auch interessieren könnte:

Seminar:

“Business Continuity Management (BCM) nach ISO 22301”

Weitere Seminare finden Sie unter https://anmatho.de/seminare diese können Sie auch als individuelles Inhouse-Seminar buchen. Sprechen Sie uns gern an KONTAKT.

Podcast:

Unser Podcast “Security on Air” beschäftigt sich mit den Themen Informationssicherheit und Datenschutz. In lockerer, informativer Form werden Sie zu allen Teilbereichen und gesetzlichen Neuerungen informiert. Sie finden uns auf “Apple Podcast”, “Spotify” und “Google Podcast” sowie natürlich auf unserer Website.

Hören Sie rein!

Sie besitzen ältere SPARC-Server der Firma Sun Microsystems (2010 von Oracle übernommen) und haben sich entschieden diese zu virtualisieren? Sie haben sich für eine der beiden Virtualisierungsmethoden mittels Zonen oder Logical Domains (LDOMs) entschieden? Dann sind Sie bereits auf einem guten Weg die Virtualisierung erfolgreich abzuschließen, sollten aber im Sinne der Informationssicherheit vor allem die Verfügbarkeit der virtuellen Server im Blick behalten.

Folgendes Szenario: Wenn man seine z.B. 12 physikalischen Server auf nur einen neuen Server migriert, dann muss man sich darüber klar sein, dass bei Ausfall dieses neuen Servers alle virtuellen Server solange nicht verfügbar sind, bis die Reparatur dieses physikalischen Server erfolgt ist.

Eine solche Situation ist im Rahmen der Informationssicherheit kaum akzeptabel. Daher ist eine Virtualisierung auf mehrere Server unbedingt empfehlenswert. Sowohl mit LDOMs als auch mit Zonen kann und sollte man Maßnahmen für ein „Disaster Recovery“ konfigurieren. Diese können dann auch beim plötzlichen Ausfall einer Trägerplattform genutzt werden, um die virtuellen Server der betroffenen Plattform auf der noch aktiven Plattform relativ schnell wieder zum Laufen zu bringen. Darüber hinaus besteht mit der Live-Migration die Möglichkeit geplante Downtimes, z.B. für Wartungsarbeiten, komplett zu vermeiden.

Gern beraten wir Sie bei der Umsetzung der Virtualisierung Ihrer Sun-Umgebung. Wir unterstützen Sie bei der Auswahl der richtigen Methode, über die Konzeptionierung des Umzuges bis hin zur technischen Hilfe bei der Virtualisierung.

Für die Virtualisierung älterer SPARC-Server der Firma Sun-Microsystems (2010 von Oracle übernommen) stehen ab Solaris 10 zwei Virtualisierungsmethoden zur Verfügung, die im Produkt bereits verankert sind:

• Zonen (auch bekannt unter dem Begriff Container)
• Oracle VM Server for SPARC (besser bekannt als Logical Domains [LDOMs])

Beide Virtualisierungsmethoden haben ihre Vor- und Nachteile:

Vorteile der Virtualisierung mittels Zonen
– Leicht konfigurierbar
– Mit dem Hilfsmittel „P2V“ (Physical to Virtual) gibt es eine standardisierte Möglichkeit den physikalischen Server in eine Zone zu migrieren
– Möglichkeit, sogenannte „Branded Zones“ zu erstellen, in denen eine Solaris 8 oder Solaris 9 Instanz unter einem Solaris 10 Kernel laufen kann (damit kann z.B. ein physikalischer Server unter Solaris 8 in eine Solaris 8 Branded Zone migriert werden)
Nachteil der Virtualisierung mittels Zonen:
– Alle Zonen auf einem System laufen als Erweiterung desselben Kernels, wodurch Nebenwirkungen zwischen Zonen nicht vollständig ausgeschlossen werden können

Vorteile der Virtualisierung mittels LDOMs:
– Jeder in eine Gast-LDOM virtualisierte Server läuft auf einer eigenen und vollständigen Solaris-Instanz
– Möglichkeit der „Live-Migration“, d.h. ein virtueller Server (Gast-LDOM) kann im laufenden Betrieb von einer Plattform auf eine andere umziehen.
Nachteile der Virtualisierung mittels LDOMs:
– Mindestens zwei Plattformen (2 Server aus der T-Reihe) müssen existieren
– und noch weitere Voraussetzungen erfüllt sein.

Im Sinne der Informationssicherheit ist die Virtualisierung, egal mit welcher Methode, unbedingt empfehlenswert, um so die Verfügbarkeit aller Applikationen zu gewährleisten.

Gern beraten wir Sie bei der Umsetzung der Virtualisierung Ihrer Sun-Umgebung. Wir unterstützen Sie bei der Auswahl der richtigen Methode, über die Konzeptionierung des Umzuges bis hin zur technischen Hilfe bei der Virtualisierung.

Kommt Ihnen die folgende Situation bekannt vor? Sie haben vor etwa 10 bis 12 Jahren einige SPARC-Server der Firma „Sun Microsystems“ (2010 von Oracle übernommen) erworben und Teile Ihrer Applikationen auf diesen Servern installiert und ggf. zuvor diese Applikationsumgebung selbst entwickelt bzw. entwickeln lassen. Damit läuft Ihre produktive Umgebung unter Solaris 10 oder auch älter. Aufgrund ihrer typischerweise hohen Laufzeitstabilität ist allerdings diese Umgebung ein wenig aus dem Fokus der „anstehenden Neuanschaffungen“ geraten.
Jetzt aber müssen Sie feststellen, dass die Unterstützung bei Hardware-Ausfällen Ihrer Server nicht mehr garantiert ist („End of Service Life“ ist überschritten), d.h. es kann zu Problemen bei der Beschaffung von Ersatzteilen kommen. Damit aber noch nicht genug, vor allem im Sinne der Informationssicherheit gerät damit der Punkt Verfügbarkeit und ggf. auch der Punkt Integrität in Gefahr.

Was ist jetzt zu tun, vor allem wenn man die Applikationen nicht auf eine andere Plattform übernehmen will oder auch weiterhin die Stabilität der Sun-Server nutzen möchte? Hier nun unser Vorschlag, wie Sie mit dieser Situation umgehen können:
Virtualisieren Sie Ihre Server auf einen oder besser zwei neue SPARC-Server. Unter SPARC (typischerweise T-Reihe) stehen Ihnen ab Solaris 10 zwei Virtualisierungsmethoden zur Verfügung, die im Produkt bereits verankert sind:

• Zonen (auch bekannt unter dem Begriff Container)
• Oracle VM Server for SPARC (besser bekannt als Logical Domains [LDOMs])

Beide Methoden bieten Vor- und Nachteile, welche das sind, werden wir in einem folgenden Artikel näher erläutern. Prinzipiell führen beide Methoden zum Ziel und können mit einer guten Vorbereitung recht schnell umgesetzt werden.

Gern beraten wir Sie bei der Umsetzung der Virtualisierung Ihrer Sun-Umgebung. Wir unterstützen Sie bei der Auswahl der richtigen Methode, über die Konzeptionierung des Umzuges bis hin zur technischen Hilfe bei der Virtualisierung.

Nach monatelangen Verhandlungen hat der Bundestag am 21.03.2019 das Geschäftsgeheimnisgesetz (GeschGehG) beschlossen, das bereits in Kraft getreten ist. Es ist also höchste Zeit für Unternehmen sich damit auseinanderzusetzen, was das neue GeschGehG für den Schutz ihrer Geschäftsgeheimnisse bedeutet und welcher Handlungsbedarf besteht.

Der Begriff des Geschäftsgeheimnisses

Bisher existierte in der Europäischen Union kein einheitliches Recht, was dem Schutz von Geschäftsgeheimnissen diente. In Deutschland waren Geschäftsgeheimnisse vor allem nach § 17 UWG geschützt. Nach der Rechtsprechung des Bundesgerichtshofs (BGH) galt als Geschäfts- oder Betriebsgeheimnis jede im Zusammenhang mit einem Geschäftsbetrieb stehende Tatsache, die nicht offenkundig sondern nur einem begrenzten Personenkreis bekannt war und nach dem bekundeten, auf wirtschaftlichen Interessen beruhenden Willen des Betriebsinhabers geheim gehalten werden sollte.

Nach der Definition in § 2 Nr. 1 GeschGehG ist hingegen ein Geschäftsgeheimnis eine Information,

  • die geheim ist (nicht allgemein bekannt bei Kreisen, die üblicherweise mit solchen Informationen umgehen, und nicht ohne weiteres zugänglich),
  • die von wirtschaftlichem Wert ist (geschützt wird nur ein wirtschaftliches und kein privates Geheimhaltungsinteresse),
  • die mit angemessenen Geheimhaltungsmaßnahmen geschützt wird und
  • bei der ein berechtigtes Interesse an der Geheimhaltung besteht.

Maßnahmen, die der Geheimhaltung dienen, sind daher nach momentan geltendem Recht nicht mehr nur notwendig, um tatsächlich dem Verlust von Geschäftsgeheimnissen entgegenzuwirken, vielmehr gilt jetzt: Werden keine angemessenen Geheimhaltungsmaßnahmen getroffen, liegt schon gar kein Geschäftsgeheimnis vor und der Schutz des GeschGehG greift nicht.

Wie sehen angemessene Geheimhaltungsmaßnahmen aus?

Wann Geheimhaltungsmaßnahmen den Umständen nach angemessen im Sinne des § 2 Nr. 1 GeschGehG sind, ist eine Frage des Einzelfalls. Die wirtschaftliche Bedeutung ist hierbei das wichtigste Kriterium für ein Geschäftsgeheimnis des Unternehmens. Handelt es sich vorliegend um die „Kronjuwelen“, deren Offenlegung oder Nutzung durch Wettbewerber existenzbedrohend sein könnte? Oder geht es um Geheimnisse, die zwar wichtig für das Unternehmen sind, aber in ihrer Gesamtheit doch eher untergeordnete wirtschaftliche Bedeutung haben? Je wichtiger ein Geschäftsgeheimnis für das Unternehmen ist, desto striktere Schutzmaßnahmen müssen ergriffen werden, damit diese als angemessen gelten können. Im Übrigen ist es wohl verfehlt, alle geheimhaltungsbedürftigen Informationen mit der höchsten Geheimhaltungsstufe zu versehen und mit besonderen Sicherungsmaßnahmen zu schützen. Insbesondere müssen die Geheimhaltungsmaßnahmen und der damit einhergehende Aufwand in einem angemessenen Verhältnis zur wirtschaftlichen Bedeutung des Geschäftsgeheimnisses stehen. Von einem Konzern könnten zudem möglicherweise striktere Geheimhaltungsmaßnahmen verlangt werden, als von einem mittleren oder kleineren Unternehmen. Was genau „angemessener Schutz“ bedeutet, wird daher noch durch die Rechtsprechung zu konkretisie-ren sein.

Wie verhält es sich jetzt mit dem Reengineering?

Ein Reengineering – mithin der Nachbau eines Produktes – um ein Nachvollziehen von Geheimnissen oder vielmehr deren Entschlüsselung zu ermöglichen, wird nach momentaner Rechtslage in Zukunft – zumindest teilweise – zulässig sein!

Welche rechtlichen Möglichkeiten habe ich nun bei Geheimnisverletzungen?

Der Inhaber eines verletzten Geschäftsgeheimnisses hat nach der neuen Gesetzeslage dieselben Ansprüche wie etwa der Inhaber eines verletzten Patents. Konnte bisher vom Verletzenden lediglich Schadensersatz, Unterlassung und Auskunft verlangt werden, wird der „juristische Werkzeugkasten“ nun etwa auch um Ansprüche auf Vernichtung verletzender Produkte, Herausgabe, Rückruf sowie dauerhafte Entfernung der verletzenden Produkte aus dem Markt erweitert. Dies ist eine erhebliche Besserstellung von Inhabern verletzter Geheimnisse.

Wie steht es nun um das „Whistleblowing“?

Der Schutz von sog. Whistleblowern und Journalisten, die Geschäftsgeheimnisse im Rahmen ihrer Veröffentlichung von Missständen in Unternehmen offenlegen, war einer der wesentlichen Gründe für komplexe Diskussionen im Rahmen des Gesetzgebungsverfahrens in Deutschland. Im Ergebnis einigte man sich auf einen hohen Whistleblower-Schutz.

Solange sich die Offenlegung des Geschäftsgeheimnisses durch den Whistleblower zum Schutz des öffentlichen Interesses eignet, macht er sich im Falle eines Geschäftsgeheimnisverrats nicht strafbar. Was auch dies im Einzelnen bedeutet, bleibt weiter – insbesondere mit Blick auf die Rechtsprechung – abzuwarten.

Was müssen Unternehmen jetzt tun?

Der Schutz von Geschäftsgeheimnissen nach dem GeschGehG ist nicht verpflichtend, anders als etwa die Vorgaben der DS-GVO umzusetzen. Dennoch müssen Unternehmen handeln, um ihre Geschäftsgeheimnisse zu schützen und sich im Streitfall auch durchsetzen zu können.

Wir empfehlen ein 3-stufiges Konzept:

Zunächst sollten alle Geschäftsgeheimnisse im gesamten Unternehmen identifiziert werden. Anschließend sollten in einem zweiten Schritt alle Geheimnisse bewertet und kategorisiert werden.

Je nach Wichtigkeit des Geschäftsgeheimnisses sind in einem dritten Schritt entsprechende Schutzmaßnahmen zu treffen. Schutzmaßnahmen sind jedoch keinesfalls nur rechtlicher Natur. Neben vertraglichen Vereinbarungen, Compliance-Maßnahmen und Arbeitsanweisungen sind auch technische und organisatorische Maßnahmen zu treffen, vor allem sollte hier eine Mitarbeiter-Sensibilisierung sowie die Verbesserung der IT- und Werkssicherheit stattfinden. Dies ist – wie bei der Umsetzung des Datenschutzes oder der Informationssicherheit im Unternehmen – nur unter Einbeziehung verschiedenster Abteilungen sowie Fachrichtungen im Unternehmen umsetzbar. Entscheidende Werkzeuge für den Erfolg einer Umsetzung können hier wiederum ein Datenschutz- oder Informationssicherheitsmanagementsystem sein.

Ergebnis

Sie müssen jetzt handeln! Unternehmen, die ihre Geheimnisse auch zukünftig schützen möchten und vor allem entsprechende Ansprüche durchsetzen wollen, sind jetzt gefordert, angemessene Schutzmaßnahmen zu ergreifen und zu dokumentieren!