Skysikkerhedsovervågning

Flytning af data og applikationer til skyen udgør en ny udfordring for virksomhedens SOC'er, som ikke altid er klar til at overvåge andres infrastruktur. Ifølge Netoskope bruger den gennemsnitlige virksomhed (tilsyneladende i USA) 1246 forskellige cloud-tjenester, hvilket er 22 % mere end for et år siden. 1246 skytjenester!!! 175 af dem vedrører HR-tjenester, 170 er relateret til marketing, 110 er inden for kommunikation og 76 er inden for økonomi og CRM. Cisco bruger "kun" 700 eksterne cloud-tjenester. Så jeg er lidt forvirret over disse tal. Men problemet ligger i hvert fald ikke hos dem, men i, at skyen begynder at blive brugt ret aktivt af et stigende antal virksomheder, der gerne vil have samme muligheder for at overvåge cloud-infrastruktur som i deres eget netværk. Og denne tendens vokser – iflg ifølge American Chamber of Accounts I 2023 vil 1200 datacentre være lukket i USA (6250 er allerede lukket). Men overgangen til skyen er ikke bare "lad os flytte vores servere til en ekstern udbyder." Ny it-arkitektur, ny software, nye processer, nye restriktioner... Alt dette medfører væsentlige ændringer i arbejdet med ikke kun it, men også informationssikkerhed. Og hvis udbyderne har lært at på en eller anden måde klare at sikre sikkerheden i selve skyen (heldigvis er der mange anbefalinger), så er der med cloudinformationssikkerhedsovervågning, især på SaaS-platforme, betydelige vanskeligheder, som vi vil tale om.

Lad os sige, at din virksomhed har flyttet en del af sin infrastruktur til skyen... Stop. Ikke på denne måde. Hvis infrastrukturen er blevet overført, og du først nu tænker på, hvordan du vil overvåge den, så har du allerede tabt. Medmindre det er Amazon, Google eller Microsoft (og så med forbehold), vil du sandsynligvis ikke have meget mulighed 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, så er sikkerhedsbegivenheder slet ikke tilgængelige for dig. Hvis du har en E3-licens, gemmes dine data i kun 90 dage, og kun hvis du har en E5-licens, er varigheden af ​​loggene tilgængelig i et år (dette har dog også sine egne nuancer relateret til behovet for separat anmode om en række funktioner til at arbejde med logfiler fra Microsofts support). E3-licensen er i øvrigt meget svagere med hensyn til overvågningsfunktioner end virksomhedens Exchange. For at opnå det samme niveau skal du have en E5-licens eller en ekstra Advanced Compliance-licens, hvilket kan kræve yderligere penge, som ikke var indregnet i din økonomiske model for at flytte til cloud-infrastruktur. Og dette er blot et eksempel på undervurdering af problemer relateret til cloudinformationssikkerhedsovervågning. I denne artikel vil jeg, uden at foregive at være komplet, henlede opmærksomheden på nogle nuancer, der bør tages i betragtning, når du vælger en cloud-udbyder ud fra et sikkerhedssynspunkt. Og i slutningen af ​​artiklen vil der blive givet en tjekliste, som er værd at udfylde, før man overvejer, at spørgsmålet om overvågning af cloud informationssikkerhed er løst.

Der er flere typiske problemer, der fører til hændelser i cloudmiljøer, som informationssikkerhedstjenester ikke har tid til at reagere på eller slet ikke kan se dem:

• Sikkerhedslogfiler findes ikke. Dette er en ret almindelig situation, især blandt nybegyndere på markedet for cloudløsninger. Men du skal ikke give op på dem med det samme. Små aktører, især indenlandske, er mere følsomme over for kundernes krav og kan hurtigt implementere nogle påkrævede funktioner ved at ændre den godkendte køreplan for deres produkter. Ja, dette vil ikke være en analog af GuardDuty fra Amazon eller modulet "Proactive Protection" fra Bitrix, men i det mindste noget.
• Informationssikkerheden ved ikke, hvor loggene er gemt, eller der er ingen adgang til dem. Her er det nødvendigt at indlede forhandlinger med cloud-tjenesteudbyderen – måske vil han give sådanne oplysninger, hvis han anser kunden for vigtig for ham. Men generelt er det ikke særlig godt, når adgang til logfiler gives "ved særlig beslutning."
• Det sker også, at cloud-udbyderen har logs, men de giver begrænset overvågning og hændelsesregistrering, som ikke er tilstrækkelige til at opdage alle hændelser. For eksempel kan du kun modtage logs over ændringer på et websted eller logs over brugergodkendelsesforsøg, men ikke andre hændelser, såsom netværkstrafik, som vil skjule et helt lag af hændelser for dig, der karakteriserer forsøg på at hacke din cloud-infrastruktur.
• Der er logfiler, men adgangen til dem er svær at automatisere, hvilket tvinger dem til ikke at blive overvåget kontinuerligt, men efter en tidsplan. Og hvis du ikke kan downloade logs automatisk, så kan download af logs, for eksempel i Excel-format (som med en række indenlandske cloud-løsningsudbydere), endda føre til, at virksomhedens informationssikkerhedstjeneste ikke vil pille ved dem.
• Ingen log overvågning. Dette er måske den mest uklare årsag til forekomsten af ​​informationssikkerhedshændelser i cloudmiljøer. Det ser ud til, at der er logs, og det er muligt at automatisere adgangen til dem, men ingen gør dette. Hvorfor?

Delt skysikkerhedskoncept

Overgangen til skyen er altid en søgen efter en balance mellem ønsket om at bevare kontrollen over infrastrukturen og at overføre den til de mere professionelle hænder hos en cloududbyder, der har specialiseret sig i at vedligeholde den. Og inden for cloud-sikkerhed skal denne balance også søges. Afhængigt af den anvendte cloud-tjenesteleveringsmodel (IaaS, PaaS, SaaS), vil denne balance desuden være forskellig hele tiden. Vi skal i hvert fald huske på, at alle cloud-udbydere i dag følger den såkaldte delt ansvar og delt informationssikkerhedsmodel. Skyen er ansvarlig for nogle ting, og for andre er klienten ansvarlig for at placere sine data, sine applikationer, sine virtuelle maskiner og andre ressourcer i skyen. Det ville være hensynsløst at forvente, at vi ved at gå til skyen vil flytte alt ansvar til udbyderen. Men det er også uklogt at bygge al sikkerheden selv, når du flytter til skyen. Der kræves en balance, som vil afhænge af mange faktorer: - risikostyringsstrategi, trusselsmodel, sikkerhedsmekanismer til rådighed for cloududbyderen, lovgivning mv.

