Mit <kes>+ lesen

Anders zum SOC : Der Weg zum Branchenstandard mit flexibler Umsetzung am Beispiel Krankenhaus – Teil 1

Zu einem Security-Operations-Center (SOC) gehören ein Werkzeug, das im Netz nach Anzeichen von Angriffen sucht, eine Security-Analysten-Mannschaft und ein Vorfallsmanagement samt Aktionsplan für Notfälle – darüber ist sich die Security-Branche weitgehend einig. Aufbau und Betrieb dieser skizzierten Trias überfordern mittelständische Organisationen jedoch oft. Das Beispiel „Krankenhaus“ lehrt mit seinem Branchenstandard: Manchmal ist es hilfreicher, das gängige SOC-Modell zumindest in der Aufbauphase frech weg zu ignorieren.

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

Der relativ neue „Branchenspezifische Sicherheitsstandard für die Gesundheitsversorgung im Krankenhaus“ [1], der unter der Regie der Deutschen Krankenhausgesellschaft entwickelt und im Oktober 2019 vom Bundesamt für Sicherheit in der Informationstechnik (BSI) anerkannt wurde, ist eine überaus interessante Lektüre.

Denn er beschreibt unter anderem, wie finanziell eher mäßig ausgestattete Institutionen in Zukunft ein anspruchsvolles Sicherheitsniveau erreichen wollen – noch dazu in einer Umgebung, in der das Versagen von Cybersecuritymechanismen durchaus Menschenleben gefährden kann.

SOC ohne SOC?

Auffällig ist dabei: In dem Standard fehlt – wie auch in einigen anderen Normen aus dem Dunstkreis kritischer Infrastrukturen (KRITIS) – der Begriff „Security Operations-Center“ (SOC). Auch eine mögliche deutsche Übersetzung findet man nicht, wohl aber einen Abschnitt „Vorfallerkennung und Behandlung“. Dieser wiederum beschreibt Security-Mechanismen, die gewöhnlich sehr wohl dem Bereich SOC zugeordnet werden und in der anglophilen Sicherheitsbranche unter Threat-Detection und Incident-Management laufen. Die Definition von Verantwortlichkeiten, die Einrichtung eines Vorfallsmanagements mit Maßnahmen-Priorisierung, das Logging und Monitoring kritischer IT-Systeme und die Einrichtung von Verfahren zur Wiederherstellung der Integrität von Informationen nach einem securityrelevanten Ereignis sind dabei „MUSS“-Vorschriften, keine bloßen „SOLL“-Ideen.

Warum verlangt der Standard dann nicht ausdrücklich die Einrichtung eines SOC? Die Antwort gibt Markus Holzbrecher-Morys, Geschäftsführer IT, Datenaustausch und eHealth bei der Krankenhausgesellschaft, der stark in die Entwicklung des Branchenstandards involviert war: „Wir wollten hier einfach die Lösung des Problems nicht vorgeben.“ Dies ist umso spannender, als Holzbrecher-Morys zugleich berichtet, dass sich die Autoren des Standards intensiv Gedanken darüber gemacht hätten, für welche Security-Bereiche konkrete Umsetzungsvorschläge oder -vorgaben enthalten sein sollten und für welche nicht – das Thema „Fernzugriff“ ist etwa eines, das sehr ins technische Detail geht. Holzbrecher-Morys lässt auch durchblicken, dass man in einer konkretisierten Forderung nach einem Security-Operations-Center die Gefahr sah, über die an das Wort „SOC“ geknüpften Assoziationen falsche Erwartungen insbesondere bei den „prüfenden Stellen“ zu wecken. Der Branchensicherheitsstandard definiere Mindestanforderungen; ein „SOC“ gehe je nach Ausgestaltung zum Teil weit darüber hinaus. Aus den Entwicklungsprozessen vergleichbarer Standards ist außerdem bekannt, dass deren Autoren vermeiden möchten, die Produkte und Services gängiger Anbieter quasi zum Modellfall zu erklären und jenen somit direkt die „Tür zu öffnen“.

Anbieter- versus Branchen-Standard

