🥇Cloud sikkerhedsovervågning

Overførsel af data og applikationer til cloud-løsninger udgør en ny udfordring for virksomheders SOC'er, som ikke altid er klar til at overvåge andres infrastruktur. Ifølge Netoskope anvender et gennemsnitligt firma (åbenbart stadig i USA) 1246 forskellige cloud-tjenester, hvilket er 22% mere end sidste år. 1246 cloud-tjenester!!! 175 af dem vedrører HR-tjenester, 170 er relateret til marketing, 110 — inden for kommunikation, og 76 i finans og CRM. Cisco bruger "kun" 700 eksterne cloud-tjenester. Derfor undrer disse tal mig lidt. Men i hver fald er problemet ikke i dem, men i at cloud-løsninger aktivt begynder at blive anvendt af et stigende antal virksomheder, der ønsker at have samme overvågningsmuligheder for cloud-infrastruktur som i deres eget netværk. Og denne tendens vokser — ifølge den amerikanske revisor for 2023 planlægges det at lukke 1200 datacentre i USA (6250 er allerede lukket). Men overgangen til cloud er ikke blot "lad os flytte vores servere til en ekstern udbyder." Ny IT-arkitektur, ny software, nye processer, nye begrænsninger... Alt dette ændrer væsentligt driften, ikke kun af IT, men også af informationssikkerhed. Og hvis udbyderne har lært at håndtere sikkerheden af selve cloud'en (der er heldigvis mange anbefalinger), så er der betydelige udfordringer med overvågning af informationssikkerhed i cloud, især på SaaS-platforme, som vi vil tale om.

Lad os antage, at dit firma har flyttet noget af sin infrastruktur til skyen... Stop. Ikke sådan. Hvis infrastrukturen er flyttet, og du først nu overvejer, hvordan du vil overvåge den, så har du allerede tabt. Hvis det ikke er Amazon, Google eller Microsoft (og det kommer med forbehold), vil du sandsynligvis ikke have mange muligheder for at overvåge dine data og applikationer. Det er godt, hvis du får mulighed for at arbejde med logs. Nogle gange vil sikkerhedshændelsesdata være tilgængelige, men du vil ikke have adgang til dem. For eksempel Office 365. Hvis du har den billigste E1-licens, er sikkerhedshændelser slet ikke tilgængelige for dig. Med en E3-licens opbevares data kun i 90 dage, og kun med E5-licens er loggens varighed tilgængelig i et år (men her er der også egne nuancer, der relaterer til nødvendigheden af at anmode Microsoft-support om en række funktioner til logarbejde). For resten er E3-licensen meget svagere med hensyn til overvågningsfunktioner end den virksomhedsmæssige Exchange. For at opnå samme niveau skal du have en E5-licens eller en ekstra licens for Advanced Compliance, som kan kræve ekstra penge, der ikke blev taget højde for i din finansielle model for overgangen til skyinfrastruktur. Og dette er kun ét eksempel på undervurdering af spørgsmål relateret til overvågning af cloud-IB. I denne artikel, uden at påberåbe mig fuldstændigheden af emnet, ønsker jeg at påpege nogle nuancer, der er værd at overveje, når man vælger en cloududbyder med hensyn til sikkerhed. Og i slutningen af artiklen vil der blive givet en tjekliste, som er værd at gennemføre, før du kan betragte spørgsmålet om overvågning af cloud-IB som løst.

Der kan fremhæves flere typiske problemer, der fører til hændelser i cloudmiljøer, som cyber-sikkerhedstjenester ikke når at reagere på eller slet ikke ser:

Sikkerhedslogs eksisterer ikke. Dette er en temmelig almindelig situation, især blandt begyndere på markedet for cloudløsninger. Men man skal ikke straks opgive dem. Små aktører, især nationale, er mere følsomme over for kundernes krav og kan hurtigt implementere nogle efterspurgte funktioner ved at ændre deres godkendte produktroadmap. Ja, det vil ikke være en direkte ækvivalent til GuardDuty fra Amazon eller modulet "Proaktiv Beskyttelse" fra Bitrix, men det er i det mindste noget.
IB ved ikke, hvor logfilerne opbevares, eller der er ikke adgang til dem. Her er det nødvendigt at indgå forhandlinger med cloududbyderen — måske vil han give sådanne oplysninger, hvis han anser kunden for vigtig. Men generelt er det ikke godt, når adgangen til logfiler kun gives "ved særlige beslutninger".
Der kan også være tilfælde, hvor cloududbyderen har logfiler, men de tilbyder begrænset overvågning og registrering af hændelser, som er utilstrækkelige til at opdage alle hændelser. For eksempel kan du kun få udleveret logfiler for ændringer på hjemmesiden eller logfiler for brugerautentificeringsforsøg, mens andre hændelser, såsom om netværkstrafik, ikke gives, hvilket skjuler et helt lag af hændelser, der karakteriserer forsøg på at bryde ind i din cloudinfrastruktur.
Logfilerne findes, men det er svært at automatisere adgangen til dem, hvilket får dem til at blive overvåget ikke kontinuerligt, men efter en bestemt tidsplan. Og hvis logfilerne ikke kan downloades automatisk, kan eksport af logfiler, for eksempel i Excel-format (som hos flere indenlandske cloudløsningudbydere), føre til en modvilje mod at arbejde med dem fra den corporate IT-sikkerhedstjeneste.
Der er ingen overvågning af logfiler. Dette er måske den mest uklare årsag til opståen af sikkerhedshændelser i cloudmiljøer. Det virker som om, at logfilerne findes, og adgangen til dem kan automatiseres, men ingen gør det. Hvorfor?

Konceptet om delt cloud-sikkerhed

Overgangen til skyen handler altid om at finde balancen mellem ønsket om at bevare kontrollen over infrastrukturen og at overdrage den til mere professionelle hænder hos en cloud-udbyder, der specialiserer sig i dens drift. Og i forhold til sikkerheden i sky-miljøer er det også nødvendigt at søge denne balance. Især fordi denne balance vil være forskellig afhængigt af den anvendte model for cloud-tjenester (IaaS, PaaS, SaaS). Under alle omstændigheder skal man huske, at alle cloud-udbydere i dag følger den såkaldte model for delt ansvar og delt informationssikkerhed. Cloud’en er ansvarlig for noget, mens kunden, der har placeret sine data, applikationer, virtuelle maskiner og andre ressourcer i skyen, er ansvarlig for noget andet. Det ville være uovervejet at tro, at ved at gå til skyen, kan vi overlade alt ansvar til udbyderen. Men det er heller ikke fornuftigt at opbygge al sikkerhed selv ved overgangen til skyen. Der er behov for en balance, der vil afhænge af mange faktorer: risikostyringsstrategier, trusselsmodeller, de sikkerhedsmekanismer, som cloud-udbyderen har, lovgivning osv.