For eksempel er klassificeringen af ​​data hostet i skyen altid kundens ansvar. En cloud-udbyder eller en ekstern tjenesteudbyder kan kun hjælpe ham med værktøjer, der hjælper med at markere data i skyen, identificere overtrædelser, slette data, der overtræder loven, eller maskere dem ved hjælp af en eller anden metode. På den anden side er fysisk sikkerhed altid skyudbyderens ansvar, som den ikke kan dele med kunderne. Men alt, hvad der er mellem data og fysisk infrastruktur, er netop genstand for diskussion i denne artikel. For eksempel er tilgængeligheden af ​​skyen udbyderens ansvar, og opsætning af firewallregler eller aktivering af kryptering er klientens ansvar. I denne artikel vil vi forsøge at se på, hvilke informationssikkerhedsovervågningsmekanismer, der leveres i dag af forskellige populære cloud-udbydere i Rusland, hvad er funktionerne ved deres brug, og hvornår er det værd at se på eksterne overlejringsløsninger (for eksempel Cisco E- mail Security), der udvider din skys muligheder med hensyn til cybersikkerhed. I nogle tilfælde, især hvis du følger en multi-cloud-strategi, har du intet andet valg end at bruge eksterne informationssikkerhedsovervågningsløsninger i flere cloud-miljøer på én gang (for eksempel Cisco CloudLock eller Cisco Stealthwatch Cloud). Nå, i nogle tilfælde vil du indse, at den cloud-udbyder, du har valgt (eller pålagt dig), ikke tilbyder nogen informationssikkerhedsovervågning overhovedet. Dette er ubehageligt, men heller ikke lidt, da det giver dig mulighed for tilstrækkeligt at vurdere risikoniveauet forbundet med at arbejde med denne sky.

Cloud Security Monitoring Lifecycle

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

• stole på værktøjerne fra din cloud-udbyder,
• bruge løsninger fra tredjeparter, der vil overvåge de IaaS-, PaaS- eller SaaS-platforme, du bruger,
• byg din egen cloud-overvågningsinfrastruktur (kun for IaaS/PaaS-platforme).

Lad os se, hvilke funktioner hver af disse muligheder har. Men først skal vi forstå den generelle ramme, der vil blive brugt ved overvågning af cloud-platforme. Jeg vil fremhæve 6 hovedkomponenter i informationssikkerhedsovervågningsprocessen i skyen:

• Udarbejdelse af infrastruktur. Fastlæggelse af de nødvendige applikationer og infrastruktur til indsamling af begivenheder, der er vigtige for informationssikkerheden til opbevaring.
• Kollektion. På dette stadium aggregeres sikkerhedshændelser fra forskellige kilder til efterfølgende transmission til behandling, lagring og analyse.
• Behandling. På dette trin transformeres og beriges dataene for at lette efterfølgende analyse.
• Opbevaring. Denne komponent er ansvarlig for kort- og langtidslagring af indsamlede behandlede og rådata.
• Analyse. På dette stadium har du mulighed for at opdage hændelser og reagere på dem automatisk eller manuelt.
• Indberetning. Denne fase hjælper med at formulere nøgleindikatorer for interessenter (ledelse, revisorer, cloud-udbyder, kunder osv.), der hjælper os med at træffe bestemte beslutninger, for eksempel at skifte udbyder eller styrke informationssikkerheden.

Forståelse af disse komponenter vil give dig mulighed for hurtigt at beslutte i fremtiden, hvad du kan tage fra din udbyder, og hvad du skal gøre selv eller med inddragelse af eksterne konsulenter.

Indbyggede cloud-tjenester

Jeg skrev allerede ovenfor, at mange cloud-tjenester i dag ikke giver nogen informationssikkerhedsovervågningsfunktioner. Generelt er de ikke meget opmærksomme på emnet informationssikkerhed. For eksempel en af ​​de populære russiske tjenester til at sende rapporter til offentlige myndigheder via internettet (jeg vil ikke specifikt nævne dens navn). Hele afsnittet om sikkerheden af ​​denne tjeneste drejer sig om brugen af ​​certificeret CIPF. Informationssikkerhedssektionen i en anden indenlandsk cloud-tjeneste til elektronisk dokumenthåndtering er ikke anderledes. Den taler om offentlige nøglecertifikater, certificeret kryptografi, eliminering af websårbarheder, beskyttelse mod DDoS-angreb, brug af firewalls, sikkerhedskopier og endda regelmæssige informationssikkerhedsrevisioner. Men der er ikke et ord om overvågning eller om muligheden for at få adgang til informationssikkerhedsbegivenheder, som kan være af interesse for denne tjenesteudbyders klienter.

Generelt kan du forstå, hvor seriøst den tager dette problem, når cloududbyderen beskriver informationssikkerhedsproblemer på sin hjemmeside og i sin dokumentation. Læser man for eksempel manualerne til “My Office”-produkterne, står der slet ikke et ord om sikkerhed, men i dokumentationen til det separate produkt “My Office. KS3”, designet til at beskytte mod uautoriseret adgang, er der en sædvanlig liste over punkter af 17. orden af ​​FSTEC, som "My Office.KS3" implementerer, men det er ikke beskrevet, hvordan det implementerer det, og vigtigst af alt, hvordan man integrere disse mekanismer med virksomhedens informationssikkerhed. Måske findes sådan dokumentation, men jeg fandt den ikke i det offentlige domæne på webstedet "My Office". Selvom jeg måske bare ikke har adgang til disse hemmelige oplysninger?

For Bitrix er situationen meget bedre. Dokumentationen beskriver formaterne af hændelsesloggene og interessant nok indtrængningsloggen, som indeholder hændelser relateret til potentielle trusler mod cloud-platformen. Derfra kan du trække IP, bruger- eller gæstenavn, begivenhedskilde, tidspunkt, brugeragent, begivenhedstype, osv. ud. Sandt nok kan du arbejde med disse begivenheder enten fra kontrolpanelet i selve skyen eller uploade data i MS Excel-format. Det er nu svært at automatisere arbejde med Bitrix-logfiler, og du bliver nødt til at gøre noget af arbejdet manuelt (uploade rapporten og indlæse den i din SIEM). Men hvis vi husker, at en sådan mulighed indtil relativt for nylig ikke eksisterede, så er det et stort fremskridt. Samtidig vil jeg bemærke, at mange udenlandske cloud-udbydere tilbyder lignende funktionalitet "for begyndere" - enten se logfilerne med dine øjne gennem kontrolpanelet, eller upload dataene til dig selv (dog uploader de fleste data i . csv-format, ikke Excel).

