Priorisierung tut not : Der Weg zum Branchenstandard mit flexibler Umsetzung am Beispiel Krankenhaus – Teil 2

Von Bettina Weßelmann und Johannes Wiele, München

Neue Standards für Informationssicherheit kriechen gewöhnlich nicht nachts aus einem dunklen Gebüsch, um völlig unerwartet über eine Organisation herzufallen. Man weiß üblicherweise schon recht lange, dass neue Regeln in Arbeit sind und irgendwann auch gelten werden. Der eine oder andere im Securityteam trommelt vielleicht schon seit geraumer Zeit immer wieder Alarm und weist auf die ganz konkreten Folgen hin, welche die Entwicklungen zu einer neuen Norm haben werden – mitunter arbeiten Teammitglieder der eigenen Organisation am kommenden Standard sogar mit. Aber wenn dann tatsächlich die erste Prüfung droht und der Auditor sein Kommen ankündigt, dann verfällt doch wieder das ganze Team in Schockstarre wie ein Trupp Kaninchen vor der Schlange und weiß nicht, wie es der Gefahr Herr werden soll.

„Whatever the explanation might be, the immediate need was to take first things first.“ – Richard Adams, Watership Down

Sachzwänge und Ressourcenknappheit

In vielen Organisationen ist es keineswegs Dickfelligkeit oder Fahrlässigkeit, die Akteure verleitet, ein Anheben des Sicherheitsniveaus auf das künftig gültige Mindestmaß lange vor sich herzuschieben. Vor allem im Mittelstand und ganz ausgeprägt im Beispielsektor der Kliniken fehlt es zuweilen so eklatant an finanziellen Mitteln, Personal und Zeit, dass kostenträchtige Projekte aus purem Mangel an Ressourcen erst dann in Angriff genommen werden, wenn es absolut nicht mehr anders geht. Und auch dann lässt sich meist nicht alles sofort bewältigen, was der Standard verlangt, sondern die Organisation muss Schritt für Schritt vorgehen und die wichtigsten Sicherheitslücken zuerst stopfen.

Man könnte nun meinen, dass Priorisierung für Securityspezialisten kein Problem darstellt. Schließlich bekommen sie während ihrer Ausbildungszeit wieder und wieder eingebläut, dass man die größten Schwachstellen in einem Netz zuerst angehen muss. Eine Priorisierung, die auch in den Augen eines Auditors Bestand hat, ist allerdings kein einfaches Unterfangen – und sie erfordert zuweilen einen geradezu brutalen Bruch mit dem gewohnten Vorgehen in einem Unternehmen.

Ein Quentchen Rücksichtslosigkeit

Der Schlüssel zu einer besseren Sicherheit in der Operational Technology (OT) und im Industrial Internet of Things (IIoT) liege in der Methodik einer „Ruthless Prioritisation“, heißt es wohl deshalb auch in einem Whitepaper des Security-Anbieters CyberX [2], der jüngst von Microsoft übernommen wurde. Ruthless? – also übersetzt rabiat, schonungslos, skrupellos – ein Wort, das eher zum Assoziationsgefüge und Vokabular von Banditenfilmen gehört als zur Prosa der organisatorischen Umsetzung von Sicherheitsvorgaben. Passt das hier?

Um derart harte Formulierungen zu wählen oder ihnen zuzustimmen, genügt es vollauf, ein paar Priorisierungs-Diskussionen in Sachen Informationssicherheit in Organisationen beliebiger Art persönlich miterlebt zu haben. Das Beharrungsvermögen eingeschliffener Vorgehensweisen, die erwähnte Zeit- und Geldnot und allzu menschliche Faktoren treten dabei nämlich häufig mit einer Vehemenz zutage, die selbst hartgesottene Firmenlenker und Berater nicht erwarten.

Priorisierung trifft Hemmnisse

Anfangs scheint alles meistens noch einfach – Einigkeit über das, was am wichtigsten ist, lässt sich betriebsintern häufig recht schnell erzielen. Aber irgendwann kommen unweigerlich Einwände ins Spiel: Für die zweifellos im allerhöchsten Maße kritische Absicherung von Asset A müsse doch zuerst die Freigabe und das Budget von Abteilung B eingeholt werden, heißt es plötzlich, und der Kollege C, der das am besten könne, arbeite doch an Projekt D, das zwar nicht wirklich wichtig, aber schon weit fortgeschritten sei.