All dies impliziert, dass Anwender tatsächlich auch anders vorgehen können, als es die breit aufgestellte Phalanx der Hersteller und Serviceprovider im SOC-Umfeld nahelegt. Was aber ist denn eigentlich das Gemeinsame hinter den Angeboten der durchaus renommierten Akteure auf dem Markt? Warum hat dieses Konzept eine so große Macht über die Vorstellung von einem sinnvollen SOC-Aufbau, dass kaum eine Institution das Thema anders angeht als mit der initialen Auswahl und Implementierung eines Basis-Werkzeugs wie etwa einer hoch komplexen Security-Informations-and-Event-Management-(SIEM)-Lösung?

  • Im Zentrum der angebotenen Architekturen steht immer ein Werkzeug, das mittels Anbindung an Security-Sensoren Indikatoren für Angriffe aus dem Netz gewinnt, mehr oder weniger gut vorselektiert und dann priorisiert an Security-Analysten weiterleitet, welche die Vorfälle einschätzen und gegebenenfalls Gegenmaßnahmen einleiten.
  • Die Sensorik stützt sich entweder auf die Log-Daten sicherheitsrelevanter Systeme und Anwendungen (SIEM), eine Analyse der Netzwerk-Kommunikation (Network-Behaviour-Analysis, NBA / Network-Behaviour-Anomaly-Detection, NBAD) oder eine Überwachung der Aktivitäten menschlicher wie maschineller Anwender (User- and Entity-Behaviour-Analytics, UEBA). Die drei Ansätze können kombiniert oder einzeln eingesetzt werden, wobei vor allem die Log-Analyse zuweilen einen hohen Aufwand bei der Anbindung der überwachten Systeme generiert.
  • Beim Monitoring wird entweder auf Abweichungen von einem zuvor als „normal“ erhobenen Verhalten von Systemen und Anwendern (Anomalie-Erkennung) oder auf Abläufe geachtet, die anderswo bereits als typische Vorgehensweisen bei einem Angriff registriert wurden (regelbasiert mit Security-Intelligence als Quelle). Auch hier lassen sich beide Verfahren kombinieren.
  • Zentrales Element der meisten Lösungen ist die „Korrelation“, eine Art künstlicher Intelligenz (KI) auf niedrigem Niveau: Für sich alleine möglicherweise unauffällige Einzelereignisse werden permanent zueinander in Beziehung gesetzt, um auch komplexere, mehrschrittige Angriffe aufdecken zu können.
  • Künstliche Intelligenz auf höherem Niveau dient dazu, unzutreffende Warnungen auszusondern (False Positives) und die übrigen zu rubrizieren und zu priorisieren, um sie dann den richtigen Bearbeitern zuzustellen.
  • Ganz offensichtlich liegt die gedankliche Basis eines solchen in weiten Teilen immer gleichen Konstrukts in der Erfahrung, dass einzelne Menschen die Flut an securityrelevanten Daten von Sicherheits- und Anwendungssystemen in einer modernen Organisation manuell gar nicht mehr schnell genug sichten und korrelieren können, um Sicherheitsvorfälle rechtzeitig wahrzunehmen. Mit weitgehender Automatisierung soll deshalb die Monitoring-Last verringert werden. Außerdem sehen die Anbieter hier Einsparungspotenzial, da KI Teile der Analystenschar ersetzen und somit den Bedarf an teuren Spezialkräften reduzieren können soll.

Künstliche versus menschliche Intelligenz

All dies erscheint dermaßen richtig, selbstverständlich und vertraut, dass es kein Wunder ist, dass eine Websuche nach „SOC ohne/ without SIEM“ praktisch keine Ergebnisse liefert, die ein SOC ohne zentrales Korrelationswerkzeug als gangbaren Weg beschreiben. Nur Alternativen fürs klassische SIEM werden diskutiert, also die oben erwähnten UEBA- und NBA-Ansätze.

