Relevanz statt Alarmmenge
Signale aus den vereinbarten Quellen werden geprüft und zusammengeführt. Offensichtliche Fehlalarme und bekannte Aktivität werden von begründetem Handlungsbedarf getrennt.
LOCKVEILSOC AS A SERVICE FÜR DEN MITTELSTAND
SOC as a Service: Aus Sicherheitsmeldungen werden klare, begründete Entscheidungen.
Signale bündeln. Relevanz bewerten. Bestätigte Risiken kontrolliert eskalieren.
LOCKVEIL überwacht die vereinbarten Datenquellen, prüft Auffälligkeiten im Kontext Ihrer Umgebung und übergibt relevante Fälle über definierte Wege. Ihre IT erhält weniger ungefilterte Alarme und mehr verwertbare Informationen für den nächsten Schritt.
GESCHÄFTSNUTZEN
Mehr Aufmerksamkeit für echte Risiken. Weniger Reibung für Ihre IT.
Ein SOC erzeugt seinen Wert nicht durch die Anzahl verarbeiteter Meldungen. Entscheidend ist, ob relevante Aktivitäten erkannt, fachlich eingeordnet und mit ausreichend Kontext an die richtige Stelle übergeben werden.
Schnellere Orientierung
Eine Eskalation enthält betroffene Konten oder Systeme, beobachtete Zusammenhänge, eine fachliche Einordnung und empfohlene nächste Schritte – soweit die verfügbaren Daten dies zulassen.
Lernender Erkennungsbetrieb
Rückmeldungen, Veränderungen Ihrer Umgebung und neue relevante Angriffsmuster fließen in die Pflege der vereinbarten Erkennungsregeln und Abläufe ein.
GEEIGNETE AUSGANGSLAGEN
Geeignet, wenn Ihre Systeme Signale liefern, aber die Bewertung nicht geregelt ist.
SOC as a Service richtet sich an Unternehmen, die kontinuierliche Erkennungsarbeit benötigen, jedoch kein eigenes Security Operations Center aufbauen möchten. Voraussetzung sind geeignete und rechtmäßig nutzbare Datenquellen.
01
Warnmeldungen treffen ungefiltert bei der IT ein.
Endpoint-, Identitäts-, Cloud- oder Firewall-Systeme erzeugen Hinweise, die neben dem Tagesgeschäft geprüft werden müssen. Dringlichkeit und Zusammenhang bleiben oft unklar.
- Viele einzelne Herstelleralarme
- Uneinheitliche Bewertung durch wechselnde Personen
02
Es fehlt eine feste Triage-Verantwortung.
Werkzeuge und Protokolle sind vorhanden, aber niemand ist dauerhaft für Prüfung, Korrelation, Dokumentation und Eskalation verantwortlich.
- Alarme bleiben außerhalb der Bürozeiten oder bei Abwesenheit liegen
- Eskalationen hängen vom persönlichen Wissen ab
03
Eine eigene SOC-Struktur wäre unverhältnismäßig.
Sie benötigen spezialisierte Analyse und belastbare Prozesse, möchten dafür aber nicht alle Rollen, Plattformen und Betriebsabläufe vollständig intern aufbauen.
- Kleine oder generalistisch aufgestellte IT
- Bedarf an spezialisierten Analysten ohne eigenes Team
04
Nach einem Vorfall soll die Erkennung besser werden.
Bekannte Angriffspfade oder forensische Erkenntnisse sollen in überprüfbare Erkennungsfälle überführt werden, damit ähnliche Aktivitäten künftig früher auffallen.
- Vorhandene Erkenntnisse ohne Detection-Use-Case
- Keine strukturierte Rückkopplung aus Vorfällen
LEISTUNGSUMFANG & ERGEBNISSE
Vom Datenanschluss bis zur qualifizierten Eskalation.
Ein belastbarer SOC-Service beginnt mit Sichtbarkeit und klaren Zuständigkeiten. Wir vereinbaren, welche Daten verarbeitet werden, welche Aktivitäten relevant sind und was nach einer bestätigten Auffälligkeit geschieht.
01BAUSTEIN
Datenquellen- und Sichtbarkeitskonzept
Relevante Identitäts-, Endpunkt-, Server-, Cloud- und Netzwerkquellen werden priorisiert; technische sowie organisatorische Voraussetzungen werden dokumentiert.
ERGEBNISDefinierte Überwachungssicht
02BAUSTEIN
Onboarding und Datenqualitätsprüfung
Vereinbarte Quellen werden angebunden und auf Vollständigkeit, Zeitbezug, Feldqualität sowie erwartete Ereignisse geprüft.
ERGEBNISPrüfbare Telemetrie
03BAUSTEIN
Erkennungsfälle und Prioritäten
Use Cases werden an kritischen Identitäten, Systemen und realistischen Angriffspfaden ausgerichtet und mit nachvollziehbaren Schweregraden versehen.
ERGEBNISRisikobasierte Detection
04BAUSTEIN
Triage und Kontextanalyse
Alarme werden auf Plausibilität, Zusammenhang und mögliche Auswirkungen geprüft. Verfügbare Kontextinformationen werden in der Fallakte gebündelt.
ERGEBNISBewerteter Sicherheitsfall
05BAUSTEIN
Eskalations- und Übergabeprozess
Ansprechpartner, erreichbare Kanäle, Entscheidungskompetenzen und Übergaben an IT oder Incident Response werden vorab festgelegt.
ERGEBNISKlarer nächster Schritt
06BAUSTEIN
Berichte und Detection-Pflege
Fälle, Datenlücken, wiederkehrende Fehlalarme und Verbesserungen werden aufbereitet. Regeln werden im vereinbarten Umfang nachgeschärft.
ERGEBNISNachvollziehbare Entwicklung
FACHLICHE EINORDNUNG
SOC as a Service fachlich eingeordnet.
Eine Plattform allein ist noch kein SOC. Wirksame Erkennung entsteht aus geeigneter Telemetrie, gepflegten Use Cases, analystischer Bewertung und einem abgestimmten Reaktionsprozess.
01
Was ist der Unterschied zwischen SIEM, EDR und einem SOC?
Ein SIEM sammelt und verarbeitet Sicherheitsdaten, ein EDR liefert Schutz- und Telemetriedaten von Endgeräten. Ein SOC ist die organisatorische und fachliche Funktion, die solche Datenquellen überwacht, bewertet und über definierte Prozesse bearbeitet. Werkzeuge unterstützen diese Funktion, ersetzen sie aber nicht.
- Technik liefert Signale
- Analysten bewerten Kontext
- Prozesse steuern die Reaktion
02
Wann wird aus einem Alarm ein Sicherheitsfall?
Ein einzelnes Signal wird zunächst validiert. Dabei werden betroffene Objekte, zeitliche Zusammenhänge, bekannte Änderungen und weitere verfügbare Indikatoren betrachtet. Erst die begründete Einordnung bestimmt Priorität und Eskalationsweg.
- Validierung des Auslösers
- Anreicherung mit Umgebungsdaten
- Dokumentierte Priorisierung
03
Welche Protokolldaten sind sinnvoll?
Priorität haben Daten aus geschäftskritischen Identitäts-, Endpunkt-, Cloud-, Server- und Netzwerkkomponenten. Welche Quellen tatsächlich benötigt werden, ergibt sich aus Angriffspfaden, Systemkritikalität, technischer Verfügbarkeit und rechtlichen Rahmenbedingungen.
- Qualität vor Datenmenge
- Kritische Systeme zuerst
- Aufbewahrung zweckgebunden festlegen
ABLAUF DER ZUSAMMENARBEIT
So entsteht ein belastbarer Erkennungs- und Eskalationsbetrieb.
Vor dem ersten Alarm müssen Sichtbarkeit, Zuständigkeit und Kommunikationswege stimmen. Deshalb beginnt der SOC-Service mit einem kontrollierten Onboarding statt mit einer ungezielten Massensammlung von Logdaten.
- 01
Schutzziele und Angriffspfade verstehen
Wir erfassen kritische Prozesse, Identitäten, Systeme, vorhandene Sicherheitswerkzeuge und bisherige Auffälligkeiten.
ERGEBNISPriorisierte Erkennungsziele - 02
Quellen und Abläufe onboarden
Daten werden schrittweise angebunden und geprüft. Parallel werden Ansprechpartner, Verfügbarkeit und Eskalationswege festgelegt.
ERGEBNISTechnisch und organisatorisch arbeitsfähiger Service - 03
Use Cases stabilisieren
Erkennungsregeln werden beobachtet, Fehlalarme analysiert und Kontextdaten ergänzt, bevor der Regelbetrieb bewertet wird.
ERGEBNISBelastbare Triage-Grundlage - 04
Regelbetrieb gemeinsam verbessern
Fälle, Datenlücken und Änderungen der Umgebung werden regelmäßig besprochen und in Datenquellen, Regeln oder Prozesse zurückgeführt.
ERGEBNISAnpassungsfähige Erkennung
ENTSCHEIDUNGSHILFE FÜR IHR UNTERNEHMEN
SOC-Angebote vergleichen: Sichtbarkeit, Reaktion und Kosten gemeinsam prüfen.
Nicht jedes SOC-Angebot umfasst dieselben Datenquellen, Betriebszeiten oder Reaktionsmaßnahmen. Fragen Sie nach dem konkreten Ablauf für Ihre Umgebung, bevor Sie Preise oder pauschale Verfügbarkeitsangaben vergleichen.
01VOR DER BEAUFTRAGUNG
Welche Systeme sind tatsächlich sichtbar?
Klären Sie die enthaltenen Datenquellen, notwendige Lizenzen und die Überwachung ausgefallener Datenzuflüsse. Besprechen Sie auch, welche geschäftskritischen Bereiche zunächst nicht abgedeckt sind.
IM ANGEBOT KLÄRENBenannte Datenquellen, Abhängigkeiten und Sichtbarkeitslücken
02VOR DER BEAUFTRAGUNG
Was bedeutet die zugesagte Reaktionszeit?
Lassen Sie erklären, wann eine Frist beginnt und ob sie Sichtung, Rückmeldung oder eine konkrete Maßnahme meint. Prüfen Sie Betriebszeiten, Vertretungen und Ihre eigene Erreichbarkeit für Eskalationen.
IM ANGEBOT KLÄRENEindeutige Zeitdefinitionen und getestete Kontaktwege
03VOR DER BEAUFTRAGUNG
Welche Kosten und Befugnisse kommen hinzu?
Besprechen Sie Onboarding, Datenvolumen, Aufbewahrung und zusätzliche Analyseleistungen. Halten Sie fest, ob ein Alarm nur gemeldet wird oder bereits ausdrücklich freigegebene Reaktionsmaßnahmen enthalten sind.
IM ANGEBOT KLÄRENAbgegrenzte laufende Kosten und Reaktionsbefugnisse
HÄUFIGE FRAGEN
Häufige Fragen zu SOC as a Service.
Die Antworten geben eine erste Orientierung. Verbindlich ist immer der konkret vereinbarte Leistungsumfang für Ihre Umgebung.
01Ist der LOCKVEIL SOC-Service rund um die Uhr besetzt?+
Das wird nicht pauschal zugesagt. Überwachungszeiten, Bereitschaften und Reaktionswege werden passend zum Bedarf festgelegt und ergeben sich ausschließlich aus dem konkreten Angebot beziehungsweise Vertrag.
02Können vorhandene Sicherheitswerkzeuge weiterverwendet werden?+
Häufig ja. Zu Beginn prüfen wir Schnittstellen, Datenqualität und die Eignung für die priorisierten Erkennungsfälle. Ein Werkzeugwechsel ist kein Selbstzweck und wird nur bei einer relevanten technischen Lücke empfohlen.
03Reagiert das SOC selbstständig auf betroffenen Systemen?+
Nur wenn konkrete Reaktionsmaßnahmen, technische Berechtigungen und Freigaberegeln ausdrücklich vereinbart sind. Standardmäßig steht die qualifizierte Bewertung und Eskalation im Vordergrund; weitergehende Incident Response wird separat koordiniert.
04Welche Daten muss unser Unternehmen bereitstellen?+
Das hängt von den Erkennungszielen ab. Typisch sind Protokolle aus Identitätsdiensten, Endgeräten, Cloud-Plattformen, Servern oder Netzwerkkomponenten. Wir priorisieren gezielt und vermeiden Datensammlung ohne begründeten Zweck.
05Wie werden Fehlalarme reduziert?+
Regeln werden mit Umgebungswissen, bekannten Administrationsabläufen und Rückmeldungen aus bearbeiteten Fällen verfeinert. Fehlalarme lassen sich reduzieren, aber nicht vollständig ausschließen, ohne möglicherweise relevante Sichtbarkeit zu verlieren.
06Wie beginnt die Zusammenarbeit?+
Nach der fachlichen Aufnahme definieren wir ein priorisiertes Startset an Datenquellen und Use Cases. Es folgen technische Anbindung, Qualitätsprüfung, Prozessabstimmung und eine Stabilisierungsphase vor dem Regelbetrieb.
07Was kostet SOC as a Service?+
Der Preis richtet sich nach Datenquellen, Datenvolumen, benötigten Werkzeugen, Überwachungszeiten und dem vereinbarten Analyse- und Eskalationsumfang. Onboarding, laufender Betrieb und zusätzliche Incident-Response-Leistungen sollten im Angebot getrennt erkennbar sein. Eine belastbare Summe lässt sich erst nach der Aufnahme Ihrer Umgebung nennen.
KOSTENLOSES ERSTGESPRÄCH
Welche Sicherheitsmeldungen erreichen Ihre IT heute?
Im kostenlosen Erstgespräch klären wir vorhandene Werkzeuge, relevante Systeme und Ihre Erwartungen an Überwachung und Eskalation. Daraus lässt sich ein realistischer SOC-Leistungsumfang ableiten.
- 01Erkennungsbedarf einordnen
- 02Datenquellen und Lücken prüfen
- 03Überwachungsumfang sauber abgrenzen