Ein Security Operations Center (SOC) gehört in Konzernen inzwischen zum Standard. Einrichtung und Betrieb eines SOCs gelten allerdings als extrem teuer und überfordern auf den ersten Blick vor allem Unternehmen aus dem Mittelstand. Die Kosten schrumpfen aber auf ein erträgliches Maß, wenn das richtige Werkzeug und ein geschickt austariertes Betriebsmodell im Mittelpunkt stehen.

Gesetzgeber und Regulierungsinstanzen drängen immer stärker auf die Einrichtung einer Sicherheitsschicht, die bereits laufende Angriffe auf eine Organisation eindämmen kann, wenn Angreifer den Schutzwall des Unternehmens durchbrochen haben. Dies leistet ein SOC – bei entsprechender Ausrüstung an Werkzeugen, Prozessen und Personal. Die Forderung nach der Einrichtung von SOCs trifft in Deutschland besonders den Mittelstand, weil es gerade hier viele kleine bis mittlere Unternehmen mit Weltgeltung auf dem High-Tech-Sektor gibt. Sie leisten Herausragendes auf ihrem Gebiet und sind vielleicht sogar „Hidden Champions“ auf einem zukunftsträchtigen Wirtschaftssektor wie der Batterietechnik für Elektrofahrzeuge oder moderner Medizintechnik. Deshalb sind sie attraktive Ziele für gut organisierte und solide finanzierte Industriespionage oder Hacker-Gruppen mit Erpressungsabsichten. Zugleich aber können sich mittelständische Betriebe nur mit Mühe die Aufwendungen für die Einrichtung eines SOCs leisten.

Das Personal im SOC überwacht – verkürzt dargestellt – die gesamte IT-Infrastruktur einer Organisation darauf hin, ob Anomalien oder Erscheinungen auftreten, die auf Aktivitäten eines Angreifers hindeuten. Das Aufspüren derartiger Bedrohungen (Threats) gelingt unter anderem durch die Auswertung von Logdaten, die die Sicherheitssysteme im Netz ebenso bereitstellen wie zentrale Datenbanken, andere Anwendungen oder Industriesysteme. Die Werkzeuge im SOC – meist SIEM- oder TLM-Systeme (Security-Information- und Event-Management, Threat-Lifecycle-Management) – setzen die Meldungen der Einzelsysteme in Beziehung und entdecken so Abfolgen von Handlungen, die entweder untypisch für den Normalbetrieb oder andernorts bereits als Kennzeichen einer Angriffstaktik aufgefallen sind.

Die Schritte des Angreifers

Typischerweise gibt die Security-Software im SOC nacheinander Hinweise auf das erste Eindringen eines Angreifers, seine Aktivitäten zur Steuerung der folgenden Schritte wie etwa die Installation von Angriffswerkzeugen im Netz des Opfers, „Seitwärtsbewegungen“ (Lateral Movement) zur weiteren Ausbreitung und Erkundung des Zielnetzes und schließlich auf die Vorbereitung zum Datendiebstahl oder zur Sabotage. Je besser ein SOC-Werkzeug ist, desto früher wird es auf entsprechende Abläufe aufmerksam. Sobald ein SOC-Tool Handlungskaskaden erkennt, die für einen Angriff stehen könnten, schickt es je nach möglicher Bedeutsamkeit einzelne oder mehrere Meldungen an ein nachgeschaltetes Incident-Management-Team mit Security-Spezialisten für die Angriffserkennung und Gegenwehr (Detection und Response), an ein Orchestrierungswerkzeug zur Einleitung automatischer Abwehrmaßnahmen oder an ein CERT (Computer Emergency Response Team), das in schweren Fällen sofort eingreifen kann.

