Essay
Nicht das Tool macht ein gutes SOC.
Die meisten SOC-Projekte, die ich in den letzten fünfzehn Jahren gesehen habe, begannen mit der Frage nach dem richtigen Tool. Welches SIEM. Welcher EDR. Welche Plattform, die alles zusammenführt. Die Frage ist nachvollziehbar — ein Tool ist greifbar, hat einen Preis, hat Features, lässt sich ausschreiben. Und trotzdem ist sie fast immer die falsche erste Frage.
Ein gutes SOC ist kein Produkt. Es ist eine Organisation, die arbeitet, während andere schlafen. Und eine Organisation, die gut arbeitet, macht ein mittelmäßiges Tool erstaunlich gut aussehen. Eine schlechte Organisation macht das beste Tool zu einer teuren Log-Sammlung, die niemand mehr liest.
Die Industrie weiß das. Die Studien sagen es seit Jahren. Die erfahrenen Security-Menschen sagen es, wenn man sie privat fragt. Warum also ist die Tool-Frage weiterhin die erste?
Weil sie einfacher ist. Ein Tool kann man vergleichen. Man kann drei Anbieter einladen, einen PoC machen, eine Matrix ausfüllen und am Ende eine Entscheidung treffen, die sich begründen lässt. Eine Organisation kann man nicht so ausschreiben. Man kann sie nur aufbauen.
Das dauert länger, ist schwerer zu messen, und führt am Ende nicht zu einem Pressefoto beim Vertragsunterzeichnen. Es ist unspektakuläre Arbeit. Und deshalb fällt sie bei vielen SOC-Projekten hinten runter.
Das Muster ist immer ähnlich. Ein Vorstand entscheidet, dass ein SOC aufgebaut werden soll. Ein Projekt wird aufgesetzt, mit Budget und Zeitplan. Eine Tool-Auswahl wird getroffen. Das Tool wird implementiert. Nach zwölf bis achtzehn Monaten ist das Projekt „fertig” — in dem Sinne, dass das Tool läuft, dass Use Cases geschrieben sind, dass Dashboards existieren. Was fehlt, ist die eigentliche Sache: Eine Organisation, die damit arbeitet.
Ein SOC, das nicht aus der Organisation wächst, sondern ihr aufgesetzt wird, bleibt ein Fremdkörper — technisch teuer, operativ dünn.
Die Arbeit, ein SOC wirklich arbeitsfähig zu machen, beginnt, nachdem das Projekt als „abgeschlossen” markiert wurde. Sie dauert noch einmal so lang. Sie besteht darin, Menschen beizubringen, welche Alerts ernst zu nehmen sind und welche nicht. Prozesse zu entwickeln, wie Eskalationen wirklich laufen und nicht nur, wie sie im Handbuch stehen. Übergaben zu gestalten zwischen den Schichten, zwischen L1 und L2, zwischen SOC und IR. Feedback-Schleifen einzurichten, damit aus Incidents gelernt wird. Vertrauen aufzubauen zwischen SOC und dem Rest des Unternehmens, damit eine Incident-Meldung nicht zu einer politischen Auseinandersetzung wird.
Das ist Organisationsarbeit. Keine Tool-Arbeit.
Was bedeutet das praktisch? Vor allem das: Wenn ein SOC-Projekt bei Ihnen beginnt, lohnt es sich, die Reihenfolge bewusst zu setzen. Nicht erst das Tool, dann die Organisation. Sondern zuerst die Organisation, dann das Tool.
Das heißt nicht, dass man zwei Jahre Organisation aufbaut, bevor man Software einkauft. Beides muss parallel laufen. Aber die Aufmerksamkeit sollte bei der Organisation liegen — bei den Rollen, den Prozessen, den Schnittstellen, der Kultur. Das Tool ist der einfachere Teil.
Die zweite praktische Konsequenz: Die Frage, ob ein SOC gut ist, lässt sich nicht an der Technologie erkennen. Sondern an Dingen wie der Übergabe-Qualität zwischen den Schichten, der False-Positive-Rate nach zwölf Monaten Betrieb (nicht nach drei), der Frage, ob das SOC eigene Erkennungsregeln schreibt oder nur Hersteller-Defaults nutzt, und daran, wie ein Incident durch die Organisation läuft, wenn er außerhalb der Kernarbeitszeit auftritt.
All das sind Dinge, die man in einer Tool-Demo nicht sieht. Aber sie sind das, was ein SOC zu einem guten SOC macht.
Wenn Sie gerade ein SOC aufbauen oder überlegen, eines zu bauen, ist mein Rat kurz: Fangen Sie mit den Menschen an. Fangen Sie mit den Prozessen an. Fangen Sie mit den Rollen an. Das Tool kommt dann dazu, wenn die Organisation weiß, was sie damit vorhat.
Das ist langsamer. Es ist unspektakulärer. Es produziert keine guten Folien. Aber es produziert ein SOC, das arbeitet.
Und am Ende ist das der einzige Unterschied, der zählt.