Hoe werkt Security Monitoring eigenlijk?

Hoe werkt Security Monitoring eigenlijk?

DearBytesBlogDetectieHoe werkt Security Monitoring eigenlijk?

Op regelmatige basis spreek ik verschillende bedrijven over security monitoring, ofwel SOC-diensten. (SOC staat voor Security Operations Center) Bedrijven kiezen hiervoor om verschillende redenen, variërend van compliant willen zijn aan wet- en regelgeving of security-standaarden zoals ISO27001/2, NEN7510 of anderen, tot meer intrinsieke motivaties. Dan maken bedrijven zich zorgen over potentieel verlies van data of dat bedrijfsprocessen worden stilgelegd. Of een combinatie van dezen.

Hoe dan ook, als een bedrijf uiteindelijk de keuze heeft gemaakt, hoe gaat dat dan eigenlijk in zijn werk? Security Monitoring is een samenspel van mensen, processen en techniek. In een security operations center hebben we techniek nodig om zichtbaar te maken wat er in een IT-security omgeving gebeurt. Daarna hebben we analisten nodig om gebeurtenissen te analyseren en om daar opvolging aan te geven. De gebruikte techniek is meestal een SIEM.

Security Information & Event Management (SIEM)

Technisch gezien is het allemaal niet zo heel erg spectaculair. Je hebt SIEM-software nodig. SIEM staat voor Security Information and Event Management. Deze bestaan meestal uit een drietal onderdelen. Een log-collector, een log-manager en de daadwerkelijke SIEM, kortweg server.

De Log-collector

Je zorgt er voor dat je een “Log-collector” hebt. Dat is een computer die alle logging van de ICT-security-omgeving kan verzamelen en vervolgens kan normaliseren, ofwel “parsen”. Dat betekent dat de computer gaat analyseren welke informatie op een bepaalde plek in het log-bestandje staat, zodat het interpreteerbaar wordt.

Een log-regel ziet er bijvoorbeeld als volgt uit:

EFW: CONN: prio=1 rule=MailAllow conn=open connipproto=TCP connrecvif=int connsrcip=1.2.3.4 connsrcport=3359 conndestif=aux conndestip=2.3.4.5 conndestport=993

Dit voorbeeld is afkomstig van een Clavister Firewall. In dit voorbeeld vallen een paar dingen op. Ten eerste is het scheidingsteken tussen informatie een spatie tussen de tekst. Ten tweede valt de volgorde van informatie op en je ziet zaken als “connsrcip=1.2.3.4”. Dit laatste duidt aan van welk IP-adres het datapakketje afkomstig is. (Connection Source IP).

In een vergelijkbaar logbestand, van bijvoorbeeld een FortiGate Firewall, ziet zo’n logregel er heel anders uit. Hetzelfde source-IP adres zou worden aangeduid met “srcip=(1.2.3.4)” en zou op een andere positie in de log-regel staan.

Je kunt je voorstellen dat met veel verschillende merken security-producten in een omgeving het nogal lastig wordt om al die logging te interpreteren. Daarom kunnen de “log-collectors” naast het verzamelen van logging ook normaliseren.

De genormaliseerde logging wordt verzonden naar de SIEM-server en de originele logging wordt verzonden naar de log-manager.

De Log-manager

De Log-manager heb je nodig als je een incident forensisch wilt kunnen onderbouwen. Voor forensisch onderzoek is namelijk de originele logging nodig. Aangezien we zojuist geleerd hebben dat de log-collector de logging manipuleert (namelijk, normaliseert of parst), is dat forensisch gezien geen bewijslast meer.

De Log-manager ontvangt de ruwe logging en slaat deze versleuteld en cryptografisch ondertekent op. Zo kun je waarborgen dat deze logging de oorspronkelijke logging is, die niet gemanipuleerd is.

De SIEM-Server

This is where all the magic happens. De SIEM-server is de management console van de SOC-analist. In deze console tref je allerlei dashboards, analyse-schermen en rapportages. De SIEM-server kan met de genormaliseerde data interessante zaken gaan ontdekken. Je kunt bijvoorbeeld correlaties gaan leggen.

Een voorbeeld is dat een gebruiker zich om 9:24:36 aanmeldt op een lokaal werkstation. Je weet dat het lokaal is, omdat de user zich aanmeldt met een specifiek IP-adres, dat binnen het LAN zit. Om 9:53:22 meldt deze gebruiker zich nogmaals aan, maar nu via een VPN op de firewall. Het publieke IP-adres is geografisch gebonden aan Uzbekistan. Dit hoeft niets kwaadaardigs te betekenen, maar is toch op zijn minst onderzoekswaardig.

Normaliter zou dit niet opvallen. Er is bijna een half uur verstreken en dat betekent dat er bij een gemiddeld bedrijf van 500 medewerkers ruim 2,6 miljoen log-regels tussendoor zijn gekomen. Door gebruik te maken van de correlatieregels kan dit aan het licht komen en er melding van worden gedaan.