Dieses Konzept gilt als wirksam und zunehmend unverzichtbar, enthält aber auch kostentreibende Faktoren. Einer davon liegt in der Anforderung begründet, alle als kritisch betrachteten Informationsbestände und Infrastrukturelemente im Netz zu überwachen. Dem zentralen Werkzeug, das in diesem Monitoring-Szenario die technische Auswertung übernimmt, müssen somit sämtliche potenzielle Datenquellen zur Verfügung stehen, und zwar durch den Aufbau von Schnittstellen und Log-Auswertungsprogrammen (Parsern). Gegebenenfalls ist es auch sinnvoll, mit zusätzlichen forensischen Sensoren zu arbeiten, die Aktivitäten an Endpunkten oder Auffälligkeiten in den Netzwerkpaketen selbst unter die Lupe nehmen und weiterleiten. Die Identifikation der zu überwachenden Systeme, die Programmierung der Interfaces und das eventuell notwendige Training der Zentralinstanz können ein solches Implementierungsprojekt zu einem aufwendigen und langwierigen Verfahren machen. Nimmt man es aber nicht mit der notwendigen Sorgfalt in Angriff, entgehen dem SIEM- oder TLM-Werkzeug wichtige Informationen. Es ist dann teilweise blind für seine Umgebung.

Ein weiterer und der vielleicht für mittelständische Unternehmen bitterste Faktor bei SOC-Projekten resultiert aus dem Zwang zur möglichst umfassenden, rund um die Uhr wirksamen Überwachung der IT-Infrastruktur. Personen, die hier tätig sind, müssen nicht nur Angriffsalarme abschließend bewerten und die zugrunde liegenden Einzeldaten untersuchen können. Sie müssen auch in der Lage sein, schnell wirksam Abhilfe zu schaffen und bei der Neutralisierung einer Attacke möglichst geringe Nebenwirkungen in Form der negativen Beeinflussung von Geschäftsprozessen zu erzeugen. Security-Analysten, die dies leisten können, sind teuer – und der entsprechende Arbeitsmarkt ist nahezu leergefegt. Mögliche Bewerber können also hohe Gehälter verlangen und zögern auch häufig nicht, selbst lukrative Angebote abzulehnen, wenn der Arbeitsplatz nicht an einem attraktiven Einsatzort liegt. Hinzu kommen die Zulagen für Nachtschichten auf diesem Niveau.

Stellschrauben zur Kostenreduktion

So ernüchternd die Aufstellung der Kostenfaktoren sein mag, so deutlich zeigt sie aber auch die Stellschrauben für eine Verringerung der finanziellen Belastung. Die erste liegt im Bereich der Anbindung relevanter Informationsquellen an das zukünftige TLM- oder SIEM-Tool. Zwar gibt es keinen Weg, einem vorgeschalteten Risiko-Assessment zu entgehen. Dieses umfasst die Bestimmung der wichtigsten Geschäftsprozesse und wertvollsten Informationsbestände („Kronjuwelen“) sowie der zu erwartenden Anwendungsfälle (Use Cases). Doch bei der darauffolgenden Einbindung der so identifizierten kritischen Assets in die SOC-Erkennungslogik gilt es, Produkte auszuwählen, die möglichst viele der kritischen Hard- und Softwareelemente im eigenen Netz automatisch erkennen und die deren Output und Form von Log- oder Analysedaten ohne aufwendige Schnittstellenentwicklung sofort auswerten können.

Ein idealerweise kostenneutraler „Proof of Concept“ mit dem Produkt eines potenziellen Lieferanten im eigenen Netz zeigt per automatischer Discovery schnell, wie viel von der eigenen und als kritisch rubrizierten Infrastruktur ein Anbieter ohne aufwendige Nacharbeit erfassen kann. Ist die Liste der nicht entdeckten oder aber entdeckten, jedoch nicht eingebundenen vorhandenen Sensoren zu lang, lohnt sich ein weiterer Versuch mit einem anderen Kandidaten. Hat das Anbietersystem aber auf Anhieb fast alle notwendigen Quellen im Griff, sollte sich das Anwenderunternehmen zusichern lassen, dass das Proof-of-Concept-Ergebnis bei einem Zuschlag zum Angebot in den produktiven Einsatz übernommen wird. Dies spart einen enormen Teil der Anlaufkosten.