For eksempel er klassifikationen af data, der er placeret i skyen, altid kundens ansvar. Cloud-udbyderen eller en ekstern serviceudbyder kan kun hjælpe med værktøjer, der hjælper med at mærke data i skyen, identificere overtrædelser, fjerne data, der overtræder lovgivningen, eller maskere dem med forskellige metoder. På den anden side er fysisk sikkerhed altid cloud-udbyderens ansvar, som de ikke kan dele med kunderne. Alt det, der ligger mellem data og den fysiske infrastruktur, er netop emnet for denne artikel. For eksempel er tilgængeligheden af skyen et ansvar for udbyderen, mens indstillingerne af sikkerhedsreglerne eller aktiveringen af kryptering allerede er kundens ansvar. I denne artikel vil vi se nærmere på, hvilke mekanismer til overvågning af informationssikkerhed, forskellige populære cloud-udbydere i Rusland i dag tilbyder, hvilke særlige kendetegn de har, og hvornår det kan være værd at overveje eksterne løsninger (for eksempel Cisco E-mail Security), der udvider mulighederne for din sky inden for cybersikkerhed. I nogle tilfælde, især ved anvendelse af en multi-cloud-strategi, vil du ikke have noget valg end at bruge eksterne løsninger til overvågning af informationssikkerhed i flere cloud-miljøer (for eksempel Cisco CloudLock eller Cisco Stealthwatch Cloud). I andre tilfælde vil du opdage, at den valgte (eller påtvungne) cloud-udbyder slet ikke tilbyder nogen muligheder for overvågning af informationssikkerhed. Dette er ubehageligt, men det er også vigtigt, da det giver dig mulighed for at vurdere risikoniveauet, der er forbundet med at arbejde med denne sky.

Livscyklussen for overvågning af sikkerheden i skyen

For at overvåge sikkerheden af de skyer, du bruger, har du kun tre muligheder:

at stole på de værktøjer, der tilbydes af din cloud-udbyder,
at bruge løsninger fra tredjepartsleverandører, der vil overvåge de IaaS-, PaaS- eller SaaS-platforme, du bruger,
at opbygge din egen overvågningsinfrastruktur for cloud-miljøer (kun for IaaS/PaaS-platforme).

Lad os se på, hvilke funktioner hver af disse muligheder har. Men først skal vi forstå det overordnede skema, der vil blive brugt til overvågning af cloud-platforme. Jeg vil fremhæve 6 hovedkomponenter i overvågningsprocessen for informationsbeskyttelse i skyen:

Forberedelse af infrastrukturen. Fastlæggelse af de nødvendige applikationer og infrastruktur til at indsamle begivenheder, der er vigtige for informationsbeskyttelse, i lageret.
Indsamling. På dette stadium aggregeres sikkerhedsbegivenheder fra forskellige kilder til deres efterfølgende overførsel til behandling, opbevaring og analyse.
Behandling. På dette stadium transformeres og beriges dataene for at lette deres efterfølgende analyse.
Opbevaring. Denne komponent er ansvarlig for kort- og langvarig opbevaring af de indsamlede, behandlede og 'rå' data.
Analyse. På dette stadium har du mulighed for at opdage hændelser og reagere på dem automatisk eller manuelt.
Rapportering. Dette trin hjælper med at danne centrale nøgletal for interessenter (ledelse, revisorer, cloud-udbyder, kunder osv.), der hjælper os med at træffe bestemte beslutninger, f.eks. skifte udbyder eller styrke informationsbeskyttelse.

Forståelsen af disse komponenter vil gøre det muligt for dig hurtigt at afgøre, hvad du kan få fra din udbyder, og hvad du selv eller med hjælp fra eksterne konsulenter skal tage hånd om.

Indbyggede muligheder i cloud-tjenester

Jeg har allerede nævnt, at mange cloud-tjenester i dag slet ikke tilbyder nogen muligheder for overvågning af it-sikkerhed. Generelt set giver de ikke meget opmærksomhed til it-sikkerhed. For eksempel er et af de populære russiske tjenester til indsendelse af rapporter til statslige myndigheder via internettet (jeg vil specielt undlade at nævne navnet). Hele afsnittet om sikkerhed i denne tjeneste fokuserer på anvendelsen af certificerede krypteringsnøgler. Afsnittet om it-sikkerhed i en anden indenlandsk cloud-tjeneste til elektronisk dokumenthåndtering er meget mere omfattende. Det nævner certifikater for offentlige nøgler, certificeret kryptering, eliminering af web-sårbarheder, beskyttelse mod DDoS-angreb, anvendelse af sikkerhedspolitikker, backup og endda regelmæssig udførelse af it-sikkerhedsaudit. Men der nævnes ikke et ord om overvågning eller mulighed for at få adgang til it-sikkerhedshændelser, som kunne være interessante for kunderne til denne tjenesteudbyder.

Generelt set kan man ud fra, hvordan cloud-udbyderen beskriver it-sikkerhed på sin hjemmeside og i dokumentationen, forstå, hvor seriøst de overhovedet tager dette emne. For eksempel, hvis man læser vejledningerne til produkter som "Mit kontor", er der slet ikke et ord om sikkerhed, mens dokumentationen til det specifikke produkt "Mit kontor. KS3", der er beregnet til at beskytte mod uautoriseret adgang, blot indeholder en liste over punkter fra det 17. bekendtgørelse fra FSTEC, som "Mit kontor. KS3" overholder, men der er ingen beskrivelse af, hvordan det overholdes, og vigtigst af alt, hvordan disse mekanismer integreres med virksomhedens it-sikkerhed. Måske findes der sådan dokumentation, men i offentligheden, på "Mit kontor"-hjemmesiden fandt jeg ikke noget. Selvom jeg måske bare ikke har adgang til denne hemmelige information...?

Hos den samme Bitrix er situationen langt bedre. I dokumentationen beskrives formaterne for hændelseslogger og, interessant nok, indtrængningsloggen, som indeholder hændelser relateret til potentielle trusler mod cloudplatformen. Derfra kan du trække IP, brugernavn eller gæst, hændelseskilde, tid, User Agent, hændelsetype osv. Sandheden er, at du kan arbejde med disse hændelser enten fra kontrolpanelet i selve cloudtjenesten eller eksportere data i MS Excel-format. Det er dog nuværende vanskeligt at automatisere arbejdet med Bitrix-logs, og du må udføre en del af arbejdet manuelt (eksportere rapporten og uploade den til dit SIEM). Men hvis vi husker, at der for relativt kort tid siden ikke engang var en sådan mulighed, så er det en stor fremskridt. Jeg vil også bemærke, at mange udenlandske cloududbydere tilbyder lignende funktionalitet 'for begyndere' – enten skal du se loggerne med øjnene gennem kontrolpanelet, eller også eksportere data til dig (dog eksporterer de fleste data i .csv-format, ikke Excel).

