Drei SOC-Angebote vorliegen — mit welcher Matrix vergleiche ich Scope und SLA am besten?

Achtet bei den SLAs ganz genau darauf, wann der Timer für MTTD und MTTR überhaupt startet. Viele Anbieter zählen nicht ab dem Moment, in dem der Alarm im System aufschlägt, sondern erst, wenn der diensthabende Analyst das Ticket manuell bestätigt hat. Aus einer 15-Minuten-Reaktionszeit werden so in der Praxis schnell 2 Stunden.

Wir haben letztes Jahr für eine ähnliche Infrastruktur einen Vertrag über 80.000 TL abgeschlossen. Weil das Log-Kontingent viel zu knapp kalkuliert war, sind wir im dritten Monat drübergerutscht und haben 28.000 TL Nachzahlung kassiert. Klärt die Kosten für Mehrvolumen beim täglichen Log-Aufkommen unbedingt vorab verbindlich.

Verlasst euch bei der Formulierung „24/7“ niemals blind auf das Marketing. Oft sitzt in der Nachtschicht nur ein Praktikant oder ein L1-Bereitschaftsmitarbeiter, der starr auf den Bildschirm schaut. Wenn nachts um 03:00 Uhr Ransomware-Verdacht aufkommt: Ist dann direkt ein L2/L3-Experte greifbar, der den Server isolieren darf, oder wartet man auf den Dienstbeginn um 09:00 Uhr?

Die 4 wichtigsten Checkpoints für eure Vergleichsmatrix: 1) Kosten bei Überschreitung des täglichen Log-Volumens (GB/EPS). 2) Verfallen ungenutzte IR-Stunden am Monatsende oder werden sie übertragen? 3) Frequenz für Regelanpassung und Tuning. 4) Vorhalte- und Indexierungsdauer historischer Logs für Audits.

bei uns waren false positives die absolute hölle. halt wenn am tag 50 irrelevante meldungen reinkommen guckt irgendwann keiner mehr hin. lasst euch zwingend in die tabelle schreiben wie viele stunden/personentage pro monat für regeltuning vorgesehen sind.

Hinweis: Dies ist meine persönliche Erfahrung, das muss nicht auf alle zutreffen.

Bereitet für die Geschäftsführung eine risiko- und kostenorientierte Zusammenfassung vor, statt sie mit Fachbegriffen zu überfrachten. Macht neben den Angeboten eine Spalte für „Nicht abgedeckte Leistungen“ auf. Wenn im Vorfeld nicht glasklar geregelt ist, welche Schritte am Ende bei eurem internen Team hängenbleiben und was der Dienstleister übernimmt, schieben sich im Ernstfall beide Seiten gegenseitig die Schuld zu.

Verlangt vor Vertragsunterschrift zwingend einen 14-tägigen PoC (Proof of Concept). Bindet zumindest zwei kritische Server und ein paar Clients an. Ohne die Dashboards auf Usability und die tatsächliche Alarmierungsgeschwindigkeit live im Betrieb gesehen zu haben sollte man solche Summen nicht fest binden.

Wer übernimmt das EDR-Management auf den Endgeräten? Sammeln die Anbieter nur passiv Logs ein oder haben sie über ihre Tools auch die Befugnis und Möglichkeit, ein verdächtiges Gerät im Angriffsfall sofort netzwerkseitig zu isolieren?

Ich bin ein kleines Unternehmen, ich erzähle es aus meiner Sicht. Scheut euch nicht zu fragen, wer nicht fragt, zahlt am Ende mehr.

Wenn deine Situation anders ist, ändert sich das natürlich.

bei uns war es so. übrigens wenn die Zwei-Faktor-Authentifizierung aktiv ist, reicht ein gestohlenes Passwort allein nicht aus.

an deiner Setlle würde ich so vorgehen.

Meine Frage ist geklärt vielen Dank.

Ich habe mich lange damit beschäftigt. Ein automatisierter Scan-Report ist kein Penetrationstest.

Schaut zuerst, welche Daten ihr bei der Entscheidungsfindung zur Hand habt.

Gut dass du diesen Thread eröffnet hast.

Gut gemacht.

Entschuldigung, aber das gilt nicht in jedem Fall. Wenn der Benachrichtigungsweg lang ist, kommen keine Benachrichtigungen; keine Benachrichtigung bedeutet spät erkannte Vorfälle.

Mich interessiert das auch.

Ich stimme voll und ganz zu. Änderungen an Zahlungsdaten werden niemals über den Kanal bestätigt, über den sie eingehen.

Kurzfassung für Neueinsteiger: Schreibe bei Entscheidungen auch das Worst-Case-Szenario auf, nicht nur das Beste.

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