Der nächste Sparfaktor ergibt sich aus der qualitativen Flexibilität des Anbieters bei der Aufteilung der Aufgaben zwischen ihm und dem Anwenderunternehmen. Ziel sollte dabei sein, so viele teure Kräfte wie möglich einzusparen und überdies Nacht- und Wochenendarbeit zu reduzieren. Liegt das komplette Monitoring beim Kunden, muss er die größten Personalkosten stemmen. Könnte man fast alles nach außen geben und als Service buchen, entstünde das größte Einsparpotenzial. Denn gerade die am höchsten bezahlten Security-Analysten und CERT-Mitarbeiter sind immer nur dann beschäftigt, wenn es tatsächlich zu einem Zwischenfall kommt – sie müssen dann aber voll zur Verfügung stehen. Das gelingt über einen externen Service mit kundenübergreifendem Einsatz (Sharing) von Spezialisten am besten. Einem reinen Outsourcing in diesem Bereich sind allerdings häufig Grenzen gesetzt: Anwenderumgebungen enthalten häufig eigenent­wickelte, hochspezifische Systeme (zum Beispiel Produktionsanlagen); entsprechend schwer fällt es externen Kräften oder Instanzen künstlicher Intelligenz, erstens Anomalien und Angriffe zuverlässig zu erkennen und zweitens Gegenmaßnahmen einzuleiten, die wenige unerwünschte Nebenwirkungen mit sich bringen.

Folgende Kriterien und Überlegungen sind vor diesem Hintergrund geeignet, um weitere SOC-Kosten zu sparen: Der Hersteller sollte glaubhaft nachweisen können, dass seine Erkennungslogik sehr wirksam ist, etwa weil er viele Angriffsmuster aus der Branche des Kunden in seine Detektionsmechanismen einspielt. Dies reduziert die Nacharbeit durch Expertenbewertungen, sodass sich mit geringerem Personalaufwand planen lässt. Je standardisierter die eigene IT-Umgebung ist, desto mehr SOC-Arbeit lässt sich outsourcen oder an automatische Abwehrsysteme übergeben, weil dann auch externe Mitarbeiter oder KI-Systeme Angriffe sicher erkennen und wirkungsvolle Gegenmaßnahmen einleiten können. Gibt es im eigenen System aber hochindividuelle kritische Systeme wie etwa in Eigenregie programmierte Prozesse oder Produktionsanlagen, dann kann eine geschickte Arbeitsteilung auch darin liegen, das Monitoring nach außen zu geben, die Gegenwehr aber beim internen Team zu belassen. Erstens sind dazu selten Neueinstellungen nötig, weil das entsprechende Know-how ohnehin im Unternehmen liegt, und zweitens reicht für eine zeitgerechte Gegenwehr oft auch die Einrichtung einer Rufbereitschaft anstelle einer Rund-um-die-Uhr-Präsenz. Dies gilt umso mehr, wenn beispielsweise eine Überwachung nur während der Geschäftszeiten hinreichend erscheint, weil besonders kritische Systeme außerhalb dieses Zeitfensters gar nicht laufen. Je flexibler also ein Anbieter seine Services auf solche Bedingungen hin maßschneidern kann und je bereitwilliger er sich zeigt, auf individuelle Anforderungen einzugehen, desto mehr Kosten lassen sich vermeiden.

Fazit

Die Schlüsselfaktoren bei der Senkung der Kosten für die Einrichtung und den Betrieb eines SOCs sind die Qualität der Erkennungslogik eines SOC-Werkzeugs, die größtmögliche Kompatibilität zur Anwenderumgebung und die Flexibilität der angebotenen Dienstleistungen bei der Arbeitsteilung zwischen internem und externem Sicherheitspersonal. Ein Proof of Concept im eigenen Netz gibt Auskunft darüber, in welchem Maße dieses Ziel zu erreichen ist.

Rob Pronk ist Regional Director Central, Northern & Eastern Europe bei LogRhythm, www.logrhythm.com.