Når man ser bort fra muligheden for, at logs ikke er tilgængelige, tilbyder cloud-udbydere normalt tre metoder til overvågning af sikkerhedshændelser - dashboards, dataeksport og API-adgang. Selvom den første løsning tilsyneladende løser mange problemer for dig, er det ikke helt sandt; når der er flere logs, skal man skifte mellem skærme, der viser dem, hvilket medfører tab af det overordnede billede. Derudover vil cloud-udbyderen næppe give dig mulighed for at korrelere sikkerhedshændelser og analysere dem med sikkerhedsperspektiv (normalt arbejder du med rå data, som du selv skal bearbejde). Der er undtagelser, og dem vil vi diskutere senere. Endelig er det værd at spørge, hvilke hændelser din cloud-udbyder registrerer, i hvilket format, og hvorvidt de passer ind i din informationssikkerhedsovervågningsproces? For eksempel identifikation og autentifikation af brugere og gæster. Den samme Bitrix giver dig mulighed for at registrere dato og klokkeslæt for en sådan hændelse, brugernavnet eller gæstens navn (hvis modulen 'Web-analyse' er aktiveret), objektet, som der er opnået adgang til, og andre typiske webstedselementer. Men virksomhedens informationssikkerhedstjenester kan have brug for oplysninger om, hvorvidt brugeren tilgåede skyen fra en betroet enhed (for eksempel håndterer Cisco ISE denne opgave i det virksomhedens netværk). Og en så simpel opgave som geolocation, der hjælper med at bestemme, om brugerens konto til cloud-tjenesten er blevet stjålet? Selv hvis cloud-udbyderen giver dig denne funktion, er det ikke tilstrækkeligt. Den samme Cisco CloudLock analyserer ikke bare geolokation, men anvender maskinlæring til at analysere historiske data for hver bruger og overvåge forskellige anomalier i identifikations- og autentifikationsforsøg. En tilsvarende funktionalitet findes kun hos MS Azure (hvis den relevante abonnementsform er tilgængelig).

Der er en anden udfordring – da overvågning af informationssikkerhed (IS) er et nyt område for mange cloududbydere, som de først lige er begyndt at arbejde med, ændrer de konstant deres løsninger. I dag er der én version af API'en, i morgen en anden, og næste dag en tredje. Du skal også være klar til det. Det samme gælder for funktionaliteten, der kan ændre sig, og som skal tages i betragtning i dit IS-overvågningssystem. For eksempel havde Amazon først separate tjenester til overvågning af begivenheder i skyen – AWS CloudTrail og AWS CloudWatch. Så dukkede en separat begivenhedsovervågningstjeneste for IS op – AWS GuardDuty. Efter noget tid lancerede Amazon et nyt administrationssystem, Amazon Security Hub, som inkluderer dataanalyse fra GuardDuty, Amazon Inspector, Amazon Macie og flere andre. Et andet eksempel er værktøjet til integration af logfiler fra Azure med SIEM – AzLog. Mange SIEM-leverandører brugte det aktivt, indtil Microsoft i 2018 meddelte, at de ville stoppe udviklingen og støtten, hvilket satte mange kunder, der brugte dette værktøj, i en problematisk situation (hvordan det blev løst, vil vi diskutere senere).

Derfor skal du nøje overvåge alle overvågningsfunktioner, som din cloududbyder tilbyder. Eller du kan stole på eksterne løsningstilbydere, der fungerer som mellemled mellem dit SOC og den sky, du ønsker at overvåge. Ja, det bliver dyrere (selvom det ikke altid er tilfældet), men du overfører hele ansvaret til andre. Eller måske ikke helt? Lad os huske begrebet delt sikkerhed og forstå, at vi ikke kan overføre alt – vi bliver nødt til selv at finde ud af, hvordan forskellige cloududbydere sikrer overvågningen af IS for dine data, applikationer, virtuelle maskiner og andre ressourcer, der er placeret i skyen. Og vi starter med, hvad Amazon tilbyder på dette område.

Eksempel: Overvågning af IS i IaaS baseret på AWS

Ja, jeg forstår, at Amazon ikke er det bedste eksempel, fordi det er en amerikansk tjeneste, og der kan blokere den som led i bekæmpelsen af ekstremisme og spredning af forbudt information i Rusland. Men i denne publikation vil jeg blot vise, hvor forskellige de forskellige cloud-platforme er med hensyn til overvågningsmuligheder for informationssikkerhed, og hvad man skal være opmærksom på, når man overfører sine nøgleprocesser til skyen fra et sikkerhedsperspektiv. Og hvis nogen af de russiske udviklere af cloud-løsninger finder noget nyttigt, vil det være helt fantastisk.

Først skal det siges, at Amazon ikke er en uindtagelig fæstning. Dets kunder oplever regelmæssigt forskellige hændelser. For eksempel blev 198 millioner vælgeres navne, adresser, fødselsdatoer og telefonnumre stjålet fra Deep Root Analytics. 14 millioner optegnelser om Verizon-abonnenter blev stjålet fra det israelske firma Nice Systems. Samtidig giver de indbyggede funktioner i AWS mulighed for at opdage en bred vifte af hændelser. For eksempel:

indvirkning på infrastrukturen (DDoS)
kompromittering af en node (injektionskommandoer)
kompromittering af brugerkonti og uautoriseret adgang
forkert konfiguration og sårbarheder
usikre grænseflader og API'er.

Denne diskrepans skyldes, at sikkerheden for kundernes data, som vi har afklaret ovenfor, er kundens ansvar. Hvis de ikke har sørget for at aktivere beskyttelsesmekanismer og aktiveret overvågningsværktøjer, så vil de kun finde ud af om hændelsen gennem medierne eller fra deres kunder.

For identifying incidents, a wide range of monitoring services developed by Amazon can be utilized (although they are often supplemented by external tools like osquery). In AWS, all user actions are tracked, regardless of how they are performed — through the management console, command line, SDK, or other AWS services. All records of actions from each AWS account (including username, action, service, activity parameters, and its results) and API usage are accessible through the AWS CloudTrail service. You can view these events (for example, AWS IAM console logins) from the CloudTrail console, analyze them using Amazon Athena, or send them to external solutions like Splunk, AlienVault, etc. The AWS CloudTrail logs are stored in your AWS S3 bucket.

Two other AWS services provide additional important monitoring capabilities. First, Amazon CloudWatch is a monitoring service for AWS resources and applications that, among other things, allows for the identification of various anomalies in your cloud. All built-in AWS services, such as Amazon Elastic Compute Cloud (servers), Amazon Relational Database Service (databases), Amazon Elastic MapReduce (data analysis), and 30 other Amazon services, utilize Amazon CloudWatch to store their logs. Developers can use the open API from Amazon CloudWatch to add log monitoring functionality to custom applications and services, allowing for an expanded analysis of events in the context of information security.

