Molnsäkerhetsövervakning

Att flytta data och applikationer till molnet innebär en ny utmaning för företags SOC, som inte alltid är redo att övervaka någon annans infrastruktur. Enligt Netoskope använder det genomsnittliga företaget (uppenbarligen i USA) 1246 22 olika molntjänster, vilket är 1246 % mer än för ett år sedan. 175 molntjänster!!! 170 av dem är relaterade till HR-tjänster, 110 är relaterade till marknadsföring, 76 är inom kommunikation och 700 är inom ekonomi och CRM. Cisco använder "bara" XNUMX externa molntjänster. Så jag är lite förvirrad över dessa siffror. Men problemet ligger i alla fall inte hos dem, utan i att molnet börjar användas ganska aktivt av ett ökande antal företag som gärna vill ha samma möjligheter att övervaka molninfrastruktur som i det egna nätverket. Och denna trend växer - enligt enligt American Chamber of Accounts År 2023 kommer 1200 6250 datacenter att stängas i USA (XNUMX XNUMX har redan stängt). Men övergången till molnet är inte bara "låt oss flytta våra servrar till en extern leverantör." Ny IT-arkitektur, ny mjukvara, nya processer, nya begränsningar... Allt detta medför betydande förändringar i inte bara IT-arbetet utan även informationssäkerhet. Och om leverantörer har lärt sig att på något sätt klara av att säkerställa säkerheten för själva molnet (lyckligtvis finns det många rekommendationer), så med molninformationssäkerhetsövervakning, särskilt på SaaS-plattformar, finns det betydande svårigheter, som vi kommer att prata om.

Låt oss säga att ditt företag har flyttat en del av sin infrastruktur till molnet... Sluta. Inte på det här sättet. Om infrastrukturen har överförts, och du först nu funderar på hur du ska övervaka den, då har du redan förlorat. Såvida det inte är Amazon, Google eller Microsoft (och då med reservationer), har du förmodligen inte mycket möjlighet att övervaka dina data och applikationer. Det är bra om du får möjlighet att arbeta med stockar. Ibland kommer data om säkerhetshändelser att vara tillgänglig, men du kommer inte att ha tillgång till den. Till exempel Office 365. Om du har den billigaste E1-licensen är säkerhetshändelser inte tillgängliga för dig alls. Om du har en E3-licens lagras dina data i endast 90 dagar, och endast om du har en E5-licens är loggarnas varaktighet tillgänglig i ett år (dock har detta också sina egna nyanser relaterade till behovet av separat begära ett antal funktioner för att arbeta med loggar från Microsofts support). E3-licensen är för övrigt mycket svagare vad gäller övervakningsfunktioner än företagsbörsen. För att uppnå samma nivå behöver du en E5-licens eller en extra Advanced Compliance-licens, vilket kan kräva ytterligare pengar som inte ingick i din ekonomiska modell för att flytta till molninfrastruktur. Och detta är bara ett exempel på underskattning av frågor relaterade till övervakning av molninformationssäkerhet. I den här artikeln vill jag, utan att låtsas vara komplett, uppmärksamma några nyanser som bör beaktas när man väljer en molnleverantör ur säkerhetssynpunkt. Och i slutet av artikeln kommer en checklista att ges som är värd att fylla i innan man överväger att frågan om övervakning av molninformationssäkerhet är löst.

Det finns flera typiska problem som leder till incidenter i molnmiljöer, som informationssäkerhetstjänster inte har tid att svara på eller inte ser dem alls:

• Säkerhetsloggar finns inte. Detta är en ganska vanlig situation, särskilt bland nybörjare på marknaden för molnlösningar. Men du ska inte ge upp dem direkt. Små aktörer, särskilt inhemska, är mer känsliga för kundernas krav och kan snabbt implementera vissa nödvändiga funktioner genom att ändra den godkända färdplanen för sina produkter. Ja, detta kommer inte att vara en analog till GuardDuty från Amazon eller modulen "Proactive Protection" från Bitrix, men åtminstone något.
• Informationssäkerheten vet inte var loggarna lagras eller det finns ingen tillgång till dem. Här är det nödvändigt att inleda förhandlingar med molntjänstleverantören - kanske kommer han att tillhandahålla sådan information om han anser att kunden är viktig för honom. Men i allmänhet är det inte särskilt bra när tillgång till loggar tillhandahålls "genom särskilt beslut."
• Det händer också att molnleverantören har loggar, men de ger begränsad övervakning och händelseregistrering, vilket inte räcker för att upptäcka alla incidenter. Du kan till exempel bara få loggar över ändringar på en webbplats eller loggar över användarautentiseringsförsök, men inte andra händelser, såsom nätverkstrafik, som kommer att dölja ett helt lager av händelser för dig som kännetecknar försök att hacka din molninfrastruktur.
• Det finns loggar, men tillgången till dem är svår att automatisera, vilket tvingar dem att övervakas inte kontinuerligt, utan enligt ett schema. Och om du inte kan ladda ner loggar automatiskt, kan nedladdning av loggar, till exempel i Excel-format (som med ett antal inhemska molnlösningsleverantörer), till och med leda till en ovilja från företagsinformationssäkerhetstjänstens sida att mixtra med dem.
• Ingen loggövervakning. Detta är kanske den mest oklara orsaken till förekomsten av informationssäkerhetsincidenter i molnmiljöer. Det verkar som att det finns loggar, och det är möjligt att automatisera åtkomst till dem, men ingen gör detta. Varför?

Delat molnsäkerhetskoncept

Övergången till molnet är alltid ett sökande efter en balans mellan viljan att behålla kontrollen över infrastrukturen och att överföra den till de mer professionella händerna på en molnleverantör som är specialiserad på att underhålla den. Och inom området molnsäkerhet måste denna balans också eftersträvas. Dessutom, beroende på vilken molntjänstleveransmodell som används (IaaS, PaaS, SaaS), kommer denna balans att vara olika hela tiden. Vi ska i alla fall komma ihåg att alla molnleverantörer idag följer den så kallade modellen för delat ansvar och delad informationssäkerhet. Molnet är ansvarigt för vissa saker, och för andra ansvarar klienten för att placera sin data, sina applikationer, sina virtuella maskiner och andra resurser i molnet. Det skulle vara hänsynslöst att förvänta sig att genom att gå till molnet kommer vi att flytta allt ansvar till leverantören. Men det är också oklokt att bygga all säkerhet själv när du flyttar till molnet. En balans krävs, vilket kommer att bero på många faktorer: - riskhanteringsstrategi, hotmodell, säkerhetsmekanismer tillgängliga för molnleverantören, lagstiftning, etc.

