🥇Cloud Security Monitoring

De overdracht van gegevens en applicaties naar de cloud vormt een nieuwe uitdaging voor zakelijke SOC's, die niet altijd zijn voorbereid op het monitoren van externe infrastructuren. Volgens Netoskope gebruikt een gemiddeld bedrijf (blijkbaar in de VS) 1246 verschillende cloudservices, wat 22% meer is dan vorig jaar. 1246 cloudservices!!! 175 daarvan hebben betrekking op HR-diensten, 170 op marketing, 110 in communicatie en 76 in financiën en CRM. Bij Cisco worden 'slechts' 700 externe cloudservices gebruikt. Daarom ben ik een beetje verbaasd over deze cijfers. Maar in ieder geval ligt het probleem niet bij de cijfers, maar bij het feit dat steeds meer bedrijven actief beginnen gebruik te maken van clouds, die dezelfde mogelijkheden voor het monitoren van cloudinfrastructuur willen hebben als in hun eigen netwerk. En deze trend neemt toe — volgens gegevens van het Amerikaanse Rekenkantoor zullen tegen 2023 in de VS 1200 datacenters sluiten (6250 zijn al gesloten). Maar de overstap naar de cloud is niet alleen maar "laten we onze servers naar een externe provider verplaatsen." Er is een nieuwe IT-architectuur, nieuwe software, nieuwe processen, nieuwe beperkingen... Dit brengt aanzienlijke veranderingen met zich mee, niet alleen voor IT, maar ook voor informatiebeveiliging. En hoewel providers in staat zijn om de veiligheid van de cloud zelf op de een of andere manier te waarborgen (gelukkig zijn er voldoende aanbevelingen), zijn er aanzienlijke uitdagingen met cloudmonitoring van informatiebeveiliging, vooral op SaaS-platforms, waarover we zullen praten.

Stel je voor dat jouw bedrijf een gedeelte van zijn infrastructuur naar de cloud heeft verplaatst... Stop. Niet zo. Als de infrastructuur al is verplaatst en je nu pas gaat nadenken over hoe je deze gaat monitoren, dan heb je al verloren. Tenzij het Amazon, Google of Microsoft is (en zelfs dan met de nodige kanttekeningen), zal je waarschijnlijk niet veel mogelijkheden hebben om je gegevens en applicaties te monitoren. Het is goed als men je de mogelijkheid geeft om met logboeken te werken. Soms zijn gegevens over beveiligingsgebeurtenissen beschikbaar, maar heb je er geen toegang toe. Bijvoorbeeld, Office 365. Als je de goedkoopste E1-licentie hebt, zijn beveiligingsgebeurtenissen helemaal niet toegankelijk voor jou. Bij een E3-licentie worden gegevens slechts 90 dagen bewaard en alleen met een E5-licentie is de duur van de logboeken beschikbaar voor een jaar (hoewel hier ook nuances mee gemoeid zijn, zoals de noodzaak om specifieke functies voor logbeheer afzonderlijk aan Microsoft-ondersteuning aan te vragen). Overigens is de E3-licentie veel beperkt in termen van monitoringfunctionaliteiten in vergelijking met de bedrijfsversie van Exchange. Om hetzelfde niveau te bereiken, heb je een E5-licentie of een aanvullende licentie voor Advanced Compliance nodig, wat extra kosten met zich mee kan brengen die niet in je financiële model voor de overgang naar cloudinfrastructuur zijn opgenomen. En dit is slechts één voorbeeld van de onderschatting van vragen met betrekking tot de monitoring van cloudbeveiliging. In dit artikel wil ik, zonder pretentie op volledigheid, de aandacht vestigen op enkele nuances die in overweging moeten worden genomen bij het kiezen van een cloudprovider vanuit beveiligingsperspectief. Aan het eind van het artikel zal er een checklist worden gegeven die je moet doorlopen voordat je kunt stellen dat de kwestie van cloudbeveiligingsmonitoring voor jou is opgelost.

Er zijn verschillende typische problemen die leiden tot incidenten in cloudomgevingen, waarop beveiligingsdiensten niet snel genoeg kunnen reageren of deze helemaal niet opmerken:

Beveiligingslogboeken bestaan niet. Dit is een vrij voorkomende situatie, vooral bij nieuwe spelers op de markt van cloudoplossingen. Maar je moet ze ook niet meteen afschrijven. Kleinere spelers, vooral inheems, zijn vaak gevoeliger voor de eisen van klanten en kunnen snel bepaalde gevraagde functies implementeren door hun goedgekeurde roadmap voor hun producten aan te passen. Ja, het zal geen GuardDuty van Amazon of de module “Proactieve Beveiliging” van Bitrix zijn, maar het is in ieder geval iets.
De informatiebeveiliging weet niet waar de logs zijn opgeslagen of heeft geen toegang tot hen. Het is noodzakelijk om in gesprek te gaan met de cloudprovider — mogelijk kan hij dergelijke informatie verstrekken als hij de klant als belangrijk beschouwt. Over het algemeen is het echter niet goed wanneer toegang tot logs alleen op 'bijzondere beslissing' wordt verleend.
Het komt ook voor dat de logs bij de cloudleverancier aanwezig zijn, maar dat ze beperkte monitoring en registratie van gebeurtenissen bieden, wat onvoldoende is om alle incidenten te detecteren. Zo kunt u alleen logs krijgen van wijzigingen op de website of logs van gebruikersauthenticatiepogingen, terwijl andere gebeurtenissen, zoals netwerkverkeer, niet worden verstrekt, waardoor een totaalbeeld van pogingen om uw cloudinfrastructuur te hacken verloren gaat.
De logs zijn aanwezig, maar de toegang daartoe is moeilijk te automatiseren, waardoor ze niet continu worden gemonitord, maar volgens een schema. En als het ook nog eens onmogelijk is om logs automatisch te extraheren, dan kan het exporteren van logs, bijvoorbeeld in Excel-formaat (zoals bij sommige binnenlandse leveranciers van cloudoplossingen), ervoor zorgen dat de IT-beveiligingsdienst er helemaal niet mee bezig wil zijn.
Er is geen logmonitoring. Dit is waarschijnlijk de meest onbegrijpelijke reden voor het ontstaan van IT-beveiligingsincidenten in cloudomgevingen. Het lijkt erop dat de logs aanwezig zijn en dat toegang geautomatiseerd kan worden, maar niemand doet het. Waarom?

Het concept van gedeelde cloudbeveiliging

De overgang naar de cloud is altijd een zoektocht naar de balans tussen de wens om controle over de infrastructuur te behouden en deze over te dragen aan de meer professionele handen van een cloudprovider, die zich richt op het onderhoud ervan. Ook op het gebied van de beveiliging van cloudomgevingen moet deze balans worden gezocht. Bovendien zal deze balans, afhankelijk van het aangeboden model van clouddiensten (IaaS, PaaS, SaaS), steeds anders zijn. In alle gevallen moet men zich realiseren dat alle cloudproviders tegenwoordig de zogenaamde gedeelde verantwoordelijkheid en gedeelde informatiebeveiliging volgen. De cloud is verantwoordelijk voor bepaalde zaken, terwijl de klant, die zijn gegevens, applicaties, virtuele machines en andere bronnen in de cloud plaatst, voor andere zaken verantwoordelijk is. Het zou onverstandig zijn om te denken dat we, door naar de cloud over te stappen, al de verantwoordelijkheid op de provider kunnen afschuiven. Maar het is ook niet verstandig om bij de overstap naar de cloud de hele beveiliging zelf te moeten opbouwen. Een balans is noodzakelijk, afhankelijk van verschillende factoren: - risicobeheerstrategieën, dreigingsmodellen, de beschikbare beveiligingsmechanismen van de cloudprovider, wetgeving, enz.

