Managed Security Operations Center (SOC) für Microsoft 365 und Azure
REGULATORISCHER KONTEXT
NIS2 gilt - Monitoring ist keine Option mehr
Seit Dezember 2025 verpflichtet das NIS2-Umsetzungsgesetz mehr als 30.000 Unternehmen in Deutschland zu aktivem Sicherheitsmonitoring. Die Anforderungen sind sofort wirksam: dokumentierte Erkennung von Sicherheitsvorfällen, definierte Reaktionsprozesse und nachweisbare Meldeverfahren. Unternehmen, die keinen aktiven Monitoring-Prozess nachweisen können, riskieren regulatorische Konsequenzen und in vielen Fallen die persönliche Haftung der Geschäftsführung.
Ein eigenes SOC aufzubauen, das diese Anforderungen erfüllt, erfordert erhebliche Investitionen in Personal, Technologie und Prozessentwicklung. Für die meisten Organisationen mit Microsoft-365- und Azure-Umgebungen ist ein Managed-SOC-Modell, das direkt in den bestehenden Microsoft-Stack integriert ist, der schnellere und zuverlässigere Weg.
Zentrale Komponenten
24/7 Monitoring & Incident Response – ohne Vendor Lock-in
Ein SOC ist nur dann sinnvoll, wenn es im realen Betrieb funktioniert: klare Eskalationswege, saubere Zuständigkeiten, belastbare Use Cases und nachvollziehbare Entscheidungen, auch nachts und am Wochenende.
24/7 Investigation & Triage
Qualifizierte Analyse sicherheitsrelevanter Ereignisse. Klare Einordnung nach Kritikalität und Eskalation an definierte Bereitschaften.
Incident Response (IR)
Technisch eingebettet in Microsoft Defender & Sentinel. Containment-orientierte Sofortmaßnahmen mit wiederholbaren Playbooks statt Ad-hoc-Aktionismus.
Threat Intelligence & Hunting
Proaktive Suche nach neuen Angriffstechniken. Threat-Intel-gestützte Priorisierung mit Purple-Team-Validierung.
Detection Engineering
Pflege und Weiterentwicklung von Detection-Use-Cases & SOAR-Playbooks.
SO STARTEN WIR:
Vom ersten Gespräch bis zum aktiven Monitoring in drei Schritten
Schritt 1:
SOC Readiness Assessment
Wir analysieren Ihre Microsoft-Umgebung: Welche Log-Quellen sind relevant?
Welche Use Cases passen zu Ihrem Bedrohungsprofil? Welche Eskalationswege gibt es in Ihrer Organisation tatsächlich?
Dieses Assessment bildet die Grundlage für alle folgenden Konfigurationsentscheidungen.
Schritt 2: Detection Engineering & On boarding
Wir konfigurieren Microsoft Sentinel und Defender XDR entsprechend der im Assessment identifizierten UseCases. Detection Rules, SOAR-Playbooks und Eskalationsverfahren werden dokumentiert und direkt in Ihrem Tenant aktiviert, nicht auf einer externen Plattform.
Schritt 3: Managed Operations
Ihre Umgebung wird 24/7 überwacht. Das SOC-Team untersucht Alerts, klassifiziert Vorfälle nach Schweregrad und reagiert gemäß den definierten Playbooks. Regelmäßiges Reporting gibt Ihnen vollständige Transparenz über Sicherheitsereignisse, ergriffene Massnahmen und offene Empfehlungen.
OHNE VENDOR LOCK-IN
Administrativer Zugriff nach Schutzbedarf
Datenhoheit bei Ihnen
Logs, Workspaces, Entscheidungen liegen in Ihrer Umgebung
Übernahmefähige Inhalte
Use Cases, Playbooks und Eskalationspfade sind dokumentiert und übergabefähig
Transitions eingeplant
Provider-Wechsel, Inhouse-Aufbau oder Parallelbetrieb sind Teil des Modells, nicht Ausnahme
Unternhemen die uns vertrauen:
Whitepaper
DETECTION-HOHEIT STATT ANBIETER-ABHÄNGIGKEIT.
Welche fünf Fallen bei der Wahl eines SOC-Dienstleisters entstehen und welche Vertragsklauseln Kontrolle sichern oder abgeben. Für CISOs und IT-Leiter, die externes Monitoring evaluieren oder bestehende Verträge prüfen.
Häufig gestellte Fragen
FAQ
Was passiert, wenn wir den SOC später intern aufbauen wollen?
Dann übergeben wir Ihnen alle Playbooks, Detection-Regeln und Dokumentationen in Ihrem Sentinel/Defender-Tenant; Ihre Daten bleiben sowieso in Ihrer Umgebung. Ein strukturierter Ausstieg ist bei uns kein Verhandlungsthema, sondern Teil des Betriebsmodells – wir wollen nicht dasselbe Vendor-Lock-in-Risiko reproduzieren, vor dem wir Sie warnen.
Wie unterscheidet sich das von einem klassischen MSSP?
Klassische MSSPs nehmen Ihre Logs in ihre proprietäre Plattform auf und liefern Tickets aus – bei uns bleiben Datenhoheit und Architekturentscheidungen bei Ihnen, wir betreiben Ihren Microsoft-Stack direkt in Ihrem Tenant. Der Unterschied ist die Transparenz: Sie sehen jederzeit, welche Use Cases aktiv sind, wie entschieden wurde und welche Schritte notwendig waren, statt Black-Box-Alarme zu erhalten.
Brauchen wir dafür ein neues SOC oder funktioniert das mit unserem bestehenden?
Integration möglich, Fokus auf Use Cases & Eskalationswege
Welche Microsoft-Lizenzen sind für ein Managed SOC erforderlich?
Das Kernangebot setzt Microsoft Defender XDR (in Microsoft 365 E5 enthalten oder als Add-on erhaltlich) und Microsoft Sentinel (nutzungsbasierte Lizenzierung über Azure) voraus. Je nach Umgebung kommen Defender for Identity, Defender for Endpoint und Entra ID P2 hinzu. Wir prüfen Ihre aktuelle Lizenzposition im Rahmen des Readiness Assessments und identifizieren mögliche Lücken, bevor das Onboarding beginnt.
Was ist der Unterschied zwischen SOC, SIEM und MDR?
Ein SIEM (Security Information and Event Management) ist ein Softwaresystem, das sicherheitsrelevante Daten aus Ihrer gesamten Umgebung sammelt und analysiert. Ein SOC (Security Operations Center) ist das Analysten-Team, das das SIEM rund um die Uhr betreibt, Alerts bewertet und auf Vorfälle reagiert. MDR (Managed Detection and Response) beschreibt das ausgelagerte Servicemodell, bei dem ein externer Anbieter Erkennung und Reaktion übernimmt. Ein Managed SOC kombiniert alle drei Elemente: SIEM-Technologie, Analysten-Team und MDR-Servicemodell aus einer Hand, integriert direkt in Ihren Microsoft-Tenant.
Funktioniert das nur mit Microsoft Defender/Sentinel oder auch mit anderen Tools?
Unser Fokus liegt auf der Microsoft Security Plattform (Defender XDR, Sentinel, Entra), weil hier die tiefste Integration und beste API-Anbindung für echtes Response existiert – wir sind kein "alle Tools können wir"-Generalist. Wenn Sie jedoch zusätzliche Spezialtools (z.B. für OT, spezifische Cloud-Workloads) sinnvoll integriert haben, binden wir diese in die Detection-Logik und die Incident-Response-Prozesse mit ein.
Wie erfüllt das cycura-SOC die NIS2-Meldepflichten?
NIS2 verpflichtet Unternehmen, die zuständige Behörde innerhalb von 24 Stunden nach Bekanntwerden eines erheblichen Vorfalls zu benachrichtigen und innerhalb von 72 Stunden einen detaillierten Bericht einzureichen. Unser SOC liefert die Erkennungsfähigkeit, Vorfallsklassifizierung und Dokumentation, die für diese Fristen notwendig sind. Das monatliche Reporting schafft eine auditierbare Grundlage für regulatorisches und Management-Reporting.
Was passiert während eines aktiven Sicherheitsvorfalls?
Bei einem bestätigten Vorfall folgt die Reaktion einem dokumentierten Playbook: initiales Triage und Schweregrad-Klassifizierung, Containment-Massnahmen direkt in Ihrer Microsoft-Umgebung (Isolation, Kontosperrung, Policy-Durchsetzung), Benachrichtigung Ihres definierten On-Call-Kontakts und ein Post-Incident-Bericht mit Zeitlinie, ergriffenen Massnahmen und Empfehlungen. Die Reaktionsgeschwindigkeit ist durch vertraglich festgelegte SLAs geregelt, nicht durch Ad-hoc-Verfügbarkeit.
SOC Unterstützung?
Der Einstieg erfolgt nicht über den Entschluss „wir brauchen ein SOC“, sondern über eine strukturierte Einordnung: Welche Quellen sind relevant? Welche Use Cases passen? Welche Eskalationsfähigkeit existiert tatsächlich?