Nu is dit een vrij eenvoudig voorbeeld, maar het toont aan wat de mogelijkheden zijn van zo’n omgeving.

Welke logging stop ik dan in een SIEM?

Het antwoord op deze vraag kan niet heel eenvoudig gegeven worden. Het hangt er namelijk van af, wat je inzichtelijk wilt maken met een SIEM. En wat je inzichtelijk wilt maken met een SIEM, wordt meestal bepaald door een risico-analyse. Die risico-analyse laat zien welke assets voor jouw bedrijf kritiek zijn en welke minder kritiek zijn. Aan de hand daarvan kun je gaan bepalen welke logging (ofwel data-sources) relevante informatie kunnen opleveren rondom die assets. Dat is voor een bank anders dan voor een schoenenfabrikant. En voor die schoenenfabrikant is dat weer anders dan voor een e-commerce bedrijf. Het ene bedrijf verzamelt veel informatie, het andere bedrijf heeft veel digitale processen.

Als een risico-analyse is uitgevoerd, kun je een kwalificatie gaan toekennen aan de assets en kun je bepalen wat wel en niet mag met die assets. Als het goed is zijn er maatregelen genomen om toegang tot die assets te beperken. De logging van die assets en die van die maatregelen kunnen dan dus relevante informatie opleveren rondom de gebeurtenissen die plaatsvinden richting die assets.

Een verzameling maatregelen en assets kunnen bijvoorbeeld zijn: een active directory, een firewall, een intrusion detection system, de antivirus software en de logging van de betrokken assets.

Ok, got it. En nu verder…

Goed, de SIEM is ingericht en is druk bezig om alle informatie te parsen, te correleren en al dan niet te prioriteren, zodat het in de dashboards inzichtelijk kan worden gemaakt.

Nu is het dus zaak om iemand naar die dashboards te laten kijken. Als de SIEM namelijk iets roept over vreemd gedrag, moet er wel iemand zijn die dat vreemde gedrag kan gaan analyseren. “Wat gebeurd er precies? Met welke aanvalstechnieken wordt gewerkt? Vanwaar is het afkomstig? Is het een afleidingsmanoeuvre? Wat is het doelwit? Hoe ernstig is het?”

De mensen die dat goed kunnen opvolgen zijn SOC-analisten. SOC-analisten zijn mensen die doorgaans niet weten hoe je omgevingen moet installeren, updaten, patchen, etc, maar zijn juist mensen die een goed beeld hebben van de samenhang van alle systemen in een omgeving, waardoor zij “the bigger picture” kunnen doorgronden. De eigenschappen van deze mensen zijn anders. En je hebt ook verschillende eigenschappen nodig.

Je hebt bijvoorbeeld mensen nodig die malware kunnen analyseren. Dan krijg je een antwoord op vragen zoals waar de malware vandaan komt, wat het doel is en hoe het zich heeft kunnen manifesteren.

Maar je hebt ook mensen nodig die big-data kunnen analyseren. Er komt immers ongelofelijk veel data binnen, en daar moet je wat mee. Er zit misschien wel meer in die data verborgen dan wat de SIEM uit zichzelf bedenkt.

Grofweg, de ideale analist is iemand die algoritmes, software code, datastructuren, besturingssystemen, netwerken, big-data en kwetsbaarheden begrijpt. En nog veel meer. Daarnaast moet het een passie zijn, moeten ze leergierig zijn, nieuwsgierig, motivaties van aanvallers begrijpen en hun opdrachtgevers begrijpen.

Hoe ziet DearBytes security monitoring?

DearBytes levert security monitoring als dienst aan in twee smaken.

De eerste oplossing is gebaseerd op AlienVault. Deze oplossing combineert een aantal extra functies met de SIEM. Met behulp van AlienVault kunnen wij namelijk in kaart brengen welke systemen er bij jouw bedrijf aanwezig zijn. We kunnen dan samen gaan bekijken hoe we die systemen moeten kwalificeren. Als we dat gedaan hebben, gaan we deze systemen controleren op kwetsbaarheden. Zo weten we precies wat de zwakke plekken in de systemen zijn. Dat is voor ons prettig, wij weten nu waar we op moeten letten. Voor onze klant is dat ook prettig, je weet nu wat je moet oplossen.

Nu we weten wat de belangrijke systemen zijn en we weten ook wat de kwetsbaarheden van die systemen zijn, willen we graag weten wat er op die systemen af komt. Dat kunnen wij met behulp van AlienVault doen, door het netwerkverkeer te analyseren. AlienVault heeft daarvoor een Intrusion Detection Systeem (IDS) ingebouwd zitten. Deze IDS mag je vergelijken met een anti-inbraak alarm. Het kan patronen en abnormaliteiten herkennen en analyses doen op protocollen. Het kan bijvoorbeeld een zogenaamde ‘command and control’ sessie herkennen, of een poort-scan detecteren. Maar ziet ook wanneer opeens een ongebruikelijke stroom data het netwerk verlaat.