We hebben het in afgelopen post vaak gehad over verschillende Azure-based beveiligingsoplossingen. Een beveiliging is echter slechts een onderdeel van de oplossing. Een security incident doet zich vaak voor wanneer een beveiligingssysteem omzeild kan worden. Echter, alvorens aanvallers deze bypass kunnen maken moeten ze diverse stappen uitvoeren welke in essentie geen beveiligingsissue opleveren, maar gecombineerd een duidelijk patroon van een aanval kunnen bieden. Wanneer we dit patroon vroegtijdig kunnen ontdekken dan kunnen we een potentiële aanval stoppen alvorens deze uitgevoerd kan worden.

SIEM en/of SOAR?

Om deze stappen te vinden, herkennen en aan elkaar te correleren is nogal wat intelligentie en informatie nodig. Alles begint uiteraard bij voldoende logging. Deze logging moet verzameld worden en genormaliseerd worden zodat alle data op eenzelfde manier verwerkt en geïnterpreteerd kan worden. Als dat gedaan is dient deze data “bekeken” en “geïnterpreteerd” te worden. Verschillende logs welke met elkaar te maken hebben moeten eveneens gecorreleerd worden zodat events niet op zichzelf beoordeeld worden maar ook zodat patronen ontdekt kunnen worden. Tenslotte moet er een baseline zijn van “normaal” gedrag zodat al het “afwijkende” gedrag gemeld kan worden.

We kennen hiervoor tegenwoordig 2 soorten systemen, namelijk SIEM en SOAR systemen.

SIEM: Security Information en Event Management
SOAR: Security Orchestration Automated Response

Het grote verschil is dat een SIEM voornamelijk een event collector is van verschillende sources. Een SIEM kan al deze events correleren en meten n.a.v. een baseline. Het SIEM systeem kan vervolgens eventuele excessen melden zodat een analist deze nader kan inspecteren.

Zodra er AI bij komt kijken om “op een slimme manier” deze events te interpreteren en prioriteren en welke middels “playbooks” ook automatische remediation taken kan uitvoeren spreken we van een SOAR systeem. Het grote voordeel van een SOAR systeem is dat dit soort systemen bij het overschrijden van bepaalde waardes snel geautomatiseerd kunnen reageren. Dit is altijd sneller dan dat een analist triage kan uitvoeren en de potentiële aanval kan stoppen.

Er zijn verschillende SIEM en SOAR systemen op de markt. Microsoft kent zijn eigen SOAR systeem genaamd “Microsoft Sentinel” (voorheen Azure Sentinel).

Wat is Microsoft Sentinel?

Microsoft Sentinel is een cloud-native SIEM en SOAR oplossing welke draait in de Azure-cloud. Het heeft als doel holistische beveiligingsoperaties mogelijk te maken door eenduidige mogelijkheden te bieden voor het verzamelen, detecteren, reageren en onderzoeken van events. Microsoft Sentinel wordt vaak gebruikt voor:

  • Visualisatie van loggegevens
  • Anomaliedetectie en alarmering
  • Onderzoek naar beveiligingsincidenten
  • Proactieve jacht op bedreigingen
  • Geautomatiseerde reactie op beveiligingsgebeurtenissen

Het voordeel van Microsoft Sentinel is dat de setup ontzettend eenvoudig is. De tool is aanwezig in Azure waardoor het verzamelen van Azure loggegevens ontzettend eenvoudig is. Microsoft Sentinel kan functioneren over verschillende Azure subscriptions en wordt betaald op basis van gebruik. De kosten voor Sentinel wordt betaald met GB en zijn afhankelijk van datastroom tiers. Zo betaal je voor elke GB in een 400 GB per dag tier +/- 5 euro per dag.

Aangezien de logs welke Sentinel verwerkt niet alleen afkomstig kunnen zijn vanuit Microsoft omgevingen maar ook vanuit allerhande externe systemen kunnen de dagelijkse kosten voor Sentinel snel oplopen. Het voordeel is dan weer dat Sentinel een zeer schaalbare oplossing is waarbij je alleen betaald voor gebruik.

Naast het pay-as-you-go model kent Sentinel nog een aantal andere opties zoals de E5 license data grand waarbij iedere gebruiker 5MB aan data mag ingesten in Microsoft Sentinel. Bij 1000 gebruikers hebben we het dus al snel over 5GB per dag.