Auch diese Konzepte sind aber ebenfalls mit jener extrem hohen Einstiegsschwelle behaftet, die bei einer großen Zahl potenzieller Anwender die Implementierung entweder auf halbem Weg scheitern lässt oder in eine unabsehbare Zukunft verschiebt. Das in der KI liegende Einsparpotenzial mag dabei spätere Betriebskosten senken, macht sich aber bei der Einstiegsinvestition nicht so sehr bemerkbar, dass es Organisationen mit wirklich kleinem Budget ausreichend helfen würde.

Foto 1

Ein SOC braucht sowohl Überblick als auch Detail-Analysen: Viele bunte Monitore, bequeme Sessel, ein engagiertes Team – die Wunschbilder der Leitstellen für IT-/IT-Sicherheit (im Bild: Nationales
Lagezentrum des BSI) und in Krankenhäusern gleichen sich hier zunehmend. Die Wirklichkeit sieht allerdings oft noch anders aus.

Umgebungscharakteristik

Es gibt also eine hinreichende Motivation, nach Alternativen zu suchen, und offenbar hat man beim Branchenstandard „Krankenhaus“ diese Möglichkeit gesehen. Vielleicht geben die Arbeitsbedingungen in diesem Sektor Aufschluss darüber, welches Vorgehen sich hier – und vielleicht auch anderswo – dem verbreiteten Standard-Konzept entgegenhalten lässt. Die folgenden Rahmenbedingungen sind für Krankenhäuser charakteristisch – aber bei Weitem nicht nur dort zu finden:

  • Der finanzielle Rahmen für Security ist begrenzt. Generell stecken die meisten Krankenhäuser wirtschaftlich im engen Korsett des staatlichen Gesundheitswesens, da fast alle zugleich notwendigen und teuren Leistungen über die Vorgaben der gesetzlichen Krankenversicherung abzurechnen sind. Und wenn eine Klinik schon Geld für spezielle Technik ausgibt, ist der fachliche und gesellschaftliche Druck groß, die Medizin im engeren Sinne zu priorisieren: Diagnosegeräte, Behandlung, OP-Ausrüstung und so weiter. Alles, was nicht nachvollziehbar der Rettung von Menschenleben dient, steht unter einem extremen Rechtfertigungszwang. Deutsche Krankenhäuser verwendeten 2017 nur 2 % ihres Budgets auf die gesamte IT [2] – das lässt erahnen, was für die Cyber-Sicherheit bleibt.
  • Die Personalausstattung im Bereich IT und IT-Security ist limitiert. Wie bei der Technik gilt: Mittel sollen vorrangig der Hauptleistung von Einrichtungen zugeteilt werden, also ärztlichem Personal, Labormitarbeitern und Pflegekräften. Dem Bedarf dieser Bereiche etwa die Gehaltsforderungen eines Cybersecurity-Analysten entgegenzusetzen, ist schwierig – zumindest solange ein Krankenhaus noch keinen Datenskandal erlebt hat. Genau den gilt es aber dringend zu vermeiden.
  • Die IT muss generell hoch verfügbar sein, damit ein Versagen keine Menschenleben gefährdet. Zugleich beherbergt und transportiert die IT hoch sensible Daten. Nur moderne, individuell gestaltete Schutzkonzepte kommen da mit. Allerdings gibt es durchaus Beispiele dafür, dass im Krisenfall ein Krankenhaus seinen Betrieb temporär auch ohne IT aufrechterhalten kann – das bedeutet aber langfristig unzumutbare Belastungen für die Mitarbeiter, weshalb ein schneller Wiederanlauf der IT im Krisenfall gewährleistet sein muss.
  • 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, die informationellen „Kronjuwelen“ zu schützen, kann sich aber aufgrund des hohen Arbeitsdrucks im Bereich der Kernaufgaben kaum mit technischen Fragen des Datenschutzes befassen. Man darf aber immerhin darauf zählen, dass Mitarbeiter datenschutzrelevante Beobachtungen melden, wenn sie dafür eine Anlaufstelle kennen.
  • 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 und überdies die Macht haben, auch experimentelle Technik ans Netz zu bringen, „Bring your own Device“ (BYOD) einzufordern oder stationsinterne Datensilos aufzubauen. Viele dieser in ihrem jeweiligen Bereich hoch professionellen Spezialisten arbeiten überdies parallel in der kommunikativ freizügigen Wissenschaftswelt. Die Grenzen zwischen den Sphären „Klinik“ sowie „Forschung/Lehre“ lassen sich kaum strikt ziehen, zumal die Beheimatung in beiden Bereichen ein zentraler Erfolgsfaktor für das Klinikum und ein lebensrettendes Moment für die Patienten sein kann. Wer Mitglieder der hoch privilegierten Benutzergruppen zu Verhaltensänderungen bewegen will, muss sie überzeugen – wenn dies allerdings gelingt, kann die IT-Security im Klinikumfeld mit hoher „Compliance“ zu Sicherheitsregeln rechnen (vgl. [3]).
  • Am Netz hängen zwar viele weitgehend standardisierte IT-Systeme wie ein Krankenhaus-Informationssystem (KIS), ein Labor-Informationssystem (LIS), ein Radiologie-Informationssystem (RIS) sowie das typische Archiv-und Kommunikationssystem für diagnostische Bilder (PACS). Zugleich finden sich gerade in Universitätskliniken aber auch teilweise überaus langlebige, teilweise brandneue und experimentelle IoT-Geräte in Diagnosezentren, Laboren und Krankenzimmern, die sich nur mit Mühe in gängige IT-Security-Konzepte integrieren lassen. Sie direkt ans Netz zu bringen, kann beispielsweise zu Fernwartungszwecken, zur internen Überwachung, zur Steuerung oder zur statistischen Auswertung von Informationen sinnvoll sein. Eine Störung solcher Systeme durch Sabotage gefährdet allerdings direkt und „in Echtzeit“ Menschenleben, macht Heilungschancen zunichte und bedroht obendrein die Reputation der Häuser.
  • Bei den Informationssystemen ist die Integrität der Daten extrem kritisch, denn ein Patient kann nur dann richtig behandelt werden, wenn dafür korrekte Diagnosedaten zur Verfügung stehen.