Und außerdem sollte für Asset A doch unbedingt der neue CISO an Bord sein, die Personalabteilung habe doch sogar schon eine Anzeige geschaltet. Obendrein müsse man sich erst einarbeiten und gerade jetzt sei doch völlig unklar, ob sich in nächster Zeit Technik E oder F durchsetzen werde. Und wie bitte – und hier kommt das Totschlagsargument! – solle man denn den Vorgaben von IT-Sicherheitsgesetz (IT-SiG), ISO 2700x, PCI DSS, EU Datenschutzgrundverordnung (DSGVO) und so weiter gerecht werden, wenn man jetzt einfach nach eigenem Gusto festlege, was zuerst zu tun sei und was man sträflich vernachlässigen wolle?

Priorisierung ist tatsächlich der Schlüssel zu signifikanten Verbesserungen in Sachen Informationssicherheit – gerade im Mittelstand mit seinen begrenzten finanziellen und personellen Mitteln. Die „gnadenlose“ Durchsetzung des First-Things-First-Prinzips fordert aber ein wohldurchdachtes, mutiges und zugleich kooperatives Vorgehen! Die meisten Einwürfe von Bedenkenträgern sind durchaus begründet. Und sie resultieren auch aus dem verständlichen Wunsch, einmal mühsam angestoßene Projekte auch konsequent voranzutreiben, statt immer wieder mit anderen Dingen zu beginnen.

Kliniken in der Zwickmühle

Wie schwer es Krankenhäuser haben, Investitionen in IT-Sicherheit zu tätigen, hat die <kes> bereits im ersten Beitrag der Reihe [4] ausführlich beschrieben. Hier noch einmal die wichtigsten Punkte in Kürze:

• Der finanzielle Rahmen für Informationssicherheit ist begrenzt. Priorität genießt die Behandlung, und das Korsett des staatlichen Gesundheitswesens begrenzt die wirtschaftliche Kraft.
• Die Personalausstattung im Bereich IT und IT-Security ist limitiert.
• Die IT eines Krankenhauses muss hoch verfügbar sein, damit ein Versagen keine Menschenleben in Gefahr bringt. Zugleich beherbergt und transportiert die IT hochsensible Daten.
• Angreifern ist der Wert personenbezogener medizinischer Daten bewusst und sie kennen die Restriktionen, unter denen Kliniken arbeiten. Das Bedrohungspotenzial ist somit hoch.
• Das Personal ist aufgrund der Vertrautheit mit der ärztlichen Schweigepflicht gut dafür sensibilisiert, Informationen zu schützen, kann sich aber aufgrund des hohen Arbeitsdrucks kaum mit technischen Fragen des Datenschutzes und der Informationssicherheit befassen.
• Mit renommierten Chefärzten und Laborleitern gehören potenziell starke Gruppen zur Mitarbeiterschaft, die einengende Regeln für die IT-Nutzung nicht ohne Rechtfertigung akzeptieren.
• Am Netz hängen gerade in Universitätskliniken zwar viele weitgehend standardisierte IT-Systeme, aber auch teilweise überaus langlebige, teilweise hoch experimentelle IoT-Geräte.

Nur mit Rechtfertigung

Das Setzen neuer Prioritäten, die dann „ohne Wenn und Aber“ zu verfolgen sind, gelingt deshalb nur mit ehrlicher Rechtfertigung – erstens gegenüber dem eigenen Stab, der dem disruptiven Vorgehen zustimmen muss, und zweitens gegenüber eventuellen externen Auditoren, für die das gewählte Verfahren aus der Complianceperspektive „gut genug“ erscheinen sollte. Dabei muss das ganze Team „ruthless“ an die Sache herangehen – wenn dies ein Einzelner gegen den Strom und gegen die eigenen Mitarbeiter versucht, haben seine Autorität und das Projekt keine großen Chancen.