Till exempel är klassificeringen av data som lagras i molnet alltid kundens ansvar. En molnleverantör eller en extern tjänsteleverantör kan bara hjälpa honom med verktyg som hjälper till att markera data i molnet, identifiera överträdelser, radera data som bryter mot lagen eller maskera det med en eller annan metod. Å andra sidan är fysisk säkerhet alltid molnleverantörens ansvar, som den inte kan dela med kunderna. Men allt som är mellan data och fysisk infrastruktur är just föremål för diskussion i denna artikel. Till exempel är tillgängligheten av molnet leverantörens ansvar, och att sätta upp brandväggsregler eller aktivera kryptering är kundens ansvar. I den här artikeln kommer vi att försöka titta på vilka mekanismer för övervakning av informationssäkerhet som tillhandahålls idag av olika populära molnleverantörer i Ryssland, vad är funktionerna för deras användning och när är det värt att titta på externa överlagringslösningar (till exempel Cisco E- mail Security) som utökar kapaciteten i ditt moln när det gäller cybersäkerhet. I vissa fall, särskilt om du följer en strategi för flera moln, har du inget annat val än att använda externa lösningar för övervakning av informationssäkerhet i flera molnmiljöer samtidigt (till exempel Cisco CloudLock eller Cisco Stealthwatch Cloud). Tja, i vissa fall kommer du att inse att molnleverantören du har valt (eller ålagt dig) inte erbjuder några funktioner för övervakning av informationssäkerhet alls. Detta är obehagligt, men inte heller lite, eftersom det låter dig bedöma risknivån som är förknippad med att arbeta med detta moln på ett adekvat sätt.

Cloud Security Monitoring Lifecycle

För att övervaka säkerheten för molnen du använder har du bara tre alternativ:

• lita på verktygen från din molnleverantör,
• använda lösningar från tredje part som kommer att övervaka de IaaS-, PaaS- eller SaaS-plattformar du använder,
• bygg din egen molnövervakningsinfrastruktur (endast för IaaS/PaaS-plattformar).

Låt oss se vilka funktioner vart och ett av dessa alternativ har. Men först måste vi förstå det allmänna ramverket som kommer att användas vid övervakning av molnplattformar. Jag skulle lyfta fram 6 huvudkomponenter i informationssäkerhetsövervakningsprocessen i molnet:

• Förberedelse av infrastruktur. Fastställande av nödvändiga applikationer och infrastruktur för att samla in händelser som är viktiga för informationssäkerheten i lagring.
• Samling. I detta skede aggregeras säkerhetshändelser från olika källor för efterföljande överföring för bearbetning, lagring och analys.
• Behandling. I detta skede omvandlas och berikas data för att underlätta efterföljande analys.
• Lagring. Denna komponent ansvarar för kort- och långtidslagring av insamlad bearbetad och rådata.
• Analys. I detta skede har du möjlighet att upptäcka incidenter och svara på dem automatiskt eller manuellt.
• Rapportering. Detta steg hjälper oss att formulera nyckelindikatorer för intressenter (ledning, revisorer, molnleverantör, kunder, etc.) som hjälper oss att fatta vissa beslut, till exempel att byta leverantör eller stärka informationssäkerheten.

Genom att förstå dessa komponenter kan du snabbt bestämma i framtiden vad du kan ta från din leverantör och vad du måste göra själv eller med inblandning av externa konsulter.

Inbyggda molntjänster

Jag skrev redan ovan att många molntjänster idag inte tillhandahåller någon informationssäkerhetsövervakningsfunktion. I allmänhet ägnar de inte mycket uppmärksamhet åt ämnet informationssäkerhet. Till exempel en av de populära ryska tjänsterna för att skicka rapporter till statliga myndigheter via Internet (jag kommer inte specifikt att nämna dess namn). Hela avsnittet om säkerheten för denna tjänst kretsar kring användningen av certifierad CIPF. Informationssäkerhetsdelen av en annan inhemsk molntjänst för elektronisk dokumenthantering är inte annorlunda. Den talar om certifikat för offentliga nyckel, certifierad kryptografi, eliminering av webbsårbarheter, skydd mot DDoS-attacker, användning av brandväggar, säkerhetskopior och till och med regelbundna revisioner av informationssäkerhet. Men det finns inte ett ord om övervakning och inte heller om möjligheten att få tillgång till informationssäkerhetshändelser som kan vara av intresse för denna tjänsteleverantörs kunder.

I allmänhet, genom att molnleverantören beskriver informationssäkerhetsproblem på sin webbplats och i sin dokumentation, kan du förstå hur allvarligt den tar detta problem. Om du till exempel läser manualerna för "My Office"-produkterna står det inte ett ord om säkerhet alls, utan i dokumentationen för den separata produkten "My Office. KS3”, utformad för att skydda mot obehörig åtkomst, finns det en vanlig lista över punkter av 17:e ordningen i FSTEC, som "My Office.KS3" implementerar, men det beskrivs inte hur det implementerar det och, viktigast av allt, hur man integrera dessa mekanismer med företagens informationssäkerhet. Kanske finns sådan dokumentation, men jag hittade den inte offentligt på webbplatsen "Mitt kontor". Även om jag kanske helt enkelt inte har tillgång till denna hemliga information? ..

För Bitrix är situationen mycket bättre. Dokumentationen beskriver formaten för händelseloggarna och, intressant nog, intrångsloggen, som innehåller händelser relaterade till potentiella hot mot molnplattformen. Därifrån kan du hämta IP, användar- eller gästnamn, händelsekälla, tid, användaragent, händelsetyp, etc. Det är sant att du kan arbeta med dessa händelser antingen från själva molnets kontrollpanel eller ladda upp data i MS Excel-format. Det är nu svårt att automatisera arbete med Bitrix-loggar och du måste göra en del av arbetet manuellt (ladda upp rapporten och ladda den i din SIEM). Men om vi kommer ihåg att en sådan möjlighet tills relativt nyligen inte fanns, så är detta stora framsteg. Samtidigt vill jag notera att många utländska molnleverantörer erbjuder liknande funktionalitet "för nybörjare" - antingen titta på loggarna med dina ögon genom kontrollpanelen eller ladda upp data till dig själv (de flesta laddar dock upp data i . csv-format, inte Excel).

