Einfach mal SOC machen ft. Michael Fischer
E38

Einfach mal SOC machen ft. Michael Fischer

So, wir sind jetzt im zweiten Take angekommen hier für die neue Folge von Breach.fm.

Ich bin mit meinem Gast gerade schon auf eine andere Plattform gewechselt,

weil wir einen so großen Lag zwischen uns beiden hatten.

Was bei, wie viele Kilometer liegen zwischen uns?

100 maximal. sie mal.

Ja, irgendwie sowas, als es gar nicht so eigentlich sein sollte.

Trotzdem, ich mache einfach den gleichen Aufbau nochmal.

Willkommen zur neuen Folge, zur zweiten Folge dieses Jahr, im Jahre 2024.

Wir haben sehr viel positives Feedback zur letzten Folge mit Johannes bekommen

und für die, die gefragt haben, ja, Johannes und ich haben schon gesagt,

dass wir nochmal eine Folge aufnehmen werden.

Wir waren nur, wie ich, glaube ich, am Ende der Folge gesagt gesagt habe,

leider ein bisschen zeitlich begrenzt dieses Mal.

Und ja, wie gesagt, vielen Dank. Shared weiterhin.

Breach.fm gebt uns eine positive Bewertung auf der Plattform eurer Wahl.

Und wie ich versprochen habe, wir werden jetzt im zweiwöchigen Rhythmus bleiben.

Und auch heute werden wir eine sehr spannende Folge, glaube ich, haben.

Wir haben, glaube ich, auch seit Wochen und Monaten über diese Folge,

ich will nicht sagen verhandelt, aber gesprochen.

Und ich konnte meinen Gast davon überzeugen. Und dieser Gast das darf sich jetzt

gerne selbst vorstellen. Wer bist du? Was machst du?

Ja, vielen Dank für die Einladung, Robert. Und schön, dass es geklappt hat nach

tatsächlich jetzt langer Zeit der Terminfindung, wenn wir zweimal Zeit haben.

Mein Name ist Michael Fischer. Ich bin Product Owner des Cyber Defense Centers

der Stadtwerke München.

So gesehen fachlicher Teamlead eines kleinen Teams,

dass in den letzten Jahren die Herausforderung mit allen Hürden,

Höhen und Tiefen angenommen hat, ein CDC aufzubauen.

Ja, sehr schön. Also das wird heute auch wieder so ein bisschen das große Thema sein.

Wir werden zwar natürlich nicht nur über CDC, SOC oder wie man es auch immer

Themen nennen, sprechen werden, aber was ich auf alle Fälle mal sehr interessant

finde, wir haben jetzt ganz oft über die Perspektive von Managed Providern gesprochen.

Wir haben auch ganz oft über die Perspektive vielleicht von Unternehmen gesprochen,

die da schon auch teilweise schon sehr weit sind.

Heute würden wir gerne mal so ein bisschen darüber sprechen,

wie fängt man damit denn überhaupt an?

Weil das, was wir ganz häufig sehen und da haben wir uns ja auch schon öfters

mal darüber unterhalten, ist, dass Unternehmen,

Behörden oder wer auch immer ganz oft versuchen, so auf Zwang von heute auf

morgen das große Bild zu schaffen und dann natürlich in der Planung komplett

hängen bleiben, weil die Ressourcen werden nie ganz da sein.

Man wird nie ganz die Menschen finden, die man eigentlich dafür bräuchte.

Und ja, weil man die ganze Zeit 100 Prozent will, wird man nie bei 10 Prozent

auch noch ankommen. Und du hast zu mir mal vor relativ langer Zeit schon mal

gesagt, einfach mal anfangen.

Und was meinst du denn damit? Wie war da vielleicht auch deine Historie?

Wie war da vielleicht auch deine Herangehensweise, um zu sagen,

ich schaue jetzt mal, dass ich mit den gegebenen Mitteln möglichst weit komme?

Ja, das einfach am Anfang ist immer leicht getan.

Ich glaube, wir hatten das Glück, hier ein sehr,

sehr großes Stück weit dazu in die Lage versetzt worden zu sein,

einfach wirklich nach unserem Gusto die besten Mittel erstmal einzuführen.