Uden at overveje muligheden uden logs, tilbyder cloud-udbydere dig normalt tre muligheder for at overvåge sikkerhedshændelser - dashboards, dataupload og API-adgang. Det første ser ud til at løse mange problemer for dig, men det er ikke helt sandt - hvis du har flere magasiner, skal du skifte mellem de skærme, der viser dem, og miste det overordnede billede. Derudover er det usandsynligt, at cloududbyderen giver dig mulighed for at korrelere sikkerhedshændelser og generelt analysere dem ud fra et sikkerhedssynspunkt (normalt har du at gøre med rådata, som du selv skal forstå). Der er undtagelser, og dem vil vi tale nærmere om. Endelig er det værd at spørge, hvilke hændelser der registreres af din cloududbyder, i hvilket format, og hvordan svarer de til din informationssikkerhedsovervågningsproces? For eksempel identifikation og autentificering af brugere og gæster. Den samme Bitrix giver dig mulighed for, baseret på disse hændelser, at registrere datoen og klokkeslættet for begivenheden, navnet på brugeren eller gæsten (hvis du har "Web Analytics"-modulet), det objekt, der tilgås og andre elementer, der er typiske for en hjemmeside . Men virksomhedens informationssikkerhedstjenester kan have brug for oplysninger om, hvorvidt brugeren har adgang til skyen fra en betroet enhed (f.eks. i et virksomhedsnetværk implementeres denne opgave af Cisco ISE). Hvad med en så simpel opgave som geo-IP-funktionen, som vil hjælpe med at afgøre, om en cloud-tjenestebrugerkonto er blevet stjålet? Og selvom cloud-udbyderen leverer det til dig, er det ikke nok. Den samme Cisco CloudLock analyserer ikke bare geolocation, men bruger maskinlæring til dette og analyserer historiske data for hver bruger og overvåger forskellige uregelmæssigheder i identifikations- og autentificeringsforsøg. Kun MS Azure har lignende funktionalitet (hvis du har det relevante abonnement).

Der er en anden vanskelighed – da informationssikkerhedsovervågning for mange cloududbydere er et nyt emne, som de lige er begyndt at beskæftige sig med, ændrer de hele tiden noget i deres løsninger. I dag har de en version af API'en, i morgen en anden, i overmorgen en tredje. Det skal du også være forberedt på. Det samme er tilfældet med funktionalitet, som kan ændre sig, som skal tages i betragtning i dit informationssikkerhedsovervågningssystem. For eksempel havde Amazon oprindeligt separate cloud-hændelsesovervågningstjenester - AWS CloudTrail og AWS CloudWatch. Så dukkede en separat tjeneste til overvågning af informationssikkerhedshændelser op - AWS GuardDuty. Efter nogen tid lancerede Amazon et nyt ledelsessystem, Amazon Security Hub, som inkluderer analyse af data modtaget fra GuardDuty, Amazon Inspector, Amazon Macie og flere andre. Et andet eksempel er værktøjet til at integrere Azure-logfiler med SIEM - AzLog. Det blev aktivt brugt af mange SIEM-leverandører, indtil Microsoft i 2018 annoncerede ophøret med dets udvikling og support, hvilket konfronterede mange kunder, der brugte dette værktøj med et problem (vi vil tale om, hvordan det blev løst senere).

Overvåg derfor nøje alle de overvågningsfunktioner, som din cloududbyder tilbyder dig. Eller stol på eksterne løsningsudbydere, der vil fungere som mellemled mellem din SOC og den sky, du ønsker at overvåge. Ja, det vil være dyrere (men ikke altid), men du vil flytte hele ansvaret over på en andens skuldre. Eller ikke det hele?.. Lad os huske konceptet med delt sikkerhed og forstå, at vi ikke kan flytte noget - vi bliver nødt til uafhængigt at forstå, hvordan forskellige cloud-udbydere leverer overvågning af informationssikkerheden for dine data, applikationer, virtuelle maskiner og andre ressourcer hostet i skyen. Og vi starter med, hvad Amazon tilbyder i denne del.

Eksempel: Informationssikkerhedsovervågning i IaaS baseret på AWS

Ja, ja, jeg forstår, at Amazon ikke er det bedste eksempel på grund af det faktum, at dette er en amerikansk tjeneste, og den kan blokeres som en del af kampen mod ekstremisme og spredning af information, der er forbudt i Rusland. Men i denne publikation vil jeg blot vise, hvordan forskellige cloud-platforme adskiller sig i deres informationssikkerhedsovervågningsmuligheder, og hvad du bør være opmærksom på, når du overfører dine nøgleprocesser til skyerne ud fra et sikkerhedssynspunkt. Nå, hvis nogle af de russiske udviklere af cloud-løsninger lærer noget nyttigt for sig selv, så vil det være fantastisk.

Den første ting at sige er, at Amazon ikke er en uigennemtrængelig fæstning. Forskellige hændelser sker jævnligt med hans klienter. For eksempel blev navne, adresser, fødselsdatoer og telefonnumre på 198 millioner vælgere stjålet fra Deep Root Analytics. Det israelske firma Nice Systems stjal 14 millioner registreringer af Verizon-abonnenter. AWS's indbyggede muligheder giver dig dog mulighed for at opdage en lang række hændelser. For eksempel:

• indvirkning på infrastruktur (DDoS)
• node kompromis (kommandeinjektion)
• kompromittering af konto og uautoriseret adgang
• forkert konfiguration og sårbarheder
• usikre grænseflader og API'er.

Denne uoverensstemmelse skyldes, at kunden, som vi fandt ud af ovenfor, selv er ansvarlig for sikkerheden af ​​kundedata. Og hvis han ikke gad at tænde for beskyttelsesmekanismer og ikke tændte for overvågningsværktøjer, vil han kun lære om hændelsen fra medierne eller fra sine klienter.

For at identificere hændelser kan du bruge en lang række forskellige overvågningstjenester udviklet af Amazon (selvom disse ofte suppleres af eksterne værktøjer såsom osquery). Så i AWS overvåges alle brugerhandlinger, uanset hvordan de udføres - gennem administrationskonsollen, kommandolinjen, SDK eller andre AWS-tjenester. Alle registreringer af hver AWS-kontos aktivitet (inklusive brugernavn, handling, service, aktivitetsparametre og resultat) og API-brug er tilgængelige via AWS CloudTrail. Du kan se disse hændelser (såsom AWS IAM-konsollogins) fra CloudTrail-konsollen, analysere dem ved hjælp af Amazon Athena eller "outsource" dem til eksterne løsninger såsom Splunk, AlienVault osv. Selve AWS CloudTrail-loggene placeres i din AWS S3-spand.

To andre AWS-tjenester giver en række andre vigtige overvågningsmuligheder. For det første er Amazon CloudWatch en overvågningstjeneste for AWS-ressourcer og applikationer, der blandt andet giver dig mulighed for at identificere forskellige anomalier i din sky. Alle indbyggede AWS-tjenester, såsom Amazon Elastic Compute Cloud (servere), Amazon Relational Database Service (databaser), Amazon Elastic MapReduce (dataanalyse) og 30 andre Amazon-tjenester, bruger Amazon CloudWatch til at gemme deres logfiler. Udviklere kan bruge den åbne API fra Amazon CloudWatch til at tilføje logovervågningsfunktionalitet til tilpassede applikationer og tjenester, så de kan udvide omfanget af hændelsesanalyse inden for en sikkerhedskontekst.

