Zoeken

SOAR: conclusies voor 2020

De CyberSOC geeft zijn feedback over SOAR-oplossingen, zowel met betrekking tot intern gebruik door ons als door onze eerste klanten.

Sinds 2016 halen de afkortingen SIRP (Security Incident Response Platform; Platform voor respons op beveiligingsincidenten) en vervolgens SOAR (Security Orchestration Automation Response; Beveiligingsorkestratie Automatiseringsreactie) de krantenkoppen. Inmiddels zijn er integratieprojecten gestart en is de markt geconsolideerd met een aantal belangrijke acquisities:

Ondanks dat het nut van zo'n tool vandaag niet meer bewezen hoeft te worden is het toch zaak om begin 2020 de balans op te maken en de situatie te inventariseren. In dit artikel gaan we het een en ander aan feedback geven op SOAR-oplossingen, zowel voor onze interne toepassingen als de oplossingen die waargenomen zijn bij onze eerste klanten die een integratieproject startte.

Afbeelding 1 - Belangrijkste acquisities van SOAR-oplossingen - Bron: Orange Cyberdefense

SOAR: inventarisatie en analyse

Het is duidelijk dat vandaag de dag de meest volwassen klanten op het gebied van cyberbeveiligingskwesties al zijn gaan nadenken over een SOAR-oplossing en deze zelfs al hebben geïmplementeerd. Grote organisaties en MSSP's (Managed Security Service Providers; beheerde serviceproviders voor beveiliging) zijn het meest betrokken bij deze behoefte om de verwerking van incidenten te automatiseren en industrialiseren. Het is duidelijk dat een kleinere organisatie vanuit veiligheidsoogpunt de neiging zal hebben om haar strategie te richten op andere prioriteiten, zoals detectie.

Kan en moet een organisatie zich in deze context uitrusten met een SOAR zodra haar SOC (Security Operation Center; Beveiligingscentrum) is geïnstalleerd? Sommige bedrijven hebben er inderdaad voor gekozen om het complete pakket in te zetten: SIEM (Security Information and Event Management; Beveiligingsinformatie en gebeurtenisbeheer) + SOAR. Deze projecten zijn ambitieus, het tempo ligt hoog, maar met advies, assistentie en sterke teambetrokkenheid is het heel goed mogelijk, maar beslist geen factor in het succes van het SOC.

Wat betreft implementatie publiceerde Gartner in februari 2018 een onderzoek getiteld Preparing Your Security Operations for Orchestration and Automation Tools (Uw beveiligingsactiviteiten voorbereiden op orkestratie- en automatiseringstools), waarin integratietijden van 6 tot 9 maanden worden genoemd. De cijfers liggen redelijk dicht bij wat we hebben waargenomen, rekening houdend met het feit dat, net als de meeste SIEM-detectiescenario's en -regels, workflows (of playbooks) voortdurend verbeteren.

In termen van gebruikerscasussen lijkt het automatiseren van de verwerking van kwaadaardige e-mails die zijn verzameld uit een speciale misbruikmailbox het meest voorkomend te zijn bij een groot aantal implementaties door klanten en het verhoudt zich goed tot het automatiseren van tijdrovende taken. Het automatisch ontleden en extraheren van artefacten en hun verrijking (Whois, DNS-record, HTTPS-certificaatinformatie, enz.) komt op de eerste plaats. Dit wordt gevolgd door een min of meer grondige analyse van de mail, inclusief de vergelijking van indicatoren met Threat Intelligence-databases (Informatie-databases van bedreigingen) en het detoneren van bestanden en URL's in een sandbox. Sommige organisaties hebben namelijk een zekere voorsprong genomen met de toepassing van meerdere aanvullende tools die onder andere zorgen voor een meer diepgaande analyse: Levenshtein-afstand, patroon/tekst-matching, beeldanalyse (OCR, logodetectie, etc.), maar ook algoritmen voor machine learning, die de kennisbanken aanvullen die vaak onvoldoende zijn om meer geavanceerde of gerichte aanvallen te detecteren.

Afbeelding 2 - Phishing Playbook geautomatiseerd (extract) - Bron: Demisto/ Palo Alto XSOAR