Sprich, mit dem Anfang, denke ich, braucht er erstmal Leute,

die Lust haben, ein Thema vorwärts zu bringen, wie bei allen anderen Themen auch.

Hier insbesondere das Thema Security Monitoring, sprich SIEM, XDA,

was der Markt da halt hergibt, sich ein Produkt anzuschauen,

mehrere Produkte anzuschauen und diese Leute sind dann dazu befähigt worden,

bei uns eben mal ein SIEM-System einzukaufen.

Ganz wichtig fand ich und sehr, sehr hilfreich in diesem Moment,

dass wir kein Team waren, was ganz neu aufgebaut wurde.

Wir kannten das Unternehmen schon und wir waren exklusiv für diese Aufgabe oder

für diese Mission, kann man ja schon fast sagen, abgestellt,

dort das Thema Security Monitoring weiter auszubauen.

Sprich, wir wussten, in welchen Netzbereichen wir uns wie fortbewegen können,

wie wir Themen implementieren.

Und ja, diese, ich sage es mal sehr, sehr positiv, Narrenfreiheit hat uns sehr

geholfen, da sehr schnell auf die Straße zu kommen.

Vor allem mit einem etablierten SIM-System, was wir dann einkaufen konnten nach

einer entsprechenden Ausschreibung.

Dort recht schnell Geschwindigkeit eben auch einzubekommen.

Das meine ich mitmachen. Also die Herausforderung einfach mal gucken,

was ist so der Kern? Was muss ich machen?

Das ist aus meiner Sicht, wie gesagt, die Leute, die müssen Lust haben,

die müssen sich natürlich auch auskennen.

Ich brauche eine Technik und ich muss ein bisschen tatsächlich dann auch schauen,

dass die Rahmenbedingungen stimmen.

Das heißt, nach ein paar Gesprächen mit befreundeten Socks,

Haben wir uns dann dazu entschieden, auch dieses Thema Betriebsrat mit Bestimmungsrecht,

eben was mit so einem Security-Monitoring-Thema einhergeht, auch direkt mit

anzugehen, um da nicht irgendwie Gefahr zu laufen, irgendwo nachher in politisches

Treibsand zu kommen und uns dadurch Steine in den Weg zu legen.

Du sprichst, finde ich, ein paar wichtige Punkte an. Also ich sehe auch immer

häufiger, dass wenn das Thema SOC angegangen wird, dass man dann im Grunde genommen

neue Kräfte ranzieht von außen, was jetzt sicherlich erstmal per se auch gar nicht schlimm ist.

Aber dass man sich da auf Teams aufbaut, die gar nicht aus bestehenden Kräften

irgendwie zusammengesetzt werden.

Und ich denke mir auch immer besonders, wenn man, wie bei euch,

und da wird man sicherlich auch mal drüber reden, jetzt nicht von heute auf

morgen schon weiß, ja, was will ich denn überhaupt monitoren,

wie will ich es monitoren, welche Daten sind denn überhaupt für mich interessant,

das ist ja so ein Thema, das hatten wir vor zwei Wochen in der Folge auch schon mit dem Johannes,

dann ist es, finde ich, schon immer wichtig, dass es Leute gibt,

die eine gewisse Betriebserfahrung haben, die auch mal wissen können,

wo müssen wir denn vielleicht besonders hinschauen, vielleicht gibt es hier

Netzbereiche, an die man sonst gar nicht denkt.

Wiederum sehe ich natürlich auch das andere Extrem, und da hast du auch einen

wichtigen Punkt angesprochen mit, dass die Leute dann exklusiv dafür Zeit bekommen.

Ich sehe immer häufiger, dass man dieses gut gemeinte Sock dann intern aufbaut

und sagt, ihr macht das jetzt mit und ihr macht es neben euren anderen Tätigkeiten.

Und ich habe immer das Gefühl, die anderen Tätigkeiten werden am Ende meistens

dann doch wieder zu wichtig im Tagesbetrieb, als dass dann diese neuen Aufgaben

wirklich an Relevanz gewinnen können.

Wieso war das bei euch auch so wichtig, dass die Leute sich dann wirklich exklusiv

