Monitoring van cloudbeveiliging

Het verplaatsen van gegevens en applicaties naar de cloud vormt een nieuwe uitdaging voor bedrijfs-SOC's, die niet altijd klaar zijn om de infrastructuur van anderen te monitoren. Volgens Netoskope gebruikt de gemiddelde onderneming (blijkbaar in de VS) 1246 verschillende clouddiensten, wat 22% meer is dan een jaar geleden. 1246 clouddiensten!!! 175 daarvan hebben betrekking op HR-diensten, 170 op marketing, 110 op het gebied van communicatie en 76 op financieel en CRM. Cisco gebruikt ‘slechts’ 700 externe clouddiensten. Ik ben dus een beetje in de war door deze cijfers. Maar in ieder geval ligt het probleem niet bij hen, maar bij het feit dat de cloud vrij actief begint te worden gebruikt door een toenemend aantal bedrijven die over dezelfde mogelijkheden willen beschikken voor het monitoren van de cloudinfrastructuur als in hun eigen netwerk. En deze trend groeit - volgens Dat meldt de Amerikaanse Chamber of Accounts In 2023 zullen in de Verenigde Staten 1200 datacenters gesloten zijn (6250 zijn er al gesloten). Maar de transitie naar de cloud is niet alleen ‘laten we onze servers naar een externe provider verhuizen’. Nieuwe IT-architectuur, nieuwe software, nieuwe processen, nieuwe beperkingen... Dit alles brengt aanzienlijke veranderingen met zich mee in het werk van niet alleen IT, maar ook van informatiebeveiliging. En als providers hebben geleerd om op de een of andere manier om te gaan met het waarborgen van de veiligheid van de cloud zelf (gelukkig zijn er veel aanbevelingen), dan zijn er bij het monitoren van de beveiliging van cloudinformatie, vooral op SaaS-platforms, aanzienlijke problemen, waar we het over zullen hebben.

Stel dat uw bedrijf een deel van zijn infrastructuur naar de cloud heeft verplaatst... Stop. Niet op deze manier. Als de infrastructuur is overgedragen en je denkt nu pas na over hoe je deze gaat monitoren, dan heb je al verloren. Tenzij het Amazon, Google of Microsoft is (en dan onder voorbehoud), zult u waarschijnlijk niet veel mogelijkheden hebben om uw gegevens en applicaties te monitoren. Het is goed als je de mogelijkheid krijgt om met logs te werken. Soms zijn gegevens over beveiligingsgebeurtenissen beschikbaar, maar heeft u er geen toegang toe. Bijvoorbeeld Office 365. Als u de goedkoopste E1-licentie heeft, zijn beveiligingsgebeurtenissen helemaal niet voor u beschikbaar. Als u een E3-licentie heeft, worden uw gegevens slechts 90 dagen bewaard, en alleen als u een E5-licentie heeft, is de duur van de logs een jaar beschikbaar (dit heeft echter ook zijn eigen nuances die verband houden met de noodzaak om afzonderlijk een aantal functies voor het werken met logs opvragen bij Microsoft support). Overigens is de E3-licentie veel zwakker in termen van monitoringfuncties dan zakelijke Exchange. Om hetzelfde niveau te bereiken heeft u een E5-licentie of een aanvullende Advanced Compliance-licentie nodig, waarvoor mogelijk extra geld nodig is dat niet in uw financiële model is verwerkt voor de overstap naar de cloudinfrastructuur. En dit is slechts één voorbeeld van onderschatting van problemen die verband houden met het monitoren van de beveiliging van cloudinformatie. In dit artikel wil ik, zonder de pretentie te hebben volledig te zijn, de aandacht vestigen op enkele nuances waarmee rekening moet worden gehouden bij het kiezen van een cloudprovider vanuit veiligheidsoogpunt. En aan het einde van het artikel wordt een checklist gegeven die de moeite waard is om te voltooien voordat wordt overwogen dat het probleem van het monitoren van cloudinformatiebeveiliging is opgelost.

Er zijn een aantal typische problemen die leiden tot incidenten in cloudomgevingen, waarop informatiebeveiligingsdiensten geen tijd hebben om te reageren of deze helemaal niet zien:

• Beveiligingslogboeken bestaan ​​niet. Dit is een vrij veel voorkomende situatie, vooral onder beginnende spelers op de markt voor cloudoplossingen. Maar je moet ze niet meteen opgeven. Kleine spelers, vooral binnenlandse, zijn gevoeliger voor de eisen van klanten en kunnen snel bepaalde vereiste functies implementeren door de goedgekeurde roadmap voor hun producten te wijzigen. Ja, dit zal geen analoog zijn van GuardDuty van Amazon of de “Proactive Protection” -module van Bitrix, maar in ieder geval iets.
• Informatiebeveiliging weet niet waar de logs zijn opgeslagen of er is geen toegang toe. Hier is het noodzakelijk om onderhandelingen aan te gaan met de cloudserviceprovider - misschien zal hij dergelijke informatie verstrekken als hij de klant belangrijk voor hem acht. Maar over het algemeen is het niet erg goed als toegang tot logbestanden ‘bij een speciaal besluit’ wordt verleend.
• Het komt ook voor dat de cloudprovider over logs beschikt, maar deze bieden beperkte monitoring en gebeurtenisregistratie, die niet voldoende zijn om alle incidenten te detecteren. U ontvangt bijvoorbeeld mogelijk alleen logboeken van wijzigingen op de site of logboeken van pogingen tot gebruikersauthenticatie, maar geen andere gebeurtenissen, bijvoorbeeld over netwerkverkeer, waardoor een hele laag gebeurtenissen voor u verborgen blijft die kenmerkend zijn voor pogingen om uw cloudinfrastructuur te hacken. .
• Er zijn logboeken, maar de toegang daartoe is moeilijk te automatiseren, waardoor ze niet continu, maar volgens een schema moeten worden gemonitord. En als je logs niet automatisch kunt downloaden, kan het downloaden van logs, bijvoorbeeld in Excel-formaat (zoals bij een aantal binnenlandse aanbieders van cloudoplossingen), zelfs leiden tot onwil bij de bedrijfsinformatiebeveiligingsdienst om eraan te sleutelen.
• Geen logbewaking. Dit is misschien wel de meest onduidelijke reden voor het optreden van informatiebeveiligingsincidenten in cloudomgevingen. Het lijkt erop dat er logboeken zijn en dat het mogelijk is om de toegang daartoe te automatiseren, maar niemand doet dit. Waarom?

Gedeeld cloudbeveiligingsconcept

De transitie naar de cloud is altijd een zoektocht naar een evenwicht tussen de wens om de controle over de infrastructuur te behouden en deze over te dragen aan de meer professionele handen van een cloudprovider die gespecialiseerd is in het onderhoud ervan. En op het gebied van cloudsecurity moet dit evenwicht ook gezocht worden. Bovendien zal deze balans, afhankelijk van het gebruikte cloudserviceleveringsmodel (IaaS, PaaS, SaaS), steeds anders zijn. Hoe dan ook moeten we niet vergeten dat alle cloudproviders tegenwoordig het zogenaamde gedeelde verantwoordelijkheids- en gedeelde informatiebeveiligingsmodel volgen. Voor sommige dingen is de cloud verantwoordelijk, en voor andere is de klant verantwoordelijk, door zijn gegevens, zijn applicaties, zijn virtuele machines en andere bronnen in de cloud te plaatsen. Het zou roekeloos zijn om te verwachten dat we door naar de cloud te gaan alle verantwoordelijkheid op de provider afschuiven. Maar het is ook onverstandig om alle beveiliging zelf in te bouwen als je naar de cloud overstapt. Er is een evenwicht nodig, dat afhangt van vele factoren: - strategie voor risicobeheer, dreigingsmodel, beveiligingsmechanismen die beschikbaar zijn voor de cloudprovider, wetgeving, enz.