Die Corona-Krise bringt mehr Organisationen denn je in die Lage, das Beste aus schrumpfenden Budgets machen zu müssen und trotzdem Angreifern etwas entgegenzusetzen, die gerade diese Situation verstärkt auszunutzen versuchen. Auf der Habenseite gilt allerdings auch, dass bei normativ tätigen Institutionen derzeit eine größere Bereitschaft besteht, Priorisierungen bei Audits zu akzeptieren, sofern eventuelle normative „Muss-Ziele“ nicht einfach ignoriert werden und das Fernziel sowie der Plan für den Weg dorthin stimmen.

Man darf nur nicht erwarten, dass die prüfenden Instanzen dies auch zugeben. Auf die Anfrage der Autoren, wie das BSI beispielsweise damit umgehen wolle, wenn Kliniken nicht sofort alle MUSS-Kriterien des neuen Branchenstandards erfüllen könnten und KRITIS-Häuser stattdessen eine Schritt-für-Schritt-Strategie vorlegten, antwortete BSI-Pressereferentin Josephine Steffen: „Die Formulierung MUSS bezeichnet gemäß RFC 2119 (Stand 1997) und DIN 820-2:2012 eine Anforderung, die zwingend erfüllt werden muss (uneingeschränkte Anforderung). Damit ist kein Vorlegen von Schritt-für-Schritt-Strategien möglich.“

Das BSI muss wohl so antworten, um sich in diesem heiklen Bereich gegen Ausreden und Verzögerungstaktiken zu wappnen. Aber wenn ein „Was muss, das muss!“ auf ein „Was nicht geht, das geht nicht!“ trifft, lässt sich kein noch so wichtiges Ziel mehr erreichen – den Betroffenen bleibt wieder nur das hilflose Erstarren.

Von Müssen und Können

Außerdem setzt die Praxis in unserem Fall der Durchsetzung aller Forderungen Grenzen: Ein wegen defekter Bremsen gemeingefährlich gewordenes Auto kann der TÜV einfach stilllegen, denn für den Fahrer gibt es ja Bus, Taxi und Bahn. Aber wie weit geht das Sanktionspotenzial bei einer Institution, die man zuvor selbst als „kritisch“ für die Existenz der sozialen Gemeinschaft eingestuft hat? Es dürfte schwerfallen und kaum zu rechtfertigen sein, aus IT-Sicherheitsgründen allzu tief in die Arbeit einer Klinik einzugreifen, die täglich lebensrettende Arbeit leistet. Man muss ein Maß für den Compliance-Druck finden und darf die Adressaten nicht fundamental gefährden.

Steffen benennt in ihrer Antwort übrigens eine ganze Reihe konkreter Hilfen, mit denen das BSI Krankenhäuser dabei unterstützt, die Ziele des Branchenstandards zu erreichen. Darunter: Leitlinien, Empfehlungen, Auslegungshilfen und Anwendungshinweise zur Umsetzung abstrakter Vorgaben, die Durchführung von Informationsveranstaltungen und Workshops sowie die Beantwortung individueller Anfragen, die sich bei der Umsetzung des Standards ergeben. Das ergibt nur Sinn, wenn es wohl doch einen gewissen zeitlichen Spielraum gibt. Und innerhalb dieses Zeitraums muss nach der Logik der schnellstmöglichen Herstellung von Sicherheit nun einmal das Wichtigste zuerst getan werden. Liegt dafür eine Strategie vor, MUSS ein Auditor diese also honorieren, so sehr es auch seine Pflicht sein mag, zäh und nachdrücklich auf die schnellstmögliche Umsetzung aller zwingenden Vorgaben zu drängen.

Außerdem gilt: Die Spielräume für Compliance-Betroffene liegen oft nicht im „ob“, sondern im „wie“ der Umsetzung einer Anforderung verborgen. Der erste Beitrag dieser Reihe hat dies am Beispiel von Incident-Management-Maßnahmen gezeigt, die der Branchenstandard für Kliniken fordert. Er lässt nicht explizit, aber faktisch und durch bewusste Auslassung konkreter technisch-organisatorischer Maßnahmen eine Schritt-für-Schritt-Vorgehensweise mit einem sinnvollen Vorlaufbetrieb für ein fernes Security-Operations-Center zu.

Branchenstandard und Priorisierung im Krankenhaus-Sektor

Was die Compliance und verwertbare Frameworks als Orientierungspunkt betrifft, verfügen deutsche Kliniken seit einiger Zeit über ein klares und akzeptiertes Regelwerk. Der Branchenspezifische Sicherheitsstandard „Medizinische Versorgung“ [1] wurde zusammen mit der Deutschen Krankenhausgesellschaft entwickelt und veröffentlicht und ist seit Oktober 2019 vom BSI anerkannt. Er gilt allerdings formell nur für jene etwas weniger als zehn Prozent der Krankenhäuser in Deutschland, die beim BSI als „Kritische Infrastrukturen“ (KRITIS) im Sinne des IT-Sicherheitsgesetzes registriert sind.

Sowohl der Geltungsbereich als auch das Anerkennungsdatum sind der Grund dafür, warum der Krankenhaus-Standard in nächster Zeit viele Priorisierungs-Meetings generieren wird: Die als KRITIS geltenden Häuser müssen festlegen, wie sie den Standard möglichst bald zu erreichen gedenken – und die nicht in diese Kategorie fallenden kleineren Kliniken werden zunehmend einem Druck ausgesetzt, ihn ebenfalls so weit wie möglich zu erfüllen.

Priorisierung, praktisch

„Hazel,“ he said, „We ought to do our best to make some holes here [to hide from the enemies in the night].“ – Richard Adams, Watership Down

Priorisierung ohne Wenn und Aber bedeutet, dass man neue Projekte in Angriff nehmen muss, andere aber zunächst auf Eis gelegt werden. Von Beschäftigten verlangt das, sich komplett auf neue Ziele einzulassen und unter Umständen bereits begonnene, der Karriere zuträgliche Vorhaben aufzugeben. Die plötzliche Unterwerfung unter einen fremden Vorgabenkontext kann, wenn sie unsensibel verlangt wird, zu unwillkürlichen Reaktanz-Effekten führen – im Extremfall zu Verweigerung, Gegenwehr und „Dienst nach Vorschrift“.

Schritt 1: Um Verständnis werben

Sicherheitsverantwortliche, die eine Repriorisierung von Security-Maßnahmen in einer Organisation vornehmen müssen, tun deshalb gut daran, die Gründe hierfür ausführlich zu erläutern und aufzuzeigen, warum der geforderte Strategie-Schwenk notwendig ist. Sie sollten außerdem offen zugeben, dass sie sich selbst in einer Zwangssituation befinden (vgl. [3]). In dieser Phase können prüfende Instanzen in besonderem Maße helfen, indem sie Mitarbeiter schicken, die von der Genese neuer Standards berichten und erklären, warum sie die Umsetzung für zwingend erforderlich halten.

Erst wenn im Team hinreichende Einigkeit über die neue Vorgehensweise besteht, lohnt sich der Start in das entsprechende Projekt!

Schritt 2: Vorgaben analysieren

Es gibt einen guten Grund, die Analyse neuer Vorgaben an den Anfang zu stellen: Würde man gleich zu Beginn ein weiteres Mal auf den Status der eigenen Institution blicken, bestünde die Gefahr, in alte Denkmuster zurückzufallen und wieder bei den wohlbekannten Bedenken und Einwänden zu landen. Die neue Norm sollte gezielt auf MUSS-, KANN- und SOLL-Vorgaben hin überprüft werden. Die Muss-Vorgaben sind diejenigen, bei denen die Priorisierung anzusetzen hat.

Muss-Vorschriften sind anschließend zu rubrizieren:

• Gibt es für die identifizierten Muss-Vorschriften detaillierte Umsetzungsvorgaben oder stellt die Norm den Weg zum Ziel frei? In ein und derselben Norm kann dies je nach Maßnahme unterschiedlich sein (vgl. [4]). Bei wenig detaillierten Vorgaben („Stand der Technik“ o. Ä.) ist einerseits der Spielraum größer, andererseits muss die prüfende Instanz der Organisation mehr Zeit einräumen, den für sie geeigneten Weg zu finden. Bei Vorschriften mit Detailvorgaben ist zu prüfen, ob sie umsetzbar sind – auf alte Legacy-Systeme etwa lassen sich nicht immer alle modernen Forderungen anwenden, sodass kompensierende Maßnahmen notwendig sind (zur Magie der „Compensating Controls“ siehe unten).
• Welche Muss-Vorschriften erfüllt die Organisation schon ganz oder teilweise? Hier hat später noch eine detailliertere Reifegrad-Einschätzung einzusetzen (Schritt 3). Schon jetzt sollten aber entsprechende Maßnahmen in der Hierarchie nach oben rücken! Sie gehören in die Hände von Spezialisten, die damit schon Erfahrungen gesammelt haben. Hilfreich ist dabei auch ein Mapping auf Normen, denen die betroffene Organisation vielleicht schon länger gehorchen muss, da Überdeckungen fast zwangsläufig bestehen.
• Welche Muss-Vorschriften erfüllt die Organisation noch gar nicht? Hier muss sofort mit Machbarkeitsanalysen begonnen und zwingend ein Weg zum Ziel skizziert werden, der Aufwände erfasst und den Möglichkeiten der Organisation entgegenstellt.

Schritt 3: Reifegrad-Selbsteinschätzung

Bei allen teilweise umgesetzten Muss-Vorschriften sollte man als Nächstes „quick and dirty“ per Selbsteinschätzung dokumentieren, wie weit die entsprechenden Maßnahmen im Unternehmen gediehen sind. Zunächst gilt dann: Was bereits am weitesten fortgeschritten ist, sollte auch zuerst fertiggestellt werden, sofern keine Ergebnisse aus dem später folgenden Risiko-Assessment (Schritt 5) eine andere Reihenfolge nahelegen.

Schritt 4: Identifikation von „Quick Wins“

Neben dem zwingenden Blick auf die Muss-Vorschriften lohnt sich auch ein Blick auf die Kann-Vorgaben, denn vielleicht erfüllt die Organisation die eine oder andere davon schon und kann sich durch die Dokumentation dieser Fakten in ein besseres Licht rücken.

Auch „Quick Wins“ sollten in diesem Stadium ermittelt werden: Dabei handelt es sich um Vorgaben jeder Kategorie, deren Ziel-Stand die Organisation mit minimalem Aufwand erreichen kann, etwa durch die Aktivierung einer Option bei einer bereits implementierten Security-Software. Ein typischer Fall im Krankenhaus-Umfeld wäre zum Beispiel, dass eine Lösung zur Absicherung mobiler Geräte bereits existiert, Elemente wie die Nutzdaten-Verschlüsselung oder eine starke Authentifizierung aber noch fehlen oder einfach nicht konfiguriert worden sind. Dann lässt sich mit relativ geringem Aufwand schnell ein besseres Sicherheitsniveau schaffen.

Allerdings lauern hier auch besondere Fallstricke:

• Quick Wins können zu Pseudo-Auswegen aus dem Priorisierungszwang mutieren, die zu viele Ressourcen an „angenehme“, aber nicht unbedingt vorrangige Aktivitäten binden. Unter Zeitdruck neigen Menschen dazu, aus einem komplexen Anforderungsgeflecht zunächst leicht erreichbare Schritte auszuwählen, um wichtigere, aber schwierigere Schritte ein wenig auf die lange Bank schieben zu können. Bei der Identifikation von Quick Wins sollte deshalb analytisch kühl vorgegangen werden – echte Prioritäten gehen vor.
• Nicht alles, was einfach erscheint, ist auch einfach: Techniker und Budget-Verantwortliche könnten etwa dazu neigen, jede „bloße Änderung der Security-Richtlinien“ per se als Quick Win anzusehen, weil derartige Maßnahmen keine Investitionen erfordern. Greifen neue Policies aber stark in die Arbeitspraxis der Anwender ein, kann dies zu Reibungsverlusten in täglichen Abläufen oder zu Widerständen führen, die den Erfolg der Maßnahme unterminieren. Ein zusätzlicher Schritt im Anmeldeprozess an einem Mobilgerät etwa könnte in einer Klinik einen massiv steigenden Zeitbedarf zur Folge haben, wenn er in jedem Krankenzimmer, das eine Pflegekraft aufsucht, jedes Mal neu durchgeführt werden muss.

Schritt 5: Risiko-Assessment