Een laatste opties is een zogenaamde “Capacity Reservation” waarbij een afspraak gemaakt wordt met Microsoft om een X aantal GB’s per dag te ingesten. Microsoft geeft een hoge korting (tot wel 65%) op vooraf afgesproken (en dus ook gefactureerde) data.

Om data vanuit niet-Azure bronnen te verzamelen kent Sentinel honderden verschillende connectoren zoals Function Apps, Logic Apps, Agents, Syslog, en native codeless connectors.

Hoe werkt Microsoft Sentinel?

Sentinel centraliseert beheerd de complete flow voor het verzamelen, detecteren, reageren en onderzoeken van bedreigingen. Sentinel biedt de gebruiker bedreigingsinformatie en intelligente beveiligingsanalysemogelijkheden die de zichtbaarheid van bedreigingen, waarschuwingsdetectie, reactie op bedreigingen verbeteren. Dit doet Microsoft Sentinel volgens een zogenaamde cyclus.

Deze cyclus die begint met logbeheer. Alle data komt binnen als “raw logs” welke door de verzendende identiteit wordt uitgestuurd. Deze data wordt genormaliseerd en gevalideerd. Als dat gebeurt is wordt deze data weer gebruikt voor detectie en onderzoek. Daarnaast kunnen we in Sentinel geautomatiseerde reacties maken op bepaalde waarschuwingen (SOAR functionaliteit)

Collect:
Sentinel verzamelt gegevens van alle apparaten, gebruikers, applicaties en infrastructuur, inclusief componenten die zich on-premises en in meerdere clouds bevinden.

Detect:
Sentinel biedt mogelijkheden voor het uitvoeren van geautomatiseerde analyse en verstrekt informatie over bedreigingen. Sentinel helpt om reeds bekende bedreigingen snel te detecteren en gebruikt AI en baselining om false-positives te verminderen. Detectie regels worden in de KQL (Kusto Query Language) taal geschreven.

Investigate:
Sentinel gebruikt AI technologie om snel en effectief verdachte activiteiten op grote schaal te detecteren.

Respond:
De kracht van Sentinel zit hem o.a. in het “respond” gedeelte. Sentinel maakt aangepaste orkestratie en automatisering mogelijk zodat teams snel en gemakkelijk om incidenten kunnen reageren of zodat Sentinel zelf kan ingrijpen.

Microsoft Sentinel Componenten:

Microsoft Sentinel bestaat uit een aantal core-componenten. Deze zijn:

  • Data Connectors
  • Workbooks
  • Log Retention
  • Analytics
  • Thread Hunting
  • Incidenten / Onderzoek
  • Automation Playbooks

Data Connectors:

Data-connectoren zorgen ervoor dat logdata van allerhande verschillende bronnen naar Microsoft Sentinel verstuurd kunnen worden. In sommige gevallen kunnen we gemakkelijk een service toevoegen (zoals reeds bestaande Azure services) en in andere gevallen moeten we een connector gebruiken zoals Syslog. Wanneer we een connector gebruiken moeten we deze meestal configureren en finetunen. Microsoft heeft gegevensbronschema’s goed gedocumenteerd waardoor dat het configureren geen “rocket science” is.

Sentinel biedt dataconnectoren voor algemene bronnen en scenario's, waaronder syslog, clouds zoals Amazon Web Services (AWS) en Microsoft Azure, Common Event Format (CEF) en Trusted Automated eXchange of Indicator Information (TAXII).

Aangepaste toepassingen, unieke niet-beveiligingslogboeken en logboeken voor fysieke beveiliging (OT) kunnen ook in Microsoft Sentinel worden geïntegreerd.

Workbooks:

Binnen Sentinel kunnen we zogenaamde “Workbooks” gebruiken om de gegevens te bewaken, te meten en te controleren. Het maken van aangepaste en interactieve workbooks kan op basis van diverse beschikbare default sjablonen. Het is ontzettend handig om ingebouwde Sentinel-workbook templates te gebruiken om direct na het aansluiten van een gegevensbron inzichten te verkrijgen. Er kunnen uiteraard ook custom workbooks gemaakt worden welke inzicht geven in een specifieke data- of onderzoeksworkflow. Welke gebruikt worden om te rapporteren of om te controleren op specifieke afwijkingen.

Log Retention:

Microsoft Sentinel slaat gegevens op met behulp van Log Workspaces. De instellingen van deze workspaces bepalen hoe lang u de beschikking heeft over de daarin opgeslagen logs. Logboeken kunnen ook voor b.v. langdurige opslag worden doorgestuurd naar ADX (Azure Data Explorer).