De classificatie van gegevens die in de cloud worden gehost, is bijvoorbeeld altijd de verantwoordelijkheid van de klant. Een cloudprovider of een externe dienstverlener kan hem alleen helpen met tools die helpen gegevens in de cloud te markeren, overtredingen te identificeren, gegevens te verwijderen die in strijd zijn met de wet of deze op de een of andere manier te maskeren. Aan de andere kant is fysieke beveiliging altijd de verantwoordelijkheid van de cloudaanbieder en kan deze niet delen met klanten. Maar alles wat zich tussen data en fysieke infrastructuur bevindt, is juist onderwerp van discussie in dit artikel. Zo is de beschikbaarheid van de cloud de verantwoordelijkheid van de aanbieder en is het instellen van firewallregels of het mogelijk maken van encryptie de verantwoordelijkheid van de klant. In dit artikel zullen we proberen te bekijken welke mechanismen voor het monitoren van informatiebeveiliging tegenwoordig worden aangeboden door verschillende populaire cloudproviders in Rusland, wat de kenmerken zijn van hun gebruik en wanneer het de moeite waard is om naar externe overlay-oplossingen te kijken (bijvoorbeeld Cisco E- mail Security) die de mogelijkheden van uw cloud op het gebied van cyberbeveiliging uitbreiden. In sommige gevallen, vooral als u een multi-cloudstrategie volgt, heeft u geen andere keuze dan externe oplossingen voor informatiebeveiligingsmonitoring in meerdere cloudomgevingen tegelijk te gebruiken (bijvoorbeeld Cisco CloudLock of Cisco Stealthwatch Cloud). Welnu, in sommige gevallen zult u zich realiseren dat de cloudprovider die u heeft gekozen (of u heeft opgelegd) helemaal geen mogelijkheden biedt voor het monitoren van informatiebeveiliging. Dit is onaangenaam, maar ook niet een beetje, omdat u hiermee het risiconiveau dat gepaard gaat met het werken met deze cloud adequaat kunt inschatten.

Levenscyclus van cloudbeveiligingsmonitoring

Om de veiligheid van de clouds die u gebruikt te monitoren, heeft u slechts drie opties:

• vertrouw op de tools van uw cloudprovider,
• oplossingen van derden gebruiken die toezicht houden op de IaaS-, PaaS- of SaaS-platforms die u gebruikt,
• bouw uw eigen cloudmonitoringinfrastructuur (alleen voor IaaS/PaaS-platforms).

Laten we eens kijken welke functies elk van deze opties heeft. Maar eerst moeten we het algemene raamwerk begrijpen dat zal worden gebruikt bij het monitoren van cloudplatforms. Ik zou zes hoofdcomponenten van het informatiebeveiligingsmonitoringproces in de cloud willen benadrukken:

• Voorbereiding van de infrastructuur. Bepalen van de benodigde applicaties en infrastructuur voor het verzamelen van gebeurtenissen die belangrijk zijn voor informatiebeveiliging in opslag.
• Verzameling. In dit stadium worden beveiligingsgebeurtenissen uit verschillende bronnen samengevoegd voor daaropvolgende verzending voor verwerking, opslag en analyse.
• Behandeling. In dit stadium worden de gegevens getransformeerd en verrijkt om daaropvolgende analyses te vergemakkelijken.
• Opslag. Deze component is verantwoordelijk voor de opslag op korte en lange termijn van verzamelde verwerkte en ruwe gegevens.
• Analyse. In deze fase heeft u de mogelijkheid om incidenten te detecteren en er automatisch of handmatig op te reageren.
• Rapportage. Deze fase helpt bij het formuleren van sleutelindicatoren voor belanghebbenden (management, auditors, cloudprovider, klanten, etc.) die ons helpen bepaalde beslissingen te nemen, bijvoorbeeld het veranderen van een provider of het versterken van de informatiebeveiliging.

Als u deze componenten begrijpt, kunt u in de toekomst snel beslissen wat u van uw leverancier kunt afnemen en wat u zelf of met behulp van externe adviseurs moet doen.

Ingebouwde cloudservices

Ik schreef hierboven al dat veel clouddiensten tegenwoordig geen mogelijkheden bieden voor het monitoren van informatiebeveiliging. Over het algemeen besteden ze niet veel aandacht aan het onderwerp informatiebeveiliging. Bijvoorbeeld een van de populaire Russische diensten voor het verzenden van rapporten naar overheidsinstanties via internet (ik zal de naam niet specifiek noemen). Het hele hoofdstuk over de beveiliging van deze dienst draait om het gebruik van gecertificeerde CIPF. Het informatiebeveiligingsgedeelte van een andere binnenlandse cloudservice voor elektronisch documentbeheer is niet anders. Er wordt gesproken over certificaten met openbare sleutels, gecertificeerde cryptografie, het elimineren van kwetsbaarheden op het web, bescherming tegen DDoS-aanvallen, het gebruik van firewalls, back-ups en zelfs regelmatige informatiebeveiligingsaudits. Maar er wordt met geen woord gerept over monitoring, noch over de mogelijkheid om toegang te krijgen tot informatiebeveiligingsgebeurtenissen die interessant kunnen zijn voor klanten van deze dienstverlener.

Over het algemeen kunt u, door de manier waarop de cloudprovider informatiebeveiligingsproblemen op zijn website en in zijn documentatie beschrijft, begrijpen hoe serieus hij deze kwestie neemt. Als u bijvoorbeeld de handleidingen van de “My Office”-producten leest, staat er helemaal geen woord over beveiliging, maar in de documentatie van het afzonderlijke product “My Office”. KS3”, ontworpen om te beschermen tegen ongeoorloofde toegang, is er een gebruikelijke lijst met punten van de 17e orde van de FSTEC, die “My Office.KS3” implementeert, maar er wordt niet beschreven hoe het dit implementeert en, belangrijker nog, hoe Integreer deze mechanismen met bedrijfsinformatiebeveiliging. Misschien bestaat dergelijke documentatie, maar ik heb deze niet gevonden in het publieke domein, op de website "My Office". Hoewel ik misschien gewoon geen toegang heb tot deze geheime informatie?

Voor Bitrix is ​​de situatie veel beter. De documentatie beschrijft de formaten van de gebeurtenislogboeken en, interessant genoeg, het inbraaklogboek, dat gebeurtenissen bevat die verband houden met potentiële bedreigingen voor het cloudplatform. Van daaruit kunt u het IP-adres, de gebruikers- of gastnaam, de gebeurtenisbron, de tijd, de gebruikersagent, het gebeurtenistype, enz. eruit halen. Het is waar dat u met deze gebeurtenissen kunt werken via het configuratiescherm van de cloud zelf, of gegevens kunt uploaden in MS Excel-formaat. Het is nu moeilijk om het werk met Bitrix-logboeken te automatiseren en u zult een deel van het werk handmatig moeten doen (het rapport uploaden en in uw SIEM laden). Maar als we bedenken dat deze mogelijkheid tot voor kort niet bestond, dan is dit een grote vooruitgang. Tegelijkertijd zou ik willen opmerken dat veel buitenlandse cloudproviders vergelijkbare functionaliteit bieden “voor beginners” - bekijk de logs met je ogen via het controlepaneel, of upload de gegevens naar jezelf (de meeste uploaden gegevens echter in . csv-formaat, niet Excel).