Second, the VPC Flow Logs service allows for the analysis of network traffic sent to or received by your AWS servers (from outside or internally) as well as between microservices. When any of your AWS VPC resources interact with the network, the VPC Flow Logs service records information about the network traffic, including the source and destination network interfaces, as well as IP addresses, ports, protocol, byte count, and packet count observed. Those experienced in local network security will recognize this as analogous to flows. NetFlow, som kan genereres af enterprise-grade switcher, routere og firewalls. Disse logfiler er vigtige for IKT-overvågning, fordi de, i modsætning til hændelser om bruger- og applikationshandlinger, også tillader overvågning af netværksinteraktioner i det virtuelle private cloud-miljø i AWS.

Således leverer disse tre AWS-tjenester – AWS CloudTrail, Amazon CloudWatch og VPC Flow Logs – tilsammen en tilstrækkelig effektiv præsentation af brugen af din konto, brugernes adfærd, infrastrukturopbevaring, applikations- og servicaktivitet samt netværksaktivitet. For eksempel kan de hjælpe med at opdage følgende anomalier:

Forsøg på website-scanning, søgning efter backdoors, søgning efter sårbarheder gennem udsving i “404-fejl”.
Injection-angreb (f.eks. SQL injection) gennem udsving i “500-fejl”.
Kendte værktøjer til angreb som sqlmap, nikto, w3af, nmap osv. gennem analyse af User Agent-feltet.

Amazon Web Services har også udviklet andre tjenester til cybersikkerhed, som gør det muligt at løse mange andre opgaver. For eksempel er der i AWS en indbygget tjeneste til revision af politikker og konfigurationer — AWS Config. Denne tjeneste sikrer en kontinuerlig revision af dine AWS-ressourcer og deres konfigurationer. Lad os tage et simpelt eksempel: Antag, at du vil sikre, at brugernes adgangskoder er deaktiveret på alle dine servere, og at adgang kun er mulig via certifikater. AWS Config gør det nemt at kontrollere dette for alle dine servere. Der er også andre politikker, der kan anvendes på dine cloud-servere: «Ingen server må bruge port 22», «Kun administratorer kan ændre firewall-regler» eller «Kun brugeren Ivashko kan oprette nye brugerkonti, og dette kan kun gøres om tirsdagen». I sommeren 2016 blev AWS Config-tjenesten udvidet til at automatisere opdagelsen af overtrædelser af de udformede politikker. AWS Config Rules er i det væsentlige kontinuerlige konfigurationsanmodninger til de tjenester, du bruger fra Amazon, som genererer hændelser i tilfælde af overtrædelse af de relevante politikker. For eksempel, i stedet for at udføre AWS Config-anmodninger med jævne mellemrum for at kontrollere, at alle virtuelle servers diske er krypterede, kan AWS Config Rules bruges til konstant at kontrollere serverdiskene for at sikre, at denne betingelse er opfyldt. Og vigtigst af alt, i konteksten af denne publikation, genererer enhver overtrædelse hændelser, der kan analyseres af din IKT-tjeneste.

Der findes også AWS-ækvivalenter til traditionelle virksomhedsløsninger inden for IKT, som også genererer sikkerhedshændelser, som du kan og bør analysere:

indbruddetektering — AWS GuardDuty
kontrol af informationslækager — AWS Macie
EDR (selvom det er lidt mærkeligt at tale om slutpunkter i skyen) — AWS Cloudwatch + open source-løsninger som osquery eller GRR
Netflow-analyse — AWS Cloudwatch + AWS VPC Flow
DNS-analyse — AWS Cloudwatch + AWS Route53
AD — AWS Directory Service
kontoadministration — AWS IAM
SSO — AWS SSO
sikkerhedsanalyse — AWS Inspector
konfigurationsstyring — AWS Config
WAF — AWS WAF.

Jeg vil ikke gå i detaljer om alle de Amazon-tjenester, der kan være nyttige i forbindelse med informationssikkerhed. Det vigtigste at forstå er, at alle disse kan generere hændelser, som vi kan og skal analysere i relation til IS, ved at benytte både de indbyggede funktioner fra Amazon samt eksterne løsninger, såsom SIEM, der kan hente sikkerhedshændelser til dit overvågningscenter og analysere dem der sammen med hændelser fra andre cloud-tjenester eller fra intern infrastruktur, perimeter eller mobile enheder.

Uanset hvad, så begynder alt med datakilder, der giver dig IS-hændelser. Blandt disse kilder kan nævnes:

CloudTrail — brug af API og brugerhandlinger
Trusted Advisor — sikkerhedskontrol i overensstemmelse med bedste praksis
Config — opgørelse og konfiguration af konti og serviceindstillinger
VPC Flow Logs — forbindelser til virtuelle interfaces
IAM — identifikations- og autentifikationstjeneste
ELB Access Logs — belastningsbalancer
Inspector — sårbarheder i applikationer
S3 — filopbevaring
CloudWatch — applikationsaktiviteter
SNS — notificeringstjeneste.

Amazon, ved at tilbyde et sådant spektrum af hændelseskilder og værktøjer til deres generering, er dog stærkt begrænset i sine muligheder for at analysere de indsamlede data i forhold til IS. Du bliver nødt til selv at gennemgå de tilgængelige logs og lede efter relevante indikatorer for kompromittering. AWS Security Hub, som Amazon for nylig har lanceret, har til formål at løse dette problem og fungerer som en form for cloud-SIEM for AWS. Men den er stadig kun i begyndelsen og er begrænset både i antallet af kilder, den arbejder med, og i andre begrænsninger fastlagt af Amazon's arkitektur og abonnementer.

Eksempel: Overvågning af IS i IaaS baseret på Azure

Jeg ønsker ikke at gå ind i en lang debat om, hvilken af de tre cloud-udbydere (Amazon, Microsoft eller Google) der er den bedste (især da hver af dem har sine specifikke egenskaber og er egnet til forskellige opgaver); lad os koncentrere os om de muligheder for overvågning af IT-sikkerhed, som disse aktører tilbyder. Man må erkende, at Amazon AWS var en af de første inden for dette segment og derfor har gjort større fremskridt i forhold til sine IT-sikkerhedsfunktioner (selv om mange anerkender, at det kan være svært at bruge dem). Men det betyder ikke, at vi skal ignorere de muligheder, som Microsoft og Google tilbyder.

Microsofts produkter har altid været præget af en "åbenhed", og situationen i Azure er den samme. For eksempel, mens AWS og GCP altid baserer sig på konceptet "alt, der ikke er tilladt, er forbudt", er tilgangen i Azure den stik modsatte. Når man opretter et virtuelt netværk i skyen og en virtuel maskine i det, er alle porte og protokoller som standard åbne og tilladte. Derfor bliver man nødt til at lægge lidt flere kræfter i den indledende konfiguration af adgangskontrolsystemet i Microsofts cloud. Dette stiller også strengere krav til overvågning af aktiviteten i Azure.