Utan att överväga alternativet utan loggar, erbjuder molnleverantörer dig vanligtvis tre alternativ för att övervaka säkerhetshändelser - instrumentpaneler, datauppladdning och API-åtkomst. Den första verkar lösa många problem för dig, men detta är inte helt sant - om du har flera tidningar måste du växla mellan skärmarna som visar dem och förlorar helhetsbilden. Dessutom är det osannolikt att molnleverantören ger dig möjligheten att korrelera säkerhetshändelser och generellt analysera dem ur säkerhetssynpunkt (vanligtvis har du att göra med rådata, som du själv måste förstå). Det finns undantag och vi kommer att prata om dem vidare. Slutligen är det värt att fråga vilka händelser som registreras av din molnleverantör, i vilket format och hur överensstämmer de med din process för informationssäkerhetsövervakning? Till exempel identifiering och autentisering av användare och gäster. Samma Bitrix tillåter dig, baserat på dessa händelser, att registrera datum och tid för händelsen, namnet på användaren eller gästen (om du har modulen "Web Analytics"), det objekt som nås och andra element som är typiska för en webbplats . Men företagsinformationssäkerhetstjänster kan behöva information om huruvida användaren fick åtkomst till molnet från en betrodd enhet (till exempel i ett företagsnätverk implementeras denna uppgift av Cisco ISE). Vad sägs om en så enkel uppgift som geo-IP-funktionen, som hjälper till att avgöra om ett användarkonto för molntjänsten har stulits? Och även om molnleverantören tillhandahåller det till dig räcker det inte. Samma Cisco CloudLock analyserar inte bara geolokalisering, utan använder maskininlärning för detta och analyserar historisk data för varje användare och övervakar olika anomalier i identifierings- och autentiseringsförsök. Endast MS Azure har liknande funktionalitet (om du har rätt prenumeration).

Det finns en annan svårighet – eftersom informationssäkerhetsövervakning för många molnleverantörer är ett nytt ämne som de precis har börjat ta itu med, förändrar de hela tiden något i sina lösningar. Idag har de en version av API:t, imorgon en annan, i övermorgon en tredje. Du måste också vara beredd på detta. Detsamma gäller funktionalitet, som kan ändras, vilket måste beaktas i ditt övervakningssystem för informationssäkerhet. Till exempel hade Amazon från början separata tjänster för övervakning av molnhändelser – AWS CloudTrail och AWS CloudWatch. Då dök en separat tjänst för övervakning av informationssäkerhetshändelser upp – AWS GuardDuty. Efter en tid lanserade Amazon ett nytt ledningssystem, Amazon Security Hub, som inkluderar analys av data som tagits emot från GuardDuty, Amazon Inspector, Amazon Macie och flera andra. Ett annat exempel är Azure-loggintegreringsverktyget med SIEM - AzLog. Det användes aktivt av många SIEM-leverantörer, tills 2018 Microsoft tillkännagav upphörandet av sin utveckling och support, vilket konfronterade många kunder som använde det här verktyget med ett problem (vi kommer att prata om hur det löstes senare).

Övervaka därför noggrant alla övervakningsfunktioner som din molnleverantör erbjuder dig. Eller lita på externa lösningsleverantörer som kommer att fungera som mellanhänder mellan din SOC och molnet du vill övervaka. Ja, det blir dyrare (men inte alltid), men du kommer att lägga allt ansvar på någon annans axlar. Eller inte allt? .. Låt oss komma ihåg konceptet delad säkerhet och förstå att vi inte kan flytta någonting - vi måste självständigt förstå hur olika molnleverantörer tillhandahåller övervakning av informationssäkerheten för dina data, applikationer, virtuella maskiner och andra resurser värd i molnet. Och vi börjar med vad Amazon erbjuder i den här delen.

Exempel: Informationssäkerhetsövervakning i IaaS baserad på AWS

Ja, ja, jag förstår att Amazon inte är det bästa exemplet på grund av att detta är en amerikansk tjänst och den kan blockeras som en del av kampen mot extremism och spridning av information som är förbjuden i Ryssland. Men i den här publikationen skulle jag bara vilja visa hur olika molnplattformar skiljer sig i sina möjligheter till informationssäkerhetsövervakning och vad du bör vara uppmärksam på när du överför dina nyckelprocesser till molnen ur säkerhetssynpunkt. Tja, om några av de ryska utvecklarna av molnlösningar lär sig något användbart för sig själva, så kommer det att vara bra.

Det första man kan säga är att Amazon inte är en ogenomtränglig fästning. Olika incidenter händer regelbundet med hans klienter. Till exempel stals namn, adresser, födelsedatum och telefonnummer till 198 miljoner väljare från Deep Root Analytics. Det israeliska företaget Nice Systems stal 14 miljoner register över Verizon-prenumeranter. AWS inbyggda möjligheter tillåter dig dock att upptäcka ett brett utbud av incidenter. Till exempel:

• påverkan på infrastruktur (DDoS)
• nod kompromiss (kommandeinjektion)
• kontokompromiss och obehörig åtkomst
• felaktig konfiguration och sårbarheter
• osäkra gränssnitt och API:er.

Denna diskrepans beror på att kunden, som vi fick reda på ovan, själv är ansvarig för säkerheten för kunddata. Och om han inte brydde sig om att slå på skyddsmekanismer och inte aktiverade övervakningsverktyg, kommer han bara att lära sig om händelsen från media eller från sina klienter.

För att identifiera incidenter kan du använda ett brett utbud av olika övervakningstjänster utvecklade av Amazon (även om dessa ofta kompletteras med externa verktyg som osquery). Så i AWS övervakas alla användaråtgärder, oavsett hur de utförs - via hanteringskonsolen, kommandoraden, SDK eller andra AWS-tjänster. Alla register över varje AWS-kontos aktivitet (inklusive användarnamn, åtgärd, tjänst, aktivitetsparametrar och resultat) och API-användning är tillgängliga via AWS CloudTrail. Du kan se dessa händelser (som AWS IAM-konsolinloggningar) från CloudTrail-konsolen, analysera dem med Amazon Athena eller "outsourca" dem till externa lösningar som Splunk, AlienVault, etc. Själva AWS CloudTrail-loggarna placeras i din AWS S3-hink.

Två andra AWS-tjänster tillhandahåller ett antal andra viktiga övervakningsmöjligheter. För det första är Amazon CloudWatch en övervakningstjänst för AWS-resurser och applikationer som bland annat låter dig identifiera olika anomalier i ditt moln. Alla inbyggda AWS-tjänster, som Amazon Elastic Compute Cloud (servrar), Amazon Relational Database Service (databaser), Amazon Elastic MapReduce (dataanalys) och 30 andra Amazon-tjänster, använder Amazon CloudWatch för att lagra sina loggar. Utvecklare kan använda det öppna API:et från Amazon CloudWatch för att lägga till loggövervakningsfunktioner till anpassade applikationer och tjänster, vilket gör att de kan utöka omfattningen av händelseanalys inom ett säkerhetssammanhang.