Zonder de optie zonder logboeken te overwegen, bieden cloudproviders u doorgaans drie opties voor het monitoren van beveiligingsgebeurtenissen: dashboards, gegevensupload en API-toegang. De eerste lijkt veel problemen voor je op te lossen, maar dit is niet helemaal waar: als je meerdere tijdschriften hebt, moet je schakelen tussen de schermen waarop ze worden weergegeven, waardoor het totaalbeeld verloren gaat. Bovendien is het onwaarschijnlijk dat de cloudprovider u de mogelijkheid biedt om beveiligingsgebeurtenissen met elkaar in verband te brengen en deze in het algemeen vanuit een beveiligingsoogpunt te analyseren (meestal heeft u te maken met onbewerkte gegevens, die u zelf moet begrijpen). Er zijn uitzonderingen en we zullen er verder over praten. Ten slotte is het de moeite waard om u af te vragen welke gebeurtenissen door uw cloudprovider worden vastgelegd, in welk formaat, en hoe komen deze overeen met uw informatiebeveiligingsmonitoringproces? Denk bijvoorbeeld aan identificatie en authenticatie van gebruikers en gasten. Met dezelfde Bitrix kunt u op basis van deze gebeurtenissen de datum en het tijdstip van de gebeurtenis, de naam van de gebruiker of gast (als u over de module “Web Analytics” beschikt), het bezochte object en andere elementen die typisch zijn voor een website registreren. . Maar bedrijfsinformatiebeveiligingsdiensten hebben mogelijk informatie nodig over de vraag of de gebruiker toegang heeft gehad tot de cloud vanaf een vertrouwd apparaat (in een bedrijfsnetwerk wordt deze taak bijvoorbeeld geïmplementeerd door Cisco ISE). Hoe zit het met zo'n eenvoudige taak als de geo-IP-functie, die zal helpen bepalen of een gebruikersaccount van een cloudservice is gestolen? En zelfs als de cloudprovider u dit ter beschikking stelt, is dit niet voldoende. Datzelfde Cisco CloudLock analyseert niet alleen de geolocatie, maar gebruikt hiervoor machine learning en analyseert historische gegevens voor elke gebruiker en monitort verschillende afwijkingen in identificatie- en authenticatiepogingen. Alleen MS Azure heeft vergelijkbare functionaliteit (als u over het juiste abonnement beschikt).

Er is nog een probleem: 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, overmorgen een derde. Ook hierop moet je voorbereid zijn. Hetzelfde geldt voor de functionaliteit, die kan veranderen en waarmee rekening moet worden gehouden in uw monitoringsysteem voor informatiebeveiliging. Amazon had aanvankelijk bijvoorbeeld aparte services voor het monitoren van cloudgebeurtenissen: AWS CloudTrail en AWS CloudWatch. Toen verscheen er een aparte service voor het monitoren van informatiebeveiligingsgebeurtenissen: AWS GuardDuty. Na enige tijd lanceerde Amazon een nieuw beheersysteem, Amazon Security Hub, dat de analyse omvat van gegevens ontvangen van GuardDuty, Amazon Inspector, Amazon Macie en verschillende anderen. Een ander voorbeeld is de Azure-logboekintegratietool met SIEM - AzLog. Het werd actief gebruikt door veel SIEM-leveranciers, totdat Microsoft in 2018 de stopzetting van de ontwikkeling en ondersteuning aankondigde, waardoor veel klanten die deze tool gebruikten met een probleem werden geconfronteerd (we zullen later praten over hoe het werd opgelost).

Houd daarom zorgvuldig alle monitoringfuncties in de gaten die uw cloudprovider u biedt. Of vertrouw op externe leveranciers van oplossingen die als tussenpersoon zullen optreden tussen uw SOC en de cloud die u wilt monitoren. Ja, het zal duurder zijn (hoewel niet altijd), maar je schuift alle verantwoordelijkheid op de schouders van iemand anders. Of niet alles? Laten we het concept van gedeelde beveiliging onthouden en begrijpen dat we niets kunnen verschuiven - we zullen onafhankelijk moeten begrijpen hoe verschillende cloudproviders monitoring bieden van de informatiebeveiliging van uw gegevens, applicaties, virtuele machines en andere bronnen gehost in de cloud. En we beginnen met wat Amazon in dit deel te bieden heeft.

Voorbeeld: Monitoring van informatiebeveiliging in IaaS op basis van AWS

Ja, ja, ik begrijp dat Amazon niet het beste voorbeeld is vanwege het feit dat dit een Amerikaanse dienst is en kan worden geblokkeerd als onderdeel van de strijd tegen extremisme en de verspreiding van in Rusland verboden informatie. Maar in deze publicatie wil ik alleen laten zien hoe verschillende cloudplatforms verschillen in hun mogelijkheden voor het monitoren van informatiebeveiliging en waar u vanuit veiligheidsoogpunt op moet letten bij het overbrengen van uw belangrijkste processen naar de cloud. Nou, als sommige Russische ontwikkelaars van cloudoplossingen iets nuttigs voor zichzelf leren, dan zou dat geweldig zijn.

Het eerste wat we moeten zeggen is dat Amazon geen ondoordringbare vesting is. Bij zijn cliënten gebeuren regelmatig diverse incidenten. Zo werden de namen, adressen, geboortedata en telefoonnummers van 198 miljoen kiezers gestolen uit Deep Root Analytics. Het Israëlische bedrijf Nice Systems heeft 14 miljoen records van Verizon-abonnees gestolen. Dankzij de ingebouwde mogelijkheden van AWS kunt u echter een breed scala aan incidenten detecteren. Bijvoorbeeld:

• impact op infrastructuur (DDoS)
• knooppuntcompromis (opdrachtinjectie)
• accountcompromis en ongeautoriseerde toegang
• onjuiste configuratie en kwetsbaarheden
• onveilige interfaces en API's.

Deze discrepantie is te wijten aan het feit dat, zoals we hierboven hebben ontdekt, de klant zelf verantwoordelijk is voor de beveiliging van klantgegevens. En als hij niet de moeite heeft genomen om beschermingsmechanismen in te schakelen en geen monitoringtools heeft ingeschakeld, zal hij alleen via de media of van zijn cliënten over het incident te weten komen.

Om incidenten te identificeren, kunt u gebruik maken van een breed scala aan verschillende door Amazon ontwikkelde monitoringdiensten (hoewel deze vaak worden aangevuld met externe tools zoals osquery). In AWS worden dus alle gebruikersacties gemonitord, ongeacht hoe ze worden uitgevoerd: via de beheerconsole, opdrachtregel, SDK of andere AWS-services. Alle gegevens van de activiteit van elk AWS-account (inclusief gebruikersnaam, actie, service, activiteitsparameters en resultaat) en API-gebruik zijn beschikbaar via AWS CloudTrail. U kunt deze gebeurtenissen (zoals inloggen op de AWS IAM-console) bekijken vanaf de CloudTrail-console, ze analyseren met Amazon Athena, of ze ‘uitbesteden’ aan externe oplossingen zoals Splunk, AlienVault, enz. De AWS CloudTrail-logboeken zelf worden in uw AWS S3-bucket geplaatst.

Twee andere AWS-services bieden een aantal andere belangrijke monitoringmogelijkheden. Ten eerste is Amazon CloudWatch een monitoringservice voor AWS-bronnen en -applicaties waarmee u onder meer verschillende afwijkingen in uw cloud kunt identificeren. Alle ingebouwde AWS-services, zoals Amazon Elastic Compute Cloud (servers), Amazon Relational Database Service (databases), Amazon Elastic MapReduce (gegevensanalyse) en 30 andere Amazon-services, gebruiken Amazon CloudWatch om hun logs op te slaan. Ontwikkelaars kunnen de open API van Amazon CloudWatch gebruiken om logmonitoringfunctionaliteit toe te voegen aan aangepaste applicaties en services, waardoor ze de reikwijdte van gebeurtenisanalyse binnen een beveiligingscontext kunnen uitbreiden.