Dan komen de meer generieke playbooks en de sortering en kwalificatie van incidenten. Hier vinden we meestal in bronnen, een SIEM, of eenvoudiger een EDR (Endpoint detection and response; Eindpuntdetectie en response) of netwerkprobes, die waarschuwingen terugsturen en die vervolgens worden verzameld, 'in kaart gebracht' en verrijkt met verschillende integraties (Active Directory, Threat Intelligence, CMDB of Configuration Management Database, enz.). Opdrachten, notificaties en SLA-beheer (Service Level Agreements; overeenkomst inzake dienstverleningsniveau) maken vaak deel uit van dit eerste generieke draaiboek.

Afbeelding 3: Industrialisatie van het sorteren en kwalificeren van incidenten. Bron: Orange Cyberdefense CyberSOC

Bij grote organisaties die doorgaans een CERT en/of een CSIRT hebben met gerichte compromisindicatoren (IOC's), vonden we ook een vrij veel voorkomende gebruikerscasus: het zoeken naar indicatoren in het hele informatiesysteem. Vanuit een MISP-instantie (Malware Information Sharing Platform; Platform voor het delen van informatie over malware) worden ze verzonden vanuit een e-mail, een CSV-bestand of een eenvoudige indicator: de mogelijkheid om snel SIEM-, logbeheer-, EDR- of NTA-apparatuur (Network Traffic Analysis; Analyse netwerkverkeer) te onderzoeken om vast te kunnen stellen of een indicator is waargenomen op het netwerk of in een besturingssysteem wordt ook gedragen door de SOAR.

De interesse is reëel omdat de meeste inbreukindicatoren tegenwoordig worden ingezet binnen SIEM's voor realtime detectie, maar ze worden niet onderzocht over een eerdere periode.

We kunnen daarom een ​​toekomstige inbreuk ontdekken, maar geen inbreuk in het verleden. Waarom niet? Een groot aantal aanvallen is veranderlijk of punctueel. Phishing of infecties door malware zoals diefstal maken het bijvoorbeeld mogelijk om inloggegevens te exfiltreren. Zonder historisch onderzoek zou deze inbreuk nooit zijn geïdentificeerd. Het lijdt geen twijfel dat eerdere ransomwarecampagnes ook een groot aantal bedrijven hebben aangezet om hun vermogen om naar inbreuken te zoeken verder te ontwikkelen.

Afbeelding 4 - Retro hunting-operatie. Bron: Orange Cyberdefense

Naast het generieke aspect worden natuurlijk meer specifieke incidentrespons-playbooks ingezet. Er wordt prioriteit gegeven aan de behandeling van incidenten van het malwaretype die kunnen worden uitgesplitst naar type (ransomware, wormen, Trojaanse paarden, enz.), of zelfs naar familie (Emotet, Nanocore, Azorult, enz.). Omdat sortering, verrijking en kwalificatie stroomopwaarts gedeeltelijk geautomatiseerd zijn, is het werk hier meer gericht op de analist met handmatige taken met een hoge toegevoegde waarde.

Playbooks voor het reageren op schadelijke e-mailincidenten worden ook op grote schaal gebruikt met gezinsspecifieke informatie: phishing, spear phishing, president-fraude en vele anderen.

Afbeelding 5 - Playbook voor malware-onderzoek (uittreksel). Bron: IBM Resilient

De automatisering van saneringsprocessen wordt nog maar marginaal ingezet. Hoewel het technisch mogelijk is (plaatsing van een zwarte lijst op een proxy/firewall, isolatie van een station/server met behulp van een EDR, verwijderen van e-mails uit mailboxen via Office 365, enz.), vertrouwen organisaties nog steeds op handmatige implementatie.

Of de verantwoordelijke teams hebben directe toegang tot de oplossing en er wordt een taak aan hen toegewezen, of de SOAR zorgt ervoor dat er automatisch een ticket wordt aangemaakt voor een tool van een derde partij, zoals een ITSM (IT Service Management). Een goede kennis van de risico's en een up-to-date repository om kritische servers, VIP's en beheerders te identificeren zijn noodzakelijk om collateral damage zoveel mogelijk te voorkomen of te beperken. Op basis van de verzamelde informatie kan vervolgens een beslissingsboom worden gebouwd.

Natuurlijk vinden we tegenwoordig enkele gevallen van massaal ingezet gebruik, maar ieder bedrijf heeft evenwel zeer verschillende behoeften. Een MSSP, die niet altijd administratieve toegang heeft bij de klant, zal het gebruik ervan oriënteren op onderzoekende playbooks en zal veel belang hechten aan samenwerkingsaspecten, kapitalisatie en de kennisbasis. Een organisatie met een eigen SOC heeft meer toegang en kan zo de contextualisering, het herstel, maar ook de ontwikkeling van IT- en business-playbooks uitbreiden.

SOAR: welke moeilijkheden ondervindt u?

Hoewel paradoxaal lijkt de eerste geconstateerde moeilijkheid het beheer van menselijke hulpbronnen te zijn. Omdat oplossingen zelden plug-and-play zijn en er sprake is van een gebrek aan IT-beveiligingsvaardigheden, zijn implementaties veel complexer en tijdrovender dan verwacht. Een duidelijk meetbaar investeringsrendement wordt dan ook zelden behaald in de eerste maanden van een dergelijk project.

Automatiserings- en integratiemogelijkheden rijmen vaak met ontwikkeling, wat natuurlijk specifieke vaardigheden, een operationeel model, of zelfs een toegewijd team impliceert in het geval van playbooks of complexe connectoren die in eigen huis zijn ontwikkeld. Bovendien zijn bij integraties met tools of oplossingen van derden een groot aantal heterogene teams binnen het project betrokken, waarvan sommige zeer sceptisch kunnen zijn dat een tool automatisch ook potentieel schadelijke acties uit kan voeren. Er zijn natuurlijk functionaliteiten beschikbaar om dit soort acties te beperken of te valideren, maar dit is niet altijd voldoende om mensen te overtuigen.

Het aanpassen aan veranderingen is ook een uitdaging voor teams. Interfaces zijn soms op het eerste gezicht ingewikkeld om te begrijpen en zijn pas na een paar dagen of zelfs weken gebruik onder controle. Teams van niveau 1 krijgen te maken met de meest opvallende verandering die evenzeer worden beïnvloed door de komst van een nieuwe tool als door de automatisering van een groot deel van het sorteer- en kwalificatieproces. Rekening houdend met het verloop van de teams, is het trainen van deze nieuwe tools dan ook een reëel probleem vanwege de centrale rol ervan.

Onder het veelbelovende marketingdiscours schuilt daarom een flinke complexiteit en sommige organisaties hebben nog niet de nodige vordering verworven om de implementatie van een SOAR op zich te nemen. Afhandelingsprocessen voor beveiligingsincidenten worden vaak slechts gedeeltelijk beheerst en gedocumenteerd, en zonder deze essentiële contextuele informatie is automatisering niet mogelijk.

Ons advies voordat u aan een SOAR-project begint

Governance en projectmanagement

Zoals vermeld in de inleiding; projecten zijn lang en er zijn veel teams bij betrokken. Het aspect governance en projectmanagement mag daarom niet worden verwaarloosd. De validatie van technische vereisten, die het openen van veel netwerkstromen en het creëren van serviceaccounts of API's (Application Programming Interface; Interface voor applicatieprogrammering) met zich meebrengen, evenals de mobilisatie van teams kunnen aanzienlijke risico's met zich meebrengen. Laten we niet vergeten dat de organisaties die zichzelf het meest waarschijnlijk zullen toerusten met een SOAR ver verwijderd zijn van het start-upmodel. Complexe processen en het werken in silo's zijn echte remmen, vooral omdat teams soms heel verschillende, zelfs tegenstrijdige doelstellingen hebben.

De definitie van een werkmodel voor een doel is het verkrijgen van een reflectie: wie is verantwoordelijk voor het maken en verbeteren van playbooks? Een nieuw toegewijd team of de SOC-teams? Dezelfde vraag moet worden gesteld voor de definitie van processen, de ontwikkeling en het onderhoud van integraties, en voor het platform. Ook projectmanagementmethoden die specifiek zijn voor de ontwikkelingswereld hebben hier hun plaats en moeten worden meegenomen.

SOAR: bekende en gecontroleerde processen

Processen voor respons op incidenten zijn momenteel slecht gedocumenteerd. Het is essentieel dat ze bekend en gedomineerd zijn, maar ze moeten bovenal betrouwbaar en gecontextualiseerd zijn.

Er bestaan basissen: SANS, NIST en zelfs CERT's, zoals CERT SG delen hun incidentresponsformulieren en methodologieën. Sommige oplossingen bevatten ook sjablonen voor playbooks en workflows. Deze documenten en sjablonen zijn uiteraard zeer goede uitgangspunten, maar de contextualisering mag niet worden verwaarloosd en een begeleiding bij de definitie en verbetering van de incidentresponsprocessen is in bepaalde gevallen verstandig. De BPMN-standaard (Business Process Model and Notation; Bedrijfsprocesmodel en notatie) lijkt unaniem te worden aanvaard omdat een groot aantal uitgevers op deze standaard vertrouwt voor het modelleren van playbooks.

Een documentatie van upstream incidentresponsprocessen maakt het ook mogelijk om hun representatie te optimaliseren door vergelijkbare of identieke fasen te identificeren die aanwezig zijn in verschillende gebruiksscenario's. Het beheer van een gecompromitteerd account bijvoorbeeld. Of dit nu het gevolg is van een malware-infectie of via phishing tot stand is gekomen, het proces zal bij de meeste organisaties vrijwel hetzelfde zijn. Dus bij sommige oplossingen waarbij het maken van 'sub-playbooks' mogelijk is zal het hergebruik van sub-blokken de integratie en evolutie van playbooks veel gemakkelijker worden.

Het gebruik in beperkte modus moet ook worden overwogen. Hoe te werken als de SOAR-oplossing niet beschikbaar is? Het nut van het voorbereiden van deze responsprocessen, die gedocumenteerd en snel toegankelijk zijn, maakt het mogelijk om het SOC aanvaardbaar te houden, ondanks een verslechtering van de dienstverlening.

SOAR: prioritering

De fout om van meet af aan een te groot deel van het incidentresponsproces te willen automatiseren wordt veel gemaakt door bedrijven. In plaats daarvan zou de beste aanpak zijn om in eerste instantie uitsluitend handmatige playbooks in te zetten en vervolgens iteratief te werken om als eerste de meest repetitieve en tijdrovende taken te automatiseren.

Deze methode maakt het mogelijk om snel een operationele oplossing te krijgen maar ook om zeer eenvoudig het investeringsrendement te kunnen berekenen. Het volgen van dit type tool is daarom natuurlijker voor teams van analisten.

Het is ook beter om te focussen op voorbereiding en kwaliteit dan op het aantal geïntegreerde playbooks. We raden u aan om te beginnen met het identificeren van een aantal gevallen van beperkt gebruik, het in kaart brengen van de apparatuur en de te gebruiken oplossingen, het bepalen van de informatie die relevant is voor uw organisatie en operationele teams, zodat u velden kunt maken, invullen en 'toewijzen' die heel specifiek zijn voor uw organisatie. Daarna volgt de definitie van de metrics en KPI's die moeten worden geïntegreerd. Een testprocedure en acceptatietest kunnen worden gebruikt om de volledige implementatieketen te valideren.

Conclusie

Als MSSP- en SOAR-gebruiker hebben we de dringende plicht om onze klanten te adviseren en te ondersteunen die nu het nut en de complexiteit van zo'n tool in twijfel trekken. Uitgevers kunnen ook een bijdrage leveren door echt kant-en-klare producten aan te bieden met eenvoudige modellen zoals SaaS-oplossingen (software as a service), die aldus de adoptie van minder gevorderde organisaties kunnen vergemakkelijken en hen een interessant rendement op hun investering biedt. Dit is de benadering van oplossingen zoals Microsoft's Azure Sentinel en Rapid7's InsightIDR/ Connect, die SOAR-oplossingen bieden die rechtstreeks zijn geïntegreerd met hun SIEM SaaS-oplossingen. Hoewel deze oplossingen minder geavanceerd zijn dan pure players, bieden ze toch voldoende functionaliteit voor de meeste SOC's.

Naast editors en serviceproviders lijken ook communities van gebruikers een belangrijke rol te spelen, en een aantal editors gebruikt dit marketingargument. Het gratis maar beperkt delen van de code van integraties, playbooks en oplossingen die inhoud beschikbaar maken, bijvoorbeeld op een GitHub-repository vergemakkelijken daarom het delen en community-participatie. De Palo Alto XSOAR-oplossing (voorheen Demisto) heeft deze interesse bijvoorbeeld duidelijk begrepen en biedt een Github-repository en een Slack-kanaal voor zijn community.

We zitten nog in de beginfase van SOAR. Gartner gaf aan dat in 2022 30% van de organisaties met een team van minimaal vijf mensen een SOAR zullen hebben, vergeleken met minder dan 5% in 2019. De komende jaren zullen cruciaal zijn voor deze oplossingen, en deze drie spelers (MSSP, uitgevers en communities) zullen een cruciale rol spelen.

Incident Response Hotline

Facing cyber incidents right now?

Contact our 24/7/365 world wide service incident response hotline.

Tel: +31 184 78 81 11