Analytics:

Het hart van Sentinel bestaat uit Analytische regels. Deze regels worden gebruikt om waarschuwingen te correleren tot incidenten. Analyseregels kunnen geplande query's zijn of query's die op aanvraag worden uitgevoerd. Een incident is vaak een samenvatting van gerelateerde waarschuwingen die samen een potentiële dreiging vormen. Sentinel biedt ingebouwde correlatieregels en machine learning-regels om het gedrag van het netwerk en de daarop aanwezig resources in kaart te brengen. En om vervolgens afwijkingen te detecteren. Zeker wanneer Sentinel net geïmplementeerd is zal het nodig zijn om deze omgeving te finetunen. Niet elke default regel zal optimaal werken in combinatie met uw infrastructuur en log verzameling. Na verloop van tijd zullen de inspanningen tot het finetunen afnemen. De baseline is dan bekend en de regels zijn geoptimaliseerd. Een juiste optimalisatie voorkomt veel false-positives.

Thread Hunting:

Een ander belangrijk onderdeel van Sentinel is het zogenaamde “Thread Hunting”:

Thread Hunting maakt het mogelijk om potentiële problemen vroegtijdig op te sporen en vinden deze dus nog voor de EDR deze zou kunnen ontdekken. Hierbij wordt gebruik gemaakt van specifieke detectie-inhoud welke is vrijgegeven door Microsoft of andere informatie over threads. Beveiligingsanalisten die via Sentinel Thread Hunting uitvoeren volgen hierbij het "zero trust" principe. waardoor geavanceerde bedreigingen zoals zero-days te detecteren zijn. Sentinel maakt “thread-hunting” niet alleen inzichtelijk maar geeft de security analist meteen toegang tot diverse additionele data en intelligence om zo succesvol mogelijk potentiële risico’s op te sporen.

Voor het “thread hunten” kan door de analist gebruik gemaakt worden van speciale hunting queries. Deze queries kunnen worden opgeslagen om zo op een later moment weer hergebruikt te worden. Daarnaast kan de analist zogenaamde “bladwijzers” aanmaken voor interessante gebeurtenissen zodat deze later verder geanalyseerd kunnen worden of zodat deze informatie gedeeld kan worden met andere medewerkers.

Incidenten / Onderzoek:

Wanneer een incident gevonden wordt zal Microsoft Sentinel een waarschuwing genereren. Aan deze waarschuwing kunnen ook diverse playbooks worden gekoppeld om op die manier automatisch actie te ondernemen. Elke waarschuwing zal door de analist afgehandeld moeten worden met de juiste informatie zodat het systeem hier weer van leert. Waarschuwing kunnen ook doorgestuurd worden naar andere analisten.

Daarnaast zal Sentinel proberen om zoveel mogelijk data toe te voegen aan de waarschuwing zodat niet alleen het punt van detectie geanalyseerd kan worden maar zodat de analist ook deze waarschuwing kan terug herleiden tot de bron (point of entry). Dit doet Sentinel door o.a. een tijdslijn te genereren.

Automation Playbooks:

De SOAR functionaliteit van Microsoft Sentinel wordt met name bekracht via de zogenaamde “Automation Playbooks”. Deze playbooks helpen bij de verrijking, inperking, integratie met een ITSM (IT Service Management Tool)  of andere aangepaste geautomatiseerde reactie op potentiele incidenten. Azure Playbooks, samen met Azure Logic Apps en Azure Functions helpen om de overhead van analisten te verminderen, reactietijden te verkorten en om specifieke werkstromen te integreren.

Tenslotte

Sentinel is al een tijdje op de markt en we zien dat dit product steeds volwassener wordt met verschillende en goed geoliede processen en integraties. Microsoft Sentinel kent legio aan integraties (waaronder ook voor IoT en voorzichtig PA systemen) en heeft als voordeel dat het systeem direct geïntegreerd zit in Azure. Niet alleen de aanwezigheid en integratie van het product in Azure is een voordeel maar ook de kennis die Microsoft heeft uit al deze omgevingen komt ten goede van Microsoft Sentinel. Al deze kennis komt eerst beschikbaar in Sentinel alvorens andere vendoren deze kennis gebruiken. Wanneer je een Microsoft gebruiker bent en zoekt naar een SIEM/SOAR systeem dan is Microsoft Sentinel zeker het overwegen waard.

Jarno Baselier