Ten tweede kunt u met de VPC Flow Logs-service het netwerkverkeer analyseren dat wordt verzonden of ontvangen door uw AWS-servers (extern of intern), maar ook tussen microservices. Wanneer een van uw AWS VPC-bronnen interactie heeft met het netwerk, registreert VPC Flow Logs details over het netwerkverkeer, inclusief de bron- en bestemmingsnetwerkinterface, evenals de IP-adressen, poorten, protocol, aantal bytes en aantal pakketten dat u gebruikt. zaag. Degenen die ervaring hebben met lokale netwerkbeveiliging zullen dit herkennen als analoog aan threads NetFlow, die kan worden gecreëerd door switches, routers en firewalls op bedrijfsniveau. Deze logboeken zijn belangrijk voor het monitoren van informatiebeveiliging, omdat ze, in tegenstelling tot gebeurtenissen over de acties van gebruikers en applicaties, u ook in staat stellen netwerkinteracties in de virtuele private cloud-omgeving van AWS niet te missen.

Samenvattend bieden deze drie AWS-services – AWS CloudTrail, Amazon CloudWatch en VPC Flow Logs – samen redelijk krachtig inzicht in uw accountgebruik, gebruikersgedrag, infrastructuurbeheer, applicatie- en serviceactiviteit en netwerkactiviteit. Ze kunnen bijvoorbeeld worden gebruikt om de volgende afwijkingen te detecteren:

• Pogingen om de site te scannen, naar achterdeurtjes te zoeken, naar kwetsbaarheden te zoeken via uitbarstingen van “404-fouten”.
• Injectieaanvallen (bijvoorbeeld SQL-injectie) via uitbarstingen van “500 fouten”.
• Bekende aanvalstools zijn sqlmap, nikto, w3af, nmap, etc. door analyse van het User Agent-veld.

Amazon Web Services heeft ook andere diensten ontwikkeld voor cyberbeveiligingsdoeleinden waarmee u vele andere problemen kunt oplossen. AWS heeft bijvoorbeeld een ingebouwde service voor het controleren van beleid en configuraties: AWS Config. Deze service biedt continue auditing van uw AWS-bronnen en hun configuraties. Laten we een eenvoudig voorbeeld nemen: stel dat u er zeker van wilt zijn dat gebruikerswachtwoorden op al uw servers zijn uitgeschakeld en dat toegang alleen mogelijk is op basis van certificaten. Met AWS Config kunt u dit eenvoudig voor al uw servers controleren. Er zijn nog andere beleidsregels die op uw cloudservers kunnen worden toegepast: 'Geen enkele server kan poort 22 gebruiken', 'Alleen beheerders kunnen de firewallregels wijzigen' of 'Alleen gebruiker Ivashko kan nieuwe gebruikersaccounts maken, en dat kan hij alleen op dinsdag. " In de zomer van 2016 werd de AWS Config-service uitgebreid om de detectie van overtredingen van ontwikkeld beleid te automatiseren. AWS-configuratieregels zijn in wezen continue configuratieverzoeken voor de Amazon-services die u gebruikt, die gebeurtenissen genereren als het bijbehorende beleid wordt geschonden. In plaats van bijvoorbeeld periodiek AWS Config-query's uit te voeren om te verifiëren dat alle schijven op een virtuele server zijn gecodeerd, kunnen AWS Config Rules worden gebruikt om voortdurend serverschijven te controleren om er zeker van te zijn dat aan deze voorwaarde wordt voldaan. En, belangrijker nog, in de context van deze publicatie genereren eventuele overtredingen gebeurtenissen die door uw informatiebeveiligingsdienst kunnen worden geanalyseerd.

AWS heeft ook een equivalent van traditionele oplossingen voor bedrijfsinformatiebeveiliging, die ook beveiligingsgebeurtenissen genereren die u kunt en moet analyseren:

• Inbraakdetectie - AWS GuardDuty
• Controle op informatielekken - AWS Macie
• EDR (hoewel er een beetje vreemd over eindpunten in de cloud wordt gesproken) - AWS Cloudwatch + open source osquery of GRR-oplossingen
• Netflow-analyse - AWS Cloudwatch + AWS VPC Flow
• DNS-analyse - AWS Cloudwatch + AWS Route53
• AD - AWS-directoryservice
• Accountbeheer - AWS IAM
• SSO - AWS SSO
• beveiligingsanalyse - AWS Inspector
• configuratiebeheer - AWS Config
• WAF - AWS WAF.

Ik zal niet in detail alle Amazon-diensten beschrijven die nuttig kunnen zijn in het kader van informatiebeveiliging. Het belangrijkste is om te begrijpen dat ze allemaal gebeurtenissen kunnen genereren die we kunnen en moeten analyseren in de context van informatiebeveiliging, waarbij we voor dit doel zowel de ingebouwde mogelijkheden van Amazon zelf als externe oplossingen gebruiken, bijvoorbeeld SIEM, die breng beveiligingsgebeurtenissen naar uw meldkamer en analyseer ze daar samen met gebeurtenissen van andere cloudservices of van interne infrastructuur, perimeter- of mobiele apparaten.

Het begint in ieder geval allemaal met de gegevensbronnen die u voorzien van informatiebeveiligingsgebeurtenissen. Deze bronnen omvatten, maar zijn niet beperkt tot:

• CloudTrail - API-gebruik en gebruikersacties
• Trusted Advisor - veiligheidscontrole op basis van best practices
• Config - inventarisatie en configuratie van accounts en service-instellingen
• VPC Flow Logs - verbindingen met virtuele interfaces
• IAM - identificatie- en authenticatiedienst
• ELB-toegangslogboeken - Load Balancer
• Inspector - kwetsbaarheden in toepassingen
• S3 - bestandsopslag
• CloudWatch - Applicatieactiviteit
• SNS is een notificatiedienst.

Amazon biedt weliswaar zo’n scala aan gebeurtenisbronnen en hulpmiddelen voor het genereren ervan, maar is zeer beperkt in zijn vermogen om de verzamelde gegevens te analyseren in de context van informatiebeveiliging. U zult de beschikbare logboeken zelfstandig moeten bestuderen, op zoek naar relevante indicatoren van compromissen daarin. AWS Security Hub, dat Amazon onlangs lanceerde, wil dit probleem oplossen door een cloud-SIEM voor AWS te worden. Maar tot nu toe staat het nog maar aan het begin van zijn reis en wordt het beperkt door zowel het aantal bronnen waarmee het werkt als door andere beperkingen die zijn vastgelegd door de architectuur en abonnementen van Amazon zelf.

Voorbeeld: Informatiebeveiligingsmonitoring in IaaS op basis van Azure

Ik wil geen lang debat voeren over welke van de drie cloudproviders (Amazon, Microsoft of Google) beter is (vooral omdat elk van hen nog steeds zijn eigen specifieke kenmerken heeft en geschikt is om zijn eigen problemen op te lossen); Laten we ons concentreren op de mogelijkheden voor het monitoren van informatiebeveiliging die deze spelers bieden. Toegegeven moet worden dat Amazon AWS een van de eersten in dit segment was en daarom het verst is gevorderd op het gebied van zijn informatiebeveiligingsfuncties (hoewel velen toegeven dat ze moeilijk te gebruiken zijn). Maar dit betekent niet dat we de kansen die Microsoft en Google ons bieden, zullen negeren.

