Bij Defenced zien we dat steeds meer van onze klanten gebruik maken van de cloud. En dat is niet gek. De snelheid en het gemak waarmee nieuwe systemen en services aangemaakt kunnen worden is ongekend, alsook de mate van schaalbaarheid. De cloud is dus zowel flexibel als elastisch.
Toch wordt het beveiligingsaspect vaak onderschat of vergeten. Moet ik nog denken aan cybersecurity bij een cloud-only model? Heeft het nog zin om een Security Operations Center (SOC) af te nemen of zijn de standaard services binnen de cloud al goed genoeg? Heeft een SOC eigenlijk wel inzicht in wat er zich daadwerkelijk afspeelt in mijn cloudomgeving? Op deze vragen geven we antwoord.
Servicemodellen in de cloud
De publieke cloud kent hoofdzakelijk drie servicemodellen. Dit zijn Infrastructure-as-a-Service (IaaS), Platform-as-a-service (PaaS) en Software-as-a-Service (SaaS).
Bij IaaS behoudt de gebruiker de controle over het systeem. Waar de daadwerkelijke hardware onzichtbaar is voor de gebruiker, is deze wel in controle over het besturingssysteem en alle applicaties die hierop draaien. Denk bij IaaS aan het aanmaken van virtuele machines met behulp van AWS EC2 of Microsoft Azure.
Voorbeelden van PaaS services zijn serverless computing zoals AWS Lambda of Azure Functions, maar ook databases als AWS DynamoDB en Azure CosmosDB. Deze services maakt de gebruiker aan zonder te hoeven zorgen voor de infrastructuur. De gehele hardware, besturingssysteem en het onderhoud van de applicatie zelf zijn onzichtbaar voor de gebruiker. Wel kan de gebruiker configuratie maken op gebied van networking (denk aan firewall rules) en de werking van de applicatie zelf.
In het SaaS model is de gebruiker alleen eigenaar van de toegang tot en de data in de applicatie. Een veel gebruikt voorbeeld is Microsoft 365. De werking, systemen, applicaties en het onderhoud daarvan zijn volledig onzichtbaar voor de gebruiker.
Gedeelde verantwoordelijkheid
Veel gebruikers denken onterecht dat het security vraagstuk bij de Cloud Service Provider (CSP) ligt. Zoals zojuist besproken is er een duidelijke scheiding in verantwoordelijkheid afhankelijk van het servicemodel wat gekozen wordt. CSPs zijn hier ook duidelijk over. Middels het gedeelde verantwoordelijkheidsmodel wordt aangegeven waar de verantwoordelijkheid ligt voor de beveiligingstaken. In de afbeelding hieronder wordt het model van Microsoft Azure weergeven. Dit vertaald zich echter moeiteloos naar andere CSPs als Amazon AWS, Google Cloud Platform en Oracle Cloud Infrastructure.
Niets staat de gebruiker in de weg om een publiek toegankelijke virtuele machine in de cloud te plaatsen met kwetsbaarheden. In het IaaS model, waar deze virtuele machines onder vallen, is de CSP alleen verantwoordelijk voor de beveiliging van de fysieke hardware. Hoewel in het PaaS model de CSP deels verantwoordelijk is voor de network controls, kun je als gebruiker je data per ongeluk open zetten voor het publieke internet. Alleen in het SaaS model is dit risico kleiner, maar is een goed uitgedacht proces voor access control een must.
SOC-as-a-Service in de cloud
Nu we weten dat een deel van de verantwoordelijk voor cybersecurity altijd bij de gebruiker ligt ongeacht het model, kunnen we kijken wat een SOC als Managed Security Service Provider (MSSP) voor meerwaarde kan bieden.
Een SOC heeft data nodig in de vorm van logs. Deze logs hangen af van het servicemodel dat gekozen is. Voor een volledige IaaS omgeving kan een SOC vaak net zo veel betekenen als bij een on-premise omgeving. De meeste grote CSPs ondersteunen een volledige mirror traffic, waarbij het verkeer van een interface of zelfs een heel subnet doorgestuurd kan worden naar een geplaatste Intrusion Detection System (IDS). Belangrijk is wel dat de IDS om kan gaan met VXLAN encapsulation.
Daarnaast heeft hier de gebruiker zelf de controle over de virtuele systemen, wat betekent dat agents geïnstalleerd kunnen worden voor het doorsturen van logs naar het SOC platform. Denk hierbij aan Windows Event Logs, Sysinternals Sysmon of Linux Syslog.
Voor PaaS oplossingen is de MSSP meer afhankelijk van het gekozen product en de mogelijkheden die de CSP biedt. Vaak heeft in het PaaS model de gebruiker de keuze tussen een aantal logging opties. Dit kan gescheiden worden in Control Plane logs en Data Plane logs. Control Plane logs gaan over de PaaS service zelf en zijn standaard beschikbaar, waar Data Plane logs over de inhoud gaan en zelf geconfigureerd moeten worden door de gebruiker. Een voorbeeld hiervan is de Azure CosmosDB. Aanpassingen aan de service zelf zijn standaard beschikbaar in de logs terwijl de gebruiker de logs voor alle interacties met de data zelf, zoals het verwijderen van data, zelf aan moet zetten.
Voor SaaS services is er vaak weinig te configureren. De beschikbaarheid van logs is vaak niet te configureren en kan ook afhangen van de afgenomen licentie. Denk hierbij aan Microsoft 365, waar een E5 licentie meer logs biedt dan een E3 licentie op het gebied van Exchange logging.
Daarnaast zien we vaak dat klanten de data wel hebben, maar er niet naar kijken. Vaak gaat het zelfs om belangrijke data, zoals alerts gegenereerd door EDR services als Microsoft Defender of AWS GuardDuty. Een SOC als MSSP kan hier een oplossing zijn, door alle vals positieven eruit te filteren en de meldingen waar actie op vereist is door te sturen naar de klant. Daarnaast kunnen deze meldingen met behulp van machine learning en AI aan andere databronnen gecorreleerd worden om zo een duidelijker beeld van een potentieel security incident te geven. Met alle verschillende databronnen binnen de cloud, vaak ook verspreid over alle 3 de servicemodellen, is het vaak lastig om zonder de juiste tools en expertise de gebeurtenissen te correleren.
Kennis en expertise
Nu we de logs hebben is het van belang dat deze ook begrepen worden door de analist van het SOC. Kennis van logs voor on-premise systemen vertalen zich goed naar het IaaS model. Voor PaaS en SaaS modellen is het van belang dat de kennis en expertise over het formaat en de inhoud van de logs aanwezig is. Specifieke vakkennis van cloud logs kan ook fouten voorkomen. Een voorbeeld hiervan zijn de Activity Logs in Microsoft Azure, wat alle activiteiten vastlegt op het gebied van het aanmaken, aanpassen en verwijderen van resources binnen de Azure omgeving. Wanneer een gebruiker dit doet via het Azure Portaal, wordt het IP-adres van de gebruiker in de logs foutief weergegeven als een IP-adres van Azure zelf. Onwetendheid van zulke specifieke details kan leiden tot foute conclusies.
Een SOC als MSSP heeft dus zeker meerwaarde voor zowel cloud-only als hybride omgevingen. De logs zijn beschikbaar en de toegevoegde kennis en expertise van een SOC voor zowel advies over de configuratie van de cloud services als de inhoud van de logs is nodig voor een geslaagde cybersecurity aanpak.
De Open-XDR (Open eXtended Detection and Response) structuur van het Defenced SOC platform maakt het mogelijk om zelfs de logs vanuit een on-premise omgeving te combineren met logs uit de cloud. Een Open-XDR SOC is een geïntegreerd cybersecurityplatform dat verschillende beveiligingstools en -technologieën samenbrengt om organisaties te helpen bij het detecteren, reageren op, en onderzoeken van bedreigingen en beveiligingsincidenten. Het combineert verschillende technologieën en benaderingen, waaronder Security Information and Event Management (SIEM), Security Orchestration, Automation, and Response (SOAR), Endpoint Detection and Response (EDR) en Network Detection and Response (NDR), om een holistische beveiligingsoplossing te bieden.
Respectievelijk zijn deze verantwoordelijk voor het verzamelen, normaliseren en analyseren loggegevens en beveiligingsinformatie van verschillende bronnen, het automatiseren en orchestreren van beveiligingsprocessen en reacties op beveiligingsincidenten, het detecteren en reageren op kwaadaardige activiteiten op endpoints, en het detecteren van verdacht netwerkverkeer. Dit alles is vendor onafhankelijk, wat zeker met een hybride IT landschap waar een deel in de cloud staat en een deel on-premise van grote meerwaarde is.
