Security Operations Center (SOC)

Wer braucht ein Security Operations Center (SOC)?

Unabhängig von der Größe oder dem Zweck eines Unternehmens ist es wertvoll, ein dediziertes Team auf Organisationsebene zu haben, dessen Aufgabe es ist, Sicherheitsvorgänge und -vorfälle ständig zu überwachen und auf alle Probleme zu reagieren, die auftreten können. Die verschiedenen Zuständigkeiten innerhalb eines Cybersecurity-Teams können äußerst komplex sein, und ein SOC kann nicht nur als taktische Konsole dienen, um die Teammitglieder bei der Ausführung ihrer täglichen Aufgaben zu unterstützen, sondern auch als strategisches Zentrum, um das Team über größere, längerfristige Sicherheitstrends auf dem Laufenden zu halten.

Ein typisches Security Operations Center verfolgt eine beliebige Anzahl von Sicherheitswarnungen, auf die ein Unternehmen stoßen könnte, einschließlich potenzieller Bedrohungsmeldungen über Technologien und Tools sowie Mitarbeiter, Partner und externe Quellen. Von diesem Punkt aus untersucht und validiert das SOC dann die gemeldete Bedrohung, um sicherzustellen, dass es sich nicht um einen False Positive handelt (d. h. eine gemeldete Bedrohung, die eigentlich harmlos ist). Wenn der Sicherheitsvorfall als gültig erachtet wird und eine Reaktion erfordert, übergibt das SOC ihn an die entsprechenden Personen oder Teams zur Reaktion und Wiederherstellung.

Es bedarf einer ausgeklügelten Kombination aus Fachwissen, Prozessen und Organisation, um ein Security Operations Center als Teil eines umfassenden Programms zur Erkennung und Reaktion auf Vorfälle effektiv zu betreiben. Aus diesem Grund ist nicht jedes Unternehmen in der Lage, ein SOC intern zu unterstützen oder Ressourcen dafür bereitzustellen. Stattdessen entscheiden sich viele dafür, ihr SOC von einer externen Agentur verwalten zu lassen oder es sogar komplett auszulagern.

Die Grundlagen schaffen

Es gibt eine Reihe von unterstützenden Komponenten, die vorhanden sein müssen, bevor ein SOC für ein Unternehmen eine brauchbare Option ist. Die erste ist ein gutes Programm zur Verwaltung der Angriffsfläche. Dazu gehören Technologien zur Bedrohungsabwehr für alle Eintritts- und Austrittswege von Bedrohungen, regelmäßiges Scannen auf Schwachstellen (und zugehörige Patches), Pen-Tests, Benutzerauthentifizierung und -autorisierung, Asset-Management, Tests externer Anwendungen (mit zugehörigen Patches) und Fernzugriffsmanagement.

Als Nächstes muss ein Plan zur Reaktion auf Vorfälle vorliegen. Typischerweise ist eines der Hauptziele der Einführung eines SOC in ein IDR-Programm die Erhöhung der Effektivität bei der Erkennung von Bedrohungen in der Unternehmensumgebung. Wenn die Incident-Response-Prozesse, die auf die Entdeckung eines Verstoßes folgen, nicht vorhanden sind und regelmäßig getestet werden, werden nur einige Komponenten eines effektiven IDR-Programms angesprochen.

Schließlich ist es wichtig, einen Disaster-Recovery-Plan zu haben. Eine Sicherheitsverletzung ist nur ein spezifisches Beispiel für eine Katastrophe, von der sich Unternehmen erholen müssen. Sobald die erkannte Sicherheitslücke vollständig erfasst und die betroffenen Anlagen, Anwendungen und Benutzer eingedämmt wurden, muss ein Plan zur Wiederherstellung der normalen Geschäftsabläufe vorhanden sein. Das ist Disaster Recovery.

Die ersten Schritte

Aufgrund der Komplexität eines Security Operation Centers gibt es beim Aufbau viele Dinge zu beachten. Unabhängig davon, ob es intern eingerichtet oder ausgelagert wird, ist die Vorbereitung auf die folgenden drei Elemente entscheidend für den Erfolg des SOC:

• Personal: Das Verständnis der Rollen und Verantwortlichkeiten der SOC-Analysten ist eine wichtige Vorstufe zur Auswahl der Technologie, die Ihr SOC betreiben wird. Die Teams, die Sie bilden, und die Aufgaben, die Sie ihnen zuweisen, hängen von der bestehenden Struktur Ihres Unternehmens ab. Wenn Sie beispielsweise ein SOC aufbauen, um die vorhandenen Fähigkeiten zur Erkennung von und Reaktion auf Bedrohungen zu erweitern, sollten Sie überlegen, für welche spezifischen Aufgaben die Mitglieder des SOC-Teams zuständig sind und welche den IDR-Teams außerhalb des SOC übertragen werden. Außerdem sollten Sie die Zuständigkeiten zwischen den SOC-Analysten aufteilen, damit klar ist, wer High-Fidelity-Warnungen bearbeitet, wer Low-Fidelity-Warnungen validiert, wer Warnmeldungen eskaliert, wer nach unbekannten Bedrohungen sucht usw. Viele Security Operations Center arbeiten mit einem abgestuften Rahmen für Mitarbeiter, um klare Verantwortlichkeiten und Hierarchien zu schaffen.
• Technologie: Die Entscheidung, welche Technologie das SOC verwendet, ist der Punkt, an dem sich die Zeit, die in die Festlegung der oben genannten Rollen und Verantwortlichkeiten investiert wird, auszahlt. Welche Technologie wird verwendet werden? Wahrscheinlich müssen sie Tools für die Log-Aggregation, die Analyse des Benutzerverhaltens, die Abfrage von Endpunkten, die Echtzeitsuche und mehr kombinieren. Es ist wichtig, sich anzuschauen, wie die SOC-Analysten Ihre Technologie nutzen, und festzustellen, ob die vorhandene Technologie die SOC-Prozesse unterstützt oder behindert und ob sie durch neue Technologie ersetzt werden muss. Darüber hinaus ist es wichtig, Kommunikationstools einzurichten, mit denen die Analysten zusammenarbeiten können.
• Prozesse: Die Etablierung der Prozesse, denen die oben genannten Personen und Technologien folgen werden, ist die letzte Komponente, die Sie beim Start eines SOC berücksichtigen müssen. Was passiert, wenn ein Sicherheitsvorfall validiert, gemeldet, eskaliert oder an ein anderes Team weitergegeben werden muss? Wie werden Sie Metriken sammeln und analysieren? Diese Prozesse müssen präzise genug sein, um sicherzustellen, dass Ermittlungshinweise in der Reihenfolge ihrer Kritikalität behandelt werden, aber auch locker genug, um Analyseprozesse nicht zu diktieren. Prozesse können über die Effektivität eines SOC entscheiden und sind die Mühe wert, sie richtig zu gestalten.