Auf den ersten Blick ergibt sich aus diesen Parametern ein Szenario, auf welches das gängige SOCBild der Anbieter passt. Vor allem die Tatsache, dass ein Angreifer direkt auf Diagnose- und Behandlungssysteme zugreifen könnte, schreit geradezu nach einem ständig laufenden, schnell korrelierenden SOC-Tool.

Foto 2

Auch Intensivbetten, medizinische Geräte und Patienten im Krankenhaus profitieren von Überwachungszentralen zumindest für einzelne Stationen (im Bild: Intensivstation im Salzkammergut Klinikum Gmunden) – Forschungsprojekte werden teils bereits „remote“ überwacht. Die eingesetzte Technik ähnelt durchaus den Dashboards und Analysebildschirmen eines SOC – ohne IT wird an dieser Stelle vieles deutlich schwieriger.

Stolpersteine für Standard-Tools

Auf den zweiten Blick gibt es allerdings Aspekte, die gegen einen forcierten Einstieg ins übliche, toolbasierte SOC sprechen: So sind gerade die medizinischen Geräte, um die es hier geht, in der Realität vieler kleinerer Kliniken noch lange nicht in größerem Maße direkt am Netz und damit zum Teil des „Internet of Things“ (IoT) geworden.

Diesen Schritt zu gehen, erfordert aber einen noch einmal höheren Aufwand als die Integration klassischer IT-Systeme ins Security-Monitoring: Da medizinische Systeme für ihre interne Kommunikation andere Protokolle verwenden, als man sie in der „normalen“ IT-Welt kennt, müssen zur Einbindung in ein IT-gestütztes Überwachungssystem entweder neue Schnittstellen mühsam entwickelt werden. Oder der Anwender muss zusätzlich zum IT-SOC-Tool noch ein spezialisiertes IoT-Monitoring-Werkzeug beschaffen, das Anomalien bei medizinischen Spezialgeräten erfassen und an das SOC weiterleiten kann. „Security by Design“ aus der Hand der Hersteller medizinischer Geräte wird diese Problematik erst in der Zukunft entschärfen.