For det andet giver VPC Flow Logs-tjenesten dig mulighed for at analysere netværkstrafikken, der sendes eller modtages af dine AWS-servere (eksternt eller internt), såvel som mellem mikrotjenester. Når nogen af ​​dine AWS VPC-ressourcer interagerer med netværket, registrerer VPC Flow Logs detaljer om netværkstrafikken, herunder kilde- og destinationsnetværksgrænsefladen, samt IP-adresser, porte, protokol, antal bytes og antallet af pakker, du sav. De, der har erfaring med lokal netværkssikkerhed, vil genkende dette som analogt med tråde NetFlow, som kan oprettes af switches, routere og firewalls i virksomhedskvalitet. Disse logfiler er vigtige for informationssikkerhedsovervågningsformål, fordi de, i modsætning til hændelser om brugernes og applikationers handlinger, også giver dig mulighed for ikke at gå glip af netværksinteraktioner i AWS virtuelle private cloud-miljø.

Sammenfattende giver disse tre AWS-tjenester – AWS CloudTrail, Amazon CloudWatch og VPC Flow Logs – tilsammen ret kraftfuld indsigt i din kontobrug, brugeradfærd, infrastrukturstyring, applikations- og serviceaktivitet og netværksaktivitet. For eksempel kan de bruges til at opdage følgende anomalier:

• Forsøg på at scanne webstedet, søge efter bagdøre, søge efter sårbarheder gennem udbrud af "404-fejl".
• Injektionsangreb (for eksempel SQL-injektion) gennem bursts af "500 fejl".
• Kendte angrebsværktøjer er sqlmap, nikto, w3af, nmap osv. gennem analyse af feltet User Agent.

Amazon Web Services har også udviklet andre tjenester til cybersikkerhedsformål, der giver dig mulighed for at løse mange andre problemer. For eksempel har AWS en indbygget service til revision af politikker og konfigurationer - AWS Config. Denne service giver kontinuerlig revision af dine AWS-ressourcer og deres konfigurationer. Lad os tage et simpelt eksempel: Lad os sige, at du vil sikre dig, at brugeradgangskoder er deaktiveret på alle dine servere, og at adgang kun er mulig baseret på certifikater. AWS Config gør det nemt at kontrollere dette for alle dine servere. Der er andre politikker, der kan anvendes på dine cloud-servere: "Ingen server kan bruge port 22", "Kun administratorer kan ændre firewallregler" eller "Kun brugeren Ivashko kan oprette nye brugerkonti, og han kan gøre Det er kun om tirsdagen. " I sommeren 2016 blev AWS Config-tjenesten udvidet til at automatisere registreringen af ​​overtrædelser af udviklede politikker. AWS Config Rules er i det væsentlige kontinuerlige konfigurationsanmodninger for de Amazon-tjenester, du bruger, som genererer hændelser, hvis de tilsvarende politikker overtrædes. For eksempel, i stedet for periodisk at køre AWS Config-forespørgsler for at bekræfte, at alle diske på en virtuel server er krypteret, kan AWS Config Rules bruges til løbende at kontrollere serverdiske for at sikre, at denne betingelse er opfyldt. Og vigtigst af alt, i forbindelse med denne publikation genererer enhver overtrædelse begivenheder, der kan analyseres af din informationssikkerhedstjeneste.

AWS har også sin ækvivalent til traditionelle virksomhedsinformationssikkerhedsløsninger, som også genererer sikkerhedshændelser, som du kan og bør analysere:

• Intrusion Detection - AWS GuardDuty
• Informationslækagekontrol - AWS Macie
• EDR (selvom det taler om endepunkter i skyen lidt mærkeligt) - AWS Cloudwatch + open source osquery eller GRR-løsninger
• Netflow-analyse - AWS Cloudwatch + AWS VPC Flow
• DNS-analyse - AWS Cloudwatch + AWS Route53
• AD - AWS Directory Service
• Account Management - AWS IAM
• SSO - AWS SSO
• sikkerhedsanalyse - AWS Inspector
• konfigurationsstyring - AWS Config
• WAF - AWS WAF.

Jeg vil ikke i detaljer beskrive alle Amazon-tjenester, der kan være nyttige i forbindelse med informationssikkerhed. Det vigtigste er at forstå, at de alle kan generere begivenheder, som vi kan og bør analysere i forbindelse med informationssikkerhed, ved at bruge til dette formål både Amazons indbyggede muligheder og eksterne løsninger, for eksempel SIEM, som kan tage 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.

Under alle omstændigheder starter det hele med de datakilder, der giver dig informationssikkerhedsbegivenheder. Disse kilder omfatter, men er ikke begrænset til:

• CloudTrail - API-brug og brugerhandlinger
• Trusted Advisor - sikkerhedstjek i forhold til bedste praksis
• Config - opgørelse og konfiguration af konti og serviceindstillinger
• VPC Flow Logs - forbindelser til virtuelle grænseflader
• IAM - identifikation og autentificeringstjeneste
• ELB Access Logs - Load Balancer
• Inspektør - applikationssårbarheder
• S3 - fillagring
• CloudWatch - Applikationsaktivitet
• SNS er en notifikationstjeneste.

Amazon tilbyder, mens den tilbyder en sådan række af begivenhedskilder og værktøjer til deres generation, meget begrænset i sin evne til at analysere de indsamlede data i forbindelse med informationssikkerhed. Du bliver nødt til selvstændigt at studere de tilgængelige logfiler og lede efter relevante indikatorer for kompromis i dem. AWS Security Hub, som Amazon for nylig lancerede, har til formål at løse dette problem ved at blive en cloud SIEM for AWS. Men indtil videre er det kun i begyndelsen af ​​sin rejse og er begrænset både af antallet af kilder, som det arbejder med, og af andre restriktioner etableret af Amazons arkitektur og abonnementer.

Eksempel: Informationssikkerhedsovervågning i IaaS baseret på Azure

Jeg ønsker ikke at komme ind i en lang debat om, hvilken af ​​de tre cloud-udbydere (Amazon, Microsoft eller Google) der er bedre (især da hver af dem stadig har sine egne specifikke detaljer og er velegnede til at løse sine egne problemer); Lad os fokusere på de informationssikkerhedsovervågningsfunktioner, som disse spillere tilbyder. Det må indrømmes, at Amazon AWS var en af ​​de første i dette segment og derfor er kommet længst med sine informationssikkerhedsfunktioner (selvom mange indrømmer, at de er svære at bruge). Men det betyder ikke, at vi vil ignorere de muligheder, som Microsoft og Google giver os.