darauf konzentrieren konnten und wie schwer war es auch, so eine Entscheidung zu bekommen?

Weil am Ende fehlen diese Ressourcen ja an anderer Stelle, muss man ja ehrlich

sein. Die haben ja davor auch was gemacht.

Das stimmt. Es wurde sich aber schon vor längerer Zeit zum Glück in Unternehmen dazu entschieden,

dass es halt nicht mehr state of the art ist, große Mauern außen drum zu bauen,

um IT-Infrastrukturen, sondern eben auch das Innendrin anzupacken.

Somit wurden so gesehen diese Leute, also wenige Leute, ich war mit dabei,

eingestellt, die sich tatsächlich explizit um dieses Thema kümmern sollten.

Sprich, dadurch, dass du natürlich am Anfang noch ein Stück weit freie Ressourcen

hast, schaust du dich dann um.

Das heißt, wir waren zunächst einmal wirklich im Dunstkreis des Firewall-Managements etc.

Beheimatet. und haben dort mit Firewall-Regeln implementiert und an anderen

Themen noch mitgearbeitet, konnten so die Umgebung sehr gut kennenlernen auch einfach und sehen,

hey, das sind so viele Firewall-Logs, nur um auf das Thema direkt mal zu sprechen zu kommen.

Wir zahlen uns dumm und dämlich, wenn wir dort alle Logs reinladen in ein Team.

Das macht auch gar keinen Sinn.

Und na ja, da haben wir uns dann mit der Zeit herausgefaced aus diesen Themen

und machen dann jetzt 100% die CDC Security Monitoring Themen.

Wenn wir vielleicht sogar nochmal ein paar Schritte zurückgehen.

Man spricht ja mittlerweile in so einer Selbstverständlichkeit davon,

dass man einen SOC einführt, dass man CDC einführt.

Und das klingt jetzt fast wie eine dumme Frage, aber was war denn überhaupt

die Motivation, das Ganze zu machen?

Also auch die Motivation der Stadtwerke, in anderen Fällen des Unternehmens.

Man sagt natürlich ja, um sicherer zu werden, aber es gibt ja oft auch andere

Gründe. Es gibt irgendwelche Compliance-Gründe, es gibt gesetzliche Anforderungen.

Wieso hat man sich auch dazu entschieden, diesen Weg zu gehen?

Das ist eine sehr, sehr gute Frage. Die hundertprozentigen Rahmenbedingungen

kenne ich tatsächlich davon nicht.

Da es schon recht lange zurückliegt tatsächlich.

Das geht aber tatsächlich wirklich primär darauf, es zurückzuführen.

Dass wirklich Security-Strategien an wie, was ist State-of-the-Art betrachtet

wurden, um dann zu entscheiden, dieser besagte Mauer drumherum reicht einfach

nicht mehr, es weicht sich alles auf, Remote-Zugang hier, Remote-Zugang dort,

SaaS etc., was eingeführt wird, dass das Thema einfach angegangen werden muss

im Sinne einer zukünftigen IT-Sicherheitsstrategie.

Jetzt habt ihr ja viel am Anfang, wie es ja immer in dem, wenn man es richtig

macht, meiner Meinung nach, oder wenn man es seriös macht, hat man am Anfang

immer einen relativ großen Bauch an Sock-Engineering-Aufgaben und kommt,

da sind viele Leute auch immer so ein bisschen enttäuscht, noch gar nicht zu

diesen fancy Aufgaben mit, ich zerlege hier Threads, ich mache Analysen,

sondern eigentlich ist man erstmal damit beschäftigt, die Prozesse aufzubauen,

die Technologie aufzubauen, die Technologie dahin zu tunen.

Und dieser ganze Teil von, ich mache dann wirklich SOC-Operations,

ich komme in so ein Daily Business, braucht oft unglaublich lange und das ist

vielen Firmen in meiner Erfahrung gar nicht bewusst.

Wie lange hat es bei euch gebraucht, bis ihr überhaupt mal in den Modus kam,

dass ihr sagen konntet, wir können uns jetzt auch wirklich um den Grundsatz

Analytics kümmern und wir kommen langsam in so eine Art von Tagesgeschäft rein? Das.