CyberX und Nozomi sind zwei Beispiele für Anbieter, die sich mit der Überwachung existierender IoT-Systeme befassen und so den Entwicklungsaufwand prinzipiell reduzieren können – aber wieder gilt, dass die entsprechenden Lösungen erst einmal eingekauft oder als Managed Service gebucht werden müssen.

Kenner der Szene wissen zu berichten, dass für Kliniken die Anfangsinvestition selbst bei einem Managed-Service-Ansatz oft immer noch zu hoch ist, um sie in einem Satz finanziell stemmen zu können. Auch für monatliche oder jährliche Servicegebühren reicht das Budget nicht immer. Und Einsparmöglichkeiten durch Automatisierung und KI greifen kaum, wenn ein Anwender noch über gar keine Systeme verfügt und die gesamte SOC-Ausstattung neu implementieren muss.

Hier gibt es allerdings die Chance auf einen Workaround mittels zeitlicher Dehnung: Wie für das produzierende Gewerbe erhöht sich für Kliniken zwar ständig der Digitalisierungsdruck. Es ist aber noch immer möglich, kritische und lebenserhaltende IoT-Geräte außerhalb von eventuellen Fernwartungszyklen von den IT-Netzen zu isolieren. Im Kliniksektor existiert also offenbar noch ein gewisses Zeitfenster für die Verbesserung des Security-Niveaus, das man für einen überlegten und finanziell tragbaren SOC-Aufbau sinnvoll nutzen könnte.

Menschliche Sensoren und Reserven

Ein weiterer Aspekt ist, dass heutige SOC-Technik einen in Kliniken stark ausgeprägten Sensorikbereich gar nicht erfassen kann: die menschliche Aufmerksamkeit. Für Social-Engineering etwa oder von Mitarbeitern beobachtete Versuche, abgeschottete Bereiche zu betreten, hat heutige SOC-Technik noch keine Eingangsschnittstelle (siehe auch [4]). In Kliniken ist das Personal jedoch, wie erwähnt, aufgrund der Erfahrungen mit der ärztlichen Schweigepflicht stark dafür sensibilisiert, personenbezogene Daten zu schützen – und selbstverständlich werden Menschen in kritischer Verfassung auf den Intensivstationen nicht nur durch Technik, sondern auch durch medizinisches Personal überwacht. Die grundsätzliche Tendenz moderner SOC-Technik, den Einfluss des menschlichen Faktors im Monitoring-Bereich zu reduzieren, passt im klinischen Umfeld also nicht so gut zur Realität wie anderswo.

Hier fügt sich gut ein Ereignis ins Bild, auf das in anderem Zusammenhang wieder Markus Holzbrecher-Morys verweist: Als 2016 das Lukaskrankenhaus in Neuss unter einem Cyber-Angriff litt, konnte trotz lahmgelegter IT der Kernbetrieb aufrechterhalten und teilweise sogar ausgebaut werden – allerdings unter extrem hoher Belastung des Krankenhaus-Personals, das längst automatisierte Vorgänge nun wieder manuell ausführen musste. Das SOC eines Krankenhauses kann also durchaus darauf zählen, dass das gesamte Personal in stärkerem Maße Krisensituationen abfedert und zur „Remediation“ beiträgt als in anderen Bereichen. Dies darf man zwar nicht willentlich ausnutzen, es verschafft Sicherheitsfachkräften aber faktisch doch ein weiteres zeitliches Polster für die Entwicklung eines Modells für die SOC-Implementierung, das der schwierigen finanziellen Situation gerecht wird.

Und noch etwas weiß Holzbrecher-Morys zu berichten: „Es gibt einzelne Kliniken, die über hinreichend Fachpersonal verfügen, um selbst kreativ Probleme lösen zu können und dabei Geld zu sparen. Das geht bis zur Absicherung des Netzzugangs von IoT-Geräten mit selbstprogrammierten Soft- und Hardware-Lösungen auf der Basis von Kleincomputern wie den Raspberry- oder Banana-Pis, die dann im klinischen Umfeld auch noch in für den medizinischen Einsatz adäquate Gehäuse eingebaut werden müssen. Dies sind allerdings Einzelfälle – gerade in kleinen Häusern gibt es die entsprechenden Spezialisten nur selten.“