Microsoft-produkter har altid været kendetegnet ved deres "åbenhed", og i Azure er situationen den samme. For eksempel, hvis AWS og GCP altid går ud fra konceptet "hvad der ikke er tilladt er forbudt", så har Azure den stik modsatte tilgang. For eksempel, når du opretter et virtuelt netværk i skyen og en virtuel maskine i den, er alle porte og protokoller åbne og tilladt som standard. Derfor skal du bruge lidt flere kræfter på den indledende opsætning af adgangskontrolsystemet i skyen fra Microsoft. Og dette stiller også strengere krav til dig med hensyn til overvågning af aktivitet i Azure-skyen.

AWS har en særegenhed forbundet med det faktum, at når du overvåger dine virtuelle ressourcer, hvis de er placeret i forskellige regioner, så har du vanskeligheder med at kombinere alle begivenheder og deres samlede analyse, for at eliminere, hvilke du skal ty til forskellige tricks, som f.eks. Opret din egen kode til AWS Lambda, der transporterer begivenheder mellem regioner. Azure har ikke dette problem - dens aktivitetslogmekanisme sporer al aktivitet på tværs af hele organisationen uden begrænsninger. Det samme gælder AWS Security Hub, som for nylig blev udviklet af Amazon til at konsolidere mange sikkerhedsfunktioner inden for et enkelt sikkerhedscenter, men kun inden for sin region, hvilket dog ikke er relevant for Rusland. Azure har sit eget sikkerhedscenter, som ikke er bundet af regionale begrænsninger, som giver adgang til alle sikkerhedsfunktionerne på cloud-platformen. Desuden kan det til forskellige lokale teams levere sit eget sæt af beskyttelsesfunktioner, herunder sikkerhedshændelser, der administreres af dem. AWS Security Hub er stadig på vej til at blive magen til Azure Security Center. Men det er værd at tilføje en flue i salven - du kan presse meget ud af Azure af det, der tidligere blev beskrevet i AWS, men dette gøres mest bekvemt kun for Azure AD, Azure Monitor og Azure Security Center. Alle andre Azure-sikkerhedsmekanismer, inklusive analyse af sikkerhedshændelser, administreres endnu ikke på den mest bekvemme måde. Problemet er delvist løst af API'en, som gennemsyrer alle Microsoft Azure-tjenester, men dette vil kræve yderligere indsats fra dig for at integrere din sky med din SOC og tilstedeværelsen af ​​kvalificerede specialister (faktisk som med enhver anden SIEM, der arbejder med skyen API'er). Nogle SIEM'er, som vil blive diskuteret senere, understøtter allerede Azure og kan automatisere opgaven med at overvåge det, men det har også sine egne vanskeligheder - ikke alle kan samle alle de logfiler, som Azure har.

Hændelsesindsamling og -overvågning i Azure leveres ved hjælp af Azure Monitor-tjenesten, som er hovedværktøjet til at indsamle, lagre og analysere data i Microsoft-skyen og dens ressourcer - Git-lagre, containere, virtuelle maskiner, applikationer mv. Alle data, der indsamles af Azure Monitor, er opdelt i to kategorier - metrics, der indsamles i realtid og beskriver nøgleydelsesindikatorer for Azure-skyen, og logfiler, der indeholder data organiseret i poster, der karakteriserer visse aspekter af aktiviteten af ​​Azure-ressourcer og -tjenester. Derudover kan Azure Monitor-tjenesten ved hjælp af Data Collector API indsamle data fra enhver REST-kilde for at bygge sine egne overvågningsscenarier.

Her er et par sikkerhedshændelseskilder, som Azure tilbyder dig, og som du kan få adgang til via Azure Portal, CLI, PowerShell eller REST API (og nogle kun gennem Azure Monitor/Insight API):

• Aktivitetslogfiler - denne log besvarer de klassiske spørgsmål om "hvem", "hvad" og "hvornår" vedrørende enhver skriveoperation (PUT, POST, SLET) på skyressourcer. Hændelser relateret til læseadgang (GET) er ikke inkluderet i denne log, ligesom en række andre.
• Diagnostiske logfiler - indeholder data om operationer med en bestemt ressource inkluderet i dit abonnement.
• Azure AD-rapportering - indeholder både brugeraktivitet og systemaktivitet relateret til gruppe- og brugeradministration.
• Windows Event Log og Linux Syslog - indeholder hændelser fra virtuelle maskiner hostet i skyen.
• Metrics - indeholder telemetri om ydeevne og sundhedsstatus for dine cloudtjenester og -ressourcer. Målt hvert minut og gemt. inden for 30 dage.
• Network Security Group Flow Logs - indeholder data om netværkssikkerhedshændelser indsamlet ved hjælp af Network Watcher-tjenesten og ressourceovervågning på netværksniveau.
• Lagerlogs - indeholder hændelser relateret til adgang til lagerfaciliteter.

Til overvågning kan du bruge eksterne SIEM'er eller den indbyggede Azure Monitor og dens udvidelser. Vi vil tale om informationssikkerhedshændelsesstyringssystemer senere, men lad os indtil videre se, hvad Azure selv tilbyder os til dataanalyse i forbindelse med sikkerhed. Hovedskærmen for alt sikkerhedsrelateret i Azure Monitor er Log Analytics Security and Audit Dashboard (den gratis version understøtter en begrænset mængde hændelseslager i kun en uge). Dette dashboard er opdelt i 5 hovedområder, der visualiserer oversigtsstatistikker over, hvad der sker i det cloudmiljø, du bruger:

• Sikkerhedsdomæner - vigtige kvantitative indikatorer relateret til informationssikkerhed - antallet af hændelser, antallet af kompromitterede noder, ikke-patchede noder, netværkssikkerhedshændelser osv.
• Bemærkelsesværdige problemer - viser antallet og vigtigheden af ​​aktive informationssikkerhedsproblemer
• Detektioner - viser mønstre af angreb, der er brugt mod dig
• Threat Intelligence - viser geografisk information om eksterne noder, der angriber dig
• Almindelige sikkerhedsforespørgsler - typiske forespørgsler, der hjælper dig med bedre at overvåge din informationssikkerhed.

Azure Monitor-udvidelser omfatter Azure Key Vault (beskyttelse af kryptografiske nøgler i skyen), Malware Assessment (analyse af beskyttelse mod ondsindet kode på virtuelle maskiner), Azure Application Gateway Analytics (analyse af blandt andet cloud firewall-logfiler) mv. . Disse værktøjer, beriget med visse regler for behandling af hændelser, giver dig mulighed for at visualisere forskellige aspekter af aktiviteten af ​​cloud-tjenester, herunder sikkerhed, og identificere visse afvigelser fra driften. Men som det ofte sker, kræver enhver yderligere funktionalitet et tilsvarende betalt abonnement, hvilket vil kræve tilsvarende økonomiske investeringer fra dig, som du skal planlægge på forhånd.