För det andra låter tjänsten VPC Flow Logs dig analysera nätverkstrafiken som skickas eller tas emot av dina AWS-servrar (externt eller internt), såväl som mellan mikrotjänster. När någon av dina AWS VPC-resurser interagerar med nätverket, registrerar VPC Flow Logs detaljer om nätverkstrafiken, inklusive käll- och destinationsnätverksgränssnittet, såväl som IP-adresser, portar, protokoll, antal byte och antal paket du fick syn på. De som har erfarenhet av lokal nätverkssäkerhet kommer att känna igen detta som analogt med trådar Nettoflödet, som kan skapas av switchar, routrar och brandväggar av företagsklass. Dessa loggar är viktiga för övervakning av informationssäkerhet eftersom, till skillnad från händelser om användares och applikationers handlingar, tillåter de dig också att inte missa nätverksinteraktioner i AWS virtuella privata molnmiljö.

Sammanfattningsvis ger dessa tre AWS-tjänster – AWS CloudTrail, Amazon CloudWatch och VPC Flow Logs – tillsammans ganska kraftfull insikt i din kontoanvändning, användarbeteende, infrastrukturhantering, applikations- och tjänstaktivitet och nätverksaktivitet. De kan till exempel användas för att upptäcka följande anomalier:

• Försök att skanna webbplatsen, söka efter bakdörrar, söka efter sårbarheter genom skurar av "404-fel".
• Injektionsattacker (till exempel SQL-injektion) genom skurar av "500 fel".
• Kända attackverktyg är sqlmap, nikto, w3af, nmap, etc. genom analys av fältet User Agent.

Amazon Web Services har även utvecklat andra tjänster för cybersäkerhetsändamål som låter dig lösa många andra problem. Till exempel har AWS en inbyggd tjänst för granskning av policyer och konfigurationer - AWS Config. Den här tjänsten tillhandahåller kontinuerlig granskning av dina AWS-resurser och deras konfigurationer. Låt oss ta ett enkelt exempel: Låt oss säga att du vill se till att användarlösenord är inaktiverade på alla dina servrar och att åtkomst endast är möjlig baserat på certifikat. AWS Config gör det enkelt att kontrollera detta för alla dina servrar. Det finns andra policyer som kan tillämpas på dina molnservrar: "Ingen server kan använda port 22", "Endast administratörer kan ändra brandväggsregler" eller "Endast användaren Ivashko kan skapa nya användarkonton, och han kan göra det bara på tisdagar. " Sommaren 2016 utökades AWS Config-tjänsten för att automatisera upptäckten av överträdelser av utvecklade policyer. AWS Config Rules är i huvudsak kontinuerliga konfigurationsförfrågningar för Amazon-tjänsterna du använder, som genererar händelser om motsvarande policyer överträds. Till exempel, istället för att regelbundet köra AWS Config-frågor för att verifiera att alla diskar på en virtuell server är krypterade, kan AWS Config Rules användas för att kontinuerligt kontrollera serverdiskar för att säkerställa att detta villkor är uppfyllt. Och, viktigast av allt, i samband med denna publikation genererar eventuella överträdelser händelser som kan analyseras av din informationssäkerhetstjänst.

AWS har också sin motsvarighet till traditionella företagsinformationssäkerhetslösningar, som också genererar säkerhetshändelser som du kan och bör analysera:

• Intrångsdetektering - AWS GuardDuty
• Informationsläckagekontroll - AWS Macie
• EDR (även om det pratar om endpoints i molnet lite konstigt) - AWS Cloudwatch + open source osquery eller GRR-lösningar
• Netflowanalys - AWS Cloudwatch + AWS VPC Flow
• DNS-analys - AWS Cloudwatch + AWS Route53
• AD - AWS Directory Service
• Account Management - AWS IAM
• SSO - AWS SSO
• säkerhetsanalys - AWS Inspector
• konfigurationshantering - AWS Config
• WAF - AWS WAF.

Jag kommer inte att beskriva i detalj alla Amazon-tjänster som kan vara användbara i samband med informationssäkerhet. Det viktigaste är att förstå att alla av dem kan generera händelser som vi kan och bör analysera i samband med informationssäkerhet, och för detta ändamål använder både Amazons inbyggda kapacitet och externa lösningar, till exempel SIEM, som kan ta säkerhetshändelser till ditt övervakningscenter och analysera dem där tillsammans med händelser från andra molntjänster eller från intern infrastruktur, perimeter eller mobila enheter.

I vilket fall som helst börjar allt med datakällorna som ger dig informationssäkerhetshändelser. Dessa källor inkluderar, men är inte begränsade till:

• CloudTrail - API-användning och användaråtgärder
• Trusted Advisor - säkerhetskontroll mot bästa praxis
• Config - inventering och konfiguration av konton och tjänsteinställningar
• VPC Flow Logs - anslutningar till virtuella gränssnitt
• IAM - identifierings- och autentiseringstjänst
• ELB Access Logs - Load Balancer
• Inspektör - applikationssårbarheter
• S3 - fillagring
• CloudWatch - Applikationsaktivitet
• SNS är en aviseringstjänst.

Amazon erbjuder ett sådant utbud av evenemangskällor och verktyg för sin generation, men är mycket begränsad i sin förmåga att analysera den insamlade informationen i samband med informationssäkerhet. Du måste självständigt studera de tillgängliga loggarna och leta efter relevanta indikatorer på kompromiss i dem. AWS Security Hub, som Amazon nyligen lanserade, syftar till att lösa detta problem genom att bli ett moln SIEM för AWS. Men än så länge är det bara i början av sin resa och är begränsat både av antalet källor som det fungerar med och av andra restriktioner som fastställts av Amazons arkitektur och prenumerationer.

Exempel: Informationssäkerhetsövervakning i IaaS baserad på Azure

Jag vill inte gå in i en lång debatt om vilken av de tre molnleverantörerna (Amazon, Microsoft eller Google) som är bättre (särskilt eftersom var och en av dem fortfarande har sina egna specifika detaljer och är lämpliga för att lösa sina egna problem); Låt oss fokusera på funktionerna för övervakning av informationssäkerhet som dessa spelare tillhandahåller. Det ska erkännas att Amazon AWS var en av de första i detta segment och därför har kommit längst vad gäller sina informationssäkerhetsfunktioner (även om många medger att de är svåra att använda). Men det betyder inte att vi kommer att ignorera de möjligheter som Microsoft och Google ger oss.