AWS har en funktion, der gør, at når du overvåger dine virtuelle ressourcer, kan du støde på vanskeligheder med at samle alle begivenheder og analysere dem, hvis ressourcerne befinder sig i forskellige regioner. For at løse dette problem skal du ofte ty til løsninger som at oprette din egen kode til AWS Lambda, der flytter begivenheder mellem regioner. I Azure findes der ikke et sådant problem — dens aktivitetslog overvåger al aktivitet på tværs af hele organisationen uden begrænsninger. Det samme gælder for AWS Security Hub, som Amazon for nylig har udviklet til at konsolidere mange sikkerhedsfunktioner inden for et enkelt sikkerhedscenter, men kun inden for sin egen region, hvilket dog ikke er relevant for Rusland. Azure har sit eget Security Center, som ikke er underlagt regionale begrænsninger, hvilket giver adgang til alle sikkerhedsfunktioner på cloudplatformen. Desuden kan det tilvejebringe et sæt beskyttelsesmuligheder til forskellige lokale teams, herunder styrede sikkerhedsbegivenheder. AWS Security Hub stræber stadig efter at ligge på niveau med Azure Security Center. Men der skal også nævnes en skefuld bævre, idet du kan udnytte meget af det, der tidligere blev beskrevet om AWS i Azure, men det gøres mest bekvemt kun for Azure AD, Azure Monitor og Azure Security Center. Alle andre sikkerhedsmekanismer i Azure, herunder analyse af sikkerhedsbegivenheder, styres endnu ikke på den mest brugervenlige måde. Dels løses problemet af et API, der gennemsyrer alle Microsoft Azures tjenester, men det vil kræve ekstra indsats fra din side for at integrere dit cloudmiljø med dit SOC og adgang til kvalificerede specialister (ligesom med et hvilket som helst andet SIEM, der arbejder med cloud API'er). Nogle SIEM, som vil blive nævnt senere, understøtter allerede Azure og kan automatisere overvågningen af det, men der er også udfordringer med dem — ikke alle kan hente alle logs, som findes i Azure.

Hændtering og overvågning af begivenheder i Azure sker ved hjælp af tjenesten Azure Monitor, som er det primære værktøj til indsamling, opbevaring og analyse af data i Microsofts cloud og dens ressourcer — Git-depot, containere, virtuelle maskiner, applikationer osv. Alle data indsamlet af Azure Monitor opdeles i to kategorier — målinger, der indsamles i realtid og beskriver de væsentligste præstationsindikatorer for Azure cloud, og logfiler, der indeholder data organiseret i poster, som kendetegner forskellige aspekter af ressourcers og tjenesters aktiviteter. Desuden kan Azure Monitor ved hjælp af Data Collector API indsamle data fra enhver REST-kilde for at opbygge egne overvågningsscenarier.

Her er nogle kilder til sikkerhedsbegivenheder, som Azure tilbyder, og som du kan få adgang til via Azure Portal, CLI, PowerShell eller REST API (nogle kun gennem Azure Monitor / Insight API):

Aktivitetslogfiler — denne log svarer på de klassiske spørgsmål "hvem", "hvad" og "hvornår" vedrørende enhver registreringsoperation (PUT, POST, DELETE) på cloudressourcer. Begivenheder, der vedrører læseadgang (GET), kommer ikke ind i denne log, ligesom en række andre.
Diagnostiklogfiler — indeholder data om operationer med en given ressource, der er en del af dit abonnement.
Azure AD-rapportering — indeholder både brugeraktivitet og systemaktivitet relateret til administration af grupper og brugere.
Windows Event Log og Linux Syslog — indeholder begivenheder fra virtuelle maskiner, der hostes i skyen.
Målinger — indeholder telemetri om præstation og "sundhed" for dine cloudtjenester og ressourcer. Måles hvert minut og opbevares i 30 dage.
Network Security Group Flow Logs — indeholder data om netværkssikkerhedsbegivenheder, der indsamles ved hjælp af Network Watcher-tjenesten og netværksniveau overvågning af ressourcer.
Lagerlogfiler — indeholder begivenheder relateret til adgang til lagringssystemer.

Til overvågning kan du bruge eksterne SIEM eller den indbyggede Azure Monitor og dens udvidelser. Vi vil tale mere om systemer til sikkerhedshændelsesstyring senere, men lad os først se, hvad Azure selv tilbyder til dataanalyse i sikkerhedssammenhæng. Hovedskærmen for alt, der relaterer til sikkerhed i Azure Monitor, er Log Analytics Security and Audit Dashboard (den gratis version understøtter opbevaring af et begrænset antal hændelser i kun en uge). Denne panel er delt op i 5 hovedområder, der visualiserer en opsummering af den statistik, der vedrører, hvad der sker i dit cloud-miljø:

Security Domains — nøglemålinger relateret til informationssikkerhed — antal hændelser, antal kompromitterede noder, ubeskyttede noder, netværkssikkerhedshændelser mv.
Notable Issues — viser antal og alvor af aktive informationssikkerhedsproblemer
Detections — viser mønstre for angreb, der er blevet anvendt imod dig
Threat Intelligence — viser geografisk information om de eksterne noder, der angriber dig
Common security queries — typiske forespørgsler, der kan hjælpe dig med bedre at overvåge din informationssikkerhed.

Som Azure Monitor-udvidelser kan nævnes Azure Key Vault (beskyttelse af kryptografiske nøgler i skyen), Malware Assessment (analyse af beskyttelse mod malware på virtuelle maskiner), Azure Application Gateway Analytics (analyse, herunder logfiler fra cloud-firewall) mv. Disse værktøjer, beriget med specifikke hændelsesbehandlingsregler, giver mulighed for at visualisere forskellige aspekter af cloudtjenesternes aktivitet, herunder sikkerhed, og identificere afvigelser fra normal drift. Men som ofte er tilfældet kræver enhver ekstra funktionalitet en tilsvarende betalt subscription, hvilket vil kræve, at du planlægger de nødvendige økonomiske investeringer på forhånd.

Azure har en række indbyggede trusselsmonitoreringsfunktioner, som er integreret i Azure AD, Azure Monitor og Azure Security Center. Disse inkluderer blandt andet opdagelsen af interaktioner mellem virtuelle maskiner og kendte skadelige IP-adresser (takket være integrationen med Microsofts Threat Intelligence-tjenester), opdagelse af malware i cloud-infrastrukturen gennem alarmer fra cloud-hostede virtuelle maskiner, brute force-angreb mod virtuelle maskiner, sårbarheder i brugersystemkonfigurationen, login fra anonymiseringsværktøjer eller inficerede noder, lækage af konti, login fra usædvanlige placeringer osv. I dag er Azure en af de få cloud-udbydere, der tilbyder indbyggede Threat Intelligence-muligheder til at berige de indsamlede IT-sikkerhedshændelser.

Som nævnt tidligere er beskyttelsesfunktionen og de deraf følgende sikkerhedshændelser ikke tilgængelige for alle brugere på samme måde, men kræver en bestemt abonnementstype, der inkluderer de funktioner, du har brug for, som genererer de relevante hændelser til overvågning af IT-sikkerhed. For eksempel er nogle af de funktioner til overvågning af anomalier i konti, der er beskrevet i det foregående afsnit, kun tilgængelige med premium licens P2 til Azure AD-tjenesten. Uden denne vil du, ligesom med AWS, være nødt til at analysere de indsamlede sikkerhedshændelser manuelt. Derudover vil ikke alle hændelser til analyse være tilgængelige afhængigt af din type Azure AD-licens.

På Azure-portalen kan du administrere både forespørgsler til de ønskede registreringslogger samt konfigurere dashboards til visualisering af nøgleindikatorer for IT-sikkerhed. Derudover kan du også vælge Azure Monitor-udvidelser, som giver dig mulighed for at udvide funktionaliteten af Azure Monitor-logger og få en dybere analyse af hændelserne set fra et sikkerhedsmæssigt perspektiv.

Hvis du har brug for ikke bare at arbejde med logs, men også et omfattende sikkerhedscenter for din Azure-cloudplatform, herunder styring af informationssikkerhedspolitikker, er det nødvendigt at overveje at arbejde med Azure Security Center. De fleste nyttige funktioner er tilgængelige mod et ekstra gebyr, såsom trusselopdagelse, overvågning uden for Azure, overholdelsesevaluering osv. (i den gratis version er du kun i stand til at få sikkerhedsevalueringer og anbefalinger til at løse identificerede problemer). Det konsoliderer alle sikkerhedsrelaterede spørgsmål ét sted. Faktisk kan man tale om et højere niveau af informationssikkerhed end hvad Azure Monitor tilbyder, da de indsamlede data fra din cloudfabrik beriges med mange kilder, såsom Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, outlook.com, MSN.com, Microsoft Digital Crimes Unit (DCU) og Microsoft Security Response Center (MSRC), hvorefter komplekse algoritmer for maskinlæring og adfærdsanalyse anvendes, hvilket i sidste ende skal forbedre effektiviteten af trusselopdagelse og reaktion på dem.

Azure har også sin egen SIEM — den blev introduceret i begyndelsen af 2019. Dette er Azure Sentinel, som bygger på data fra Azure Monitor og også kan integreres med eksterne sikkerhedsløsninger (f.eks. NGFW eller WAF), hvis liste hele tiden bliver udvidet. Derudover giver integrationen med Microsoft Graph Security API dig mulighed for at forbinde dine egne Threat Intelligence feeds til Sentinel, hvilket beriger mulighederne for hændelsesanalyse i din Azure-cloud. Man kan påstå, at Azure Sentinel er det første 'native' SIEM, der er tilgængeligt hos cloududbydere (de samme Splunk eller ELK, som kan placeres i skyen, f.eks. AWS, er trods alt ikke udviklet af leverandører af traditionelle cloudtjenester). Azure Sentinel og Security Center kunne kaldes SOC'en for Azure-cloud og kunne være de eneste værktøjer, du behøvede (med visse forbehold), hvis du ikke havde nogen anden infrastruktur, og hvis alle dine beregningsressourcer var flyttet til skyen, og det ville være Microsoft Azure.

Men da de indbyggede funktioner i Azure (selv med et abonnement på Sentinel) ofte ikke er tilstrækkelige til overvågning af informationssikkerhed og integration af denne proces med andre kilder til sikkerhedshændelser (både cloud-baserede og interne), opstår behovet for at eksportere de indsamlede data til eksterne systemer, herunder SIEM. Dette gøres både via API og ved hjælp af særlige udvidelser, som officielt kun findes for følgende SIEM - Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight og ELK. For ikke så længe siden var der flere sådanne SIEM, men fra den 1. juni 2019 stoppede Microsoft med at understøtte Azure Log Integration Tool (AzLog), som i de tidlige dage af Azure og i mangel af en ordentlig standardisering af logbehandling (Azure Monitor eksisterede endnu ikke) gjorde det muligt at integrere eksterne SIEM med Microsoft-cloud. Nu er situationen ændret, og Microsoft anbefaler platformen Azure Event Hub som det primære integrationsværktøj for andre SIEM. Mange har allerede gennemført en sådan integration, men vær opmærksom på, at de muligvis ikke fanger alle Azure-logs, men kun nogle (tjek dokumentationen for dit SIEM).

Afslutningsvis vil jeg gerne give en generel anbefaling om denne cloud-service, Azure. Før du påstår noget om overvågningsfunktionerne for informationssikkerhed i Azure, er det vigtigt at konfigurere dem omhyggeligt og teste, at de fungerer som beskrevet i dokumentationen, og som Microsofts konsulenter har forklaret (de kan have forskellige syn på, hvordan Azure-funktionerne fungerer). Hvis der er økonomiske muligheder, kan man få meget ud af Azure i forhold til overvågning af informationssikkerhed. Hvis dine ressourcer derimod er begrænsede, må du ligesom i tilfælde af AWS stole på egne ressourcer og de rå data, som Azure Monitor giver dig. Husk, at mange overvågningsfunktioner koster penge, og det er bedst at sætte sig ind i priserne på forhånd. For eksempel kan du gratis gemme data i op til 31 dage med en maksium på 5 GB pr. kunde — overskridelse af disse værdier vil kræve ekstra betaling (ca. 2+ dollar for hver ekstra GB fra kunden og 0,1 dollar for opbevaring af 1 GB hver ekstra måned). Arbejdet med applikationstelemetri og målinger kan også kræve yderligere økonomiske midler, ligesom arbejdet med alarmer og meddelelser (der er en gratis grænse, som måske ikke er nok til dine behov).

Eksempel: Overvågning af informationssikkerhed i IaaS baseret på Google Cloud Platform

Google Cloud Platform fremstår som en relativ nykommen i forhold til AWS og Azure, men det har sine fordele. I modsætning til AWS, som gradvist har opbygget sine funktionaliteter, herunder beskyttelse, har GCP, ligesom Azure, en bedre centraliseret styring, hvilket reducerer fejl og implementeringstiden i virksomheden. Set fra et sikkerhedsmæssigt perspektiv befinder GCP sig bemærkelsesværdigt mellem AWS og Azure. Det har også en central eventlog for hele organisationen, men den er ikke fuldstændig. Nogle funktioner er stadig i beta, men gradvist vil denne mangel blive udbedret, og GCP vil blive en mere moden platform med hensyn til overvågning af informationssikkerhed.

Det primære værktøj til registrering af hændelser i GCP er Stackdriver Logging (svarende til Azure Monitor), som giver dig mulighed for at indsamle hændelser på tværs af din cloud-infrastruktur (også fra AWS). I GCP har hver organisation, projekt eller mappe fire registreringslogfiler med hensyn til sikkerhed:

Admin Activity – indeholder alle hændelser relateret til administrativ adgang, såsom oprettelse af en virtuel maskine, ændring af adgangsrettigheder osv. Denne log skrives altid, uanset dit ønske, og gemmer sine data i 400 dage.
Data Access – indeholder alle hændelser relateret til behandling af data fra cloud-brugere (oprettelse, ændring, læsning osv.). Som standard skrives denne log ikke, da dens størrelse hurtigt kan vokse. Derfor er opbevaringstiden kun 30 dage. Desuden skrives der ikke alt i denne log. For eksempel registreres hændelser relateret til ressourcer, der er offentligt tilgængelige for alle brugere, eller som er tilgængelige uden login i GCP, ikke.
System Event – indeholder systemhændelser, der ikke er relateret til brugere, eller handlinger fra en administrator, der ændrer konfigurationen af cloud-ressourcer. Den skrives altid og opbevares i 400 dage.
Access Transparency – er et unikt eksempel på en registreringslog, der dokumenterer alle handlinger fra Google-medarbejdere (men endnu ikke for alle GCP-tjenester), der får adgang til din infrastruktur som led i deres arbejdsopgaver. Denne log opbevares i 400 dage og er ikke tilgængelig for alle GCP-kunder, men kun under visse betingelser (enten Gold- eller Platinum-support eller tilstedeværelsen af 4 roller af en bestemt type inden for virksomhedssupport). En lignende funktion findes også for eksempel i Office 365 – Lockbox.

Eksempel på log: 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: "Sagsnummer: bar123"
 type: "KUNDEN_INITIEREDE_SUPPORT"
 ]
 accesses: [
 0: {
 methodName: "GoogleInternal.Read"
 resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
 }
 ]
 }
 logName: "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.comaccess_transparency"
 operation: {
 id: "12345xyz"
 }
 receiveTimestamp: "2017-12-18T16:06:37.400577736Z"
 resource: {
 labels: {
 project_id: "1234567890"
 }
 type: "project"
 }
 severity: "NOTICE"
 timestamp: "2017-12-18T16:06:24.660001Z"
}

