Angesichts der hohen Zahl von Sicherheitsbedrohungen fühlt sich mein Security-Team zunehmend überfordert.
Ein Sicherheitskonzept, bei dem man von einem System zum anderen springen muss, macht keinen Spaß. Die Untersuchung einer Bedrohung und die Reaktion darauf ist sehr zeitaufwendig, weil ich auf fünf bis zehn unterschiedlichen Plattformen unterwegs sein muss.
Anstatt noch mehr zu arbeiten, müssen wir eine Möglichkeit finden, intelligenter zu arbeiten.
Kommt euch eine dieser Aussagen bekannt vor?
SOAR-Lösungen (Security Orchestration, Automation and Response) werden immer wertvoller für Security-Teams, die mit steigenden Qualifikationsdefiziten im Bereich IT-Sicherheit konfrontiert sind und gleichzeitig täglich vor einem Berg von Sicherheitswarnmeldungen stehen. Viele Teams setzen mittlerweile SOAR-Lösungen ein, um die MTTR (Mean-Time-To-Respond) zu verkürzen, der Überlastung der Security-Teams und der Fluktuation innerhalb der Teams entgegenzuwirken und um Sicherheitsprozesse zu straffen. Doch es gibt einige Aspekte, die ihr bei der Implementierung von SOAR-Technologie unbedingt beachten solltet.
Aus gutem Grund suchen neue SOAR-Kunden nach Richtlinien und zertifizierten Architekturen, um sicherzustellen, dass ihre Bereitstellung von Beginn an auf einem sicheren Fundament steht. Bei der Entscheidung über die Implementierung von SOAR-Technologie gilt es, Aspekte wie Verfügbarkeit, Performance, Skalierbarkeit und die Gesamtkosten für die Verwaltung zu berücksichtigen.
Hier sind fünf wichtige Fragen, die ihr und das Security Operations-Team klären solltet, bevor ihr mit der Implementierung beginnt:
- Braucht euer SOAR-Tool einen Disaster-Recovery-Plan, der mehrere Standorte umfasst?
- Möchtet ihr die SOAR-Lösung für das Case-Management verwenden?
- Möchtet ihr eine eigene externe Infrastruktur bereitstellen oder Cloud-Infrastrukturen wie Splunk Cloud nutzen?
- Wie viele Analysten werden das SOAR-Tool zu einem beliebigen Zeitpunkt gleichzeitig nutzen?
- Wie viele Ereignisse pro Stunde werdet ihr an euer SOAR-Tool weiterleiten?
Bei der Vorbereitung auf die Implementierung einer SOAR-Lösung solltet ihr außerdem die wichtigsten Use Cases überprüfen, die euer Security-Team automatisieren möchte, um zu entscheiden, ob ihr SOAR im „Headless“-Betrieb oder im Case-Management-Betrieb nutzen wollt.
Wenn euer Team das SOAR-Tool für einfache Playbook-Ausführungen einsetzen wird, wobei die Automatisierung im Back-End erfolgt und nur wenige interaktive Benutzer erforderlich sind, ist der „Headless“-Betrieb vielleicht die beste Lösung. Wenn euer Team jedoch am Back-End automatisieren und gleichzeitig andere Funktionen der Benutzeroberfläche des SOAR-Tools nutzen möchte, um eingehende Sicherheits-Events besser beurteilen zu können, solltet ihr stattdessen eine Bereitstellung mit Case-Management-Betrieb in Erwägung ziehen.
Für Security Use Cases empfehlen wir in der Regel ein Case Management Deployment. Da SOAR-Technologie jedoch auch für Use Cases außerhalb des Sicherheitsbereichs zum Einsatz kommt, ist in einigen Fällen auch ein „Headless“-Betrieb denkbar.
Wenn ihr mehr darüber erfahren möchtet, was für eine erfolgreiche Implementierung von SOAR-Technologie erforderlich ist, seht euch unser [englisches] On-Demand Webinar „Splunk Phantom Deployment Models and Use Cases“ von Rob Gresham, Global Security Architect bei Splunk, an.
*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier: Top 5 Considerations for Implementing SOAR Technology.
----------------------------------------------------
Thanks!
Splunk