Azure har en række indbyggede trusselsovervågningsfunktioner, der er integreret i Azure AD, Azure Monitor og Azure Security Center. Blandt dem, for eksempel, påvisning af interaktion af virtuelle maskiner med kendte ondsindede IP'er (på grund af tilstedeværelsen af ​​integration med Threat Intelligence-tjenester fra Microsoft), påvisning af malware i cloud-infrastrukturen ved at modtage alarmer fra virtuelle maskiner hostet i skyen, adgangskode gætteangreb ” på virtuelle maskiner, sårbarheder i konfigurationen af ​​brugeridentifikationssystemet, logning på systemet fra anonymisatorer eller inficerede noder, kontolækager, logning på systemet fra usædvanlige steder osv. Azure er i dag en af ​​de få cloud-udbydere, der tilbyder dig indbyggede Threat Intelligence-funktioner til at berige indsamlede informationssikkerhedsbegivenheder.

Som nævnt ovenfor er sikkerhedsfunktionaliteten og som følge heraf de sikkerhedshændelser, der genereres af den, ikke lige tilgængelige for alle brugere, men kræver et bestemt abonnement, der inkluderer den funktionalitet, du har brug for, som genererer de passende hændelser til informationssikkerhedsovervågning. For eksempel er nogle af funktionerne beskrevet i det foregående afsnit til overvågning af uregelmæssigheder i konti kun tilgængelige i P2 premium-licensen til Azure AD-tjenesten. Uden det bliver du, som i tilfældet med AWS, nødt til at analysere de indsamlede sikkerhedshændelser "manuelt". Og afhængigt af typen af ​​Azure AD-licens vil ikke alle hændelser være tilgængelige til analyse.

På Azure-portalen kan du administrere både søgeforespørgsler efter logfiler af interesse for dig og konfigurere dashboards til at visualisere vigtige informationssikkerhedsindikatorer. Derudover kan du der vælge Azure Monitor-udvidelser, som giver dig mulighed for at udvide funktionaliteten af ​​Azure Monitor-logfiler og få en dybere analyse af hændelser fra et sikkerhedssynspunkt.

Hvis du ikke kun har brug for evnen til at arbejde med logfiler, men et omfattende sikkerhedscenter til din Azure-cloudplatform, inklusive administration af informationssikkerhedspolitik, så kan du tale om behovet for at arbejde med Azure Security Center, hvoraf de fleste af de nyttige funktioner er tilgængelige for nogle penge, for eksempel trusselsdetektion, overvågning uden for Azure, compliance-vurdering osv. (i den gratis version har du kun adgang til en sikkerhedsvurdering og anbefalinger til at fjerne identificerede problemer). Det samler alle sikkerhedsproblemer på ét sted. Faktisk kan vi tale om et højere niveau af informationssikkerhed, end Azure Monitor giver dig, da de data, der indsamles i hele din cloud-fabrik, i dette tilfælde beriges ved hjælp af 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), hvorpå forskellige sofistikerede maskinlærings- og adfærdsanalysealgoritmer er overlejret, hvilket i sidste ende skulle forbedre effektiviteten af ​​at opdage og reagere på trusler .

Azure har også sin egen SIEM - den dukkede op i begyndelsen af ​​2019. Dette er Azure Sentinel, som er afhængig af data fra Azure Monitor og også kan integreres med. eksterne sikkerhedsløsninger (for eksempel NGFW eller WAF), hvis liste er konstant voksende. Derudover har du gennem integrationen af ​​Microsoft Graph Security API mulighed for at forbinde dine egne Threat Intelligence-feeds til Sentinel, hvilket beriger mulighederne for at analysere hændelser i din Azure-sky. Det kan argumenteres for, at Azure Sentinel er den første "native" SIEM, der dukkede op fra cloud-udbydere (den samme Splunk eller ELK, som kan hostes i skyen, for eksempel AWS, er stadig ikke udviklet af traditionelle cloud-tjenesteudbydere). Azure Sentinel og Security Center kunne kaldes SOC for Azure-skyen og kunne begrænses til dem (med visse forbehold), hvis du ikke længere havde nogen infrastruktur, og du overførte alle dine computerressourcer til skyen, og det ville være Microsoft cloud Azure.