Zusätzlich sollte man noch in Betracht ziehen, dass mit der gängigen Verteilung wichtiger Informationen auf KIS, LIS, RIS und PACS eine Art branchenspezifischer „Informations-Segmentierung“ vorliegt, die den Schutz kritischer Daten zumindest vereinfachen kann und es möglicherweise auch erleichtert, beim Monitoring Prioritäten zu setzen. Werden die erwähnten Systeme gut präventiv gesichert – also beispielsweise mit starker Authentifizierung ausgestattet, die allerdings schnelle Notfallzugriffe zulassen muss (vgl. [3]) –, ist auch die Überwachung auf Anomalien hin tendenziell weniger aufwendig. Problematisch kann dagegen der Schutz gegen Risiken aus dem schwer kontrollierbaren Einsatz mobiler Geräte sein. Hier müssen gegebenenfalls entsprechende Policies helfen.

Beta-SOC

Nimmt man all diese Überlegungen zusammen, könnte die eine oder andere Klinik vielleicht tatsächlich auf ein Modell zurückgreifen, das die übliche Security-Literatur normalerweise mit Prädikaten wie „unzureichend“ oder „zweite Wahl“ versieht: Ein SOC ohne SIEM, NBA oder UEBA.

Rein von der Definition her ist ein Security-Operations-Center eine Betriebseinheit, die – hier ist Wikipedia einmal wenig hinzuzufügen – „Dienstleistungen für die EDV-Sicherheit bietet: ein Verfahren zur Vorbeugung und Behandlung von unvorhergesehenen Schwierigkeiten“. Weitere Kennzeichen laut Definition sind eine (in der Praxis durchaus nicht überall erreichte) Rund-um-die-Uhr-Überwachung und die Auswertung von Informationen gängiger Security-Tools wie Intrusion-Detection, Virenschutz, Firewalls und Vulnerability-Management sowie von kritischen Anwendungen. Hinzu kommt ein Rahmen aus steuernden Verwaltungs- und Qualitätssteigerungsprozessen.

Ein Klinik-SOC ist somit schon existent, bringt praktische Vorteile für die Sicherheit und kann die Vorfallsmanagement-Anforderungen des Branchenstandards erfüllen, wenn:

  • die Überwachungskonsolen der zentralen Informationssysteme und gegebenenfalls der vernetzten medizinischen Geräte in einem Kontrollraum zusammengefasst werden,
  • die Fragen „Was will ich erkennen?“ und „Was kann ich schon erkennen?“ im neu ernannten SOC-Kreis diskutiert werden und das Ergebnis als Ist- und Zielbild sowie in Form von Use-Cases für das SOC dokumentiert werden kann,
  • ein Prozedere für die Kommunikation an den Konsolen beobachteter Auffälligkeiten unter den zuständigen Sicherheits-Spezialisten vereinbart wird,
  • ein Weg für die Einbeziehung „menschlicher Sensorik“ gefunden wurde und
  • aus echten Vorfällen auch langfristig Lehren gezogen werden können, indem man ein entsprechendes Qualitätssteigerungsverfahren definiert.

Vorlaufbetrieb als Einstiegshilfe