Nach der Auseinandersetzung mit den Vorgaben steht ein kurzes, knappes Risiko-Assessment an. Im Scope liegen die von der zu beachtenden Norm erfassten Bereiche. Das Assessment dient dazu, die individuelle Situation der betroffenen Organisation mit den verallgemeinernden Annahmen der Norm-Autoren abzugleichen. So existieren vielleicht bestimmte Risiken gar nicht, von deren Existenz die Vorgaben ausgehen – im Beispiel etwa dann, wenn eine Klinik primär pflegt und nur über wenige Diagnose-Einheiten verfügt.

Einzelne Risiken können allerdings auch höher sein, als es bei vergleichbaren Institutionen gewöhnlich der Fall ist – im Beispiel „Krankenhaus“ etwa aufgrund der Fachausrichtung einer Klinik oder aufgrund von ungewöhnlichen lokalen Gegebenheiten. Dem Autorenteam ist beispielsweise ein Krankenhaus bekannt, das an einem Hang gelegen ist und bei dem deshalb die Notaufnahme und die Anlieferung großer, schwerer Waren über ein und denselben Eingang erfolgen müssen. Dies erhöht zwangsläufig das Risiko, dass Daten unter Lebensgefahr eingelieferter Patienten Personenkreisen zugänglich werden, die nichts mit der Behandlung zu tun haben. Solche speziellen Situationen justieren die in Schritt 2 und 3 vorläufig festgelegte Prioritätensetzung noch einmal neu, und auch hier gilt: Die Entscheidungen sind nachvollziehbar zu dokumentieren.

Schritt 6: Projektplanung

Für die priorisierten Maßnahmen gilt es anschließend, Projektpläne aufzustellen. Auch im Kleinen sollte man versuchen, jede einzelne Maßnahme in Unterschritte aufzuteilen, die für sich bereits das Sicherheitsniveau heben. Mühsam sind in dieser Phase die nun sehr detaillierten Aufwandsschätzungen, welche die finanziellen und personellen Mittel der betroffenen Institution berücksichtigen müssen. Die Ergebnisse sollten exakt und schonungslos dokumentiert werden, damit sie – so weit wie möglich – einem künftigen Auditor als Argumentationsgrundlage vorgelegt werden können.

Zeigt sich, das bestimmte Maßnahmen die Institution fundamental überfordern, hilft vielleicht der (temporäre) Griff zu kompensierenden Maßnahmen (Compensating Controls).

Kompensation

„I think we‘ve done enough,“ he said, „for today, anyway. I should like to go down to the bottom of the hill and find some really good grass. […] Does anyone feel like coming with me?“ – Richard Adams, Watership Down

Die Idee der „Compensating Controls“ liegt darin, für nicht in der vorgegebenen Form umsetzbare Maßnahmen aus einer Norm gleichwertige Ersatzmaßnahmen zu identifizieren, die ebenfalls zum Ziel führen. Einen festen Platz haben diese Modelle etwa in der Informationssicherheits-Norm der Kreditkartenbranche (PCI DSS). Dort kommen sie beispielsweise dann zum Einsatz, wenn die im Bankenbereich häufig anzutreffenden uralten Mainframes gar nicht mit Autorisierungs- oder Verschlüsselungstechnik ausgerüstet werden können, die man heute vernünftigerweise verlangt. In diesem Fall sind also technische Hinderungsgründe vorhanden, und vermutlich würden sie auch technisch gelöst – etwa durch Vorschaltung eines nach aktueller Praxis hinreichend gesicherten Gateways zum System.

Wer auf kompensierende Maßnahmen setzen will, muss den Sinn und die Ziele einzelner Vorschriften eines Normenwerks genau analysieren und dann gut dokumentieren, warum er glaubt, den Vorgaben auch auf anderem Weg gerecht werden zu können.

In einigen Fällen ist aber auch ein Ausweichen auf fundamental andere Sicherheitsbereiche denkbar. So könnte man ein mit IT-Mitteln kaum zu schützendes System in einen besonders stark abgeschotteten Serverraum transferieren, wenn dies das Sicherheitsniveau erhöht. Compensating Controls fordern somit die Kreativität der Anwender heraus, die sich allerdings in gewissen Grenzen bewegen sollte – so wurden einem Mitglied des Autorenteams beim PCI-DSS-Audit einer Großtankstelle einmal zwei ausgewachsene Dobermänner vor der Tür zum „Serverzimmer“ präsentiert, das die Computer für die Zahlungsabwicklung beherbergte. Die Hunde sollten als Ersatzmaßnahme für fehlende technische Zugriffs- und Zugangssicherungen fungieren – so etwas funktioniert nicht.