Adgang til de nævnte logfiler kan opnås på flere måder (omtrent som i de tidligere nævnte Azure og AWS) — via Log Viewer-grænsefladen, gennem API, via Google Cloud SDK eller gennem aktivitetssiden for dit projekt, hvor du er interesseret i hændelser. På samme måde kan de også eksporteres til eksterne løsninger for yderligere analyse. Dette gøres ved at eksportere loggene til BigQuery-lagring eller Cloud Pub/Sub.

Udover Stackdriver Logging tilbyder GCP-platformen også funktionaliteten Stackdriver Monitoring, som muliggør overvågning af nøglemålepunkter (ydelse, opfyldning af krav, generelt status osv.) af cloudtjenester og applikationer. De behandlede og visualiserede data kan lette identifikationen af problemer i din cloud-infrastruktur, også i forhold til sikkerhed. Men det skal bemærkes, at denne funktionalitet ikke vil være meget omfattende netop i forhold til informationssikkerhed, da GCP i dag ikke har en tilsvarende funktion som AWS GuardDuty og ikke kan udpege de dårlige hændelser blandt alle registrerede hændelser (Google har udviklet Event Threat Detection, men det er stadig i beta, og det er for tidligt at tale om dens anvendelighed). Stackdriver Monitoring kunne bruges som et system til opdagelse af anomalier, som derefter vil blive undersøgt for at finde årsagerne til deres optræden. Men under de nuværende forhold med mangel på kvalificeret personale inden for informationssikkerhed på markedet ser denne opgave i øjeblikket besværlig ud.