Men da de indbyggede muligheder i Azure (selv om du har et abonnement på Sentinel) ofte ikke er nok til at overvåge informationssikkerhed og integrere denne proces med andre kilder til sikkerhedshændelser (både cloud og interne), er der en behov for at eksportere de indsamlede data til eksterne systemer, som kan omfatte SIEM. Dette gøres både ved hjælp af API'et og ved hjælp af specielle udvidelser, som i øjeblikket kun er officielt tilgængelige for følgende SIEM'er - Splunk (Azure Monitor Add-On til Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight og ELK. Indtil for nylig var der flere sådanne SIEM'er, men fra 1. juni 2019 stoppede Microsoft med at understøtte Azure Log Integration Tool (AzLog), som i begyndelsen af ​​eksistensen af ​​Azure og i mangel af normal standardisering af arbejdet med logfiler (Azure) Monitor eksisterede ikke engang endnu) gjorde det nemt at integrere ekstern SIEM med Microsoft-skyen. Nu har situationen ændret sig, og Microsoft anbefaler Azure Event Hub-platformen som det vigtigste integrationsværktøj til andre SIEM'er. Mange har allerede implementeret en sådan integration, men vær forsigtig - de fanger måske ikke alle Azure-logfiler, men kun nogle (se i dokumentationen til din SIEM).

Som afslutning på en kort udflugt til Azure, vil jeg gerne give en generel anbefaling om denne cloud-tjeneste - før du siger noget om informationssikkerhedsovervågningsfunktionerne i Azure, bør du konfigurere dem meget omhyggeligt og teste, at de fungerer som skrevet i dokumentationen og som konsulenterne fortalte dig Microsoft (og de kan have forskellige syn på funktionaliteten af ​​Azure-funktioner). Hvis du har de økonomiske ressourcer, kan du presse en masse nyttig information ud fra Azure i forhold til overvågning af informationssikkerhed. Hvis dine ressourcer er begrænsede, vil du, som i tilfældet med AWS, kun skulle stole på din egen styrke og de rådata, som Azure Monitor giver dig. Og husk, at mange overvågningsfunktioner koster penge, og det er bedre at sætte sig ind i prispolitikken på forhånd. For eksempel kan du gratis gemme 31 dages data op til et maksimum på 5 GB pr. kunde - overskridelse af disse værdier vil kræve, at du betaler ekstra penge (ca. $2+ for at gemme hver ekstra GB fra kunden og $0,1 for lagring af 1 GB hver ekstra måned). Arbejde med applikationstelemetri og målinger kan også kræve yderligere midler, samt arbejde med advarsler og meddelelser (en vis grænse er gratis tilgængelig, som måske ikke er nok til dine behov).

Eksempel: Informationssikkerhedsovervågning i IaaS baseret på Google Cloud Platform

Google Cloud Platform ligner en ung i forhold til AWS og Azure, men dette er til dels godt. I modsætning til AWS, der gradvist øgede sine muligheder, herunder sikkerhedsfunktioner, havde problemer med centralisering; GCP er ligesom Azure meget bedre styret centralt, hvilket reducerer fejl og implementeringstid på tværs af virksomheden. Fra et sikkerhedssynspunkt er GCP mærkeligt nok mellem AWS og Azure. Han har også en enkelt begivenhedsregistrering for hele organisationen, men den er ufuldstændig. Nogle funktioner er stadig i beta-tilstand, men gradvist bør denne mangel elimineres, og GCP vil blive en mere moden platform med hensyn til informationssikkerhedsovervågning.

Hovedværktøjet til at logge hændelser i GCP er Stackdriver Logging (svarende til Azure Monitor), som giver dig mulighed for at indsamle hændelser på tværs af hele din cloud-infrastruktur (såvel som fra AWS). Fra et sikkerhedsperspektiv i GCP har hver organisation, projekt eller mappe fire logfiler:

• Admin Activity - indeholder alle hændelser relateret til administrativ adgang, for eksempel oprettelse af en virtuel maskine, ændring af adgangsrettigheder osv. Denne log skrives altid, uanset dit ønske, og gemmer dens data i 400 dage.
• Dataadgang - indeholder alle hændelser relateret til arbejde med data af cloud-brugere (oprettelse, ændring, læsning osv.). Som standard skrives denne log ikke, da dens volumen svulmer meget hurtigt. Af denne grund er dens holdbarhed kun 30 dage. Derudover er ikke alt skrevet i dette blad. For eksempel skrives begivenheder relateret til ressourcer, der er offentligt tilgængelige for alle brugere, eller som er tilgængelige uden at logge på GCP, ikke til den.
• Systemhændelse - indeholder systemhændelser, der ikke er relateret til brugere, eller handlinger fra en administrator, der ændrer konfigurationen af ​​cloud-ressourcer. Det er altid skrevet og gemt i 400 dage.
• Access Transparency er et unikt eksempel på en log, der fanger alle handlinger fra Google-medarbejdere (men endnu ikke for alle GCP-tjenester), som får adgang til din infrastruktur som en del af deres jobopgaver. Denne log gemmes i 400 dage og er ikke tilgængelig for alle GCP-klienter, men kun hvis en række betingelser er opfyldt (enten Guld- eller Platinniveau-support eller tilstedeværelsen af ​​4 roller af en bestemt type som en del af virksomhedssupport). En lignende funktion er også tilgængelig for eksempel i Office 365 - Lockbox.

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

Adgang til disse logfiler er mulig på flere måder (på nogenlunde samme måde som tidligere omtalt Azure og AWS) - gennem Log Viewer-grænsefladen, gennem API'et, gennem Google Cloud SDK eller gennem aktivitetssiden for dit projekt, som du er interesseret i arrangementer. På samme måde kan de eksporteres til eksterne løsninger for yderligere analyse. Sidstnævnte gøres ved at eksportere logfiler til BigQuery eller Cloud Pub/Sub-lager.

Udover Stackdriver Logging tilbyder GCP-platformen også Stackdriver Monitoring-funktionalitet, som giver dig mulighed for at overvåge nøglemålinger (ydeevne, MTBF, overordnet helbred osv.) for cloud-tjenester og applikationer. Bearbejdede og visualiserede data kan gøre det nemmere at finde problemer i din cloud-infrastruktur, herunder i forbindelse med sikkerhed. Men det skal bemærkes, at denne funktionalitet ikke vil være særlig rig i forbindelse med informationssikkerhed, da GCP i dag ikke har en analog til den samme AWS GuardDuty og ikke kan identificere dårlige blandt alle registrerede hændelser (Google har udviklet Event Threat Detection, men det er stadig under udvikling i beta, og det er for tidligt at tale om dets anvendelighed). Stackdriver-overvågning kunne bruges som et system til at opdage anomalier, som derefter ville blive undersøgt for at finde årsagerne til deres forekomst. Men i betragtning af manglen på personale, der er kvalificeret inden for GCP-informationssikkerhed på markedet, ser denne opgave i øjeblikket vanskelig ud.

Det er også værd at give en liste over nogle informationssikkerhedsmoduler, der kan bruges i din GCP-sky, og som ligner, hvad AWS tilbyder:

• Cloud Security Command Center er en analog af AWS Security Hub og Azure Security Center.
• Cloud DLP - Automatisk opdagelse og redigering (f.eks. maskering) af data hostet i skyen ved hjælp af mere end 90 foruddefinerede klassifikationspolitikker.
• Cloud Scanner er en scanner for kendte sårbarheder (XSS, Flash Injection, upatchede biblioteker osv.) i App Engine, Compute Engine og Google Kubernetes.
• Cloud IAM - Styr adgang til alle GCP-ressourcer.
• Cloud Identity - Administrer GCP-bruger-, enheds- og applikationskonti fra en enkelt konsol.
• Cloud HSM - beskyttelse af kryptografiske nøgler.
• Cloud Key Management Service - administration af kryptografiske nøgler i GCP.
• VPC Service Control - Opret 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, der kan sendes til BigQuery-lageret til analyse eller eksport til andre systemer, herunder SIEM. Som nævnt ovenfor er GCP en aktivt udviklende platform, og Google udvikler nu en række nye informationssikkerhedsmoduler til sin platform. Blandt dem er Event Threat Detection (nu tilgængelig i beta), som scanner Stackdriver-logfiler på jagt efter spor af uautoriseret aktivitet (analogt med GuardDuty i AWS), eller Policy Intelligence (tilgængelig i alfa), som giver dig mulighed for at udvikle intelligente politikker for adgang til GCP-ressourcer.

Jeg lavede en kort oversigt over de indbyggede overvågningsmuligheder i populære cloud-platforme. Men har du specialister, der er i stand til at arbejde med "rå" IaaS-udbyderlogfiler (ikke alle er klar til at købe de avancerede funktioner i AWS eller Azure eller Google)? Derudover er mange bekendt med ordsproget "tillid, men verificer", som er mere sandt end nogensinde inden for sikkerhed. Hvor meget stoler du på de indbyggede muligheder hos cloud-udbyderen, der sender dig informationssikkerhedsbegivenheder? Hvor meget fokuserer de overhovedet på informationssikkerhed?

Nogle gange er det værd at se på overlay cloud-infrastrukturovervågningsløsninger, der kan supplere indbygget cloud-sikkerhed, og nogle gange er sådanne løsninger den eneste mulighed for at få indsigt i sikkerheden af ​​dine data og applikationer hostet i skyen. Derudover er de simpelthen mere bekvemme, da de påtager sig alle opgaverne med at analysere de nødvendige logfiler, der genereres af forskellige cloud-tjenester fra forskellige cloud-udbydere. Et eksempel på en sådan overlejringsløsning er Cisco Stealthwatch Cloud, som er fokuseret på en enkelt opgave – overvågning af anomalier i informationssikkerheden i cloudmiljøer, herunder ikke kun Amazon AWS, Microsoft Azure og Google Cloud Platform, men også private skyer.

Eksempel: Overvågning af informationssikkerhed ved hjælp af Stealthwatch Cloud

AWS giver en fleksibel computerplatform, men denne fleksibilitet gør det lettere for virksomheder at begå fejl, der fører til sikkerhedsproblemer. Og den delte informationssikkerhedsmodel bidrager kun til dette. Kørsel af software i skyen med ukendte sårbarheder (kendte kan bekæmpes f.eks. af AWS Inspector eller GCP Cloud Scanner), svage adgangskoder, forkerte konfigurationer, insidere osv. Og alt dette afspejles i opførselen af ​​cloud-ressourcer, som kan overvåges af Cisco Stealthwatch Cloud, som er et informationssikkerhedsovervågnings- og angrebsdetekteringssystem. offentlige og private skyer.

En af nøglefunktionerne i Cisco Stealthwatch Cloud er evnen til at modellere enheder. Med det kan du oprette en softwaremodel (det vil sige en simulering næsten i realtid) af hver af dine cloud-ressourcer (det er lige meget, 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 autoskaleringsgrupper. Disse modeller bruger strukturerede datastrømme leveret af cloud-tjenester som input. For AWS vil disse for eksempel være VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda og AWS IAM. Enhedsmodellering opdager automatisk rollen og adfærden for enhver af dine ressourcer (du kan tale om profilering af al skyaktivitet). Disse roller omfatter Android- eller Apple-mobilenhed, Citrix PVS-server, RDP-server, mail-gateway, VoIP-klient, terminalserver, domænecontroller osv. Den overvåger derefter løbende deres adfærd for at afgøre, hvornår risikabel eller sikkerhedstruende adfærd opstår. Du kan identificere adgangskodegætning, DDoS-angreb, datalæk, ulovlig fjernadgang, ondsindet kodeaktivitet, sårbarhedsscanning og andre trusler. For eksempel ser det sådan ud at detektere et fjernadgangsforsøg fra et land, der er atypisk for din organisation (Sydkorea) til en Kubernetes-klynge via SSH:

Og sådan ser det påståede læk af information fra Postgress-databasen til et land, som vi ikke tidligere har mødt interaktion med:

Endelig er det sådan, for mange mislykkede SSH-forsøg fra Kina og Indonesien fra en ekstern fjernenhed ser ud:

Eller antag, at serverforekomsten i VPC'en ifølge politik aldrig skal være en fjernlogindestination. Lad os yderligere antage, at denne computer oplevede et fjernlogon på grund af en fejlagtig ændring i firewall-reglerpolitikken. Funktionen Entity Modeling vil registrere 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-kald (inklusive brugernavn, dato og klokkeslæt, blandt andre detaljer ), hvilket foranledigede ændringen af ​​ITU-reglen. Og så kan denne information sendes til SIEM til analyse.

Lignende funktioner er implementeret for ethvert cloudmiljø, der understøttes af Cisco Stealthwatch Cloud:

Enhedsmodellering er en unik form for sikkerhedsautomatisering, der kan afdække et hidtil ukendt problem med dine mennesker, processer eller teknologi. For eksempel giver det dig mulighed for at opdage blandt andet sikkerhedsproblemer som:

• Har nogen opdaget en bagdør i den software, vi bruger?
• Er der tredjepartssoftware eller -enheder i vores sky?
• Misbruger den autoriserede bruger rettigheder?
• Var der en konfigurationsfejl, der tillod fjernadgang eller anden utilsigtet brug af ressourcer?
• Er der et datalæk fra vores servere?
• Prøvede nogen at oprette forbindelse til os fra en atypisk geografisk placering?
• Er vores sky inficeret med ondsindet kode?

En detekteret informationssikkerhedshændelse kan sendes i form af en tilsvarende billet til Slack, Cisco Spark, PagerDuty-hændelsesstyringssystemet og også sendes til forskellige SIEM'er, herunder Splunk eller ELK. For at opsummere kan vi sige, at hvis din virksomhed bruger en multi-cloud-strategi og ikke er begrænset til en enkelt cloud-udbyder, er informationssikkerhedsovervågningsfunktionerne beskrevet ovenfor, så brug af Cisco Stealthwatch Cloud er en god mulighed for at få et samlet sæt overvågning muligheder for de førende cloud-spillere - Amazon, Microsoft og Google. Det mest interessante er, at hvis man sammenligner priserne for Stealthwatch Cloud med avancerede licenser til informationssikkerhedsovervågning i AWS, Azure eller GCP, kan det vise sig, at Cisco-løsningen bliver endnu billigere end de indbyggede muligheder hos Amazon, Microsoft. og Googles løsninger. Det er paradoksalt, men det er sandt. Og jo flere skyer og deres muligheder du bruger, jo mere indlysende vil fordelen ved en konsolideret løsning være.

Derudover kan Stealthwatch Cloud overvåge private skyer implementeret i din organisation, for eksempel baseret på Kubernetes-containere eller ved at overvåge Netflow-flows eller netværkstrafik modtaget gennem spejling i netværksudstyr (selv indenlandsk produceret), AD-data eller DNS-servere og så videre. Alle disse data vil blive beriget med Threat Intelligence-oplysninger indsamlet af Cisco Talos, verdens største ikke-statslige gruppe af cybersikkerhedstrusler.

Dette giver dig mulighed for at implementere et samlet overvågningssystem for både offentlige og hybride skyer, som din virksomhed måtte bruge. Den indsamlede information kan derefter analyseres ved hjælp af Stealthwatch Clouds indbyggede muligheder eller sendes til din SIEM (Splunk, ELK, SumoLogic og flere andre understøttes som standard).

Hermed vil vi færdiggøre første del af artiklen, hvor jeg gennemgik de indbyggede og eksterne værktøjer til overvågning af informationssikkerhed på IaaS/PaaS platforme, som giver os mulighed for hurtigt at detektere og reagere på hændelser, der opstår i cloudmiljøerne, der vores virksomhed har valgt. I anden del vil vi fortsætte emnet og se på muligheder for overvågning af SaaS-platforme ved hjælp af eksemplet med Salesforce og Dropbox, og vi vil også forsøge at opsummere og sætte alt sammen ved at skabe et samlet informationssikkerhedsovervågningssystem for forskellige cloud-udbydere.

Kilde: www.habr.com