Im Klinikbereich wäre es beispielsweise denkbar, die Absicherung der Zugänge zu einem isolierten und nicht mit dem Netz verbundenen Diagnosegerät allein der Aufmerksamkeit des Bedienpersonals anheimzustellen. Damit allerdings wird ein Problem sichtbar, das bei vielen Compensating Controls eine Rolle spielt: Sie generieren potenziell Mehrarbeit, und zwar mitunter für Mitarbeiter, die nicht zur IT und IT-Security gehören. Die erste Folge dieser Reihe [4] zeigte dies bereits am Beispiel der Erkennung und Behandlung von Sicherheitsvorfällen, die ansatzweise auch ohne Bereitstellung eines typischen SIEM- oder SOC-Werkzeugs bewältigt werden kann, dazu allerdings dem SOC-Personal und allen anderen Angestellten erhöhte Aufmerksamkeit abverlangt.

Wer arbeitsintensive Kompensationsmaßnahmen in Betracht zieht, sollte diese unbedingt als lediglich temporäre Vorgehensweise konzipieren und den betroffenen Mitarbeitern ehrlich mitteilen, in welchem Umfang und wie lange mit Mehrbelastung zu rechnen ist. Anderenfalls machen mangelnde Akzeptanz und gegebenenfalls pure Erschöpfung die Wirksamkeit der Entlastungsmaßnahmen schnell zunichte. Und: Für die Phase der Mehrarbeit sollte das Unternehmen nach Möglichkeit auch eine ganz andere Art von „Kompensation“ anbieten, um die Anstrengungen des Personals zu honorieren – etwa in Form karrierefördernder Maßnahmen.

Fazit

„I admit it was a good idea,“ replied Blackberry. „Let’s remember it. It might come in handy again some time.“ – Richard Adams, Watership Down

Konsequente Priorisierung ist ein guter Weg, um Überforderungen aus neuen Anforderungskatalogen im Bereich Informationssicherheit und Datenschutz zu begegnen. Ein gewisser Raum für Schritt-für-Schritt-Vorgehensweisen bleibt fast immer – und die Chance, dass ein Auditor eine entsprechende Strategie auch akzeptiert, steigt mit der Professionalität des Vorschlags und dem Grad der Abstimmung auf reale Risiken.

Der Vorgang der Prioritätensetzung ist allerdings kein Selbstläufer. Vor allem die möglichen Reaktionen von Mitarbeitern auf einen radikalen Kurswechsel müssen vorab bedacht werden, damit das Team auch nach dem Paradigmenwechsel und unter temporär erschwerten Arbeitsbedingungen zusammenhält.

Bettina Weßelmann (bettina@wesselmann.com) ist Beraterin für Unternehmenskommunikation und Fachautorin mit dem Spezialgebiet Informationssicherheit. Dr. Johannes Wiele (johannes@wiele.com) ist freier Autor sowie GDD-geprüfter Datenschutzbeauftragter und arbeitet als Senior-Manager in der Cybersecurity-Beratung.

Literatur

[1] Deutsche Krankenhausgesellschaft (DKG), Branchenspezifischer Sicherheitsstandard (B3S) für die Gesundheitsversorgung im Krankenhaus, Version 1.1, Oktober 2019, www.dkgev.de/themen/digitalisierung-daten/informationssicherheit-und-technischer-datenschutz/informationssicherheit-im-krankenhaus/
[2] CyberX, 2020 Global IoT/ICS Risk Report, Oktober 2019, https://cyberx-labs.com/resources/risk-report-2020/ (Registrierung erforderlich)
[3] Bettina Weßelmann, Johannes Wiele, Commedia della Sicurezza, Rollen und Zwänge in Sicherheitsprojekten, <kes> 2020#2, S. 10
[4] Bettina Weßelmann, Johannes Wiele, Anders zum SOC, Der Weg zum Branchenstandard mit flexibler Umsetzung am Beispiel Krankenhaus – Teil 1, <kes> 2020#3, S. 51