Microsoft-produkter har alltid kännetecknats av sin "öppenhet" och i Azure är situationen liknande. Till exempel, om AWS och GCP alltid utgår från konceptet "vad som inte är tillåtet är förbjudet", så har Azure det raka motsatta tillvägagångssättet. Till exempel, när du skapar ett virtuellt nätverk i molnet och en virtuell maskin i det, är alla portar och protokoll öppna och tillåtna som standard. Därför måste du lägga lite mer ansträngning på den initiala installationen av åtkomstkontrollsystemet i molnet från Microsoft. Och detta ställer också strängare krav på dig när det gäller övervakning av aktivitet i Azure-molnet.

AWS har en egenhet förknippad med det faktum att när du övervakar dina virtuella resurser, om de finns i olika regioner, har du svårigheter med att kombinera alla händelser och deras enhetliga analys, för att eliminera vilka du behöver ta till olika knep, som t.ex. Skapa din egen kod för AWS Lambda som kommer att transportera evenemang mellan regioner. Azure har inte det här problemet – dess aktivitetsloggmekanism spårar all aktivitet i hela organisationen utan begränsningar. Detsamma gäller AWS Security Hub, som nyligen utvecklats av Amazon för att konsolidera många säkerhetsfunktioner inom ett enda säkerhetscenter, men endast inom dess region, vilket dock inte är relevant för Ryssland. Azure har sitt eget säkerhetscenter, som inte är bundet av regionala begränsningar, vilket ger tillgång till alla säkerhetsfunktioner i molnplattformen. Dessutom kan den för olika lokala team tillhandahålla sin egen uppsättning skyddsfunktioner, inklusive säkerhetshändelser som hanteras av dem. AWS Security Hub är fortfarande på väg att bli liknande Azure Security Center. Men det är värt att lägga till en kula – du kan pressa ur Azure mycket av det som tidigare beskrivits i AWS, men detta görs enbart för Azure AD, Azure Monitor och Azure Security Center. Alla andra Azure-säkerhetsmekanismer, inklusive analys av säkerhetshändelser, hanteras ännu inte på det mest bekväma sättet. Problemet löses delvis av API:et, som genomsyrar alla Microsoft Azure-tjänster, men detta kommer att kräva ytterligare ansträngningar från dig för att integrera ditt moln med din SOC och närvaron av kvalificerade specialister (i själva verket, som med alla andra SIEM som fungerar med moln API:er). Vissa SIEM, som kommer att diskuteras senare, stöder redan Azure och kan automatisera uppgiften att övervaka det, men det har också sina egna svårigheter - alla kan inte samla in alla loggar som Azure har.

Händelseinsamling och övervakning i Azure tillhandahålls med hjälp av Azure Monitor-tjänsten, som är huvudverktyget för att samla in, lagra och analysera data i Microsofts moln och dess resurser - Git-förråd, behållare, virtuella maskiner, applikationer, etc. All data som samlas in av Azure Monitor är indelad i två kategorier - mätvärden, som samlas in i realtid och som beskriver nyckelprestandaindikatorer för Azure-molnet, och loggar, som innehåller data organiserade i poster som kännetecknar vissa aspekter av aktiviteten för Azure-resurser och -tjänster. Dessutom, med hjälp av Data Collector API, kan Azure Monitor-tjänsten samla in data från valfri REST-källa för att bygga sina egna övervakningsscenarier.

Här är några säkerhetshändelsekällor som Azure erbjuder dig och som du kan komma åt via Azure Portal, CLI, PowerShell eller REST API (och några endast via Azure Monitor/Insight API):

• Aktivitetsloggar - den här loggen svarar på de klassiska frågorna "vem", "vad" och "när" angående alla skrivoperationer (PUT, POST, DELETE) på molnresurser. Händelser relaterade till läsåtkomst (GET) ingår inte i den här loggen, som ett antal andra.
• Diagnostiska loggar - innehåller data om operationer med en viss resurs som ingår i ditt abonnemang.
• Azure AD-rapportering - innehåller både användaraktivitet och systemaktivitet relaterad till grupp- och användarhantering.
• Windows Event Log och Linux Syslog - innehåller händelser från virtuella maskiner som är värd i molnet.
• Mätvärden - innehåller telemetri om prestanda och hälsostatus för dina molntjänster och resurser. Mäts varje minut och lagras. inom 30 dagar.
• Nätverkssäkerhetsgruppflödesloggar - innehåller data om nätverkssäkerhetshändelser som samlats in med hjälp av Network Watcher-tjänsten och resursövervakning på nätverksnivå.
• Lagringsloggar - innehåller händelser relaterade till åtkomst till lagringsanläggningar.

För övervakning kan du använda externa SIEM:er eller den inbyggda Azure Monitor och dess tillägg. Vi kommer att prata om händelsehanteringssystem för informationssäkerhet senare, men låt oss nu se vad Azure själva erbjuder oss för dataanalys i säkerhetssammanhang. Huvudskärmen för allt säkerhetsrelaterat i Azure Monitor är Log Analytics Security and Audit Dashboard (den kostnadsfria versionen stöder en begränsad mängd händelselagring under bara en vecka). Den här instrumentpanelen är uppdelad i 5 huvudområden som visualiserar sammanfattande statistik över vad som händer i molnmiljön du använder:

• Säkerhetsdomäner - viktiga kvantitativa indikatorer relaterade till informationssäkerhet - antalet incidenter, antalet komprometterade noder, oparpade noder, nätverkssäkerhetshändelser, etc.
• Notable Issues - visar antalet och vikten av aktiva informationssäkerhetsfrågor
• Detektioner - visar mönster av attacker som används mot dig
• Threat Intelligence - visar geografisk information om externa noder som attackerar dig
• Vanliga säkerhetsfrågor - typiska frågor som hjälper dig att bättre övervaka din informationssäkerhet.

Azure Monitor-tillägg inkluderar Azure Key Vault (skydd av kryptografiska nycklar i molnet), Malware Assessment (analys av skydd mot skadlig kod på virtuella maskiner), Azure Application Gateway Analytics (analys av bland annat molnbrandväggsloggar) etc. . Dessa verktyg, berikade med vissa regler för bearbetning av händelser, låter dig visualisera olika aspekter av molntjänsters aktivitet, inklusive säkerhet, och identifiera vissa avvikelser från driften. Men, som ofta händer, kräver ytterligare funktionalitet ett motsvarande betalabonnemang, vilket kommer att kräva motsvarande finansiella investeringar från dig, som du måste planera i förväg.