So rudimentär dieser Ansatz auch aussehen mag: Er erhöht bei geringstmöglicher Vorlaufzeit immerhin sofort die Leistung der Vorfallserkennung, wenn auch nur in geringem Maße. Zugleich – und dies ist wichtig! – werden im bestehenden Team SOC-Prozesse eingeübt und das SOC in der Organisationsstruktur und der Security-Kommunikation des Hauses als Service verankert (vgl. [5]). Darüber hinaus zeigt die anlaufende zentralisierte Monitoring-Praxis, die sonst gern auf die Zeit nach der langwierigen Voll-Implementierung einer üblichen Lösung verschoben wird, auf anschauliche Weise, wo der größte Automatisierungsbedarf in der eigenen Organisation liegt. Dieses Wissen und die Erfahrungen mit dem SOC-Vorlaufbetrieb erleichtern es dann wiederum, sinnvolle Prioritäten zu setzen und anstelle einer Voll-Lösung zum Beispiel gezielt zu beschließen, zuerst einen passgenauen Managed Service oder eine Soft- und Hardware nur für die Überwachung der Medizin-IoT, nur für die klassische IT oder nur für die heikle mobile Endgeräte-Welt zu beschaffen. Behält das Team dabei seinen Wunschstatus für die Zukunft im Auge und achtet darauf, dass die Module später gut zu einer Gesamt-Architektur zusammengefasst werden können, steigert dieses auf den ersten Blick wenig konsequente Vorgehen das Sicherheitsniveau möglicherweise schneller und nachhaltiger als ein Hauruck-Einstieg ins große Ganze, der am Ende aus Kapazitätsgründen scheitert – oder sogar aus finanziellen Erwägungen heraus unkontrolliert wieder abgespeckt werden muss.

Fazit

Es bleibt am Ende zwar bei der kategorischen Feststellung, dass ein SOC ohne automatisierte Bedrohungserkennung und -behandlung eine stark eingeschränkte Leistungsfähigkeit aufweist und nicht als Dauerlösung taugt. Für Institutionen, die sich den Start mit der Implementierung eines voll ausgebauten SIEM-, NBA- oder UEBA-Werkzeugs aber partout nicht leisten können, bietet der mehr oder weniger manuelle Vorlaufbetrieb die Chance, sich gezielt einzuarbeiten, Mindest-Anforderungen zu erfüllen und Wege für einen Schritt-für-Schritt-Ausbau zu finden, der zuerst die größten Lücken auf dem SOC-Gebiet stopft. So gesehen kann der klinische Bereich ein gutes Vorbild für andere Branchen sein, die sich mit dem anspruchsvollen Thema „Security-Operations-Center“ ebenfalls schwertun.

Ausblick

Das Niveau neuer Compliance-Vorschriften erreicht kaum eine Organisation in einem einzigen Anlauf – fast immer muss man Prioritäten setzen und kommt auf dem Weg zum Ziel danach nur Schritt für Schritt voran. Eine Priorisierung, die auch in den Augen eines Auditors Bestand hat, ist allerdings kein einfaches Unterfangen. Der zweite Teil dieser Mini-Serie zum Thema „Branchenstandards“ befasst sich deshalb im nächsten Heft ausführlich damit, auf welche Messwerte eine sinnvolle Priorisierung bauen sollte, wie man interne Widerstände überwindet und wie man das eigene Vorgehen für eine Prüfinstanz erstens nachvollziehbar macht und zweitens glaubhaft vermittelt, dass man das Erreichen des Zielzustands nicht nur auf den St. Nimmerleinstag verschieben will. Im einen oder anderen Fall sind hier die beschriebenen „Vorlaufbetriebe“ eine Lösung – in wieder anderen Fällen helfen kompensierende Maßnahmen weiter, wenn die eigentlich naheliegendste Vorgehensweise für den Moment unerreichbar erscheint.

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), Branchenspezifi scher 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] Heike E. Krüger-Brand, Cyberrisiken als Herausforderung, Deutsches Ärzteblatt 114(42), Oktober 2017, S. A 1910, online auf www.aerzteblatt.de/archiv/194044/IT-Sicherheit-im-Krankenhaus-Cyberrisiken-als-Herausforderung
[3] Bettina Weßelmann und Johannes Wiele, Von Topdown zum Dialog: Kooperation verdrängt Kampagnenmodell, <kes>2016#1, S. 6
[4] Bettina Weßelmann und Johannes Wiele, HumanFactor-Sensoren für SIEM, <kes> 2014#4, S. 6
[5] Bettina Weßelmann und Johannes Wiele, Dauerbaustellen der Security (1): Das SOC hinter den sieben Bergen, <kes> 2016#
3, S. 50

Diesen Beitrag teilen: