Der Begriff Security Operations Center (SOC) wird von verschiedenen Akteuren unterschiedlich interpretiert. Materna fasst darunter die folgenden Tätigkeiten zusammen:
- Log Management (Operations und Engineering)
- SIEM (Operations und Engineering)
- Security Analyse Level 1, Level 2 und Level 3
- Incident Response und Forensik
- Vulnerability Scanning und Management
SOC als Herz der IT-Sicherheit
Dabei wird es für Firmen und Behörden immer schwieriger, selbst die Kapazitäten aufzubauen. Das vorhandene Personal ist im Regelfall mehr als genug ausgelastet und am Markt sind kaum die geeigneten Ressourcen zu bekommen. Darum ist es nicht verwunderlich, dass immer häufiger Security Operations Center komplett als Service bezogen werden. Ein SOC stellt in gewisser Weise den zentralen Punkt oder das „Herz“ der IT-Sicherheit und Informationssicherheit da. Daher gibt es einige Dinge zu beachten, wenn das SOC als Serviceleistung bezogen wird.
Falls über die vorhandenen Fähigkeiten noch Unklarheit existiert, macht es Sinn, zunächst die IT-Sicherheit einem Assessment zu unterziehen. Welche Kapazitäten sind bereits da, welche müssen noch aufgebaut werden? Etwas bildlich gesprochen: Organisationen sollten eine funktionierende Burgmauer haben, bevor sie die Wachposten darauf positionieren. Auf Grundlage der individuellen Risiken der Organisation sollten die benötigen IT-Sicherheitsprozesse und Kapazitäten bestimmt werden. Darauf aufbauend ist zu klären, welche dieser Prozesse und Fähigkeiten das Unternehmen selbst leisten und aufbauen kann und wo Unterstützung eines Dienstleisters benötigt wird. Dabei gilt es abzuwägen: Die Organisation selbst verfügt über tiefe Kenntnisse ihrer Geschäftsprozesse und Risiken. Ein etablierter Dienstleister besitzt dahingegen in der Regel jahrelange Erfahrung im Betrieb eines SOC und hat die verschiedenen Prozesse bereits mehrfach aufgebaut und bei verschiedenen Kunden integriert. Beides sind wichtige Wissensschätze, die berücksichtigt werden sollten.
Aus diesem Grund sollte ein Dienstleister in der Lage sein, Services nach dem Baukastenprinzip individuell für seine Kunden anzubieten und maßgeschneidert anzupassen. Dabei ist es wichtig, die Fähigkeiten nicht jedes Mal komplett neu zu erfinden, sondern Verfahren, die sich für andere Kunden und in anderen Umfeldern bewährt haben, an das individuelle Risiko und die individuelle Situation der Organisation anzupassen. So kann die Organisation selbst am meisten profitieren.
SIEM als wichtiger Baustein
Ein besonders wichtiger Baustein für ein SOC ist das SIEM – Security Incident (oder Information) and Event Management. Manchmal wird der Begriff SOC sogar synonym für SIEM verwendet. Ein SIEM ist ein zentrales System, das Logdaten von Security Devices und anderen Quellen sammelt, um sie zentral für Security-Analyst*innen verfügbar zu halten und automatisiert auf mögliche Angriffe zu durchsuchen. Ohne den genauen Angriff zu kennen, lassen sich Regeln definieren, die auf bestimmte Angriffsmuster anschlagen und es so ermöglichen, auch noch neue unbekannte Angriffstechniken zu erkennen – die sogenannten Zero Days.
Auch ein SIEM lässt sich komplett als vollgemanagten Service von einem Dienstleister beziehen. Hierbei sollte eine Organisation ähnlich wie bei den anderen SOC-Prozessen vorgehen. Nach einer Bestandsaufnahme der vorhandenen Kapazitäten und des eigenen Risikos sollte bestimmt werden, welche Prozesse von einem Dienstleister bezogen werden. Hierbei kann sich eine Organisation an den folgenden Paradigmen orientieren:
- Gemeinsam: Sie kennen das Risiko und die Geschäftsprozesse Ihrer Organisation, ein Dienstleister verfügt über die Erfahrung und Threat Intelligence. Beides sollte genutzt werden, um gemeinsam Use Cases und Playbooks zu entwerfen und so den größtmöglichen Nutzen zu erzielen.
- Risikobasiert: Alle eingesetzten Use Cases und alle angeschlossenen Logquellen sollten jeweils von ihrem individuellen Risiko bestimmt sein. Beispielsweise bringt es nichts, vorgefertigte Use Cases zu nutzen, die auf Angriffsmuster gegen ein System prüfen, das in der Organisation überhaupt nicht zum Einsatz kommt. Auf der anderen Seite haben Sie eventuell schlecht geschützte, individuelle Applikationen im Einsatz, für die es noch keine vorgefertigten Use Cases gibt. Da die Überwachung dieser Applikationen aber für Ihre Organisation von hohem Wert ist, sollten hierfür frühzeitig Use Cases entwickelt werden.
- Schrittweise: Um schnellstmöglich die Sicherheit real zu erhöhen, ist es sinnvoll, zunächst mit wenigen Use Cases und Logquellen zu beginnen. Darauf aufbauend können schrittweise Use Cases und Quellen hinzugenommen werden. So sind Sie schnell produktiv und können gleichzeitig agil auf sich verändernde Gefahrenlagen und Anforderungen reagieren.