Azure har ett antal inbyggda hotövervakningsfunktioner som är integrerade i Azure AD, Azure Monitor och Azure Security Center. Bland dem, till exempel, upptäckt av interaktion av virtuella maskiner med kända skadliga IP-adresser (på grund av närvaron av integration med Threat Intelligence-tjänster från Microsoft), upptäckt av skadlig programvara i molninfrastrukturen genom att ta emot larm från virtuella maskiner som är värd i molnet, lösenord gissa attacker ” på virtuella maskiner, sårbarheter i konfigurationen av användaridentifieringssystemet, inloggning i systemet från anonymiserare eller infekterade noder, kontoläckor, inloggning i systemet från ovanliga platser etc. Azure är idag en av få molnleverantörer som erbjuder dig inbyggda Threat Intelligence-funktioner för att berika insamlade informationssäkerhetshändelser.

Som nämnts ovan är säkerhetsfunktionaliteten och, som ett resultat, säkerhetshändelserna som genereras av den, inte tillgängliga för alla användare lika, utan kräver ett visst abonnemang som inkluderar den funktionalitet du behöver, vilket genererar lämpliga händelser för informationssäkerhetsövervakning. Till exempel är några av funktionerna som beskrivs i föregående stycke för att övervaka avvikelser i konton endast tillgängliga i P2-premiumlicensen för Azure AD-tjänsten. Utan det måste du, som i fallet med AWS, analysera de insamlade säkerhetshändelserna "manuellt". Och, beroende på typen av Azure AD-licens, kommer inte alla händelser att vara tillgängliga för analys.

På Azure-portalen kan du hantera både sökfrågor för loggar av intresse för dig och ställa in instrumentpaneler för att visualisera viktiga informationssäkerhetsindikatorer. Dessutom kan du där välja Azure Monitor-tillägg, som låter dig utöka funktionaliteten i Azure Monitor-loggar och få en djupare analys av händelser ur säkerhetssynpunkt.

Om du inte bara behöver möjligheten att arbeta med loggar, utan också ett omfattande säkerhetscenter för din Azure-molnplattform, inklusive hantering av informationssäkerhetspolicy, kan du prata om behovet av att arbeta med Azure Security Center, vars de flesta användbara funktioner är tillgängliga för lite pengar, till exempel hotdetektion, övervakning utanför Azure, efterlevnadsbedömning, etc. (i gratisversionen har du bara tillgång till en säkerhetsbedömning och rekommendationer för att eliminera identifierade problem). Den samlar alla säkerhetsfrågor på ett ställe. Faktum är att vi kan prata om en högre nivå av informationssäkerhet än vad Azure Monitor ger dig, eftersom i det här fallet data som samlas in i din molnfabrik berikas med hjälp av många källor, såsom Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) och Microsoft Security Response Center (MSRC), på vilka olika sofistikerade algoritmer för maskininlärning och beteendeanalys är överlagrade, vilket i slutändan bör förbättra effektiviteten för att upptäcka och reagera på hot .

Azure har också sin egen SIEM - den dök upp i början av 2019. Det här är Azure Sentinel, som förlitar sig på data från Azure Monitor och även kan integreras med. externa säkerhetslösningar (till exempel NGFW eller WAF), vars lista växer hela tiden. Dessutom, genom integrationen av Microsoft Graph Security API, har du möjlighet att koppla dina egna Threat Intelligence-flöden till Sentinel, vilket berikar kapaciteten för att analysera incidenter i ditt Azure-moln. Det kan hävdas att Azure Sentinel är den första "native" SIEM som dök upp från molnleverantörer (samma Splunk eller ELK, som kan vara värd i molnet, till exempel AWS, utvecklas fortfarande inte av traditionella molntjänstleverantörer). Azure Sentinel och Security Center kan kallas SOC för Azure-molnet och kan begränsas till dem (med vissa reservationer) om du inte längre hade någon infrastruktur och du överförde alla dina datorresurser till molnet och det skulle vara Microsofts moln Azure.

Men eftersom de inbyggda funktionerna i Azure (även om du har en prenumeration på Sentinel) ofta inte räcker till för att övervaka informationssäkerhet och integrera denna process med andra källor för säkerhetshändelser (både moln och interna), finns det en behöver exportera insamlade data till externa system, som kan inkludera SIEM. Detta görs både med hjälp av API:et och med hjälp av speciella tillägg, som för närvarande endast är officiellt tillgängliga för följande SIEM:er - Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight och ELK. Tills nyligen fanns det fler sådana SIEM:er, men från den 1 juni 2019 slutade Microsoft att stödja Azure Log Integration Tool (AzLog), som i början av existensen av Azure och i avsaknad av normal standardisering av arbete med loggar (Azure) Monitor existerade inte ens ännu) gjorde det enkelt att integrera extern SIEM med Microsofts moln. Nu har situationen förändrats och Microsoft rekommenderar Azure Event Hub-plattformen som det huvudsakliga integrationsverktyget för andra SIEM. Många har redan implementerat sådan integration, men var försiktig - de kanske inte fångar alla Azure-loggar, utan bara några (titta i dokumentationen för din SIEM).

Avslutningsvis en kort utflykt till Azure vill jag ge en allmän rekommendation om denna molntjänst - innan du säger något om funktionerna för informationssäkerhetsövervakning i Azure bör du konfigurera dem mycket noggrant och testa att de fungerar som det står i dokumentationen och som konsulterna sa till dig Microsoft (och de kan ha olika syn på funktionaliteten hos Azure-funktioner). Om du har ekonomiska resurser kan du klämma ut mycket användbar information från Azure när det gäller informationssäkerhetsövervakning. Om dina resurser är begränsade måste du, som i fallet med AWS, bara lita på din egen styrka och den råa data som Azure Monitor ger dig. Och kom ihåg att många övervakningsfunktioner kostar pengar och det är bättre att bekanta dig med prispolicyn i förväg. Till exempel kan du gratis lagra 31 dagars data upp till maximalt 5 GB per kund - om du överskrider dessa värden måste du lägga ut ytterligare pengar (cirka $2+ för att lagra varje ytterligare GB från kunden och $0,1 för lagra 1 GB varje ytterligare månad). Att arbeta med applikationstelemetri och mätvärden kan också kräva ytterligare medel, samt att arbeta med varningar och aviseringar (en viss gräns är tillgänglig gratis, vilket kanske inte räcker för dina behov).

Exempel: Informationssäkerhetsövervakning i IaaS baserad på Google Cloud Platform

Google Cloud Platform ser ut som en yngling jämfört med AWS och Azure, men det här är delvis bra. Till skillnad från AWS, som ökade sina möjligheter, inklusive säkerhetsfunktioner, gradvis, med problem med centralisering; GCP, liksom Azure, hanteras mycket bättre centralt, vilket minskar fel och implementeringstid över hela företaget. Ur säkerhetssynpunkt ligger GCP konstigt nog mellan AWS och Azure. Han har också en enda evenemangsregistrering för hela organisationen, men den är ofullständig. Vissa funktioner är fortfarande i betaläge, men gradvis bör denna brist elimineras och GCP kommer att bli en mer mogen plattform vad gäller informationssäkerhetsövervakning.