Bijvoorbeeld, de classificatie van gegevens die in de cloud worden geplaatst, is altijd de verantwoordelijkheid van de klant. De cloudprovider of externe dienstverlener kan alleen helpen met hulpmiddelen die helpen bij het labelen van gegevens in de cloud, het identificeren van inbreuken, het verwijderen van wettelijk onwettige gegevens of het verhullen ervan met behulp van verschillende methoden. Aan de andere kant is de fysieke beveiliging altijd de verantwoordelijkheid van de cloudprovider, die deze niet met klanten kan delen. Wat zich echter tussen de gegevens en de fysieke infrastructuur bevindt, is precies het onderwerp van dit artikel. De beschikbaarheid van de cloud is de verantwoordelijkheid van de provider, terwijl de instellingen voor ISMS-regels of het inschakelen van encryptie de verantwoordelijkheid van de klant zijn. In dit artikel zullen we proberen te onderzoeken welke mechanisms voor het monitoren van informatiebeveiliging vandaag de dag door verschillende populaire cloudproviders in Rusland worden aangeboden, wat de bijzonderheden van hun toepassing zijn en wanneer het verstandig is om externe oplossingen (zoals Cisco E-mail Security) te bekijken die de mogelijkheden van uw cloud op het gebied van cyberbeveiliging uitbreiden. In sommige gevallen, vooral bij het volgen van een multi-cloudstrategie, heeft u geen andere keuze dan externe monitoringoplossingen voor informatiebeveiliging in meerdere cloudomgevingen te gebruiken (zoals Cisco CloudLock of Cisco Stealthwatch Cloud). In andere gevallen zult u merken dat de door u geselecteerde (of opgelegde) cloudprovider helemaal geen mogelijkheden voor het monitoren van informatiebeveiliging biedt. Dit is vervelend, maar ook waardevol, omdat het een eerlijke inschatting van het risiconiveau met betrekking tot het werken met deze cloud mogelijk maakt.

Levenscyclus van cloudbeveiligingsmonitoring

Om de beveiliging van uw gebruikte clouds te monitoren, heeft u slechts drie mogelijkheden:

vertrouwen op de tools die door uw cloudprovider worden aangeboden,
gebruik maken van oplossingen van derde partijen die de door u gebruikte IaaS-, PaaS- of SaaS-platforms monitoren,
uw eigen monitoringinfrastructuur voor cloudomgevingen opbouwen (alleen voor IaaS/PaaS-platforms).

Laten we eens kijken naar de kenmerken van elk van deze opties. Maar eerst moeten we de algemene structuur begrijpen die zal worden gebruikt voor het monitoren van cloudplatforms. Ik zou zes belangrijke componenten van het monitoringproces voor informatiebeveiliging in de cloud willen onderscheiden:

Voorbereiding van de infrastructuur. Bepalen van de benodigde applicaties en infrastructuur voor het verzamelen van belangrijke evenementen voor informatiebeveiliging in de opslag.
Verzameling. In deze fase worden beveiligingsevents samengevoegd uit verschillende bronnen voor verdere verwerking, opslag en analyse.
Verwerking. In deze fase worden de gegevens omgevormd en verrijkt om de latere analyse te vergemakkelijken.
Opslag. Deze component is verantwoordelijk voor de korte- en langetermijnopslag van de verzamelde verwerkte en 'ruwe' gegevens.
Analyse. In deze fase heeft u de mogelijkheid om incidenten te detecteren en daarop te reageren in een automatische of handmatige modus.
Rapportage. Deze fase helpt bij het opstellen van belangrijke indicatoren voor belanghebbenden (leidinggevenden, auditors, cloudprovider, klanten, enz.) die ons helpen beslissingen te nemen, bijvoorbeeld het wisselen van provider of het versterken van informatiebeveiliging.

Inzicht in deze componenten stelt u in staat om snel te bepalen wat u van uw provider kunt gebruiken en wat u zelf of met externe consultants moet doen.

Ingebouwde mogelijkheden van cloudservices

Ik heb eerder al vermeld dat veel clouddiensten vandaag de dag geen enkel monitoring voor informatiebeveiliging bieden. Over het algemeen besteden ze er niet veel aandacht aan. Bijvoorbeeld, een van de populaire Russische diensten voor het indienen van rapporten bij overheidsinstanties via het internet (ik zal de naam niet noemen). Het hele gedeelte over de veiligheid van deze dienst draait om het gebruik van gecertificeerde cryptografische middelen. Het gedeelte over informatiebeveiliging van een andere binnenlandse cloudservice voor elektronische documentverwerking is aanzienlijk uitgebreider. Het gaat daar over certificaten voor openbare sleutels, gecertificeerde cryptografie, het verhelpen van webkwetsbaarheden, bescherming tegen DDoS-aanvallen, de toepassing van beveiligingsmaatregelen, back-ups en zelfs het regelmatig uitvoeren van informatiebeveiligingsaudits. Maar er staat niets over monitoring, noch over de mogelijkheid om toegang te krijgen tot informatiebeveiligingsgebeurtenissen die interessant kunnen zijn voor de klanten van deze dienstverlener.

Over het algemeen kun je aan de manier waarop een cloudprovider informatiebeveiliging beschrijft op zijn website en in de documentatie, zien hoe serieus hij dit onderwerp neemt. Bijvoorbeeld, als je de handleidingen voor de producten van "Mijn kantoor" leest, is er helemaal niets over veiligheid, en in de documentatie voor een afzonderlijk product "Mijn kantoor. KS3", bedoeld voor bescherming tegen ongeautoriseerde toegang, staat er alleen een opsomming van de punten uit het 17e besluit van de FSTEC, dat "Mijn kantoor.KS3" uitvoert, maar er wordt niet beschreven hoe het wordt uitgevoerd en, het belangrijkst, hoe deze mechanismen geïntegreerd kunnen worden met de bedrijfsinformatiebeveiliging. Misschien is zo'n documentatie er wel, maar ik heb het niet kunnen vinden op de publieke website van "Mijn kantoor". Misschien heb ik gewoon geen toegang tot deze geheime informatie?

Bij Bitrix is de situatie aanzienlijk beter. In de documentatie zijn de formaten van de gebeurtenislogboeken beschreven en, interessant genoeg, het inbraaklogboek, dat gebeurtenissen bevat die verband houden met potentiële bedreigingen voor het cloudplatform. Daaruit kunt u IP-adressen, gebruikers- of gastnamen, de bron van de gebeurtenis, tijd, User Agent, type gebeurtenis enzovoort halen. Echter, u kunt met deze gebeurtenissen werken via het beheerpaneel van de cloud of de gegevens exporteren in MS Excel-formaat. Het is momenteel moeilijk om met de logboeken van Bitrix te automatiseren, en u zult een deel van het werk handmatig moeten doen (het rapport exporteren en het in uw SIEM laden). Maar als we ons herinneren dat er nog niet zo lang geleden geen mogelijkheid was, dan is dit grote vooruitgang. Daarbij wil ik opmerken dat veel buitenlandse cloudproviders ook soortgelijke functionaliteiten aanbieden 'voor beginners' – of bekijk de logs handmatig via het beheerpaneel, of exporteer de gegevens naar uw systeem (hoewel de meeste de gegevens in .csv-formaat exporteren, en niet in Excel).