Muss ich überlegen. Es ging tatsächlich doch recht fix.

Wir haben uns Hilfe geholt bei der Implementierung des Siebensystems durch einen

guten Dienstleister, der uns dort unterstützt hat.

Das ging somit eigentlich recht fix, der ganze Aufbau der Umgebung auch hochautomatisiert.

Da hatten wir sehr, sehr gute interne Ressourcen, die das gestemmt haben,

sodass wir wirklich im Rahmen noch einer Vorbereitungszeit auch eine Sysmon-Config

erstellt haben, getestet haben, die es dann so gesehen mit der Sensorik sehr,

sehr schnell ausrollen konnten.

Also ich möchte sagen, dass das eigentlich bei uns ja wirklich schnell innerhalb

eines halben Jahres ging.

Ich glaube, wir waren am Ende des Tages selbst ein bisschen überrascht,

dass wir da schon schnell im Operating sind.

Und die Prozesse haben sich dann ein Stück weit mit dabei geformt, was ich gut finde.

Denn auch da kann man sich dann wieder übernehmen und sagen,

ich mache es erstmal auf dem Papier und dann holt einen die Realität ein.

Gehört so ein bisschen mit so einem Prinzip. Einfach erstmal machen,

gucken, was auf einen zukommt. Fail fast halt.

Ja, das finde ich erstmal gut. Also ich finde es erstmal gut,

natürlich einen Plan zu haben und auch seinen Korridor zu haben,

in dem man sich bewegen möchte und natürlich daran zu denken,

es ist ja nicht nur Technologie und wir brauchen hier auch irgendwann Prozesse.

Also wenn irgendwo eine Anomalie hochblockt, dann müssen wir schon ungefähr

wissen, wie wir damit umgehen und wann die wäre analysiert und wie wir darauf reagieren.

Trotzdem sehe ich halt auch da wieder das andere Extrem, dass es Unternehmen

gibt, die jeden Prozess davor schon festschreiben wollen und machen sich da

zwei Jahre lang Gedanken und dann wird irgendwann das erste Mal,

weiß ich nicht, so ein Alert angefasst und da merkt man ja, das ist ja gar nicht

feasible für den Praxisbericht.

Wenn du jetzt nochmal die Aufgabe hättest, hier komplett Greenfield,

du hättest auch alle Ressourcen der Welt.

Das heißt auch geltlich wäre jetzt erstmal gar nicht so das große Thema.

Du würdest jetzt auch nicht von irgendeinem ominösen Fachkräftemangel oder so betroffen werden.

Wie würdest du an Tag 1 anfangen, denn das Ganze aufzusetzen?

Ich weiß, diese perfekte Welt gibt es gar nicht, aber wir stellen die uns jetzt

einfach mal vor. Was würdest du priorisieren und was wären so deine ersten To-Dos

in den ersten, sag mal, vier Wochen?

Ich würde ehrlicherweise gar nicht so viel anders machen, denn wir hatten jetzt

keine Fails als solche, wo wir gesagt haben, da haben wir uns jetzt richtig in die Nesseln gesetzt.

Jetzt gibt es ein oder andere Thema, was wir im Vorfeld ein bisschen unnötig

dann doch aufgearbeitet haben.

Also, da bin ich ganz offen. Also ich habe den Schmarrn gemacht,

habe mir die Mitre angeschaut, geguckt, was ist da in den jeweiligen TTPs für Data Sources,

welche Data Sources brauchen wir und von einer riesigen Liste dann runter extrahiert.

Ich glaube, die findet man in jedem Best-Practice-Blog zum Thema CDC,

Security Monitoring, wesentlich schneller.

Aber ja, man wird nicht nur mal, indem man sowas macht, hält einen erstmal auf.

Wie gesagt, wir haben nicht viele solcher Overheads gemacht.

Ich denke, ich würde an der Technologie ein bisschen was anderes machen und

dort nicht erst auf ein vollumfängliches SIEM setzen, sondern tatsächlich dann

eher die standardisierten Lösungen hernehmen.

Das kommt natürlich immer darauf an, auf den Scope, den ich habe.

Sprich, wenn ich irgendwo Vorgaben habe, dass ich bestimmte OT-Bereiche als