Huvudverktyget för att logga händelser i GCP är Stackdriver Logging (liknande Azure Monitor), som låter dig samla in händelser över hela din molninfrastruktur (liksom från AWS). Ur ett säkerhetsperspektiv i GCP har varje organisation, projekt eller mapp fyra loggar:

• Adminaktivitet - innehåller alla händelser relaterade till administrativ åtkomst, till exempel att skapa en virtuell maskin, ändra åtkomsträttigheter, etc. Denna logg skrivs alltid, oavsett din önskan, och lagrar dess data i 400 dagar.
• Dataåtkomst - innehåller alla händelser relaterade till molnanvändares arbete med data (skapande, modifiering, läsning, etc.). Som standard skrivs inte denna logg, eftersom dess volym sväller mycket snabbt. Av denna anledning är dess hållbarhet endast 30 dagar. Dessutom står inte allt i denna tidning. Till exempel skrivs inte händelser relaterade till resurser som är offentligt tillgängliga för alla användare eller som är tillgängliga utan att logga in på GCP till den.
• Systemhändelse - innehåller systemhändelser som inte är relaterade till användare, eller åtgärder från en administratör som ändrar konfigurationen av molnresurser. Den skrivs alltid och lagras i 400 dagar.
• Access Transparency är ett unikt exempel på en logg som fångar alla handlingar från Googles anställda (men ännu inte för alla GCP-tjänster) som har tillgång till din infrastruktur som en del av sina arbetsuppgifter. Den här loggen lagras i 400 dagar och är inte tillgänglig för alla GCP-klienter, utan endast om ett antal villkor är uppfyllda (antingen stöd på guld- eller platinanivå, eller förekomsten av fyra roller av en viss typ som en del av företagssupport). En liknande funktion finns även tillgänglig till exempel i Office 4 - Lockbox.

Loggexempel: 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"
}

Åtkomst till dessa loggar är möjlig på flera sätt (på ungefär samma sätt som tidigare diskuterats i Azure och AWS) - genom Log Viewer-gränssnittet, via API:t, genom Google Cloud SDK eller via aktivitetssidan för ditt projekt som du är intresserade av evenemang. På samma sätt kan de exporteras till externa lösningar för ytterligare analys. Det senare görs genom att exportera loggar till BigQuery eller Cloud Pub/Sub-lagring.

Förutom Stackdriver Logging erbjuder GCP-plattformen även Stackdriver Monitoring-funktionalitet, som låter dig övervaka nyckelmått (prestanda, MTBF, övergripande hälsa, etc.) för molntjänster och applikationer. Bearbetad och visualiserad data kan göra det lättare att hitta problem i din molninfrastruktur, även i säkerhetssammanhang. Men det bör noteras att denna funktionalitet inte kommer att vara särskilt rik i informationssäkerhetssammanhang, eftersom GCP idag inte har en analog till samma AWS GuardDuty och inte kan identifiera dåliga bland alla registrerade händelser (Google har utvecklat Event Threat Detection, men det är fortfarande under utveckling i beta och det är för tidigt att prata om dess användbarhet). Stackdriver Monitoring skulle kunna användas som ett system för att upptäcka anomalier, som sedan skulle undersökas för att hitta orsakerna till att de inträffade. Men med tanke på bristen på personal som är kvalificerad inom området GCP-informationssäkerhet på marknaden ser denna uppgift för närvarande svår ut.

Det är också värt att ge en lista över några informationssäkerhetsmoduler som kan användas inom ditt GCP-moln, och som liknar vad AWS erbjuder:

• Cloud Security Command Center är en analog till AWS Security Hub och Azure Security Center.
• Cloud DLP - Automatisk upptäckt och redigering (t.ex. maskering) av data som finns i molnet med mer än 90 fördefinierade klassificeringspolicyer.
• Cloud Scanner är en skanner för kända sårbarheter (XSS, Flash Injection, unpatchade bibliotek, etc.) i App Engine, Compute Engine och Google Kubernetes.
• Cloud IAM - Styr åtkomst till alla GCP-resurser.
• Cloud Identity - Hantera GCP-användar-, enhets- och applikationskonton från en enda konsol.
• Cloud HSM - skydd av kryptografiska nycklar.
• Cloud Key Management Service - hantering av kryptografiska nycklar i GCP.
• VPC Service Control - Skapa en säker perimeter runt dina GCP-resurser för att skydda dem från läckor.
• Titan Security Key - skydd mot nätfiske.

Många av dessa moduler genererar säkerhetshändelser som kan skickas till BigQuery-lagring för analys eller export till andra system, inklusive SIEM. Som nämnts ovan är GCP en aktivt utvecklande plattform och Google utvecklar nu ett antal nya informationssäkerhetsmoduler för sin plattform. Bland dem finns Event Threat Detection (nu tillgänglig i betaversion), som skannar Stackdriver-loggar i jakt på spår av obehörig aktivitet (analogt med GuardDuty i AWS), eller Policy Intelligence (tillgänglig i alfa), som gör att du kan utveckla intelligenta policyer för tillgång till GCP-resurser.

Jag gjorde en kort översikt över de inbyggda övervakningsmöjligheterna i populära molnplattformar. Men har du specialister som kan arbeta med "råa" IaaS-leverantörsloggar (alla är inte redo att köpa de avancerade funktionerna i AWS eller Azure eller Google)? Dessutom är många bekanta med ordspråket "lita på, men verifiera", som är sannare än någonsin inom säkerhetsområdet. Hur mycket litar du på de inbyggda funktionerna hos molnleverantören som skickar informationssäkerhetshändelser till dig? Hur mycket fokuserar de på informationssäkerhet överhuvudtaget?

Ibland är det värt att titta på överlagringslösningar för övervakning av molninfrastruktur som kan komplettera den inbyggda molnsäkerheten, och ibland är sådana lösningar det enda alternativet för att få inblick i säkerheten för dina data och applikationer som är värdda i molnet. Dessutom är de helt enkelt mer bekväma, eftersom de tar på sig alla uppgifter med att analysera nödvändiga loggar som genereras av olika molntjänster från olika molnleverantörer. Ett exempel på en sådan överlagringslösning är Cisco Stealthwatch Cloud, som är fokuserad på en enda uppgift – att övervaka informationssäkerhetsavvikelser i molnmiljöer, inklusive inte bara Amazon AWS, Microsoft Azure och Google Cloud Platform, utan även privata moln.