Microsoft-producten onderscheiden zich altijd door hun ‘openheid’ en in Azure is de situatie vergelijkbaar. Als AWS en GCP bijvoorbeeld altijd uitgaan van het concept ‘wat niet mag, is verboden’, dan heeft Azure precies de tegenovergestelde aanpak. Wanneer u bijvoorbeeld een virtueel netwerk in de cloud en een virtuele machine daarin creëert, zijn alle poorten en protocollen standaard open en toegestaan. Daarom zult u wat meer moeite moeten besteden aan de eerste installatie van het toegangscontrolesysteem in de cloud van Microsoft. En dit stelt ook strengere eisen aan u als het gaat om het monitoren van activiteiten in de Azure-cloud.

AWS heeft een bijzonderheid die verband houdt met het feit dat wanneer u uw virtuele bronnen bewaakt en deze zich in verschillende regio's bevinden, u problemen ondervindt bij het combineren van alle gebeurtenissen en hun uniforme analyse, om te elimineren waarvoor u verschillende trucs moet gebruiken, zoals Creëer uw eigen code voor AWS Lambda die evenementen tussen regio's transporteert. Azure heeft dit probleem niet: het activiteitenlogboekmechanisme volgt alle activiteiten in de hele organisatie zonder beperkingen. Hetzelfde geldt voor AWS Security Hub, dat onlangs door Amazon is ontwikkeld om veel beveiligingsfuncties binnen één beveiligingscentrum te consolideren, maar alleen binnen de regio ervan, wat echter niet relevant is voor Rusland. Azure beschikt over een eigen Security Center, dat niet gebonden is aan regionale beperkingen, en toegang biedt tot alle beveiligingsfuncties van het cloudplatform. Bovendien kan het voor verschillende lokale teams zijn eigen set beschermende mogelijkheden bieden, inclusief beveiligingsgebeurtenissen die door hen worden beheerd. AWS Security Hub is nog steeds op weg om vergelijkbaar te worden met Azure Security Center. Maar het is de moeite waard om er een vlieg in de zalf aan toe te voegen: je kunt veel van wat eerder in AWS werd beschreven uit Azure halen, maar dit kan het handigst alleen worden gedaan voor Azure AD, Azure Monitor en Azure Security Center. Alle andere Azure-beveiligingsmechanismen, inclusief analyse van beveiligingsgebeurtenissen, worden nog niet op de handigste manier beheerd. Het probleem wordt deels opgelost door de API, die alle Microsoft Azure-diensten doordringt, maar dit zal extra inspanning van u vergen om uw cloud te integreren met uw SOC en de aanwezigheid van gekwalificeerde specialisten (in feite net als bij elke andere SIEM die werkt met cloud-API's). Sommige SIEM's, die later zullen worden besproken, ondersteunen Azure al en kunnen de taak van het monitoren ervan automatiseren, maar het heeft ook zijn eigen problemen: ze kunnen niet allemaal alle logboeken verzamelen die Azure heeft.

Het verzamelen en monitoren van gebeurtenissen in Azure wordt verzorgd met behulp van de Azure Monitor-service, het belangrijkste hulpmiddel voor het verzamelen, opslaan en analyseren van gegevens in de Microsoft-cloud en zijn bronnen: Git-opslagplaatsen, containers, virtuele machines, applicaties, enz. Alle gegevens die door Azure Monitor worden verzameld, zijn onderverdeeld in twee categorieën: statistieken, verzameld in realtime en die belangrijke prestatie-indicatoren van de Azure-cloud beschrijven, en logboeken, die gegevens bevatten die zijn georganiseerd in records die bepaalde aspecten van de activiteit van Azure-resources en -services kenmerken. Bovendien kan de Azure Monitor-service met behulp van de Data Collector API gegevens verzamelen uit elke REST-bron om zijn eigen bewakingsscenario's te bouwen.

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

• Activiteitenlogboeken - dit logboek beantwoordt de klassieke vragen van "wie", "wat" en "wanneer" met betrekking tot elke schrijfbewerking (PUT, POST, DELETE) op cloudbronnen. Gebeurtenissen met betrekking tot leestoegang (GET) worden niet in dit logboek opgenomen, zoals een aantal andere.
• Diagnostische logboeken - bevat gegevens over bewerkingen met een bepaalde bron die bij uw abonnement is inbegrepen.
• Azure AD-rapportage: bevat zowel gebruikersactiviteit als systeemactiviteit met betrekking tot groeps- en gebruikersbeheer.
• Windows Event Log en Linux Syslog - bevat gebeurtenissen van virtuele machines die in de cloud worden gehost.
• Metrische gegevens: bevat telemetrie over de prestaties en status van uw cloudservices en -bronnen. Elke minuut gemeten en opgeslagen. in 30 dagen.
• Network Security Group Flow Logs - bevat gegevens over netwerkbeveiligingsgebeurtenissen verzameld met behulp van de Network Watcher-service en resourcemonitoring op netwerkniveau.
• Opslaglogboeken - bevat gebeurtenissen met betrekking tot toegang tot opslagfaciliteiten.

Voor monitoring kunt u externe SIEM's of de ingebouwde Azure Monitor en de bijbehorende extensies gebruiken. We zullen het later hebben over systemen voor informatiebeveiligingsgebeurtenisbeheer, maar laten we nu eens kijken wat Azure zelf ons biedt voor data-analyse in de context van beveiliging. Het hoofdscherm voor alles wat met beveiliging te maken heeft in Azure Monitor is het Log Analytics Security and Audit Dashboard (de gratis versie ondersteunt een beperkte hoeveelheid gebeurtenisopslag gedurende slechts één week). Dit dashboard is verdeeld in vijf hoofdgebieden die samenvattende statistieken visualiseren van wat er gebeurt in de cloudomgeving die u gebruikt:

• Beveiligingsdomeinen - belangrijke kwantitatieve indicatoren met betrekking tot informatiebeveiliging - het aantal incidenten, het aantal gecompromitteerde knooppunten, niet-gepatchte knooppunten, netwerkbeveiligingsgebeurtenissen, enz.
• Opmerkelijke problemen - toont het aantal en het belang van actieve informatiebeveiligingsproblemen
• Detecties - geeft aanvalspatronen weer die tegen u worden gebruikt
• Bedreigingsinformatie - geeft geografische informatie weer over externe knooppunten die u aanvallen
• Algemene beveiligingsvragen: typische vragen waarmee u uw informatiebeveiliging beter kunt bewaken.

Tot de Azure Monitor-extensies behoren onder meer Azure Key Vault (bescherming van cryptografische sleutels in de cloud), Malware Assessment (analyse van de bescherming tegen kwaadaardige code op virtuele machines), Azure Application Gateway Analytics (analyse van onder meer cloudfirewalllogs), etc. . Met deze tools, verrijkt met bepaalde regels voor het verwerken van gebeurtenissen, kunt u verschillende aspecten van de activiteit van cloudservices visualiseren, inclusief beveiliging, en bepaalde afwijkingen van de werking identificeren. Maar zoals vaak gebeurt, vereist elke extra functionaliteit een bijbehorend betaald abonnement, waarvoor overeenkomstige financiële investeringen van u nodig zijn, die u van tevoren moet plannen.

Azure heeft een aantal ingebouwde mogelijkheden voor het monitoren van bedreigingen die zijn geïntegreerd in Azure AD, Azure Monitor en Azure Security Center. Waaronder bijvoorbeeld detectie van interactie van virtuele machines met bekende kwaadaardige IP’s (vanwege de aanwezigheid van integratie met Threat Intelligence-diensten van Microsoft), detectie van malware in de cloudinfrastructuur door alarmen te ontvangen van virtuele machines die in de cloud worden gehost, wachtwoord raden van aanvallen” op virtuele machines, kwetsbaarheden in de configuratie van het gebruikersidentificatiesysteem, inloggen op het systeem vanaf anonimisatoren of geïnfecteerde knooppunten, accountlekken, inloggen op het systeem vanaf ongebruikelijke locaties, enz. Azure is tegenwoordig een van de weinige cloudproviders die u ingebouwde Threat Intelligence-mogelijkheden biedt om de verzamelde informatiebeveiligingsgebeurtenissen te verrijken.

Zoals hierboven vermeld, zijn de beveiligingsfunctionaliteit en, als gevolg daarvan, de beveiligingsgebeurtenissen die daardoor worden gegenereerd, niet voor alle gebruikers in gelijke mate beschikbaar, maar is een bepaald abonnement vereist dat de functionaliteit bevat die u nodig heeft en die de juiste gebeurtenissen genereert voor het monitoren van informatiebeveiliging. Sommige van de in de vorige paragraaf beschreven functies voor het bewaken van afwijkingen in accounts zijn bijvoorbeeld alleen beschikbaar in de P2 premium-licentie voor de Azure AD-service. Zonder dit zult u, zoals in het geval van AWS, de verzamelde beveiligingsgebeurtenissen “handmatig” moeten analyseren. En afhankelijk van het type Azure AD-licentie zijn bovendien niet alle gebeurtenissen beschikbaar voor analyse.

Op de Azure-portal kunt u zowel zoekopdrachten naar logboeken beheren die voor u interessant zijn, als dashboards instellen om belangrijke informatiebeveiligingsindicatoren te visualiseren. Daarnaast kunt u daar Azure Monitor-extensies selecteren, waarmee u de functionaliteit van Azure Monitor-logboeken kunt uitbreiden en vanuit beveiligingsoogpunt een diepere analyse van gebeurtenissen kunt krijgen.

Als u niet alleen de mogelijkheid nodig heeft om met logboeken te werken, maar ook over een uitgebreid beveiligingscentrum voor uw Azure-cloudplatform, inclusief informatiebeveiligingsbeleidsbeheer, dan kunt u praten over de noodzaak om met Azure Security Center te werken, waarvan de meeste nuttige functies zijn voor wat geld beschikbaar, bijvoorbeeld detectie van bedreigingen, monitoring buiten Azure, beoordeling van de naleving, enz. (in de gratis versie heeft u alleen toegang tot een beveiligingsbeoordeling en aanbevelingen voor het elimineren van geïdentificeerde problemen). Het consolideert alle beveiligingsproblemen op één plek. We kunnen in feite spreken van een hoger niveau van informatiebeveiliging dan Azure Monitor u biedt, omdat in dit geval de gegevens die in uw cloudfabriek worden verzameld, worden verrijkt met behulp van vele 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), waarop verschillende geavanceerde machine learning- en gedragsanalyse-algoritmen zijn geplaatst, die uiteindelijk de efficiëntie van het detecteren van en reageren op bedreigingen moeten verbeteren .

