Kunde verlangt Log-Weiterleitung an ein SOC — welche Abteilung/Rolle sollte das bei unserer Unternehmensgröße übernehmen?

Schiebt ihr das den Admins zu, geht nach einem Monat das gegenseitige Fingerpointing los. Der Admin schickt stumpf Logs rüber, das SOC meckert „da fehlt was“, und der Kunde sitzt frustriert dazwischen. Ihr braucht dazwischen mindestens einen Koordinator, der wirklich Ahnung von Security hat.

Wenn ihr Logs per Syslog oder Agent übertragt, vergesst nicht die Bandbreite und die CPU-Last auf den Servern einzuplanen. Das kriegt die IT zwar hin, aber synchrone Time-Stamps und verschlüsselte Übertragung erfordern extra Sorgfalt.

Wir hatten mit 40 Leuten exakt dasselbe Thema. Wir haben uns monatlich 20 Stunden externe Security-Beratung geholt, hat um die 18.000 TL im Monat gekostet. Unser Admin hat pro Woche nur 4 Stunden dafür gebraucht, und die Sache lief rund.

Schickt bloß nicht panisch alles rüber, nur weil der Kunde Druck macht. Die meisten SOC-Dienstleister rechnen nach Log-Volumen ab. Wenn ihr den Scope der Systeme nicht von Anfang an scharf eingrenzt erwarten euch am Monatsende gigantische Rechnungen.

Welche Logs will der Kunde denn ganz konkret sehen? Geht es nur um OS- und Firewall-Logs oder sind auch Datenbank-Queries und detaillierte In-App-Aktivitäten gefordert?

Legt sofort eine Eskalationsmatrix fest. Wen ruft das SOC nachts um 3 Uhr an? 1) Den Admin, 2) den Lead-Dev oder 3) den Geschäftsführer? Ohne das schriftlich fixiert zu haben, solltet ihr mit der Integration gar nicht erst anfangen.

bei uns wurde das damals auch einfach den admins aufgehalst, nach zwei monaten wollten die jungs hinschmeißen. sowas muss definitiv mit externer beratung gelöst werden.

Unterm Strich: Infrastruktur bleibt beim Sysadmin, Code-Anpassungen bei den Devs, aber fürs Incident-Handling und die SLA-Abstimmung führt kein Weg an externer Security-Expertise vorbei.

Notiert, danke. Ein automatisierter Scan-Report ist kein Penetrationstest.

Ich probiere es aus.

Gespeichert. In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf.

Schreibe bei Entscheidungen auch das Worst-Case-Szenario auf, nicht nur das Beste. Korrigiert mich, falls ich falsch liege.

richtig.

Ich erkläre mal die technische Seite. Wenn du zu einem Thema drei verschiedene Antworten bekommst, war die Frage falsch gestellt.

Ich fasse das Thema mal zusammen, da es mehrere unterschiedliche Antworten gab. Überstürzte Entscheidungen sind oft solche, die man sechs Monate später korrigieren muss.

Das hatte ich auch schon überlegt. Vergessene Testumgebungen sind häufiger das Einfallstor als das Live-System.

Absolut. Wenn ich noch etwas hinzufügen darf: Maßnahmen ohne vorherige Bestandsaufnahme lassen die Türen offen, die man nicht sieht.

Schaut zuerst, welche Daten ihr bei der Entscheidungsfindung zur Hand habt. Ich hoffe, das hilft dir weiter.

Genau so ist es. Wenn ihr es zum ersten Mal macht fangt klein an, die Skalierung kommt später.

Wenn ihr das Ergebnis hier postet hilft es auch anderen.

Genau so ist es. Die meisten Vorfälle beginnen nicht mit einer Schwachstelle, sondern mit einem geleakten Passwort.

Sicherheit ist nicht absolut; es bedeutet, den Angriff so aufwendig zu machen, dass er sich nicht lohnt. Das ist meine Meinung, ich behaupte nicht, dass es absolut richtig ist.