Exempel: Övervakning av informationssäkerhet med Stealthwatch Cloud

AWS tillhandahåller en flexibel datorplattform, men denna flexibilitet gör det lättare för företag att göra misstag som leder till säkerhetsproblem. Och den delade informationssäkerhetsmodellen bidrar bara till detta. Köra programvara i molnet med okända sårbarheter (kända kan bekämpas till exempel av AWS Inspector eller GCP Cloud Scanner), svaga lösenord, felaktiga konfigurationer, insiders, etc. Och allt detta återspeglas i beteendet hos molnresurser, som kan övervakas av Cisco Stealthwatch Cloud, som är ett informationssäkerhetsövervaknings- och attackdetekteringssystem. offentliga och privata moln.

En av nyckelfunktionerna i Cisco Stealthwatch Cloud är förmågan att modellera enheter. Med den kan du skapa en mjukvarumodell (det vill säga en simulering i nästan realtid) av var och en av dina molnresurser (det spelar ingen roll om det är AWS, Azure, GCP eller något annat). Dessa kan inkludera servrar och användare, såväl som resurstyper som är specifika för din molnmiljö, såsom säkerhetsgrupper och automatiska skalningsgrupper. Dessa modeller använder strukturerade dataströmmar som tillhandahålls av molntjänster som input. Till exempel, för AWS skulle dessa vara VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda och AWS IAM. Entitetsmodellering upptäcker automatiskt rollen och beteendet för någon av dina resurser (du kan prata om att profilera all molnaktivitet). Dessa roller inkluderar Android- eller Apple-mobilenheter, Citrix PVS-server, RDP-server, e-postgateway, VoIP-klient, terminalserver, domänkontrollant, etc. Den övervakar sedan kontinuerligt deras beteende för att avgöra när riskabelt eller säkerhetshotande beteende inträffar. Du kan identifiera lösenordsgissning, DDoS-attacker, dataläckor, olaglig fjärråtkomst, skadlig kodaktivitet, sårbarhetsskanning och andra hot. Så här ser det till exempel ut att upptäcka ett fjärråtkomstförsök från ett land som är atypiskt för din organisation (Sydkorea) till ett Kubernetes-kluster via SSH:

Och så här ser den påstådda läckan av information från Postgress-databasen till ett land som vi inte tidigare har stött på interaktion med:

Slutligen är det så här för många misslyckade SSH-försök från Kina och Indonesien från en extern fjärrenhet ser ut:

Eller anta att serverinstansen i VPC:n, enligt policy, aldrig ska vara en fjärrinloggningsdestination. Låt oss vidare anta att den här datorn upplevde en fjärrinloggning på grund av en felaktig ändring i brandväggens reglerpolicy. Funktionen Entity Modeling kommer att upptäcka och rapportera denna aktivitet ("Ovanlig fjärråtkomst") i nästan realtid och peka på det specifika AWS CloudTrail-, Azure Monitor- eller GCP Stackdriver Logging API-anropet (inklusive användarnamn, datum och tid, bland andra detaljer vilket föranledde ändringen av ITU-regeln. Och sedan kan denna information skickas till SIEM för analys.

Liknande funktioner är implementerade för alla molnmiljöer som stöds av Cisco Stealthwatch Cloud:

Entitetsmodellering är en unik form av säkerhetsautomatisering som kan avslöja ett tidigare okänt problem med dina människor, processer eller teknik. Till exempel låter den dig upptäcka bland annat säkerhetsproblem som:

• Har någon upptäckt en bakdörr i programvaran vi använder?
• Finns det någon programvara eller enhet från tredje part i vårt moln?
• Missbrukar den auktoriserade användaren sina rättigheter?
• Fanns det ett konfigurationsfel som möjliggjorde fjärråtkomst eller annan oavsiktlig användning av resurser?
• Finns det ett dataläckage från våra servrar?
• Försökte någon få kontakt med oss ​​från en atypisk geografisk plats?
• Är vårt moln infekterat med skadlig kod?

En upptäckt informationssäkerhetshändelse kan skickas i form av en motsvarande biljett till Slack, Cisco Spark, incidenthanteringssystemet PagerDuty och även skickas till olika SIEM, inklusive Splunk eller ELK. För att sammanfatta, kan vi säga att om ditt företag använder en strategi för flera moln och inte är begränsat till en enda molnleverantör, är informationssäkerhetsövervakningsfunktionerna som beskrivs ovan, då användningen av Cisco Stealthwatch Cloud ett bra alternativ för att få en enhetlig uppsättning övervakning funktioner för de ledande molnaktörerna - Amazon, Microsoft och Google. Det mest intressanta är att om man jämför priserna för Stealthwatch Cloud med avancerade licenser för informationssäkerhetsövervakning i AWS, Azure eller GCP kan det visa sig att Cisco-lösningen blir ännu billigare än Amazons, Microsofts inbyggda möjligheter. och Googles lösningar. Det är paradoxalt, men det är sant. Och ju fler moln och deras kapacitet du använder, desto mer uppenbar blir fördelen med en konsoliderad lösning.

Dessutom kan Stealthwatch Cloud övervaka privata moln som är utplacerade i din organisation, till exempel baserat på Kubernetes-containrar eller genom att övervaka Netflow-flöden eller nätverkstrafik som tas emot genom spegling i nätverksutrustning (även inhemskt producerad), AD-data eller DNS-servrar och så vidare. All denna data kommer att berikas med Threat Intelligence-information som samlats in av Cisco Talos, världens största icke-statliga grupp av forskare om cybersäkerhetshot.

Detta gör att du kan implementera ett enhetligt övervakningssystem för både publika och hybridmoln som ditt företag kan använda. Den insamlade informationen kan sedan analyseras med Stealthwatch Clouds inbyggda möjligheter eller skickas till din SIEM (Splunk, ELK, SumoLogic och flera andra stöds som standard).

Med detta kommer vi att slutföra den första delen av artikeln, där jag granskade de inbyggda och externa verktygen för att övervaka informationssäkerheten för IaaS/PaaS-plattformar, som gör att vi snabbt kan upptäcka och svara på incidenter som inträffar i molnmiljöer som vårt företag har valt. I den andra delen kommer vi att fortsätta ämnet och titta på alternativ för att övervaka SaaS-plattformar med exemplet Salesforce och Dropbox, och vi kommer också att försöka sammanfatta och sätta ihop allt genom att skapa ett enhetligt övervakningssystem för informationssäkerhet för olika molnleverantörer.

Källa: will.com