Azure heeft ook een eigen SIEM – deze verscheen begin 2019. Dit is Azure Sentinel, die afhankelijk is van data uit Azure Monitor en daar ook mee kan integreren. externe beveiligingsoplossingen (bijvoorbeeld NGFW of WAF), waarvan de lijst voortdurend groeit. Bovendien heeft u door de integratie van de Microsoft Graph Security API de mogelijkheid om uw eigen Threat Intelligence-feeds te koppelen aan Sentinel, wat de mogelijkheden voor het analyseren van incidenten in uw Azure-cloud verrijkt. Er kan worden gesteld dat Azure Sentinel de eerste ‘native’ SIEM is die is verschenen bij cloudproviders (dezelfde Splunk of ELK, die in de cloud kan worden gehost, bijvoorbeeld AWS, worden nog steeds niet ontwikkeld door traditionele cloudserviceproviders). Azure Sentinel en Security Center zouden SOC voor de Azure-cloud kunnen worden genoemd en zouden daartoe beperkt kunnen zijn (met bepaalde voorbehouden) als u geen infrastructuur meer had en al uw computerbronnen naar de cloud zou overbrengen en dit de Microsoft-cloud Azure zou zijn.

Maar aangezien de ingebouwde mogelijkheden van Azure (zelfs als u een abonnement op Sentinel hebt) vaak niet voldoende zijn voor het bewaken van de informatiebeveiliging en het integreren van dit proces met andere bronnen van beveiligingsgebeurtenissen (zowel in de cloud als intern), is er een de verzamelde gegevens moeten exporteren naar externe systemen, waaronder mogelijk SIEM. Dit gebeurt zowel met behulp van de API als met behulp van speciale extensies, die momenteel officieel alleen beschikbaar zijn voor de volgende SIEM's: Splunk (Azure Monitor Add-On voor Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight en ELK. Tot voor kort waren er meer van dit soort SIEM’s, maar vanaf 1 juni 2019 stopte Microsoft met de ondersteuning van de Azure Log Integration Tool (AzLog), die aan het begin van het bestaan ​​van Azure en bij gebrek aan normale standaardisatie van het werken met logs (Azure Monitor bestond nog niet eens) maakte het eenvoudig om externe SIEM te integreren met de Microsoft-cloud. Nu is de situatie veranderd en beveelt Microsoft het Azure Event Hub-platform aan als de belangrijkste integratietool voor andere SIEM’s. Velen hebben een dergelijke integratie al geïmplementeerd, maar wees voorzichtig: mogelijk leggen ze niet alle Azure-logboeken vast, maar slechts enkele (kijk in de documentatie voor uw SIEM).

Ter afsluiting van een korte excursie naar Azure zou ik graag een algemene aanbeveling willen doen over deze cloudservice. Voordat u iets zegt over de functies voor het monitoren van informatiebeveiliging in Azure, moet u deze zeer zorgvuldig configureren en testen of ze werken zoals beschreven in de documentatie en zoals de consultants u Microsoft vertelden (en zij hebben mogelijk verschillende opvattingen over de functionaliteit van Azure-functies). Als u over de financiële middelen beschikt, kunt u veel nuttige informatie uit Azure halen op het gebied van monitoring van informatiebeveiliging. Als uw middelen beperkt zijn, dan zult u, zoals in het geval van AWS, uitsluitend moeten vertrouwen op uw eigen kracht en de ruwe data die Azure Monitor u levert. En vergeet niet dat veel monitoringfuncties geld kosten en dat het beter is om vooraf vertrouwd te raken met het prijsbeleid. U kunt bijvoorbeeld gratis 31 dagen aan gegevens opslaan tot een maximum van 5 GB per klant. Als u deze waarden overschrijdt, moet u extra geld uitgeven (ongeveer $ 2+ voor het opslaan van elke extra GB van de klant en $ 0,1 voor opslag van 1 GB per extra maand). Voor het werken met applicatietelemetrie en -statistieken kan extra geld nodig zijn, evenals voor het werken met waarschuwingen en meldingen (een bepaalde limiet is gratis beschikbaar, wat mogelijk niet voldoende is voor uw behoeften).

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