Unternehmen überwachen muss,

dann ist natürlich eine standardisierte Überwachung mit einem XDA als Beispiel schwieriger.

Aber wenn ich mich primär erstmal im Standard heterogenen Windows-Linux-Umfeld

bewege, sind so standardisierte Sensorik und Analyse-Technologien,

denke ich, dann doch die bessere Wahl erstmal.

Wenn wir auf die Prozessebene schauen, was sind für dich so auch in Anbetracht

der letzten Monate, Jahre so die absoluten Kernprozesse?

Also wo du sagst, wenn die zwei, drei Sachen nicht passen, dann können wir eigentlich

auch den Rest relativ vergessen. Weil wie gesagt, wir können immer über 10.000 Prozesse sprechen.

Ich habe das Gefühl, dass in den meisten Socks, es gibt zwei,

drei, vier richtig heftige Kernprozesse.

Wenn die sitzen, kann man über viele andere Dinge mal so ein bisschen hinwegsehen.

Also was sind da so deine Sachen, wo du sagst, ey, das muss bei uns einfach

sitzen, das muss auch trainiert werden und das ist gut, dass wir die Prozesse haben? Da.

Sehe ich wirklich als essentiell und eigentlich wirklich am wichtigsten den

Security Incident Response Prozess. Der muss sitzen.

Wobei es erstmal gar nicht so unbedingt der Prozess als solcher ist.

Das geht aus meiner Sicht wieder auf das CDC-Team über am Ende des Tages.

Denn das Team, und das ist auch so ein bisschen die Philosophie,

die wir bei uns reinbringen wollen und auch weiter ausarbeiten möchten.

Ich muss wissen, wer kann was in meinem Team, wer hat wo Spezialitäten und wer

macht im Falle eines Incidents was.

Das heißt, ich brauche jemanden, der koordiniert, der die Tasks verteilt oder

die Tasks primär koordiniert, das alles nachhält. Ich brauche jemanden,

der sich wirklich tief in die Technik reingraben kann.

Und ich brauche, ich nenne es mal Standardaufgaben, die extrem wichtig sind,

IOC-Prüfungen rausfinden, was für IOCs haben wir jetzt derzeit,

wie ist der Angreifer vorgegangen,

was hat er genutzt, um uns zu kompromittieren.

Und das muss ich trainieren, dass es einfach wirklich sitzt,

dass wenn ich sage, hey, wir haben jetzt hier einen Incident,

jeder sofort weiß, eigentlich wie ein Feuerwehrlöschzug, damit vergleiche ich

es immer, jeder aus seinem Auto springt und direkt weiß, wohin er laufen soll,

was er zu tun hat und wie kommuniziert wird.

Wie siehst du, also wir sind ja dann schon relativ spät in der Kette und ich

stimme dir natürlich in allem zu, aber wie wichtig und wie viel Priorität hat

natürlich auch auch dieses ganze Thema,

Incident-Qualifizierung, weil auch ihr werdet natürlich anhand der großen und

relativ diversen Infrastruktur viele Alarme bekommen und die allerallerwenigsten

werden sich als wirklich Incident wahrscheinlich, den man mit einem,

Koordinationsteam, einem Forensiker und sonst wie bearbeiten muss, herausstellen.

Wie viel Wert wird eben auch auf diese Stelle gelegt, also wirklich die Qualifizierung

des Ganzen und was sind da vielleicht auch so Dinge, wo du sagst,

ey, das Das hat sich für uns bewährt, wenn es da was gibt.

Es ist mir auch ein Herzensthema bei uns, tatsächlich ja die Analyse,

dass jeder Analyst das gleich macht, ganz klar.

Also die weiß, wenn da jetzt ein Alert ist, der von einem Endpunkt kommt,

dass ich meine definierten Schritte habe, im Zweifel automatisiert oder idealerweise

automatisiert, schaut, wem ist das Gerät zugeordnet?

Gibt es da vielleicht gerade einen Change oder eine Störung zu dem Gerät?

Dass einfach kein Analyst da erstmal fahrlässig oder, was heißt fahrlässig,

00:18:34.731 --> 00:18:37.611