Was ein MDR-Service leistet, wo die Grenze zu EDR, SIEM und SOC verläuft und worauf es bei der Anbieterauswahl ankommt.
Managed Detection and Response ist ein ausgelagerter Sicherheitsdienst, bei dem ein externer Anbieter die IT-Umgebung eines Unternehmens rund um die Uhr überwacht, verdächtige Aktivität analysiert und im Ernstfall aktiv eingreift. Der Anbieter stellt dafür Technologie, Analysten und definierte Abläufe bereit.
Für viele mittelständische Unternehmen wird das Thema gerade aus einem sehr praktischen Grund relevant: Die Werkzeuge sind vorhanden, die Alarme laufen auf, aber es fehlt das Personal, das sie nachts um drei bewertet. Dazu kommen Anforderungen aus NIS2 und von Cyberversicherern, die inzwischen ausdrücklich nach einer funktionierenden Angriffserkennung fragen. Dieser Leitfaden ordnet ein, was ein MDR-Service leistet, wo er sich von EDR, SIEM, SOC und MSSP unterscheidet, was er kostet und welche Verantwortung im eigenen Haus bleibt.
Managed Detection and Response beschreibt einen Managed Service, der drei Dinge zusammenbringt: eine Erkennungstechnologie auf Endpoints, im Netzwerk und in der Cloud, ein Team aus Security-Analysten, das die erzeugten Signale bewertet, und vereinbarte Prozesse, die festlegen, was nach einer Erkennung passiert.
MDR steht für Managed Detection and Response, auf Deutsch etwa „verwaltete Erkennung und Reaktion“. Die Betonung liegt auf dem zweiten Teil. Reine Erkennung liefern auch Werkzeuge, die ein Unternehmen selbst betreibt. Der Zusatz „Response“ beschreibt, dass der Anbieter im vereinbarten Rahmen auch handelt: ein kompromittiertes Gerät isolieren, einen Prozess beenden, ein Konto sperren, eine Eskalation auslösen.
Die Abkürzung ist doppelt belegt. In der Medizintechnik bezeichnet MDR die EU-Medizinprodukteverordnung (Medical Device Regulation, Verordnung (EU) 2017/745). Im Rundfunkkontext steht MDR für den Mitteldeutschen Rundfunk. Dieser Artikel behandelt ausschließlich die IT-Security-Bedeutung.
Kontext prüfen.
Wer in Ausschreibungen, Angeboten oder Audits auf den Begriff stößt, sollte den Kontext kurz prüfen, weil sich die Anforderungen fundamental unterscheiden.
Sensoren auf Endpoints (EDR), Auswertung von Netzwerk- und Cloud-Telemetrie, oft ergänzt um Log-Quellen aus Identitätssystemen, Firewalls und Kollaborationsplattformen. Manche Anbieter bringen eine eigene Plattform mit, andere arbeiten auf der Technologie, die bereits im Unternehmen läuft.
Analysten, die Signale bewerten und den Unterschied zwischen einem ungewöhnlichen, aber legitimen Vorgang und einem echten Angriffsversuch einordnen. Diese Bewertung ist der Teil, der sich am schwersten automatisieren lässt und der im eigenen Haus am meisten Personal binden würde.
Wer wird wann informiert, wer darf welche Maßnahme auslösen, was passiert außerhalb der Geschäftszeiten, wie wird ein Vorfall dokumentiert und abgeschlossen. Dieser Teil wird bei der Anbieterauswahl oft unterschätzt und entscheidet später darüber, ob ein Alarm zu einer Reaktion führt.
Der Ablauf lässt sich in vier Schritten beschreiben. In der Praxis laufen sie parallel und kontinuierlich.
Der Anbieter sammelt Telemetrie aus den vereinbarten Quellen. Typisch sind Endpoint-Agents, Firewall- und Proxy-Logs, Identitäts- und Anmeldedaten sowie Cloud-Audit-Logs aus Microsoft 365 oder Azure. Der Umfang der angebundenen Quellen bestimmt, welche Angriffswege überhaupt sichtbar werden. Ein Angriff, der ausschließlich über eine nicht angebundene Anwendung läuft, bleibt auch bei bestem Service unsichtbar.
Die gesammelten Daten laufen gegen Erkennungsregeln, Verhaltensmodelle und Threat Intelligence. Diesen Auswertungsteil führen viele Anbieter unter dem Begriff Security Analytics. Hier entsteht der größte Teil der Signale: ungewöhnliche Anmeldezeiten, ein PowerShell-Aufruf mit auffälligen Parametern, ein Dienstkonto, das plötzlich auf Dateifreigaben zugreift, für die es bisher keine Verwendung hatte.
Interessant wird es meist erst in der Kombination. Ein typisches Frühzeichen für einen Ransomware-Verlauf besteht aus mehreren unauffälligen Einzelereignissen: ein frisch angelegtes Konto mit erhöhten Rechten, das Löschen von Schattenkopien und kurz darauf ein breiter Zugriff auf Dateifreigaben. Jedes Signal für sich lässt sich erklären; zusammen ergeben sie ein Muster, das eine Reaktion rechtfertigt.
Aus vielen hundert Signalen pro Tag werden wenige Vorfälle, die eine Reaktion erfordern. Diese Filterung ist der eigentliche Wert des Service. Ein Team, das die Umgebung kennt, erkennt schneller, ob ein Muster zum normalen Betrieb gehört. In der Praxis zeigt sich hier auch, wie eng Anbieter und internes Team zusammenarbeiten: Je besser der Anbieter weiß, welche Wartungsfenster, Software-Rollouts und Sonderfälle es gibt, desto weniger Fehlalarme landen beim Kunden.
Bestätigt sich ein Vorfall, greifen die vereinbarten Maßnahmen. Je nach Vertrag reicht das von einer Benachrichtigung mit Handlungsempfehlung bis zur aktiven Eindämmung durch den Anbieter: Endpoint isolieren, Session beenden, Konto sperren, Regel ausrollen. Danach folgen Ursachenanalyse, Dokumentation und die Frage, welche Lücke den Vorfall überhaupt möglich gemacht hat.
Genau an dieser Stelle entscheidet sich, ob ein MDR-Service Wirkung entfaltet.
Ein Alarm, der um 02:40 Uhr korrekt erkannt und weitergeleitet wird, hilft wenig, wenn im Unternehmen niemand definiert hat, wer ihn entgegennimmt und wer über eine Eskalation entscheidet.
Diese Zuständigkeiten sollten vor dem Onboarding geklärt sein, nicht während des ersten Ernstfalls.
Der Leistungsumfang unterscheidet sich zwischen Anbietern deutlich. Die folgenden Bausteine finden sich in den meisten Angeboten.
Durchgehende Überwachung der angebundenen Systeme, inklusive Nächte, Wochenenden und Feiertage. Das ist der Kern des Angebots und für die meisten Unternehmen der Hauptgrund, überhaupt über MDR nachzudenken. Angriffe richten sich bewusst nach Zeitfenstern, in denen intern niemand hinschaut.
Die aktive Suche nach Angreifern, die durch die automatisierte Erkennung gerutscht sind. Analysten arbeiten dabei mit Hypothesen: Welche Spuren würde ein bestimmtes Angriffsmuster hinterlassen, und finden sich diese Spuren in der Umgebung?
Praktisch relevant wird das bei Zero-Day-Angriffen. Für eine noch unbekannte Schwachstelle gibt es keine Signatur, auf die eine Erkennungsregel anspringen könnte. Sichtbar wird stattdessen das Verhalten danach: ein Prozess, der Dinge tut, die er in dieser Umgebung noch nie getan hat. Threat Hunting ist bei vielen Anbietern ein Aufpreis- oder Premium-Baustein und sollte im Angebot ausdrücklich benannt sein.
Regelmäßige Berichte über erkannte Vorfälle, Reaktionszeiten, Trends und offene Empfehlungen. Für Audits, Versicherungsgespräche und die Geschäftsführung ist dieser Teil oft wichtiger als die technischen Details. Prüfen Sie, ob die Berichte auch ohne Anbieter-Portal exportierbar sind und ob sie die Kennzahlen enthalten, die Ihre Prüfer tatsächlich sehen wollen.
Nicht enthalten sind in der Regel Schwachstellen- und Patch-Management, forensische Tiefenanalysen nach größeren Vorfällen, die Umsetzung von Härtungsmaßnahmen, Awareness-Schulungen und der Betrieb der eigentlichen IT-Infrastruktur.
Was intern bleibt.
Auch die Entscheidung, welche Risiken das Unternehmen akzeptiert und welche Systeme im Notfall abgeschaltet werden dürfen, bleibt im eigenen Haus.
Die Begriffe überschneiden sich, weil sie unterschiedliche Ebenen beschreiben. EDR, XDR, NDR und SIEM sind Technologien. SOC beschreibt eine Organisationsform. MDR und MSSP sind Dienstleistungsmodelle.
EDR (Endpoint Detection and Response) ist die Software auf dem Endgerät, die verdächtiges Verhalten erkennt und Eingriffe ermöglicht. Sie liefert Daten und Werkzeuge, aber niemanden, der sie bedient. MDR nutzt EDR häufig als eine seiner Datenquellen und ergänzt das Team, das damit arbeitet. Wer eine EDR-Lösung lizenziert hat, aber keine Kapazität für die Auswertung, hat genau die Lücke, die MDR schließen soll.
XDR (Extended Detection and Response) erweitert den EDR-Ansatz auf Netzwerk, Cloud, E-Mail und Identitäten und korreliert die Signale über diese Ebenen hinweg. Auch XDR bleibt zunächst eine Plattform. Wird sie als Service mit Analystenteam betrieben, sprechen einige Anbieter von Managed XDR oder MXDR. Praktisch ist das eine MDR-Variante mit breiterer Datenbasis. Die Bezeichnungen sind nicht standardisiert, deshalb lohnt im Angebot der Blick auf die konkret angebundenen Datenquellen statt auf das Kürzel.
Ein SIEM sammelt und korreliert Logs aus vielen Quellen und ist damit die klassische Grundlage für Angriffserkennung und Compliance-Nachweise. Der Betrieb bindet allerdings Aufwand: Anbindung neuer Quellen, Pflege der Regeln, Umgang mit Fehlalarmen. Ein SIEM allein erzeugt Sichtbarkeit; ob daraus Reaktion wird, hängt am Team dahinter. Viele MDR-Anbieter betreiben im Hintergrund ein SIEM oder binden ein bestehendes an. Wer bereits ein SIEM im Einsatz hat, sollte im Auswahlgespräch klären, ob es weitergenutzt oder abgelöst wird. Hintergründe dazu im Beitrag Wozu braucht man ein SIEM?
Ein Security Operations Center ist die organisatorische Einheit, in der Erkennung, Analyse und Reaktion zusammenlaufen. Es kann intern aufgebaut oder eingekauft werden. SOC as a Service beschreibt üblicherweise den eingekauften Betrieb dieser Einheit, häufig mit Schwerpunkt auf Monitoring und Analyse. Im deutschsprachigen Raum begegnet Ihnen dieselbe Einheit gelegentlich als Cyber Defense Center (CDC) oder als Managed Cyber Defense — die Bezeichnungen meinen im Kern dasselbe, setzen den Schwerpunkt aber teils stärker auf Threat Intelligence und aktive Abwehr. MDR-Angebote sind meist enger geschnitten, dafür stärker auf definierte Reaktionsmaßnahmen ausgerichtet. Die Grenze verläuft in der Praxis fließend, und die Bezeichnung sagt weniger über den Leistungsumfang aus als die Liste der vereinbarten Maßnahmen.
Ein Managed Security Service Provider betreibt Sicherheitskomponenten im Auftrag des Kunden: Firewalls, Gateways, VPN, teils auch Endpoint-Lösungen. Der Schwerpunkt liegt auf Verfügbarkeit und Konfiguration. MDR setzt eine Ebene darüber an und konzentriert sich auf Erkennung und Reaktion. Viele MSSP haben ihr Portfolio inzwischen um MDR-Bausteine erweitert, sodass beide Modelle beim selben Anbieter zusammenlaufen können.
| Modell | Was Sie bekommen | Eigenes Personal nötig | 24/7 abgedeckt | Reaktion enthalten | Passt, wenn … |
|---|---|---|---|---|---|
| EDR | Software auf dem Endpoint | Ja, für Auswertung und Reaktion | Nur mit eigenem Team | Werkzeuge ja, Bedienung nein | ein Team vorhanden ist, das Alarme bewertet |
| XDR | Plattform über Endpoint, Netzwerk, Cloud, Identität | Ja | Nur mit eigenem Team | Werkzeuge ja, Bedienung nein | mehrere Ebenen korreliert werden sollen |
| SIEM | Log-Sammlung, Korrelation, Compliance-Basis | Ja, inklusive Regelpflege | Nur mit eigenem Team | Nein | Nachweise und breite Log-Auswertung im Vordergrund stehen |
| Managed SIEM | SIEM-Betrieb durch Dienstleister | Reduziert | Je nach Vertrag | Meist nein | ein SIEM gebraucht wird, aber die Pflege intern fehlt |
| SOC as a Service | Eingekaufter SOC-Betrieb, Monitoring und Analyse | Ansprechpartner intern | In der Regel ja | Je nach Vertrag | breite Security-Operations-Abdeckung gesucht wird |
| MDR | Technologie, Analystenteam und definierte Reaktion | Ansprechpartner und Entscheider intern | In der Regel ja | Ja, im vereinbarten Rahmen | Erkennung besteht, aber niemand darauf reagieren kann |
| MSSP | Betrieb von Security-Komponenten | Reduziert | Je nach Vertrag | Meist nur für betreute Komponenten | Firewalls, Gateways und Co. ausgelagert werden sollen |
In der Beratungspraxis tauchen einige Ausgangslagen immer wieder auf:
Ein eigenes SOC ist keine Voraussetzung. Der Service ist gerade für Unternehmen gedacht, die kein rund um die Uhr besetztes Team aufbauen können. Was intern trotzdem gebraucht wird: eine benannte Ansprechperson mit Vertretungsregelung, Entscheidungsbefugnis für Eskalationen, aktuelle Dokumentation der Systemlandschaft und die Bereitschaft, auf Empfehlungen des Anbieters auch zu reagieren. Ohne diese Gegenstelle bleibt der Service unter seinen Möglichkeiten.
Im Gesundheitswesen treffen sensible Daten, hohe Verfügbarkeitsanforderungen und regulatorischer Druck aufeinander; Kliniken oberhalb bestimmter Schwellenwerte fallen zusätzlich unter KRITIS-Vorgaben. In der Produktion kommt die OT-Seite hinzu, wo klassische Endpoint-Agents oft nicht installiert werden können und die Erkennung über Netzwerk-Telemetrie laufen muss. Kommunen und Stadtwerke stehen unter ähnlichem Druck bei meist knapper Personaldecke. Finanzdienstleister bringen eigene aufsichtsrechtliche Anforderungen an Auslagerungen mit, die vor Vertragsabschluss geprüft werden sollten.
Für viele Unternehmen ist Regulatorik der konkrete Anlass, sich mit MDR zu beschäftigen.
Die Richtlinie und ihre nationale Umsetzung verlangen von betroffenen Einrichtungen unter anderem Maßnahmen zur Erkennung und Behandlung von Sicherheitsvorfällen sowie Meldewege mit kurzen Fristen. Ein MDR-Service kann diese Anforderungen unterstützen, indem er Erkennung, Bewertung und Dokumentation bereitstellt. Die Verantwortung für die Meldung und für die Steuerung des Dienstleisters bleibt beim Unternehmen. Ob Ihr Unternehmen überhaupt betroffen ist, klärt das BSI in seiner Übersicht für NIS-2-regulierte Unternehmen; die praktische Einordnung liefert der Beitrag NIS2 für Industrie und KMU.
Die Norm fordert Protokollierung, Überwachung und einen Prozess für Informationssicherheitsvorfälle. MDR-Reporting liefert dafür Belege, ersetzt aber weder die Risikobewertung noch das Managementsystem.
Betreiber kritischer Anlagen müssen Systeme zur Angriffserkennung einsetzen und deren Wirksamkeit nachweisen. Hier ist besonders wichtig, welche Systeme tatsächlich angebunden sind und ob die Nachweise die geforderte Form haben. Welche Sektoren und Schwellenwerte gelten, führt das BSI auf seiner Seite zu Kritischen Infrastrukturen.
Versicherer fragen in Anträgen inzwischen regelmäßig nach Endpoint-Erkennung, Reaktionsfähigkeit außerhalb der Geschäftszeiten und Protokollierung. Ein MDR-Vertrag kann diese Fragen belegbar beantworten. Welche Schäden abgedeckt sind und welche nicht, zeigt der Beitrag Cyberversicherung für KMU.
Ein Dienstleister kann Aufgaben und Nachtschichten übernehmen. Die Pflicht, Risiken zu bewerten, Maßnahmen freizugeben und im Ernstfall zu melden, lässt sich nicht mit auslagern.
Vor Vertragsabschluss prüfen.
Bei Auslagerungen im regulierten Umfeld gehört die Prüfung des Vertrags zur Vorbereitung.
Belastbare Listenpreise gibt es kaum, weil der Preis stark von Umfang und Umgebung abhängt. Verständlich wird die Kalkulation über die Preismodelle und die Kostentreiber.
Das verbreitetste Modell. Gut planbar, solange die Zahl der Geräte stabil bleibt. Achten Sie darauf, ob Server, virtuelle Maschinen und mobile Geräte gleich gezählt werden.
Sinnvoll in Umgebungen mit vielen Geräten pro Person. Der Vergleich mit Endpoint-Preisen erfordert eine Umrechnung auf die eigene Geräte-pro-Nutzer-Quote.
Üblich bei SIEM-basierten Angeboten. Der Preis skaliert mit der Menge eingespeister Logs, was bei neuen Datenquellen zu unerwarteten Sprüngen führen kann. Lassen Sie sich zeigen, wie das Volumen gemessen wird und was bei Überschreitung passiert.
Basis-Monitoring, erweiterte Reaktion, Threat Hunting und Incident Response als getrennte Stufen. Hier lohnt der genaue Blick, welche Reaktionsmaßnahmen im gebuchten Paket wirklich enthalten sind.
Die Rechnung wird oft zu eng geführt. Rechnen Sie sie einmal von der Arbeitszeit her: Eine Woche hat 168 Stunden. Bei einer 40-Stunden-Woche sind das rechnerisch 4,2 Vollzeitstellen, um einen einzigen Platz durchgehend zu besetzen. Mit Urlaub, Krankheit, Fortbildung und Übergabezeiten landen Schichtplaner in der Praxis eher bei fünf bis sechs Personen — und das für eine Position, nicht für ein Team. Dazu kommen Werkzeuge, Weiterbildung und Recruiting in einem Markt, in dem Security-Analysten schwer zu bekommen sind. Für die meisten Unternehmen unterhalb einiger tausend Mitarbeitender liegt der Aufwand deutlich über einem eingekauften Service. Ab einer bestimmten Größe kehrt sich das Verhältnis um, oft in Kombination mit einem hybriden Modell, bei dem der eigene Tagesbetrieb intern läuft und der Anbieter die Randzeiten abdeckt.
Ein SLA sollte zwischen Zeit bis zur ersten Sichtung, Zeit bis zur Bewertung und Zeit bis zur Eindämmung unterscheiden. Eine pauschale Zusage „Reaktion innerhalb von 15 Minuten“ sagt wenig, wenn offen bleibt, worauf sich die Angabe bezieht. Ebenso wichtig: Welche Maßnahmen darf der Anbieter eigenständig ergreifen, welche brauchen eine Freigabe, und wer erteilt sie außerhalb der Geschäftszeiten?
Wo werden Telemetriedaten verarbeitet und gespeichert? Gibt es einen Auftragsverarbeitungsvertrag? Sitzt das Analystenteam im deutschsprachigen Raum, und in welcher Sprache kommen Meldungen und Berichte? Für Unternehmen mit Betriebsrat lohnt der frühe Blick darauf, welche Daten überhaupt erfasst werden.
Manche Anbieter setzen ihre eigene Plattform voraus, andere arbeiten auf vorhandenen Lösungen. Die erste Variante ist oft schneller produktiv, bindet aber an den Anbieter. Die zweite schützt bestehende Investitionen, verlangt dafür mehr Abstimmung. Klären Sie außerdem, wem die erhobenen Daten gehören und in welcher Form Sie sie beim Wechsel mitnehmen können.
Die zehn Fragen oben plus zehn weitere zu Datenschutz, Nachweisen und Ausstiegsbedingungen — als PDF zum Mitnehmen ins Auswahlgespräch, mit Hinweisen, worauf eine gute Antwort hindeutet.
Am Anfang steht die Bestandsaufnahme: Welche Systeme gibt es, welche Datenquellen lassen sich anbinden, wo liegen die kritischen Prozesse. Danach folgt der Rollout der Sensoren, meist in Wellen über einzelne Standorte oder Abteilungen. Es schließt sich eine Tuning-Phase an, in der Fehlalarme reduziert und Ausnahmen dokumentiert werden; diese Phase braucht Mitarbeit aus der eigenen IT und wird häufig zu knapp geplant. Am Ende stehen der Test der Eskalationswege und die Abnahme der Berichte. Von der Vertragsunterschrift bis zum stabilen Regelbetrieb sollten Sie je nach Umgebungsgröße mit einigen Wochen bis wenigen Monaten rechnen.
Wer den Markt sondieren möchte: Auf it-dock.de finden Sie eine Übersicht der IT-Dienstleister mit Schwerpunkt Managed Detection & Response sowie Anbieter für Managed SOC.
MDR schließt die Lücke zwischen einer Erkennung, die technisch funktioniert, und einer Reaktion, für die intern Personal und Zeit fehlen. Für Unternehmen mit kleinem IT-Team, regulatorischem Druck oder unbesetzten Randzeiten ist das ein belastbarer Weg, Sicherheitsniveau aufzubauen, ohne ein eigenes Schichtmodell zu finanzieren.
Der Service wirkt allerdings nur so gut, wie die eigene Gegenstelle organisiert ist. Vor der Anbieterauswahl sollten die Fragen geklärt sein, wer Meldungen entgegennimmt, wer eskaliert und welche Maßnahmen der Anbieter eigenständig ergreifen darf. Wer diese Punkte vorbereitet und die Angebote entlang fester Kriterien vergleicht, trifft eine Entscheidung, die auch im Ernstfall trägt.
MDR steht für Managed Detection and Response. Ein externer Anbieter überwacht die IT-Umgebung rund um die Uhr, bewertet verdächtige Aktivität durch Security-Analysten und ergreift im vereinbarten Rahmen Maßnahmen zur Eindämmung. Technologie, Personal und Prozesse kommen dabei aus einer Hand.
Managed Detection and Response, auf Deutsch etwa verwaltete Erkennung und Reaktion. Achtung: In der Medizintechnik steht dieselbe Abkürzung für die EU-Medizinprodukteverordnung.
Ein Security Operations Center ist die organisatorische Einheit, in der Sicherheitsmeldungen zusammenlaufen, bewertet und bearbeitet werden. Es kann intern betrieben oder als Service eingekauft werden. MDR ist eine mögliche Form, SOC-Leistungen einzukaufen.
Ein Security Information and Event Management sammelt Logdaten aus vielen Systemen, normalisiert sie und korreliert sie zu Sicherheitsmeldungen. Es liefert Sichtbarkeit und Nachweise, benötigt aber ein Team für Regelpflege und Bewertung.
Sammelbegriff für Sicherheitsleistungen, die ein externer Dienstleister betreibt: vom Firewall-Management über Schwachstellenscans bis zu Monitoring und Reaktion. MDR ist eine spezialisierte Ausprägung mit Fokus auf Erkennung und Reaktion.
Die kontinuierliche Überwachung von Systemen, Netzwerken und Konten auf sicherheitsrelevante Ereignisse. Security Monitoring ist Teil eines MDR-Service, endet dort aber nicht bei der Meldung.
Gemeint sind meist die Voraussetzungen auf Kundenseite: anbindbare Datenquellen, dokumentierte Systemlandschaft, benannte Ansprechpartner mit Entscheidungsbefugnis, geklärte Eskalationswege und die Freigabe, welche Maßnahmen der Anbieter eigenständig ausführen darf.
Ein SIEM liefert Daten und Korrelation. Wenn niemand die Meldungen rund um die Uhr bewertet und darauf reagiert, bleibt die Lücke bestehen. Manche Anbieter binden ein vorhandenes SIEM an, andere ersetzen es. Diese Frage gehört in das erste Auswahlgespräch.
Ein MSSP betreibt Sicherheitskomponenten wie Firewalls und Gateways und sorgt für deren Verfügbarkeit und Konfiguration. MDR konzentriert sich auf das Erkennen von Angriffen und die Reaktion darauf. Viele Anbieter kombinieren inzwischen beides.
Eine allgemeingültige Antwort gibt es nicht, weil Umgebung, Branche, Compliance-Lage und vorhandene Technologie den Ausschlag geben. Sinnvoller als eine Rangliste ist ein Kriterienvergleich: Datenquellen, Reaktionsmaßnahmen, SLA-Definition, Datenstandort, Reporting und Ausstiegsbedingungen.
Die Frage taucht regelmäßig im Zusammenhang mit der Make-or-Buy-Entscheidung auf. Aussagekräftig ist weniger das Einzelgehalt als die Gesamtrechnung: Für eine durchgehende Besetzung rund um die Uhr sind mehrere Stellen im Schichtbetrieb plus Vertretung nötig, dazu Werkzeuge und Weiterbildung.
Ein Beispiel für ein herstellergebundenes MDR-Angebot. Vergleichbare Services bieten unter anderem CrowdStrike, SentinelOne und Microsoft an, dazu zahlreiche Systemhäuser und MSSP mit eigenen oder kombinierten Plattformen. Der Leistungsumfang unterscheidet sich, weshalb sich der Vergleich anhand fester Kriterien lohnt.
EDR überwacht Endgeräte, XDR erweitert das Prinzip auf Netzwerk, Identitäten und Cloud. Was die Technik erkennt – und was Ihre Organisation damit anfangen kann.
Smishing ist Phishing per SMS. Angreifer verschicken Textnachrichten im Namen eines vertrauenswürdigen Absenders — Paketdienst, Bank, Behörde, Vorgesetzte.
Was ist Whaling? Wie diese gezielte Phishing-Attacke auf Führungskräfte funktioniert, woran Sie sie erkennen und wie Sie Ihr Unternehmen schützen.
CEO Fraud (Fake President): Wie die Betrugsmasche funktioniert, woran Sie sie erkennen und wie Sie Ihr Unternehmen wirksam davor schützen.
Vishing erklärt: So funktioniert Voice Phishing, so erkennen Sie betrügerische Anrufe – und das hilft nach einem Telefonbetrug. Mit Beispielen & FAQ.
Data Masking (deutsch: Datenmaskierung) sorgt dafür, dass aus echten personenbezogenen Daten realistische, aber nutzlose Platzhalter werden – ohne dass Tests, Reports oder Schulungen ihren Wert verlieren.
NIS2 ist jetzt relevant, weil die Richtlinie Cybersicherheit erstmals verbindlich und überprüfbar macht – mit Haftung, Meldepflichten und klaren technischen Vorgaben.
Alles über Spear-Phishing. Definition, Unterschied zu Phishing und wie sich Unternehmen schützen können.
Safety vs. Security Definitionen, Fail-Safe vs. Fail-Secure, Praxiskonflikte in OT & IT & warum beides zusammengehört
Definition, Bedrohung durch Store now, decrypt later, PQC-Standards (NIST 2024).
Informiert bleiben
Erhalten Sie wöchentlich die wichtigsten Tech-Trends, exklusive Analysen und Experteninterviews – speziell für IT-Entscheider.
Kommentare (0)
Noch keine Kommentare vorhanden.