Als we de optie van het ontbreken van logs negeren, bieden cloudproviders doorgaans drie opties voor het monitoren van beveiligingsevenementen aan — dashboards, gegevensexport en toegang via API. Het eerste lijkt veel problemen voor je op te lossen, maar dat is niet helemaal waar; bij meerdere logs moet je tussen de schermen schakelen die ze tonen, waardoor je het totaalbeeld verliest. Bovendien zal de cloudprovider je waarschijnlijk niet de mogelijkheid bieden om beveiligingsevenementen te correleren en überhaupt te analyseren vanuit een beveiligingsperspectief (meestal heb je te maken met ruwe gegevens, die je zelf moet doorgronden). Er zijn uitzonderingen, en daar zullen we later op ingaan. Het is tenslotte ook belangrijk om te vragen welke gebeurtenissen je cloudprovider vastlegt, in welk formaat, en hoe goed deze aansluiten bij jouw informatiebeveiligingsmonitoringproces. Bijvoorbeeld, de identificatie en authenticatie van gebruikers en gasten. Bitrix zelf stelt je in staat om op basis van deze gegevens de datum en het tijdstip van het evenement, de naam van de gebruiker of gast (indien de module “Webanalyse” beschikbaar is), het object waarmee toegang is verkregen en andere typische elementen van een website vast te leggen. Maar voor corporate securitydiensten kan het nodig zijn om informatie te krijgen over of de gebruiker vanaf een vertrouwd apparaat in de cloud inlogde (bijvoorbeeld, in een bedrijfsnetwerk wordt deze taak door Cisco ISE uitgevoerd). En een zo eenvoudige functie als geo-IP, die helpt bepalen of het account van de gebruiker van de cloudservice niet is gestolen? En zelfs als de cloudprovider deze aanbiedt, is dat niet voldoende. Cisco CloudLock analyseert niet alleen de geolocatie; het maakt ook gebruik van machine learning en analyseert historische gegevens van elke gebruiker en volgt verschillende anomalieën in pogingen tot identificatie en authenticatie. Een vergelijkbare functionaliteit is alleen beschikbaar bij MS Azure (met een overeenkomstige abonnementsvorm).

Er is nog een complicatie — aangezien voor veel cloudproviders het monitoren van informatiebeveiliging een nieuw onderwerp is waar ze net mee beginnen, veranderen ze voortdurend iets in hun oplossingen. Vandaag hebben ze één versie van de API, morgen een andere, en overmorgen weer een derde. Hierop moet je ook voorbereid zijn. Hetzelfde geldt voor functionaliteit, die kan veranderen en waarmee je rekening moet houden in je informatiebeveiligingsmonitoringsysteem. Bijvoorbeeld, Amazon had aanvankelijk aparte services voor het monitoren van cloudgebeurtenissen — AWS CloudTrail en AWS CloudWatch. Toen werd er een aparte service voor het monitoren van informatiebeveiliging gecreëerd — AWS GuardDuty. En na enige tijd lanceerde Amazon een nieuw beheersysteem, Amazon Security Hub, dat analyses van gegevens van GuardDuty, Amazon Inspector, Amazon Macie en andere omvat. Een ander voorbeeld is het gereedschap voor logintegratie van Azure met SIEM — AzLog. Veel SIEM-leveranciers maakten er actief gebruik van totdat Microsoft in 2018 aankondigde de ontwikkeling en ondersteuning ervan te stopzetten, wat veel klanten die dit hulpmiddel gebruikten voor een probleem stelde (hoe dit werd opgelost, zullen we later bespreken).

Houd daarom alle monitoringfuncties die jouw cloudprovider aanbiedt nauwlettend in de gaten. Of vertrouw op externe leveranciers van oplossingen die als tussenpersonen kunnen optreden tussen jouw SOC en de cloud die je wilt monitoren. Ja, dit zal duurder zijn (hoewel niet altijd), maar je schuift daarmee de volledige verantwoordelijkheid op anderen. Of toch niet helemaal? Laten we de conceptie van gedeelde verantwoordelijkheid heroverwegen en begrijpen dat we niets kunnen afschuiven — we zullen zelf moeten begrijpen hoe verschillende cloudproviders de monitoring van de informatiebeveiliging van jouw gegevens, applicaties, virtuele machines en andere in de cloud gehoste bronnen waarborgen. We beginnen met wat Amazon op dit gebied aanbiedt.

Voorbeeld: Informatiebeveiligingsmonitoring in IaaS op basis van AWS

Ja, ik begrijp dat Amazon niet het beste voorbeeld is, gezien het feit dat het een Amerikaanse service is en deze mogelijk geblokkeerd kan worden in het kader van de strijd tegen extremisme en de verspreiding van verboden informatie in Rusland. Maar in deze publicatie wil ik gewoon aantonen hoe verschillend de verschillende cloudplatformen zijn in termen van monitoring van informatiebeveiliging en waar je op moet letten bij het overdragen van je belangrijkste processen naar de cloud vanuit een beveiligingsperspectief. En als een van de Russische ontwikkelaars van cloudoplossingen hier iets nuttigs uit kan halen, zou dat geweldig zijn.

Allereerst moet ik zeggen dat Amazon geen ondoordringbare vesting is. Klanten hebben regelmatig te maken met verschillende incidenten. Bijvoorbeeld, bij Deep Root Analytics zijn 198 miljoen namen, adressen, geboortedatums en telefoonnummers van kiezers gestolen. Bij het Israëlische bedrijf Nice Systems zijn 14 miljoen abonnementgegevens van Verizon gestolen. Toch stellen de ingebouwde mogelijkheden van AWS je in staat om een breed scala aan incidenten te detecteren. Bijvoorbeeld:

invloed op de infrastructuur (DDoS)
compromittering van een knooppunt (invoegen van commando's)
compromittering van accounts en ongeautoriseerde toegang
onjuiste configuratie en kwetsbaarheden
ongeschikte interfaces en API's.

Deze discrepantie is te wijten aan het feit dat de klant zelf verantwoordelijk is voor de beveiliging van zijn gegevens, zoals we hierboven hebben vastgesteld. En als hij niet heeft gezorgd voor de inschakeling van beschermingsmechanismen en monitoringtools, dan verneemt hij pas van het incident via de media of van zijn klanten.

Om incidenten te identificeren, kunnen een breed scala aan verschillende monitoringsdiensten van Amazon worden gebruikt (hoewel deze vaak worden aangevuld met externe tools, zoals osquery). In AWS worden alle acties van gebruikers gevolgd, ongeacht hoe deze worden uitgevoerd — via de beheerdersconsole, de opdrachtregel, SDK of andere AWS-diensten. Alle logboeken van acties van elke AWS-account (inclusief gebruikersnaam, actie, dienst, parameters van activiteit en de uitkomst) en het gebruik van de API zijn beschikbaar via de AWS CloudTrail-dienst. U kunt deze gebeurtenissen (zoals inloggen op de AWS IAM-console) bekijken vanuit de CloudTrail-console, ze analyseren met Amazon Athena of ze doorgeven aan externe oplossingen zoals Splunk, AlienVault, enzovoort. De AWS CloudTrail-logs worden opgeslagen in uw AWS S3-bucket.

Twee andere AWS-diensten bieden nog een aantal belangrijke monitoringmogelijkheden. Ten eerste is Amazon CloudWatch een monitoringsdienst voor AWS-resources en -toepassingen, waarmee onder andere verschillende anomalieën in uw cloud kunnen worden gekend. Alle ingebouwde AWS-diensten, zoals Amazon Elastic Compute Cloud (servers), Amazon Relational Database Service (databases), Amazon Elastic MapReduce (data-analyse) en nog eens 30 andere Amazon-diensten, gebruiken Amazon CloudWatch om hun logboeken op te slaan. Ontwikkelaars kunnen de openbare API van Amazon CloudWatch gebruiken om monitoringfunctionaliteit toe te voegen aan hun eigen toepassingen en diensten, waardoor het scala aan te analyseren gebeurtenissen in de context van informatiebeveiliging wordt uitgebreid.

Ten tweede laat de VPC Flow Logs-dienst u het netwerkverkeer analyseren dat door of naar uw AWS-servers wordt verzonden (van buiten of van binnen) en ook tussen microservices. Wanneer een van uw AWS VPC-resources met het netwerk communiceert, legt de VPC Flow Logs-dienst gegevens vast over het netwerkverkeer, inclusief het netwerkinterface van de bron en bestemming, evenals IP-adressen, poorten, protocol, het aantal bytes en het aantal pakketten dat u heeft gezien. Degenen die ervaring hebben met lokale netwerksveiligheid zullen dit als analoog beschouwen aan flows. NetFlow, die kunnen worden aangemaakt door switches, routers en firewalls van ondernemingskwaliteit. Deze logboeken zijn belangrijk voor informatiebeveiligingsmonitoring, omdat ze, in tegenstelling tot gebeurtenissen van gebruikers en applicaties, ook netwerkinteracties binnen een virtuele privé-cloudomgeving AWS kunnen vastleggen.

Deze drie AWS-diensten - AWS CloudTrail, Amazon CloudWatch en VPC Flow Logs - bieden samen een behoorlijk effectief overzicht van het gebruik van uw account, het gedrag van gebruikers, het beheer van infrastructuur, de activiteit van applicaties en diensten, evenals netwerkactiviteit. Zo kunnen ze helpen bij het detecteren van de volgende anomalieën:

Pogingen tot het scannen van de site, het zoeken naar backdoors, het zoeken naar kwetsbaarheden via pieken in “404-fouten”.
Injection-aanvallen (bijvoorbeeld SQL-injectie) via pieken in “500-fouten”.
Bekende hulpmiddelen voor aanvallen zoals sqlmap, nikto, w3af, nmap enzovoort, via analyse van het User Agent-veld.

Amazon Web Services heeft ook andere diensten ontwikkeld voor cyberbeveiliging die veel verschillende taken kunnen oplossen. Bijvoorbeeld, binnen AWS is er een ingebouwde dienst voor het auditen van beleidsregels en configuraties - AWS Config. Deze dienst zorgt voor een voortdurende audit van uw AWS-resources en hun configuraties. Laten we een eenvoudig voorbeeld bekijken: stel dat u wilt controleren of gebruikerswachtwoorden zijn uitgeschakeld op al uw servers en dat toegang alleen mogelijk is op basis van certificaten. AWS Config maakt het eenvoudig om dit voor al uw servers te verifiëren. Er zijn ook andere beleidsregels die op uw cloudservers kunnen worden toegepast: 'Geen enkele server mag poort 22 gebruiken', 'Alleen beheerders mogen firewallregels wijzigen' of 'Alleen gebruiker Ivasjko mag nieuwe gebruikersaccounts aanmaken, en hij kan dit alleen op dinsdag doen'. In de zomer van 2016 werd de dienst AWS Config uitgebreid om het ontdekken van schendingen van gedefinieerde beleidsregels te automatiseren. AWS Config Rules zijn in feite continue configuratiequeries voor de door u gebruikte Amazon-diensten, die gebeurtenissen genereren in het geval van schendingen van de relevante beleidsregels. Bijvoorbeeld, in plaats van periodiek AWS Config-queriën uit te voeren om te controleren of alle schijven van de virtuele server zijn versleuteld, kunnen AWS Config Rules worden gebruikt voor permanente controles van serverdisks om te voldoen aan deze voorwaarde. En, wat het belangrijkst is in de context van deze publicatie, schendingen genereren gebeurtenissen die geanalyseerd kunnen worden door uw informatiebeveiligingsdienst.

AWS heeft ook zijn equivalenten van traditionele bedrijfsoplossingen voor informatiebeveiliging, die ook beveiligingsgebeurtenissen genereren die u kunt en moet analyseren:

inbraakdetectie - AWS GuardDuty
informatie lekcontrole - AWS Macie
EDR (hoewel het een beetje vreemd is om het over eindpunten in de cloud te hebben) - AWS Cloudwatch + open source oplossingen osquery of GRR
Netflow-analyse - AWS Cloudwatch + AWS VPC Flow
DNS-analyse - AWS Cloudwatch + AWS Route53
AD - AWS Directory Service
accountbeheer - AWS IAM
SSO - AWS SSO
kwetsbaarheid analyse - AWS Inspector
configuratiebeheer - AWS Config
WAF - AWS WAF.

Ik zal niet in detail ingaan op alle Amazon-diensten die nuttig kunnen zijn op het gebied van informatiebeveiliging. Het belangrijkste is te begrijpen dat ze allemaal gebeurtenissen kunnen genereren die we kunnen en moeten analyseren in de context van informatiebeveiliging, waarbij we zowel de ingebouwde mogelijkheden van Amazon zelf als externe oplossingen, zoals SIEM, kunnen inzetten die deze beveiligingsgebeurtenissen naar uw monitoringcentrum kunnen sturen voor analyse, samen met gebeurtenissen van andere cloudservices of van interne infrastructuur, perimeter of mobiele apparaten.

In ieder geval begint alles met de databronnen die u voorzien van informatiebeveiligingsgebeurtenissen. Tot deze bronnen behoren onder andere:

CloudTrail – gebruik van API's en gebruikersacties
Trusted Advisor – veiligheidschecks op naleving van best practices
Config – inventarisatie en configuratie van accounts en service-instellingen
VPC Flow Logs – verbindingen met virtuele interfaces
IAM – identificatie- en authenticatieservice
ELB Access Logs – van de load balancer
Inspector – kwetsbaarheden in applicaties
S3 – opslag voor bestanden
CloudWatch – activiteit van applicaties
SNS – notificatieservice.

Amazon, met een breed scala aan evenementbronnen en tools voor hun generatie, is echter zeer beperkt in de mogelijkheden om de verzamelde gegevens te analyseren in de context van informatiebeveiliging. U zult de beschikbare logs zelf moeten bestuderen om relevante indicatoren van compromittering te vinden. AWS Security Hub, dat recent door Amazon is gelanceerd, is bedoeld om dit probleem op te lossen en fungeert als een soort cloud SIEM voor AWS. Maar het staat nog aan het begin van zijn pad en is beperkt in zowel het aantal bronnen waarmee het werkt als andere beperkingen die zijn ingesteld door de architectuur en abonnementen van Amazon.

Voorbeeld: Informatiebeveiligingsmonitoring in IaaS op basis van Azure

Ik wil niet in een lange discussie treden over welke van de drie cloudproviders (Amazon, Microsoft of Google) beter is (omdat elke provider immers zijn eigen specifieke kenmerken heeft en geschikt is voor verschillende doeleinden); laten we ons concentreren op de mogelijkheden voor monitoring van informatiebeveiliging die deze spelers bieden. We moeten erkennen dat Amazon AWS een van de eersten in dit segment was en daarom verder gevorderd is dan de rest als het gaat om zijn functionaliteit op het gebied van informatiebeveiliging (hoewel velen erkennen dat het gebruik ervan vrij ingewikkeld is). Maar dat betekent niet dat we de mogelijkheden die Microsoft en Google bieden, over het hoofd zien.

De producten van Microsoft hebben altijd gekenmerkt door hun 'openheid' en de situatie in Azure is vergelijkbaar. Bijvoorbeeld, als AWS en GCP altijd uitgaan van het principe 'alles wat niet is toegestaan, is verboden', dan is de aanpak van Azure juist het tegenovergestelde. Bij het aanmaken van een virtueel netwerk in de cloud en een virtuele machine daarin, zijn alle poorten en protocollen standaard open en toegestaan. Daarom moet je iets meer moeite doen voor de initiële configuratie van het systeem voor toegangscontrole in de cloud van Microsoft. Dit legt ook strengere eisen op wat betreft het monitoren van de activiteit in de Azure-cloud.

AWS heeft een kenmerk waarbij, wanneer je je virtuele bronnen monitort in verschillende regio's, je problemen ondervindt met het consolideren van alle gebeurtenissen en de uniforme analyse ervan. Hiervoor moet je verschillende technieken toepassen, zoals het maken van je eigen code voor AWS Lambda, die gebeurtenissen tussen regio's verplaatst. In Azure is dit probleem er niet - de mechanisme van het Activity Log volgt alle activiteiten binnen de hele organisatie zonder beperkingen. Hetzelfde geldt voor AWS Security Hub, dat recentelijk door Amazon is ontwikkeld om veel beveiligingsfuncties te consolideren binnen één beveiligingscentrum, maar alleen binnen zijn eigen regio, wat in feite voor Rusland niet relevant is. Azure heeft zijn eigen Security Center, dat niet onderhevig is aan regionale beperkingen, en toegang biedt tot alle beveiligingsfuncties van het cloudplatform. Bovendien kan het verschillende lokale teams hun eigen set beveiligingsmogelijkheden bieden, inclusief beheerde beveiligingsincidenten. AWS Security Hub is nog steeds bezig met het worden van iets wat lijkt op het Azure Security Center. Maar er is ook een keerzijde - je kunt veel uit Azure halen wat eerder in AWS is beschreven, maar dat is voornamelijk handig voor Azure AD, Azure Monitor en Azure Security Center. Alle andere beveiligingsmechanismen van Azure, inclusief de analyse van beveiligingsgebeurtenissen, worden nog niet op de meest gebruiksvriendelijke manier beheerd. Een deel van het probleem wordt opgelost door de API, die door alle Microsoft Azure-services heen loopt, maar dit vereist extra inspanningen om je cloud met je SOC te integreren en gekwalificeerde specialisten te hebben (net als met elke andere SIEM die met cloud-API's werkt). Sommige SIEM's, waar we later op terugkomen, ondersteunen al Azure en kunnen de taak van monitoring automatiseren, maar ook daar zijn er complicaties - niet alle kunnen alle logs ophalen die beschikbaar zijn in Azure.

Het verzamelen van gebeurtenissen en hun monitoring in Azure wordt verzorgd door de Azure Monitor-service, die de belangrijkste tool is voor het verzamelen, opslaan en analyseren van gegevens in de cloud van Microsoft en zijn bronnen — Git-repositories, containers, virtuele machines, applicaties, enz. Alle gegevens die door Azure Monitor worden verzameld, zijn verdeeld in twee categorieën — statistieken, die in realtime worden verzameld en de belangrijkste prestatie-indicatoren van de Azure-cloud beschrijven, en logboeken, die gegevens bevatten die zijn georganiseerd in records die bepaalde aspecten van de activiteiten van Azure-resources en -diensten karakteriseren. Bovendien kan de Azure Monitor-service met behulp van de Data Collector API gegevens verzamelen van elke REST-bron om eigen monitoringscenario's op te stellen.

Hier zijn enkele bronnen voor beveiligingsgebeurtenissen die Azure u biedt en waartoe u toegang kunt krijgen via het Azure Portal, CLI, PowerShell of REST API (sommige alleen via de Azure Monitor / Insight API):

Activiteitslogboeken — dit logboek beantwoordt klassieke vragen als “wie”, “wat” en “wanneer” met betrekking tot elke opname-operatie (PUT, POST, DELETE) op cloudbronnen. Gebeurtenissen die verband houden met leestoegang (GET) worden niet in dit logboek opgenomen, evenals een aantal andere.
Diagnostische logboeken — bevatten gegevens over bewerkingen met een bepaalde resource binnen uw abonnement.
Azure AD-rapportage — bevat zowel gebruikersactiviteit als systeemactiviteit die verband houdt met het beheer van groepen en gebruikers.
Windows Event Log en Linux Syslog — bevatten gebeurtenissen van virtuele machines die in de cloud worden gehost.
Statistieken — bevatten telemetrie over de prestaties en ‘gezondheid’ van uw cloudservices en -bronnen. Ze worden elke minuut gemeten en 30 dagen lang bewaard.
Netwerkbeveiligingsgroep Flow Logs — bevatten gegevens over netwerkbeveiligingsgebeurtenissen die worden verzameld met de Network Watcher-service en netwerkresource-monitoring.
Opslaglogboeken — bevatten gebeurtenissen die verband houden met de toegang tot opslag.

Voor monitoring kunt u externe SIEM-systemen of de ingebouwde Azure Monitor en zijn extensies gebruiken. We zullen later nog over informatiebeveiligingsbeheersystemen praten, maar laten we eerst bekijken wat Azure zelf biedt voor data-analyse in de context van beveiliging. Het belangrijkste scherm voor alles wat met beveiliging in Azure Monitor te maken heeft, is het Log Analytics Security and Audit Dashboard (de gratis versie ondersteunt de opslag van een beperkt aantal gebeurtenissen, slechts één week). Dit dashboard is verdeeld in 5 hoofdgebieden die samenvattende statistieken visualiseren over wat er gebeurt in uw cloudomgeving:

Beveiligingsdomeinen — belangrijke kwantitatieve indicatoren die verband houden met informatiebeveiliging — het aantal incidenten, het aantal gecompromitteerde knooppunten, niet-gepatchte knooppunten, gebeurtenissen met netwerkbeveiliging, enzovoort.
Belangrijke problemen — toont het aantal en de ernst van actieve informatiebeveiligingsproblemen
Detecties — toont de patronen van aanvallen die tegen u zijn uitgevoerd
Bedreigingsinformatie — toont geografische informatie over externe knooppunten die u aanvallen
Veelvoorkomende beveiligingsvragen — typische vragen die u helpen uw informatiebeveiliging beter te monitoren.

Als extensies van Azure Monitor kunnen we Azure Key Vault noemen (beveiliging van cryptografische sleutels in de cloud), Malware Assessment (analyse van de bescherming tegen malware op virtuele machines), Azure Application Gateway Analytics (analyse van onder andere logs van de cloudfirewall), enzovoort. Deze tools, verrijkt met bepaalde regels voor het verwerken van gebeurtenissen, stellen u in staat verschillende aspecten van cloudservices te visualiseren, inclusief beveiliging, en afwijkingen van de normale werking te identificeren. Maar zoals vaak het geval is, vereist elke extra functionaliteit een bijbehorende betaalde abonnementsvorm, wat van u de nodige financiële inbreng vraagt die u van tevoren moet plannen.

Azure beschikt over een reeks ingebouwde mogelijkheden voor dreigingsmonitoring, die zijn geïntegreerd in Azure AD, Azure Monitor en Azure Security Center. Dit omvat onder andere het detecteren van interactie tussen virtuele machines en bekende kwaadaardige IP-adressen (door de integratie met de Threat Intelligence-services van Microsoft), het detecteren van malware in de cloudinfrastructuur dankzij waarschuwingen van virtuele machines die zich in de cloud bevinden, aanvallen zoals ‘wachtwoordkraken’ op virtuele machines, kwetsbaarheden in de configuratie van gebruikersidentificatiesystemen, inloggen via anonymizers of geïnfecteerde nodes, datalekken van accounts, inloggen vanuit ongebruikelijke locaties, enzovoorts. Vandaag de dag is Azure een van de weinige cloudproviders die u ingebouwde mogelijkheden voor Threat Intelligence biedt om verzamelde beveiligingsgebeurtenissen te verrijken.

Zoals eerder vermeld, zijn de beveiligingsfunctionaliteiten en, als gevolg daarvan, de door hen gegenereerde beveiligingsgebeurtenissen niet voor alle gebruikers gelijk toegankelijk. Er is een bepaalde abonnementsvorm nodig die de functionaliteit bevat die u nodig heeft en die de bijbehorende evenementen voor de monitoring van informatiebeveiliging genereert. Bijvoorbeeld, een deel van de in de vorige alinea beschreven functies voor het monitoren van anomalieën in accounts is alleen beschikbaar met de premium licentie P2 voor de Azure AD-service. Zonder deze licentie moet u, net als bij AWS, de verzamelde beveiligingsgebeurtenissen 'met de hand' analyseren. Afhankelijk van het type licentie voor Azure AD zijn niet alle gebeurtenissen beschikbaar voor analyse.

In het Azure-portaal kunt u zowel zoekopdrachten naar de logboeken die u interesseren beheren als dashboards instellen voor de visualisatie van belangrijke informatiebeveiligingsparameters. Daarnaast kunt u daar ook extensies voor Azure Monitor selecteren, die u helpen de functionaliteit van de Azure Monitor-logboeken uit te breiden en een diepere analyse van evenementen op het gebied van beveiliging te verkrijgen.

Als u niet alleen logboekbeheer nodig heeft, maar ook een alomvattend beveiligingscentrum voor uw Azure-cloudplatform, inclusief het beheer van informatiebeveiligingsbeleid, dan is het noodzakelijk om met Azure Security Center te werken. De meeste nuttige functies zijn tegen een meerprijs beschikbaar, zoals dreigingsdetectie, monitoring buiten Azure, nalevingsbeoordeling, enz. (in de gratis versie heeft u alleen toegang tot de beveiligingsbeoordeling en aanbevelingen voor het oplossen van geïdentificeerde problemen). Het consolideert alle beveiligingskwesties op één plek. In feite kunt u spreken van een hoger niveau van informatiebeveiliging dan Azure Monitor biedt, omdat de verzamelde gegevens door uw hele cloudinfrastructuur worden verrijkt met gegevens uit tal van bronnen zoals Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, outlook.com, MSN.com, Microsoft Digital Crimes Unit (DCU) en Microsoft Security Response Center (MSRC), waarbij verschillende geavanceerde machine learning-algoritmen en gedragsanalyse worden toegepast, wat uiteindelijk de effectiviteit van dreigingsdetectie en respons moet verbeteren.

Azure heeft ook zijn eigen SIEM — het werd begin 2019 geïntroduceerd. Dit is Azure Sentinel, dat is gebaseerd op gegevens van Azure Monitor en ook kan integreren met externe beveiligingsoplossingen (zoals NGFW of WAF), waarvan de lijst continu wordt bijgewerkt. Daarnaast biedt de integratie met de Microsoft Graph Security API u de mogelijkheid om uw eigen Threat Intelligence-feeds aan Sentinel te koppelen, wat de mogelijkheden voor het analyseren van incidenten in uw Azure-cloud verrijkt. Je kunt stellen dat Azure Sentinel de eerste 'native' SIEM is die is ontstaan bij cloudproviders (dezelfde Splunk of ELK, die plaatsgevonden kunnen worden in de cloud, zoals AWS, zijn immers niet ontwikkeld door traditionele cloudserviceproviders). Azure Sentinel en Security Center zouden als SOC voor de Azure-cloud kunnen worden beschouwd en men zou zich daarbij kunnen beperken (met bepaalde voorbehouden), zolang u geen andere infrastructuur heeft en al uw rekenresources naar de cloud heeft overgezet en dit Microsoft Azure-cloud zou zijn.

Maar omdat de ingebouwde mogelijkheden van Azure (zelfs met een abonnement op Sentinel) vaak tekortschieten voor de doelen van cybersecurity monitoring en de integratie van dit proces met andere bronnen van beveiligingsgebeurtenissen (zowel in de cloud als intern), ontstaat er behoefte aan het exporteren van de verzamelde gegevens naar externe systemen, waaronder ook SIEM. Dit kan zowel via API's als met speciale extensies, die op dit moment officieel alleen beschikbaar zijn voor de volgende SIEM's — Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight en ELK. Nog niet zo lang geleden waren er meer van zulke SIEM's, maar op 1 juni 2019 stopte Microsoft met de ondersteuning van de Azure Log Integration Tool (AzLog), die in de beginperiode van Azure, toen er nog geen goede standaardisering voor logverwerking was (Azure Monitor bestond toen nog niet), het mogelijk maakte om externe SIEM's eenvoudig met de Microsoft-cloud te integreren. De situatie is nu veranderd en Microsoft raadt het Azure Event Hub-platform aan als het belangrijkste integratiewerktuig voor andere SIEM's. Velen hebben deze integratie inmiddels uitgevoerd, maar wees voorzichtig, - ze kunnen niet alle logboeken van Azure vastleggen, maar slechts sommige (zie de documentatie van uw SIEM).

Ter afsluiting van een kort overzicht van Azure wil ik een algemene aanbeveling geven over deze cloudservice: voordat u iets bevestigt omtrent de functies voor monitoring van informatiebeveiliging in Azure, is het van cruciaal belang om ze zorgvuldig in te stellen en te testen of ze functioneren zoals beschreven in de documentatie en zoals u is verteld door Microsoft-consultants (hun opvattingen over de werking van Azure-functies kunnen divergeren). Bij voldoende financiële middelen kunt u veel nuttigs uit Azure halen op het gebied van informatiebeveiligingsmonitoring. Als echter uw middelen beperkt zijn, zoals in het geval van AWS, moet u vertrouwen op uw eigen kracht en de ruwe gegevens die Azure Monitor u biedt. En vergeet niet dat veel monitoringsfuncties kosten met zich meebrengen, dus het is beter om vooraf kennis te nemen van het prijsbeleid. Bijvoorbeeld, u kunt gegevens tot 31 dagen gratis opslaan tot een maximum van 5 GB per klant; als deze waarden worden overschreden, moet u extra betalen (ongeveer 2+ dollar voor elke extra GB van de klant en 0,1 dollar voor de opslag van 1 GB per extra maand). Werken met applicatietelemetrie en metrics kan ook extra financiële middelen vereisen, net als werken met waarschuwingen en meldingen (er is een bepaalde gratis limiet beschikbaar, die mogelijk niet voldoende is voor uw behoeften).

Voorbeeld: Monitoring van informatiebeveiliging in IaaS op basis van Google Cloud Platform

Google Cloud Platform lijkt, vergeleken met AWS en Azure, nog vrij jong, maar in zekere zin is dat ook goed. In tegenstelling tot AWS, dat zijn mogelijkheden, inclusief beveiliging, geleidelijk heeft opgebouwd, terwijl het problemen had met centralisatie; GCP wordt, net als Azure, veel beter centraal beheerd, wat het aantal fouten en de implementatietijd binnen organisaties vermindert. Wat betreft beveiliging bevindt GCP zich, vreemd genoeg, tussen AWS en Azure in. Het heeft ook een uniforme registratie van gebeurtenissen voor de hele organisatie, maar deze is niet compleet. Sommige functies zijn nog steeds in bèta, maar geleidelijk zou dit gebrek verholpen moeten worden en zal GCP een volwassenere platform worden op het gebied van informatiebeveiligingsmonitoring.

De belangrijkste tool voor het registreren van gebeurtenissen in GCP is Stackdriver Logging (vergelijkbaar met Azure Monitor), waarmee je gebeurtenissen in je hele cloudinfrastructuur (en ook met AWS) kunt verzamelen. Wat betreft beveiliging heeft elke organisatie, project of map in GCP vier logboeken:

Admin Activity — bevat alle gebeurtenissen die verband houden met administratieve toegang, zoals het aanmaken van een virtuele machine, het wijzigen van toegangsrechten, enz. Dit logboek wordt altijd geschreven, ongeacht je wensen, en bewaart zijn gegevens gedurende 400 dagen.
Data Access — bevat alle gebeurtenissen die verband houden met het werken met gegevens door cloudgebruikers (aanmaken, wijzigen, lezen, enz.). Standaard wordt dit logboek niet geschreven, omdat het volume snel toeneemt. Om deze reden is de bewaartijd slechts 30 dagen. Bovendien worden niet alle gebeurtenissen in dit logboek vastgelegd. Evenals gebeurtenissen die verband houden met openbaar toegankelijke bronnen voor alle gebruikers of die toegankelijk zijn zonder in te loggen in GCP.
System Event — bevat systeemgebeurtenissen die niet gerelateerd zijn aan gebruikers, of acties van een beheerder die de configuratie van cloudresources wijzigt. Dit wordt altijd geschreven en wordt 400 dagen bewaard.
Access Transparency — dit is een uniek voorbeeld van een logboek dat alle acties van Google-medewerkers vastlegt (maar voorlopig niet voor alle GCP-diensten) die toegang hebben tot jouw infrastructuur in het kader van hun werk. Dit logboek wordt 400 dagen bewaard en is niet voor elke GCP-klant toegankelijk, maar alleen onder bepaalde voorwaarden (of Gold- of Platinum-ondersteuning, of het hebben van vier rollen van een bepaald type binnen bedrijfssteun). Een vergelijkbare functie is ook beschikbaar in bijvoorbeeld Office 365 — Lockbox.

Voorbeeld logboek: Access Transparency

{
 insertId: "abcdefg12345"
 jsonPayload: {
 @type: "type.googleapis.com/google.cloud.audit.TransparencyLog"
 location: {
 principalOfficeCountry: "VS"
 principalEmployingEntity: "Google LLC"
 principalPhysicalLocationCountry: "CA"
 }
 product: [
 0: "Cloud Storage"
 ]
 reason: [
 detail: "Zaaknummer: bar123"
 type: "CUSTOMER_INITIATED_SUPPORT"
 ]
 accesses: [
 0: {
 methodName: "GoogleInternal.Read"
 resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
 }
 ]
 }
 logName: "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.comaccess_transparency"
 operation: {
 id: "12345xyz"
 }
 receiveTimestamp: "2017-12-18T16:06:37.400577736Z"
 resource: {
 labels: {
 project_id: "1234567890"
 }
 type: "project"
 }
 severity: "NOTICE"
 timestamp: "2017-12-18T16:06:24.660001Z"
}

Toegang tot de opgegeven logs is mogelijk via verschillende wegen (bijna net als bij de eerder besproken Azure en AWS) — via de Log Viewer-interface, via de API, via Google Cloud SDK of via de Activiteitspagina van uw project waarin u geïnteresseerd bent in de gebeurtenissen. Op dezelfde manier kunnen ze ook worden geëxporteerd naar externe oplossingen voor aanvullende analyse. Dit laatste gebeurt door logs naar BigQuery of Cloud Pub/Sub te exporteren.

Naast Stackdriver Logging biedt het GCP-platform ook de functionaliteit van Stackdriver Monitoring, waarmee belangrijke metrics (prestaties, uptime, algemene status, enz.) van cloudservices en applicaties kunnen worden gevolgd. De speciaal verwerkte en gevisualiseerde gegevens kunnen helpen bij het opsporen van problemen in uw cloudinfrastructuur, ook in de context van beveiliging. Echter, het is belangrijk om op te merken dat de functionaliteit op dit gebied niet erg rijk is, aangezien GCP op dit moment geen equivalent van AWS GuardDuty heeft en niet kan onderscheiden welke genoteerde gebeurtenissen daadwerkelijk kwaadwillig zijn (Google heeft Event Threat Detection ontwikkeld, maar deze bevindt zich nog in beta en het is vroeg om over de bruikbaarheid ervan te spreken). Stackdriver Monitoring zou als een anomaliedetectiesysteem kunnen worden gebruikt, waarbij die anomalieën vervolgens worden onderzocht om de oorzaken ervan te vinden. Maar gezien het gebrek aan gekwalificeerd personeel in het gebied van beveiliging op de markt, lijkt deze taak momenteel niet eenvoudig.

Daarnaast is het de moeite waard om enkele modules voor beveiliging te vermelden die kunnen worden toegepast binnen uw cloud GCP, en die vergelijkbaar zijn met wat AWS biedt:

Cloud Security Command Center — dit is het equivalent van AWS Security Hub en Azure Security Center.
Cloud DLP - automatische detectie en bewerking (bijv. masking) van gegevens die in de cloud zijn geplaatst, volgens meer dan 90 vooraf ingestelde classificatiebeleid.
Cloud Scanner - scanner voor bekende kwetsbaarheden (XSS, Flash Injection, niet-gepatchte bibliotheken, enz.) in App Engine, Compute Engine en Google Kubernetes.
Cloud IAM - toegangsbeheer voor alle GCP-bronnen.
Cloud Identity - beheer van gebruikersaccounts, apparaten en GCP-toepassingen vanuit één console.
Cloud HSM - bescherming van cryptografische sleutels.
Cloud Key Management Service - beheer van cryptografische sleutels in GCP.
VPC Service Control - het creëren van een beveiligde perimeter rond uw GCP-bronnen ter bescherming tegen lekken.
Titan Security Key - bescherming tegen phishing.

Veel van deze modules genereren beveiligingsevents die naar de BigQuery-opslag kunnen worden verzonden voor analyse of export naar andere systemen, waaronder SIEM. Zoals eerder vermeld, is GCP een actief ontwikkelend platform en ontwikkelt Google momenteel een reeks nieuwe modules voor informatiebeveiliging voor zijn platform. Onder hen Event Threat Detection (nu beschikbaar in bèta), dat de Stackdriver-logs scant op sporen van ongeautoriseerde activiteit (vergelijkbaar met GuardDuty in AWS), of Policy Intelligence (beschikbaar in alfa), dat het mogelijk maakt om intelligente toegangspolicies voor GCP-bronnen te ontwikkelen.

Ik heb een kort overzicht gemaakt van de ingebouwde monitoringmogelijkheden in populaire cloudplatforms. Maar heeft u specialisten die kunnen werken met 'ruwe' logs van de IaaS-provider (niet iedereen is bereid om geavanceerde functies van AWS of Azure of Google aan te schaffen)? Bovendien is een bekende spreuk "vertrouw, maar controleer", die op het gebied van beveiliging relevanter is dan ooit. Hoeveel vertrouwt u op de ingebouwde mogelijkheden van de cloudprovider, die u informatiebeveiligingsevents geven? Hoezeer richten zij zich überhaupt op informatiebeveiliging?

Soms is het de moeite waard om te kijken naar derde partij oplossingen voor het monitoren van cloudinfrastructuren, die de ingebouwde beveiliging van de cloud kunnen aanvullen. In sommige gevallen zijn dergelijke oplossingen de enige manier om informatie te verkrijgen over de beveiliging van uw gegevens en applicaties die in de cloud zijn geplaatst. Bovendien zijn ze gewoon handiger, omdat ze alle taken voor de analyse van relevante logs, die door verschillende cloudservices van verschillende cloudproviders worden gegenereerd, overnemen. Een voorbeeld van zo'n derde partij oplossing is Cisco Stealthwatch Cloud, dat zich richt op één taak: het monitoren van anomalieën in informatiebeveiliging in cloudomgevingen, waaronder Amazon AWS, Microsoft Azure en Google Cloud Platform, maar ook private clouds.

Voorbeeld: Informatiebeveiliging monitoring met Stealthwatch Cloud

AWS biedt een flexibele rekenplatform, maar deze flexibiliteit leidt ertoe dat bedrijven gemakkelijker fouten maken die kunnen leiden tot beveiligingsproblemen. En het gedeelde Informatiebeveiligingsmodel draagt hier alleen maar aan bij. Het draaien van software in de cloud met onbekende kwetsbaarheden (voor bekende kwetsbaarheden kan men bijvoorbeeld AWS Inspector of GCP Cloud Scanner gebruiken), zwakke wachtwoorden, onjuiste configuraties, insider dreigingen, enzovoorts. En dit alles beïnvloedt het gedrag van cloudresources, die Cisco Stealthwatch Cloud kan monitoren. Dit is een systeem voor informatiebeveiliging monitoring en aanvaldetectie in publieke en private clouds.

Een van de belangrijkste kenmerken van Cisco Stealthwatch Cloud is de mogelijkheid tot het modelleren van entiteiten. Hiermee kunt u een softwaremodel creëren (d.w.z. een simulatie bijna in real-time) van elk van uw cloudresources (ongeacht of het AWS, Azure, GCP of iets anders is). Dit kunnen servers en gebruikers zijn, evenals types resources die specifiek zijn voor uw cloudomgeving, zoals beveiligingsgroepen en auto-scaling groepen van services. Deze modellen gebruiken gestructureerde datastromen als input, geleverd door cloudservices. Voor AWS zijn dit bijvoorbeeld VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda en AWS IAM. Het modelleren van entiteiten detecteert automatisch de rol en het gedrag van een van uw resources (u kunt spreken van het profileren van alle cloudactiviteit). Onder deze rollen kunnen een Android- of Apple-mobiele telefoon, een Citrix PVS-server, een RDP-server, een mailgateway, een VoIP-client, een terminalserver, een domeincontroller, enzovoort zijn. Vervolgens houdt het continu hun gedrag bij om te bepalen wanneer risicovol of bedreigend gedrag zich voordoet. U kunt pogingen tot wachtwoordkraken, DDoS-aanvallen, datalekken, illegale externe toegang, kwaadaardige acties, kwetsbaarheidsscans en andere bedreigingen identificeren. Bijvoorbeeld, zo ziet de detectie van een poging tot externe toegang vanuit een voor uw organisatie ongebruikelijk land (Zuid-Korea) naar een Kubernetes-cluster via SSH eruit:

Zo ziet een vermoedelijke gegevenslek uit de Postgress-database naar een land, waarmee eerder geen interactie heeft plaatsgevonden, eruit:

Tot slot, zo ziet een te groot aantal mislukte SSH-aanmeldpogingen vanuit China en Indonesië vanaf een extern apparaat eruit:

Stel dat een serverexemplaar in een VPC, volgens het beleid, nooit als toegangspunt voor externe inlog zou moeten dienen. Stel verder dat er op deze computer een externe inlog heeft plaatsgevonden door een foutieve wijziging in het beleid van de firewallregels. De functie voor entiteitsmodellering zal deze activiteit ('Ongebruikelijke externe toegang') in bijna realtime detecteren en rapporteren, en aanwijzen op de specifieke AWS CloudTrail API-aanroep, Azure Monitor of GCP Stackdriver Logging (inclusief gebruikersnaam, datum en tijd, naast andere details), die de wijziging in de firewallregels heeft veroorzaakt. En vervolgens kan deze informatie naar een SIEM voor analyse worden verzonden.

Vergelijkbare mogelijkheden worden geïmplementeerd voor elke cloudomgeving die door Cisco Stealthwatch Cloud wordt ondersteund:

Entiteitsmodellering is een unieke vorm van beveiligingsautomatisering die onbekende problemen met uw mensen, processen of technologieën kan detecteren. Het kan bijvoorbeeld helpen bij het opsporen van onder andere de volgende beveiligingsproblemen:

Is er een backdoor ontdekt in de software die we gebruiken?
Is er enige externe software of hardware in onze cloud?
Misbruikt een geautoriseerde gebruiker zijn privileges?
Is er een configuratiefout gemaakt die externe toegang of ander ongeoorloofd gebruik van middelen mogelijk maakt?
Is er geen datalek vanuit onze servers?
Heeft iemand geprobeerd verbinding met ons te maken vanuit een ongebruikelijke geografische locatie?
Is onze cloud niet geïnfecteerd met malware?

Een gedetecteerde beveiligingsgebeurtenis kan worden doorgegeven als een bijbehorend ticket in Slack, Cisco Spark, het incidentbeheersysteem PagerDuty, en ook worden doorgestuurd naar verschillende SIEM's, waaronder Splunk of ELK. Samenvattend kan worden gesteld dat als uw bedrijf een multicloudstrategie hanteert en niet beperkt is tot één enkele cloudprovider, de monitoringmogelijkheden voor beveiliging die hierboven zijn beschreven, Cisco Stealthwatch Cloud een goede optie biedt voor een uniforme set mogelijkheden om de grootste cloudspelers — Amazon, Microsoft en Google — te monitoren. Het interessante is dat als je de prijzen van Stealthwatch Cloud vergelijkt met geavanceerde licenties voor beveiligingsmonitoring in AWS, Azure of GCP, het mogelijk blijkt dat de oplossing van Cisco zelfs goedkoper is dan de ingebouwde mogelijkheden van Amazon, Microsoft en Google. Paradoxaal, maar waar. En naarmate u meer cloudomgevingen en hun mogelijkheden gebruikt, zal het voordeel van een geconsolideerde oplossing steeds duidelijker worden.

Bovendien kan Stealthwatch Cloud ook private clouds monitoren die binnen uw organisatie zijn uitgerold, bijvoorbeeld op basis van Kubernetes-containers of door het monitoren van Netflow-stromen of netwerkverkeer dat wordt verkregen via mirroring in netwerkinfrastructuur (zelfs van binnenlandse productie), gegevens van AD of DNS-servers, enzovoort. Al deze gegevens worden verrijkt met informatie van Threat Intelligence die wordt verzameld door het Cisco Talos-team, de grootste ter wereld niet-gouvernementele groep van beveiligingsonderzoekers.

Dit stelt u in staat om een uniform monitoringssysteem te realiseren voor zowel publieke als hybride clouds die uw bedrijf kan gebruiken. De verzamelde informatie kan vervolgens worden geanalyseerd met behulp van de ingebouwde mogelijkheden van Stealthwatch Cloud of naar uw SIEM worden verzonden (Standaard worden Splunk, ELK, SumoLogic en verschillende andere ondersteund).

We will conclude the first part of the article, in which I examined the built-in and external tools for monitoring information security on IaaS/PaaS platforms, enabling us to promptly detect and respond to incidents occurring in the cloud environments selected by our organization. In the second part, we will continue the topic and explore monitoring options for SaaS platforms using Salesforce and Dropbox as examples, as well as try to summarize and integrate everything by creating a unified information security monitoring system across different cloud providers.

Bron: habr.com