Google Cloud Platform lijkt een jongeling vergeleken met AWS en Azure, maar dit is deels goed. In tegenstelling tot AWS, dat zijn mogelijkheden, inclusief de beveiliging, geleidelijk uitbreidde en problemen ondervond met de centralisatie; GCP wordt, net als Azure, veel beter centraal beheerd, waardoor fouten en implementatietijd in de hele onderneming worden verminderd. Vanuit veiligheidsoogpunt bevindt GCP zich vreemd genoeg tussen AWS en Azure in. Ook heeft hij één evenementenregistratie voor de hele organisatie, maar die is onvolledig. Sommige functies bevinden zich nog in de bètamodus, maar geleidelijk aan moet dit tekort worden geëlimineerd en zal GCP een volwassener platform worden op het gebied van monitoring van informatiebeveiliging.

Het belangrijkste hulpmiddel voor het vastleggen van gebeurtenissen in GCP is Stackdriver Logging (vergelijkbaar met Azure Monitor), waarmee u gebeurtenissen kunt verzamelen in uw gehele cloudinfrastructuur (en ook vanuit AWS). Vanuit beveiligingsperspectief heeft elke organisatie, project of map in GCP vier logboeken:

• Beheeractiviteit - bevat alle gebeurtenissen die verband houden met beheerderstoegang, bijvoorbeeld het maken van een virtuele machine, het wijzigen van toegangsrechten, enz. Dit logboek wordt altijd geschreven, ongeacht uw wens, en bewaart de gegevens gedurende 400 dagen.
• Gegevenstoegang - 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 ervan zeer snel toeneemt. Om deze reden is de houdbaarheid slechts 30 dagen. Bovendien staat niet alles in dit tijdschrift. Gebeurtenissen met betrekking tot bronnen die openbaar toegankelijk zijn voor alle gebruikers of die toegankelijk zijn zonder in te loggen bij GCP, worden er bijvoorbeeld niet naar geschreven.
• Systeemgebeurtenis - bevat systeemgebeurtenissen die geen verband houden met gebruikers, of acties van een beheerder die de configuratie van cloudbronnen wijzigt. Het wordt altijd geschreven en 400 dagen bewaard.
• Access Transparency is een uniek voorbeeld van een logboek dat alle acties vastlegt van Google-medewerkers (maar nog niet voor alle GCP-services) die toegang hebben tot uw infrastructuur als onderdeel van hun taken. Dit logboek wordt 400 dagen bewaard en is niet voor elke GCP-klant beschikbaar, maar alleen als aan een aantal voorwaarden is voldaan (ondersteuning op Gold- of Platinum-niveau, of de aanwezigheid van 4 rollen van een bepaald type als onderdeel van bedrijfsondersteuning). Een soortgelijke functie is bijvoorbeeld ook beschikbaar in Office 365 - Lockbox.

Logvoorbeeld: Access Transparency

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: 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.com%2Faccess_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 deze logs is op verschillende manieren mogelijk (op vrijwel dezelfde manier als eerder besproken Azure en AWS) - via de Log Viewer-interface, via de API, via de Google Cloud SDK, of via de activiteitenpagina van uw project waarvoor u geïnteresseerd bent in evenementen. Op dezelfde manier kunnen ze worden geëxporteerd naar externe oplossingen voor aanvullende analyse. Dit laatste gebeurt door logbestanden te exporteren naar BigQuery- of Cloud Pub/Sub-opslag.

Naast Stackdriver Logging biedt het GCP-platform ook Stackdriver Monitoring-functionaliteit, waarmee u belangrijke statistieken (prestaties, MTBF, algehele gezondheid, enz.) van cloudservices en -applicaties kunt monitoren. Verwerkte en gevisualiseerde data kunnen het eenvoudiger maken om problemen in uw cloudinfrastructuur op te sporen, ook op het gebied van beveiliging. Maar het moet worden opgemerkt dat deze functionaliteit niet erg rijk zal zijn in de context van informatiebeveiliging, aangezien GCP vandaag geen analoog heeft van dezelfde AWS GuardDuty en geen slechte kan identificeren onder alle geregistreerde gebeurtenissen (Google heeft Event Threat Detection ontwikkeld, maar het is nog in bètafase en het is nog te vroeg om over het nut ervan te praten). Stackdriver Monitoring zou kunnen worden gebruikt als een systeem voor het detecteren van afwijkingen, die vervolgens zouden worden onderzocht om de oorzaken van het optreden ervan te achterhalen. Maar gezien het gebrek aan personeel dat gekwalificeerd is op het gebied van GCP-informatiebeveiliging in de markt, lijkt deze taak momenteel moeilijk.

Het is ook de moeite waard om een ​​lijst te geven van enkele informatiebeveiligingsmodules die binnen uw GCP-cloud kunnen worden gebruikt en die vergelijkbaar zijn met wat AWS biedt:

• Cloud Security Command Center is een analoog van AWS Security Hub en Azure Security Center.
• Cloud DLP - Automatische detectie en bewerking (bijvoorbeeld maskeren) van gegevens die in de cloud worden gehost met behulp van meer dan 90 vooraf gedefinieerde classificatiebeleidsregels.
• Cloud Scanner is een scanner voor bekende kwetsbaarheden (XSS, Flash Injection, ongepatchte bibliotheken, etc.) in App Engine, Compute Engine en Google Kubernetes.
• Cloud IAM - Beheer de toegang tot alle GCP-bronnen.
• Cloud Identity - Beheer GCP-gebruikers-, apparaat- en applicatie-accounts vanaf één console.
• Cloud HSM - bescherming van cryptografische sleutels.
• Cloud Key Management Service - beheer van cryptografische sleutels in GCP.
• VPC Service Control - Creëer een veilige perimeter rond uw GCP-bronnen om ze tegen lekken te beschermen.
• Titan-beveiligingssleutel - bescherming tegen phishing.

Veel van deze modules genereren beveiligingsgebeurtenissen die naar BigQuery-opslag kunnen worden verzonden voor analyse of exporteren naar andere systemen, waaronder SIEM. Zoals hierboven vermeld, is GCP een platform dat zich actief ontwikkelt en Google ontwikkelt nu een aantal nieuwe informatiebeveiligingsmodules voor zijn platform. Daartoe behoren Event Threat Detection (nu beschikbaar in bèta), dat Stackdriver-logboeken scant op zoek naar sporen van ongeautoriseerde activiteit (analoog aan GuardDuty in AWS), of Policy Intelligence (beschikbaar in alfa), waarmee u intelligent beleid kunt ontwikkelen voor toegang tot GCP-bronnen.

Ik heb een kort overzicht gemaakt van de ingebouwde monitoringmogelijkheden in populaire cloudplatforms. Maar heb je specialisten die met ‘rauwe’ logs van IaaS-providers kunnen werken (niet iedereen is bereid de geavanceerde mogelijkheden van AWS of Azure of Google te kopen)? Bovendien zijn velen bekend met het adagium ‘vertrouwen, maar verifieer’, dat meer dan ooit van toepassing is op het gebied van beveiliging. Hoeveel vertrouwen heeft u in de ingebouwde mogelijkheden van de cloudprovider die u informatiebeveiligingsgebeurtenissen stuurt? Hoeveel aandacht besteden ze überhaupt aan informatiebeveiliging?

Soms is het de moeite waard om te kijken naar overlay-oplossingen voor monitoring van de cloudinfrastructuur die de ingebouwde cloudbeveiliging kunnen aanvullen, en soms zijn dergelijke oplossingen de enige optie om inzicht te krijgen in de beveiliging van uw gegevens en applicaties die in de cloud worden gehost. Bovendien zijn ze gewoon handiger, omdat ze alle taken op zich nemen van het analyseren van de benodigde logs die worden gegenereerd door verschillende clouddiensten van verschillende cloudproviders. Een voorbeeld van een dergelijke overlay-oplossing is Cisco Stealthwatch Cloud, dat zich richt op één enkele taak: het monitoren van afwijkingen in de informatiebeveiliging in cloudomgevingen, waaronder niet alleen Amazon AWS, Microsoft Azure en Google Cloud Platform, maar ook privéclouds.