Det er også værd at nævne en liste over nogle sikkerhedsmoduler, som kan anvendes i forbindelse med din GCP-cloud, og som ligner dem, som tilbydes af AWS:

Cloud Security Command Center — dette er en tilsvarende løsning til AWS Security Hub og Azure Security Center.
Cloud DLP – automatisk opdagelse og redigering (f.eks. maskering) af data, der er placeret i skyen, efter mere end 90 forudinstallerede klassifikationspolitikker.
Cloud Scanner – scanner for kendte sårbarheder (XSS, Flash Injection, ikke-patchede biblioteker osv.) i App Engine, Compute Engine og Google Kubernetes.
Cloud IAM – adgangsstyring til alle GCP-ressourcer.
Cloud Identity – styring af brugerkonti, enheder og GCP-applikationer fra en enkelt konsol.
Cloud HSM – beskyttelse af kryptografiske nøgler.
Cloud Key Management Service – styring af kryptografiske nøgler i GCP.
VPC Service Control – oprettelse af en sikker perimeter omkring dine GCP-ressourcer for at beskytte dem mod lækager.
Titan Security Key – beskyttelse mod phishing.

Mange af disse moduler genererer sikkerhedshændelser, som kan sendes til BigQuery-lageret til analyse eller eksport til andre systemer, inklusive SIEM. Som nævnt tidligere er GCP en aktivt udviklet platform, og Google arbejder i øjeblikket på en række nye sikkerhedsmoduler til sin platform. Blandt dem er Event Threat Detection (i beta), som scanner Stackdriver-logs for spor af uautoriseret aktivitet (analog til GuardDuty i AWS), eller Policy Intelligence (tilgængelig i alpha), der vil muliggøre udvikling af intelligente adgangspolitikker til GCP-ressourcer.

Jeg har lavet en lille oversigt over de indbyggede overvågningsmuligheder i populære cloud-platforme. Men har I specialister, der kan arbejde med "rå" logs fra IaaS-udbyderen (ikke alle er villige til at købe de udvidede funktioner fra AWS eller Azure eller Google)? Derudover er mange bekendt med ordsproget "stol på, men verificer", der i sikkerhedsområdet aldrig har været mere sandt. Hvor meget stoler du på de indbyggede funktioner fra cloud-udbyderen, som giver dig sikkerhedshændelser? I hvilken grad fokuserer de overhovedet på sikkerhed?

Nogle gange er det værd at overveje løsninger til overvågning af cloud-infrastrukturer, som kan supplere den indbyggede sikkerhed i clouden, og nogle gange er sådanne løsninger den eneste måde at få data om sikkerheden for dine data og applikationer, der er placeret i clouden. Derudover er de simpelthen mere bekvemme, da de tager sig af alle opgaver i forbindelse med analyse af de nødvendige logs, der genereres af forskellige cloudtjenester fra forskellige cloududbydere. Et eksempel på en sådan løsning er Cisco Stealthwatch Cloud, som fokuserer på ét eneste mål — overvågning af anomaliers informationssikkerhed i cloudmiljøer, herunder ikke bare Amazon AWS, Microsoft Azure og Google Cloud Platform, men også private skyer.

