Kriterienkatalog zur Auswahl des richtigen MSSP-/MXDR-Anbieters

MSSP, MDR, MXDR: Was bedeutet was?

Viele Ausschreibungen im Bereich Cyber Security scheitern nicht an der Anbieterqualität, sondern daran, dass intern unterschiedliche Zielbilder miteinander vermischt werden.

Ein MSSP übernimmt typischerweise den Betrieb definierter Security-Services. Dazu können Monitoring, SIEM, Managed Firewalling, Endpoint Services, Vulnerability Management oder Incident-Unterstützung gehören. Ein MDR-Modell fokussiert stärker auf Detection & Response als operative Leistung. MXDR erweitert diesen Ansatz auf mehrere Daten- und Sicherheitsdomänen, etwa Endpoint, Identity, Cloud, Network und Log-/SIEM-Ebene.

Für Großunternehmen ist wichtig: Diese Begriffe sagen noch nichts darüber aus, wie tief Investigation, Reaktion, Governance und Integrationsfähigkeit tatsächlich ausgeprägt sind. Genau deshalb sollte der Auswahlprozess nicht mit der Frage starten, „brauchen wir einen MSSP oder MXDR?“, sondern mit der Frage danach, welches Operating Model den Sicherheitsbetrieb abbilden soll.

Wer die Rolle von MDR, XDR, EDR und SIEM im Sicherheitsbetrieb noch genauer einordnen möchte, findet die technologische Abgrenzung und das Zusammenspiel der Modelle hier: Vergleich MDR, XDR, EDR und SIEM – technologische Synergien.

Warum ist die Anbieter-Auswahl für Großunternehmen anspruchsvoller geworden?

Bei Großunternehmen reicht es nicht mehr, einen Provider nur nach Tool-Kompatibilität oder SOC-Verfügbarkeit zu bewerten. Die Auswahl wird heute durch fünf Faktoren komplexer:

1. Es steigen die Anforderungen an Governance, Nachvollziehbarkeit und Auditierbarkeit.
2. Security Operations müssen über mehrere Domänen hinweg funktionieren – also nicht nur auf Endpoint-, sondern auch auf Identity-, Cloud-, Netzwerk- und Log-Ebene.
3. Souveränität, Datenhaltung und regionale Betriebsfähigkeit gewinnen an Bedeutung.
4. Es wird von Providern zunehmend erwartet, dass sie KI-gestützte und perspektivisch agentische Funktionen sinnvoll in den Betrieb eingebunden werden.
5. Services müssen messbar wirksam sein.

Orange Cyberdefense positioniert sich in diesem Umfeld als intelligence-led security-Anbieter mit AI-powered Services, 3.100+ Expert:innen und einer Threat-Intelligence-Basis aus rund 500 Quellen. Das ist für die Auswahl des richtigen Anbieters hochrelevant, da es zeigt, worauf Enterprise-Unternehmen heute achten: nicht auf isolierte Technologie, sondern auf die Kombination aus Intelligence, Operations, Governance und Integrationsfähigkeit.

MDR, SIEM oder eine Kombination aus beidem? Entscheidung nach Zielbild

Wann MDR typischerweise priorisiert wird (häufig KMU/IT-Leitung/Operations)

MDR ist oft die pragmatische Wahl, wenn:

• 24/7 Reaktionsfähigkeit gefordert ist, aber intern nicht darstellbar,
• die Organisation vor allem risikorelevante Incidents sehen und behandeln will,
• Security-Rollen klar sind, aber Tiefe/Verfügbarkeit fehlt (SOC-Betrieb).

Typische Ausgangslage: „Wir wollen weniger False Positives, schnellere Einordnung und einen klar geregelten nächsten Schritt pro Incident.“

Wann SIEM typischerweise priorisiert wird (häufig stärker reguliert/Enterprise/Plattformstrategie)

SIEM wird oft priorisiert, wenn:

• viele Domänen zentral korreliert werden müssen (Identity + Cloud + Netzwerk + App),
• Retention/Forensik und Reporting tragende Anforderungen sind,
• eine Organisation Use-Case-Ownership und Betriebsprozesse intern tragen kann (oder bewusst Co-Managed betreibt).

Wann eine Kombination aus MDR und SIEM sinnvoll ist

Die Kombination aus MDR und SIEM ist sinnvoll, wenn:

• SIEM als zentrale Daten- und Korrelationsebene dient,
• MDR als Operations-Layer die Alerts/Cases in Incidents überführt und Response steuert,
• Verantwortlichkeiten sauber getrennt sind: Daten-/Use-Case-Owner vs. Incident-Owner.

Schritt-für-Schritt-Einstieg

1. Klarheit schaffen: Was genau soll geschützt werden?

Bevor man Tools ankoppelt oder Alarme baut, sollte klar sein:

• Welche Systeme sind besonders kritisch?
  Zum Beispiel: Benutzerkonten & Logins, E-Mail, ERP/Finanzen, Produktions-IT, Admin-Zugänge.
• Welche Angriffe sind für uns realistisch?
  Typischer Ablauf: Phishing-Mail → Zugangsdaten werden geklaut → Angreifer bewegt sich weiter im Netzwerk → Daten werden gestohlen oder Systeme verschlüsselt.
• Was können wir im Ernstfall organisatorisch überhaupt tun?
  Wer darf ein Gerät vom Netz nehmen? Wer informiert Management? Wer muss rechtlich eingebunden werden? Gibt es externe Hilfe?

Ergebnis: Ein kurzes Dokument mit Systemliste, Verantwortlichen, Eskalationswegen (wer wird wann informiert) und Entscheidungsregeln.

2. Datenquellen priorisieren

Mehr Daten heißt nicht automatisch bessere Sicherheit. Sinnvoll ist, zuerst die Quellen anzubinden, die echte Entscheidungen ermöglichen, beispielsweise:

• Login- und Identitätsdaten (z. B. ungewöhnliche Anmeldungen, plötzlich neue Admin-Rechte)
• Daten von Endgeräten (z. B. Verhalten auf Laptops/Servern: verdächtige Programme, ungewöhnliche Befehle; ggf. Gerät isolieren)
• E-Mail-Sicherheit (z. B. Phishing, gefälschte Absender)
• Cloud-Protokolle (z. B. Admin-Änderungen, neue Zugänge, geänderte Berechtigungen)
• Netzwerk-/DNS-Hinweise (z. B. Kontakt zu bekannten schädlichen Servern, auffällige Datenabflüsse)

Das Ziel: Erst das anbinden, womit man im Vorfall wirklich entscheiden kann: „Ist das ein echter Angriff? Was ist betroffen? Was müssen wir tun?“

3. Use Cases definieren

Ein „Use Case“ ist ein konkreter Alarm-/Erkennungsfall mit klarer Reaktion. Starten sollten Sie mit Fällen, die

• häufig vorkommen,
• großen Schaden verursachen können,
• klar behandelbar sind.

Typische Beispiele:

• Konto kompromittiert: Anzeichen, dass ein Account übernommen wurde (z. B. ungewöhnliche Logins, Hinweise auf MFA-Umgehung)
• Verdächtige Rechteänderungen: Plötzlich bekommt jemand Admin-Rechte oder Zugänge werden auffällig erweitert
• Verdächtige Befehle auf Endgeräten: typische „Angreifer-Werkzeuge“/Befehle, die selten legitim sind
• Remote-Zugriffstools/laterale Bewegung: Angreifer versucht, von einem System zum nächsten zu springen
• Auffällige Datenbewegung: ungewöhnlich viele Daten in Cloud-Speicher, Downloads, Exporte, externer Abfluss

Woran erkennt man einen guten Use Case?
Er ist so aufgebaut: Auslöser → Kontext → Entscheidung (wie kritisch?)→ Umsetzungsplan

4. Prozesse & Rollen festlegen

Viele Programme scheitern nicht am Tool, sondern daran, dass im Ernstfall niemand weiß, wer entscheiden darf. Sie sollten daher mindestens klären:

• Wer trifft die Entscheidung im Incident? (Incident Owner: Priorität, Maßnahmen, Freigaben)
• Wie laufen Eskalation und Freigaben ab? (z. B. „Darf ein Gerät sofort isoliert werden?“)
• Welche Kommunikationswege gelten verbindlich? (Ticket, Hotline, Chat – und wann welches davon)
• Welche Vorgehenspläne gibt es? (z. B. Phishing, Kontoübernahme, Malware, Datenabfluss)

Typische Fehler und wie man sie vermeidet

Scope ist unklar

Sie überwachen alle Daten gleichermaßen: ein paar Server, ein paar Logins, ein paar Tools. Es kommen Alarme rein, aber niemand weiß:

• Welche Systeme sind wirklich kritisch?
• Welche Alarme sind bei uns wirklich gefährlich?
• Welche Reaktion ist überhaupt erlaubt/gewünscht?

Beispiel:
Ein Alarm sagt „Admin-Login ungewöhnlich“. Ist das schlimm? Möglicherweise. Wenn jedoch unklar ist, welche Admin-Konten kritisch sind und wer zuständig ist, bleibt der Alarm folgenlos.

Was hilft?

1. Erst festlegen: Top-Systeme (Tier 1), z. B. Identity/AD, E-Mail, ERP, Admin-Zugänge.
2. Dann: Top-10 Alarmfälle, die Sie wirklich betreffen können.
3. Und: Reaktionsregeln (z. B. „Bei bestätigter Kontoübernahme Passwort zurücksetzen + Session beenden + MFA neu setzen“).

Zu viele Daten, zu wenig Qualität

Sie kippen alles ins System: jede Kleinigkeit von jedem Gerät und jeder App. Das führt zu:

• zu hohen Kosten (viel Datenmenge),
• zu vielen unnötigen Alarmen,
• und am Ende schaut niemand mehr richtig hin, weil das System zu häufig alarmiert.

Beispiel:
Sie sammeln Millionen Logzeilen aus einem Webserver, allerdings haben Sie keine sauberen Login-/Identity-Daten angebunden. Ergebnis: wenig echte Sicherheitsentscheidungen.

Was hilft?

• Nicht „alles“, sondern zuerst die wichtigsten Quellen: Identity (Logins), Endpoint (EDR), E-Mail, Cloud-Admin-Logs.
• Daten „anreichern“, damit man sie versteht, z. B. „Dieses Gerät gehört zur Buchhaltung“, „dieser User ist Admin“, „dieser Server ist Tier 1“.
• Rauschen reduzieren: unwichtige Logs rausfiltern, doppelte Events vermeiden, klare Regeln, welche Daten wirklich gebraucht werden.

Use Cases ohne Vorgehensplan

Alarme sind da, allerdings weiß keiner:

• Ist das wirklich gefährlich oder nur ein Fehlalarm?
• Was müssen wir jetzt tun?
• Wer entscheidet das?

Beispiel:
Alarm: „Verdächtige PowerShell-Aktivität“.
Ohne konkreten Plan weiß niemand, ob isolieren, prüfen oder ignorieren.

Was hilft?
Für jeden wichtigen Alarmfall braucht es 4 Punkte:

1. Auslöser: Was genau löst den Alarm aus?
2. Kontext: Was macht ihn bei uns gefährlich? (z. B. Admin-User, Tier-1-System)
3. Entscheidung: Wann ist es kritisch?
4. Maßnahmenplan: Was passiert dann Schritt für Schritt?

Das Ergebnis: Jeder Alarm führt zu einer klaren Entscheidung.

Keine Zuständigkeiten

Das System läuft, langfristig wird es jedoch schlechter, da:

• Regeln nicht gepflegt werden,
• neue Systeme nicht sauber angebunden werden,
• im Ernstfall niemand schnell entscheidet.

Beispiel:
Ein neuer Cloud-Dienst wird eingeführt, allerdings sorgt niemand dafür, dass Logs angebunden werden. Oder: Es gibt wiederholt Fehlalarme, doch niemand fühlt sich verantwortlich, die Regel zu verbessern.

Was hilft konkret?
Einfache Rollenaufteilung für KMU und Enterprise-Unternehmen:

• Daten-Verantwortliche(r): sorgt dafür, dass die richtigen Datenquellen angebunden sind und sauber laufen.
• Alarm-/Use-Case-Verantwortliche(r): kümmert sich darum, dass Alarme sinnvoll sind (weniger Fehlalarme, bessere Qualität).
• Incident-Verantwortliche(r): entscheidet im Vorfall (Priorität, Maßnahmen, Eskalation).
• Service-Partner (z. B. MDR): macht Überwachung, Analyse, unterstützt bei Investigation und ggf. Response.

Das Ergebnis: Der Betrieb bleibt stabil.

Merksatz für Einsteiger

Die häufigsten Probleme sind:

1. Wir wissen nicht, was wichtig ist (Scope).
2. Wir sammeln zu viel Unnötiges (Datenrauschen).
3. Wir haben keinen festen Plan (Vorgehen).
4. Keiner ist wirklich zuständig (Ownership).