Voorbeeld: Informatiebeveiligingsmonitoring met behulp van Stealthwatch Cloud

AWS biedt een flexibel computerplatform, maar deze flexibiliteit maakt het voor bedrijven gemakkelijker om fouten te maken die tot beveiligingsproblemen leiden. En het gedeelde informatiebeveiligingsmodel draagt ​​daar alleen maar aan bij. Het draaien van software in de cloud met onbekende kwetsbaarheden (bekende kunnen worden bestreden door bijvoorbeeld AWS Inspector of GCP Cloud Scanner), zwakke wachtwoorden, foutieve configuraties, insiders, etc. En dit alles wordt weerspiegeld in het gedrag van cloudbronnen, dat kan worden gemonitord door Cisco Stealthwatch Cloud, een systeem voor het monitoren van informatiebeveiliging en het detecteren van aanvallen. publieke en private clouds.

Een van de belangrijkste kenmerken van Cisco Stealthwatch Cloud is de mogelijkheid om entiteiten te modelleren. Hiermee kunt u een softwaremodel (dat wil zeggen een bijna realtime simulatie) maken van elk van uw cloudbronnen (het maakt niet uit of het AWS, Azure, GCP of iets anders is). Dit kunnen servers en gebruikers zijn, maar ook resourcetypen die specifiek zijn voor uw cloudomgeving, zoals beveiligingsgroepen en groepen voor automatisch schalen. Deze modellen gebruiken gestructureerde datastromen van clouddiensten als input. Voor AWS zijn dit bijvoorbeeld VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda en AWS IAM. Entiteitsmodellering ontdekt automatisch de rol en het gedrag van al uw bronnen (u kunt praten over het profileren van alle cloudactiviteiten). Deze rollen omvatten een mobiel Android- of Apple-apparaat, Citrix PVS-server, RDP-server, mailgateway, VoIP-client, terminalserver, domeincontroller, enz. Vervolgens wordt hun gedrag voortdurend in de gaten gehouden om te bepalen wanneer er risicovol of veiligheidsbedreigend gedrag optreedt. U kunt het raden van wachtwoorden, DDoS-aanvallen, datalekken, illegale toegang op afstand, kwaadaardige code-activiteiten, scannen op kwetsbaarheden en andere bedreigingen identificeren. Dit is bijvoorbeeld hoe het detecteren van een poging tot externe toegang vanuit een land dat atypisch is voor uw organisatie (Zuid-Korea) naar een Kubernetes-cluster via SSH eruit ziet:

En zo ziet het vermeende lekken van informatie uit de Postgress-database naar een land waarmee we nog niet eerder interactie hebben gehad eruit:

Dit is tenslotte hoe veel mislukte SSH-pogingen uit China en Indonesië vanaf een extern apparaat er zo uitzien:

Of stel dat de serverinstance in de VPC volgens het beleid nooit een externe inlogbestemming mag zijn. Laten we verder aannemen dat deze computer een externe aanmelding heeft ondergaan als gevolg van een foutieve wijziging in het firewallregelsbeleid. De Entity Modeling-functie detecteert en rapporteert deze activiteit (“Ongebruikelijke toegang op afstand”) in bijna realtime en verwijst naar de specifieke AWS CloudTrail-, Azure Monitor- of GCP Stackdriver Logging API-aanroep (inclusief onder meer gebruikersnaam, datum en tijd). ), wat aanleiding gaf tot de wijziging van de ITU-regel. En vervolgens kan deze informatie voor analyse naar SIEM worden gestuurd.

Soortgelijke mogelijkheden zijn geïmplementeerd voor elke cloudomgeving die wordt ondersteund door Cisco Stealthwatch Cloud:

Entiteitsmodellering is een unieke vorm van beveiligingsautomatisering die een voorheen onbekend probleem met uw mensen, processen of technologie kan blootleggen. Hiermee kunt u bijvoorbeeld onder meer beveiligingsproblemen opsporen zoals:

• Heeft iemand een achterdeur ontdekt in de software die we gebruiken?
• Is er software of apparaat van derden in onze cloud?
• Maakt de geautoriseerde gebruiker misbruik van rechten?
• Was er een configuratiefout die externe toegang of ander onbedoeld gebruik van bronnen mogelijk maakte?
• Is er sprake van een datalek van onze servers?
• Probeerde iemand verbinding met ons te maken vanaf een atypische geografische locatie?
• Is onze cloud besmet met kwaadaardige code?

Een gedetecteerde informatiebeveiligingsgebeurtenis kan in de vorm van een bijbehorend ticket worden verzonden naar Slack, Cisco Spark, het incidentbeheersysteem PagerDuty, en ook naar verschillende SIEM's, waaronder Splunk of ELK. Samenvattend kunnen we zeggen dat als uw bedrijf een multi-cloudstrategie gebruikt en zich niet beperkt tot één cloudprovider, de hierboven beschreven mogelijkheden voor het monitoren van informatiebeveiliging, het gebruik van Cisco Stealthwatch Cloud een goede optie is om een ​​uniforme set van monitoring te krijgen. mogelijkheden voor de toonaangevende cloudspelers - Amazon, Microsoft en Google. Het meest interessante is dat als je de prijzen voor Stealthwatch Cloud vergelijkt met geavanceerde licenties voor informatiebeveiligingsmonitoring in AWS, Azure of GCP, het kan blijken dat de Cisco-oplossing zelfs goedkoper zal zijn dan de ingebouwde mogelijkheden van Amazon, Microsoft en Google-oplossingen. Het is paradoxaal, maar het is waar. En hoe meer clouds en hun mogelijkheden u gebruikt, hoe duidelijker het voordeel van een geconsolideerde oplossing zal zijn.

Bovendien kan Stealthwatch Cloud privéclouds monitoren die in uw organisatie worden ingezet, bijvoorbeeld op basis van Kubernetes-containers of door Netflow-stromen of netwerkverkeer te monitoren dat wordt ontvangen via mirroring in netwerkapparatuur (zelfs in eigen land geproduceerd), AD-gegevens of DNS-servers enzovoort. Al deze gegevens zullen worden verrijkt met Threat Intelligence-informatie verzameld door Cisco Talos, 's werelds grootste niet-gouvernementele groep onderzoekers op het gebied van cyberveiligheidsdreigingen.

Hierdoor kunt u een uniform monitoringsysteem implementeren voor zowel publieke als hybride clouds waar uw bedrijf gebruik van kan maken. De verzamelde informatie kan vervolgens worden geanalyseerd met behulp van de ingebouwde mogelijkheden van Stealthwatch Cloud of naar uw SIEM worden verzonden (Splunk, ELK, SumoLogic en verschillende andere worden standaard ondersteund).

Hiermee ronden we het eerste deel van het artikel af, waarin ik de ingebouwde en externe tools heb besproken voor het monitoren van informatiebeveiliging van IaaS/PaaS-platforms, waarmee we snel incidenten kunnen detecteren en erop kunnen reageren die zich voordoen in de cloudomgevingen die onze onderneming heeft gekozen. In het tweede deel gaan we verder met het onderwerp en kijken we naar opties voor het monitoren van SaaS-platforms met behulp van het voorbeeld van Salesforce en Dropbox, en we zullen ook proberen alles samen te vatten en samen te voegen door een uniform monitoringsysteem voor informatiebeveiliging te creëren voor verschillende cloudproviders.

Bron: www.habr.com