Eksempel: Overvågning af informationssikkerhed med Stealthwatch Cloud

AWS tilbyder en fleksibel platform til beregninger, men denne fleksibilitet fører til, at virksomheder lettere kan begå fejl, der medfører sikkerhedsproblemer. Den delte model for informationssikkerhed bidrager kun til dette. At køre software i clouden med ukendte sårbarheder (med kendte kan man f.eks. bekæmpe ved hjælp af AWS Inspector eller GCP Cloud Scanner), svage adgangskoder, forkerte konfigurationer, indsidere osv. Og alt dette afspejles i adfærden af cloudressourcer, som Cisco Stealthwatch Cloud kan overvåge, og som er et overvågningssystem for informationssikkerhed og angrebsopdagelse i offentlige og private skyer.

En af de vigtigste funktioner i Cisco Stealthwatch Cloud er muligheden for at modellere enheder. Med dette kan du skabe en softwaremodel (dvs. en simulering næsten i realtid) af hver af dine cloudressourcer (uanset om det er AWS, Azure, GCP eller noget andet). Disse kan omfatte servere og brugere, samt ressourcetyper, der er specifikke for dit cloudmiljø, såsom sikkerhedsgrupper og auto-skaleringtjenester. Disse modeller bruger strukturerede datastreams, der leveres af cloudtjenester, som input. For eksempel, for AWS vil det være VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda og AWS IAM. Modellering af enheder identificerer automatisk rollen og adfærden for enhver af dine ressourcer (man kan tale om profilering af al cloudaktivitet). Blandt sådanne roller findes der Android- eller Apple-mobile enheder, Citrix PVS-servere, RDP-servere, mailgateways, VoIP-klienter, terminalservere, domænecontrollere osv. Derefter overvåger den kontinuerligt deres adfærd for at bestemme, hvornår der opstår risikabel eller truende adfærd. Du kan identificere brute force-angreb, DDoS-angreb, datalækager, ulovlig fjernadgang, malware-aktivitet, sårbarhedsscanning og andre trusler. For eksempel, her er hvordan forsøg på fjernadgang fra et usædvanligt land for din organisation (Sydkorea) til en Kubernetes-klynge via SSH ser ud:

Og her er, hvad en forventet datalækage fra en Postgress-database til et land, der tidligere ikke er interageret med, ser ud:

Endelig ser dette ud til at være et for stort antal mislykkede SSH-adgangsforsøg fra Kina og Indonesien fra en ekstern fjern enhed:

Eller lad os antage, at en serverinstans i VPC ifølge politikken aldrig skal være et mål for fjernadgang. Lad os antage, at der fandt fjernadgang sted på denne computer på grund af en fejlagtig ændring af firewall-regelsættet. Entitetsmodellering vil opdage og rapportere denne aktivitet ("Usædvanlig fjernadgang") i næsten realtid og pege på det specifikke AWS CloudTrail, Azure Monitor eller GCP Stackdriver Logging API-opkald (inklusive brugernavn, dato og tidspunkt samt andre detaljer), der forårsagede ændringen i firewall-reglen. Oplysningerne kan derefter overføres til SIEM til analyse.

Lignende funktioner implementeres for ethvert cloud-miljø, der understøttes af Cisco Stealthwatch Cloud:

Entitetsmodellering er en unik form for sikkerhedsautomation, der kan opdage tidligere ukendte problemer med dine mennesker, processer eller teknologier. For eksempel muliggør det at opdage blandt andet følgende sikkerhedsproblemer:

Har nogen opdaget en bagdør i den software, vi bruger?
Er der noget tredjepartssoftware eller -enhed i vores cloud?
Misbruger en autoriseret bruger sine privilegier?
Er der begået en konfigurationsfejl, der giver fjernadgang eller anden utilsigtet brug af ressourcer?
Er der nogen data, der lækker fra vores servere?
Har nogen forsøgt at oprette forbindelse til os fra et usædvanligt geografisk sted?
Er vores cloud inficeret med skadelig kode?

En opdaget sikkerhedshændelse kan overføres som en relevant billet til Slack, Cisco Spark, PagerDuty incident management systemet, samt videregives til forskellige SIEM-systemer, herunder Splunk eller ELK. For at opsummere, hvis din virksomhed anvender en multi-cloud strategi og ikke er begrænset til én cloud-udbyder, kan de overvågningsmuligheder, der er beskrevet ovenfor, gøre Cisco Stealthwatch Cloud til en god mulighed for at få et ensartet sæt af overvågningsfunktioner for de førende cloud-udbydere - Amazon, Microsoft og Google. Det mest interessante er, at når man sammenligner priserne på Stealthwatch Cloud med avancerede licenser til sikkerhedsovervågning i AWS, Azure eller GCP, kan det vise sig, at Cisco-løsningen endda er billigere end de indbyggede funktioner i Amazon, Microsoft og Google’s løsninger. Paradoxalt, men sandt. Og jo flere clouds og deres funktioner du bruger, jo tydeligere bliver fordelene ved en konsolideret løsning.

Desuden kan Stealthwatch Cloud overvåge private clouds, der er implementeret i din organisation, for eksempel baseret på Kubernetes-containere eller ved at overvåge Netflow-strømme eller netværkstrafik, der modtages via spejling i netværksudstyr (endda lokalproduceret), data fra AD eller DNS-servere osv. Alle disse data vil blive beriget med oplysninger fra Threat Intelligence, der indsamles af Cisco Talos, som er verdens største ikke-statslige gruppe af trusselsforskere inden for cybersikkerhed.

Dette gør det muligt for dig at implementere et ensartet overvågningssystem for både offentlige og hybrid clouds, som din virksomhed kan bruge. De indsamlede oplysninger kan derefter analyseres ved hjælp af de indbyggede funktioner i Stealthwatch Cloud eller sendes til dit SIEM (som standard understøttes Splunk, ELK, SumoLogic og flere andre).

Her afslutter vi den første del af artiklen, hvor jeg har gennemgået de indbyggede og eksterne værktøjer til overvågning af informationssikkerhed på IaaS/PaaS-platforme, som gør det muligt for os hurtigt at opdage og reagere på hændelser, der opstår i de cloudmiljøer, som vores virksomhed har valgt. I den anden del fortsætter vi emnet og ser på mulighederne for overvågning af SaaS-platforme med Salesforce og Dropbox som eksempler, samt forsøger at opsummere og samle det hele ved at skabe et samlet overvågningssystem for informationssikkerhed på tværs af forskellige cloududbydere.

Kilde: habr.com