Skysikkerhetsovervåking

Å flytte data og applikasjoner til skyen gir en ny utfordring for bedriftens SOC-er, som ikke alltid er klare til å overvåke andres infrastruktur. I følge Netoskope bruker gjennomsnittlig bedrift (tilsynelatende i USA) 1246 forskjellige skytjenester, som er 22 % mer enn for ett år siden. 1246 skytjenester!!! 175 av dem er relatert til HR-tjenester, 170 er relatert til markedsføring, 110 er innen kommunikasjon og 76 er innen finans og CRM. Cisco bruker «bare» 700 eksterne skytjenester. Så jeg er litt forvirret over disse tallene. Men problemet ligger uansett ikke hos dem, men i at skyen begynner å bli ganske aktivt brukt av et økende antall selskaper som gjerne vil ha samme muligheter for overvåking av skyinfrastruktur som i sitt eget nettverk. Og denne trenden vokser – iflg ifølge American Chamber of Accounts Innen 2023 skal 1200 datasentre stenges i USA (6250 har allerede stengt). Men overgangen til skyen er ikke bare "la oss flytte serverne våre til en ekstern leverandør." Ny IT-arkitektur, ny programvare, nye prosesser, nye begrensninger... Alt dette medfører betydelige endringer i arbeidet med ikke bare IT, men også informasjonssikkerhet. Og hvis leverandører har lært å på en eller annen måte takle å sikre sikkerheten til selve skyen (heldigvis er det mange anbefalinger), så med overvåking av skyinformasjonssikkerhet, spesielt på SaaS-plattformer, er det betydelige vanskeligheter, som vi vil snakke om.

La oss si at bedriften din har flyttet en del av infrastrukturen til skyen... Stopp. Ikke på denne måten. Hvis infrastrukturen er overført, og du først nå tenker på hvordan du skal overvåke den, så har du allerede tapt. Med mindre det er Amazon, Google eller Microsoft (og da med reservasjoner), vil du sannsynligvis ikke ha mye mulighet til å overvåke dataene og applikasjonene dine. Det er bra om du får muligheten til å jobbe med logger. Noen ganger vil sikkerhetshendelsesdata være tilgjengelige, men du vil ikke ha tilgang til dem. For eksempel Office 365. Hvis du har den billigste E1-lisensen, er sikkerhetshendelser ikke tilgjengelige for deg i det hele tatt. Hvis du har en E3-lisens, lagres dataene dine i bare 90 dager, og bare hvis du har en E5-lisens er varigheten av loggene tilgjengelig i ett år (dette har imidlertid også sine egne nyanser knyttet til behovet for separat be om en rekke funksjoner for å jobbe med logger fra Microsofts kundestøtte). E3-lisensen er for øvrig mye svakere når det gjelder overvåkingsfunksjoner enn bedriftsbørsen. For å oppnå samme nivå trenger du en E5-lisens eller en ekstra Advanced Compliance-lisens, som kan kreve ekstra penger som ikke ble tatt med i din økonomiske modell for å flytte til skyinfrastruktur. Og dette er bare ett eksempel på undervurdering av problemer knyttet til overvåking av skyinformasjonssikkerhet. I denne artikkelen, uten å late som om jeg er fullstendig, vil jeg trekke oppmerksomhet til noen nyanser som bør tas i betraktning når du velger en skyleverandør fra et sikkerhetssynspunkt. Og på slutten av artikkelen vil det bli gitt en sjekkliste som er verdt å fylle ut før man vurderer at problemet med overvåking av skyinformasjonssikkerhet er løst.

Det er flere typiske problemer som fører til hendelser i skymiljøer, som informasjonssikkerhetstjenester ikke har tid til å svare på eller ikke ser dem i det hele tatt:

• Sikkerhetslogger eksisterer ikke. Dette er en ganske vanlig situasjon, spesielt blant nybegynnere i skyløsningsmarkedet. Men du bør ikke gi opp dem med en gang. Små aktører, spesielt innenlandske, er mer følsomme for kundenes krav og kan raskt implementere noen nødvendige funksjoner ved å endre det godkjente veikartet for produktene deres. Ja, dette vil ikke være en analog av GuardDuty fra Amazon eller "Proactive Protection"-modulen fra Bitrix, men i det minste noe.
• Informasjonssikkerhet vet ikke hvor loggene er lagret eller det er ikke tilgang til dem. Her er det nødvendig å gå i forhandlinger med skytjenesteleverandøren – kanskje vil han gi slik informasjon dersom han anser klienten som viktig for ham. Men generelt er det ikke veldig bra når tilgang til logger gis "ved spesiell beslutning."
• Det hender også at skyleverandøren har logger, men de gir begrenset overvåking og hendelsesregistrering, som ikke er tilstrekkelig til å oppdage alle hendelser. For eksempel kan du bare motta logger over endringer på et nettsted eller logger over brukerautentiseringsforsøk, men ikke andre hendelser, for eksempel nettverkstrafikk, som vil skjule for deg et helt lag med hendelser som karakteriserer forsøk på å hacke skyinfrastrukturen din.
• Det er logger, men tilgang til dem er vanskelig å automatisere, noe som tvinger dem til å bli overvåket ikke kontinuerlig, men etter en tidsplan. Og hvis du ikke kan laste ned logger automatisk, kan nedlasting av logger, for eksempel i Excel-format (som med en rekke innenlandske leverandører av skyløsninger), til og med føre til en motvilje fra bedriftens informasjonssikkerhetstjeneste til å fikle med dem.
• Ingen loggovervåking. Dette er kanskje den mest uklare årsaken til forekomsten av informasjonssikkerhetshendelser i skymiljøer. Det ser ut til at det er logger, og det er mulig å automatisere tilgangen til dem, men ingen gjør dette. Hvorfor?

Delt skysikkerhetskonsept

Overgangen til skyen er alltid et søk etter en balanse mellom ønsket om å opprettholde kontroll over infrastrukturen og å overføre den til de mer profesjonelle hendene til en skyleverandør som spesialiserer seg på å vedlikeholde den. Og innen skysikkerhet må denne balansen også søkes. I tillegg, avhengig av skytjenesteleveringsmodellen som brukes (IaaS, PaaS, SaaS), vil denne balansen være forskjellig hele tiden. Uansett må vi huske at alle skyleverandører i dag følger den såkalte delt ansvar og delt informasjonssikkerhetsmodell. Skyen er ansvarlig for noen ting, og for andre er klienten ansvarlig for å plassere sine data, sine applikasjoner, sine virtuelle maskiner og andre ressurser i skyen. Det ville være hensynsløst å forvente at ved å gå til skyen, vil vi flytte alt ansvar til leverandøren. Men det er også uklokt å bygge all sikkerheten selv når du flytter til skyen. Det kreves en balanse, som vil avhenge av mange faktorer: - risikostyringsstrategi, trusselmodell, sikkerhetsmekanismer tilgjengelig for skyleverandøren, lovgivning, etc.

For eksempel er klassifiseringen av data som er vert i skyen alltid kundens ansvar. En skyleverandør eller en ekstern tjenesteleverandør kan bare hjelpe ham med verktøy som vil bidra til å merke data i skyen, identifisere brudd, slette data som bryter loven, eller maskere dem ved hjelp av en eller annen metode. På den annen side er fysisk sikkerhet alltid skyleverandørens ansvar, som den ikke kan dele med klienter. Men alt som er mellom data og fysisk infrastruktur er nettopp gjenstand for diskusjon i denne artikkelen. For eksempel er tilgjengeligheten av skyen leverandørens ansvar, og å sette opp brannmurregler eller aktivere kryptering er klientens ansvar. I denne artikkelen vil vi prøve å se på hvilke overvåkingsmekanismer for informasjonssikkerhet som tilbys i dag av forskjellige populære skyleverandører i Russland, hva er funksjonene ved bruken deres, og når er det verdt å se mot eksterne overleggsløsninger (for eksempel Cisco E- mail Security) som utvider mulighetene til skyen din når det gjelder cybersikkerhet. I noen tilfeller, spesielt hvis du følger en multiskystrategi, vil du ikke ha noe annet valg enn å bruke eksterne overvåkingsløsninger for informasjonssikkerhet i flere skymiljøer samtidig (for eksempel Cisco CloudLock eller Cisco Stealthwatch Cloud). Vel, i noen tilfeller vil du innse at skyleverandøren du har valgt (eller pålagt deg) ikke tilbyr noen overvåkingsmuligheter for informasjonssikkerhet i det hele tatt. Dette er ubehagelig, men heller ikke lite, siden det lar deg vurdere risikonivået som er forbundet med å jobbe med denne skyen tilstrekkelig.

Cloud Security Monitoring Lifecycle

For å overvåke sikkerheten til skyene du bruker, har du bare tre alternativer:

• stole på verktøyene fra skyleverandøren din,
• bruke løsninger fra tredjeparter som vil overvåke IaaS-, PaaS- eller SaaS-plattformene du bruker,
• bygg din egen skyovervåkingsinfrastruktur (kun for IaaS/PaaS-plattformer).

La oss se hvilke funksjoner hvert av disse alternativene har. Men først må vi forstå det generelle rammeverket som vil bli brukt ved overvåking av skyplattformer. Jeg vil fremheve 6 hovedkomponenter i overvåkingsprosessen for informasjonssikkerhet i skyen:

• Klargjøring av infrastruktur. Fastsettelse av nødvendige applikasjoner og infrastruktur for å samle hendelser som er viktige for informasjonssikkerhet til lagring.
• Samling. På dette stadiet blir sikkerhetshendelser aggregert fra ulike kilder for påfølgende overføring for behandling, lagring og analyse.
• Behandling. På dette stadiet blir dataene transformert og beriket for å lette etterfølgende analyse.
• Oppbevaring. Denne komponenten er ansvarlig for kort- og langtidslagring av innsamlede behandlede og rådata.
• Analyse. På dette stadiet har du muligheten til å oppdage hendelser og svare på dem automatisk eller manuelt.
• Rapportering. Dette stadiet bidrar til å formulere nøkkelindikatorer for interessenter (ledelse, revisorer, skyleverandør, kunder, etc.) som hjelper oss å ta bestemte beslutninger, for eksempel å bytte leverandør eller styrke informasjonssikkerheten.

Å forstå disse komponentene vil tillate deg raskt å bestemme i fremtiden hva du kan ta fra leverandøren din, og hva du må gjøre selv eller med involvering av eksterne konsulenter.

Innebygde skytjenester

Jeg skrev allerede ovenfor at mange skytjenester i dag ikke gir noen overvåkingsmuligheter for informasjonssikkerhet. Generelt legger de ikke særlig vekt på temaet informasjonssikkerhet. For eksempel en av de populære russiske tjenestene for å sende rapporter til offentlige etater via Internett (jeg vil ikke spesifikt nevne navnet). Hele delen om sikkerheten til denne tjenesten dreier seg om bruken av sertifisert CIPF. Informasjonssikkerhetsdelen til en annen innenlandsk skytjeneste for elektronisk dokumenthåndtering er ikke annerledes. Den snakker om offentlige nøkkelsertifikater, sertifisert kryptografi, eliminering av nettsårbarheter, beskyttelse mot DDoS-angrep, bruk av brannmurer, sikkerhetskopier og til og med regelmessige informasjonssikkerhetsrevisjoner. Men det er ikke et ord om overvåking, og heller ikke om muligheten for å få tilgang til informasjonssikkerhetshendelser som kan være av interesse for klienter til denne tjenesteleverandøren.

Generelt sett kan du forstå hvor alvorlig den tar dette problemet på den måten skyleverandøren beskriver informasjonssikkerhetsproblemer på nettstedet og i dokumentasjonen. For eksempel, hvis du leser manualene for "My Office"-produktene, står det ikke et ord om sikkerhet i det hele tatt, men i dokumentasjonen for det separate produktet "My Office. KS3", designet for å beskytte mot uautorisert tilgang, er det en vanlig liste over punkter i 17. orden av FSTEC, som "My Office.KS3" implementerer, men det er ikke beskrevet hvordan det implementerer det og, viktigst av alt, hvordan man integrere disse mekanismene med bedriftens informasjonssikkerhet. Kanskje finnes det slik dokumentasjon, men jeg fant den ikke i det offentlige domene på nettstedet "Mitt kontor". Selv om jeg kanskje ikke har tilgang til denne hemmelige informasjonen?

For Bitrix er situasjonen mye bedre. Dokumentasjonen beskriver formatene til hendelsesloggene og interessant nok inntrengingsloggen, som inneholder hendelser relatert til potensielle trusler mot skyplattformen. Derfra kan du hente ut IP, bruker- eller gjestenavn, hendelseskilde, tidspunkt, brukeragent, hendelsestype osv. Riktignok kan du jobbe med disse hendelsene enten fra kontrollpanelet til selve skyen, eller laste opp data i MS Excel-format. Det er nå vanskelig å automatisere arbeid med Bitrix-logger, og du må gjøre noe av arbeidet manuelt (laste opp rapporten og laste den inn i SIEM). Men hvis vi husker at en slik mulighet inntil relativt nylig ikke eksisterte, så er dette stor fremgang. Samtidig vil jeg merke meg at mange utenlandske skyleverandører tilbyr lignende funksjonalitet "for nybegynnere" - enten se på loggene med øynene gjennom kontrollpanelet, eller last opp dataene til deg selv (men de fleste laster opp data i . csv-format, ikke Excel).

Uten å vurdere alternativet uten logger, tilbyr skyleverandører deg vanligvis tre alternativer for å overvåke sikkerhetshendelser - dashbord, dataopplasting og API-tilgang. Det første ser ut til å løse mange problemer for deg, men dette er ikke helt sant - hvis du har flere blader, må du bytte mellom skjermene som viser dem, og mister helhetsbildet. I tillegg er det usannsynlig at skyleverandøren vil gi deg muligheten til å korrelere sikkerhetshendelser og generelt analysere dem fra et sikkerhetssynspunkt (vanligvis har du å gjøre med rådata, som du må forstå selv). Det finnes unntak, og vi vil snakke om dem videre. Til slutt er det verdt å spørre hvilke hendelser som registreres av skyleverandøren din, i hvilket format, og hvordan samsvarer de med overvåkingsprosessen for informasjonssikkerhet? For eksempel identifikasjon og autentisering av brukere og gjester. Den samme Bitrix lar deg, basert på disse hendelsene, registrere dato og klokkeslett for hendelsen, navnet på brukeren eller gjesten (hvis du har "Web Analytics"-modulen), objektet du får tilgang til og andre elementer som er typiske for et nettsted . Men bedriftsinformasjonssikkerhetstjenester kan trenge informasjon om hvorvidt brukeren har tilgang til skyen fra en pålitelig enhet (for eksempel i et bedriftsnettverk implementeres denne oppgaven av Cisco ISE). Hva med en så enkel oppgave som geo-IP-funksjonen, som vil bidra til å avgjøre om en brukerkonto for skytjenester er stjålet? Og selv om skyleverandøren gir deg det, er ikke dette nok. Den samme Cisco CloudLock analyserer ikke bare geolokalisering, men bruker maskinlæring for dette og analyserer historiske data for hver bruker og overvåker ulike anomalier i identifiserings- og autentiseringsforsøk. Bare MS Azure har lignende funksjonalitet (hvis du har riktig abonnement).

Det er en annen vanskelighet – siden for mange skyleverandører er overvåking av informasjonssikkerhet et nytt tema som de akkurat begynner å forholde seg til, endrer de stadig noe i løsningene sine. I dag har de én versjon av API, i morgen en annen, i overmorgen en tredje. Du må også være forberedt på dette. Det samme gjelder funksjonalitet, som kan endres, som må tas i betraktning i ditt overvåkingssystem for informasjonssikkerhet. For eksempel hadde Amazon opprinnelig separate skybegivenhetsovervåkingstjenester – AWS CloudTrail og AWS CloudWatch. Da dukket det opp en egen tjeneste for overvåking av informasjonssikkerhetshendelser – AWS GuardDuty. Etter en tid lanserte Amazon et nytt styringssystem, Amazon Security Hub, som inkluderer analyse av data mottatt fra GuardDuty, Amazon Inspector, Amazon Macie og flere andre. Et annet eksempel er Azure-loggintegrasjonsverktøyet med SIEM - AzLog. Det ble aktivt brukt av mange SIEM-leverandører, inntil Microsoft i 2018 kunngjorde opphør av utviklingen og støtten, noe som konfronterte mange kunder som brukte dette verktøyet med et problem (vi skal snakke om hvordan det ble løst senere).

Overvåk derfor nøye alle overvåkingsfunksjonene som skyleverandøren din tilbyr deg. Eller stol på eksterne løsningsleverandører som vil fungere som mellomledd mellom din SOC og skyen du vil overvåke. Ja, det vil være dyrere (men ikke alltid), men du vil flytte alt ansvaret over på andres skuldre. Eller ikke alt? .. La oss huske konseptet med delt sikkerhet og forstå at vi ikke kan flytte noe - vi må uavhengig forstå hvordan forskjellige skyleverandører gir overvåking av informasjonssikkerheten til dine data, applikasjoner, virtuelle maskiner og andre ressurser vert i skyen. Og vi starter med hva Amazon tilbyr i denne delen.

Eksempel: Informasjonssikkerhetsovervåking i IaaS basert på AWS

Ja, ja, jeg forstår at Amazon ikke er det beste eksemplet på grunn av det faktum at dette er en amerikansk tjeneste og den kan blokkeres som en del av kampen mot ekstremisme og spredning av informasjon som er forbudt i Russland. Men i denne publikasjonen vil jeg bare vise hvordan ulike skyplattformer er forskjellige i sine overvåkingsmuligheter for informasjonssikkerhet og hva du bør være oppmerksom på når du overfører nøkkelprosessene dine til skyene fra et sikkerhetssynspunkt. Vel, hvis noen av de russiske utviklerne av skyløsninger lærer noe nyttig for seg selv, så vil det være flott.

Det første å si er at Amazon ikke er en ugjennomtrengelig festning. Ulike hendelser skjer regelmessig med hans klienter. For eksempel ble navn, adresser, fødselsdato og telefonnumre til 198 millioner velgere stjålet fra Deep Root Analytics. Det israelske selskapet Nice Systems stjal 14 millioner poster med Verizon-abonnenter. AWS sine innebygde funksjoner lar deg imidlertid oppdage et bredt spekter av hendelser. For eksempel:

• innvirkning på infrastruktur (DDoS)
• node kompromiss (kommandeinjeksjon)
• kontokompromittering og uautorisert tilgang
• feil konfigurasjon og sårbarheter
• usikre grensesnitt og APIer.

Dette avviket skyldes at, som vi fant ut ovenfor, kunden selv er ansvarlig for sikkerheten til kundedata. Og hvis han ikke gadd å slå på beskyttelsesmekanismer og ikke slo på overvåkingsverktøy, vil han bare lære om hendelsen fra media eller fra klientene sine.

For å identifisere hendelser kan du bruke et bredt spekter av ulike overvåkingstjenester utviklet av Amazon (selv om disse ofte kompletteres med eksterne verktøy som osquery). Så i AWS overvåkes alle brukerhandlinger, uavhengig av hvordan de utføres - gjennom administrasjonskonsollen, kommandolinjen, SDK eller andre AWS-tjenester. Alle registreringer av hver AWS-kontos aktivitet (inkludert brukernavn, handling, tjeneste, aktivitetsparametere og resultat) og API-bruk er tilgjengelig gjennom AWS CloudTrail. Du kan se disse hendelsene (som AWS IAM-konsollpålogginger) fra CloudTrail-konsollen, analysere dem ved hjelp av Amazon Athena, eller "outsource" dem til eksterne løsninger som Splunk, AlienVault, etc. Selve AWS CloudTrail-loggene plasseres i AWS S3-bøtten din.

To andre AWS-tjenester gir en rekke andre viktige overvåkingsfunksjoner. For det første er Amazon CloudWatch en overvåkingstjeneste for AWS-ressurser og applikasjoner som blant annet lar deg identifisere ulike anomalier i skyen din. Alle innebygde AWS-tjenester, som Amazon Elastic Compute Cloud (servere), Amazon Relational Database Service (databaser), Amazon Elastic MapReduce (dataanalyse) og 30 andre Amazon-tjenester, bruker Amazon CloudWatch til å lagre loggene sine. Utviklere kan bruke det åpne API-et fra Amazon CloudWatch for å legge til loggovervåkingsfunksjonalitet til tilpassede applikasjoner og tjenester, slik at de kan utvide omfanget av hendelsesanalyse innenfor en sikkerhetskontekst.

For det andre lar VPC Flow Logs-tjenesten deg analysere nettverkstrafikken som sendes eller mottas av AWS-serverne dine (eksternt eller internt), så vel som mellom mikrotjenester. Når noen av dine AWS VPC-ressurser samhandler med nettverket, registrerer VPC Flow Logs detaljer om nettverkstrafikken, inkludert kilde- og destinasjonsnettverksgrensesnittet, samt IP-adresser, porter, protokoll, antall byte og antall pakker du sag. De som har erfaring med lokal nettverkssikkerhet vil gjenkjenne dette som analogt med tråder NetFlow, som kan opprettes av svitsjer, rutere og brannmurer av bedriftskvalitet. Disse loggene er viktige for overvåking av informasjonssikkerhet fordi, i motsetning til hendelser om handlingene til brukere og applikasjoner, lar de deg også ikke gå glipp av nettverksinteraksjoner i AWS virtuelle private skymiljø.

Oppsummert gir disse tre AWS-tjenestene – AWS CloudTrail, Amazon CloudWatch og VPC Flow Logs – sammen ganske kraftig innsikt i kontobruken din, brukeratferd, infrastrukturadministrasjon, applikasjons- og tjenesteaktivitet og nettverksaktivitet. De kan for eksempel brukes til å oppdage følgende anomalier:

• Forsøk på å skanne nettstedet, søke etter bakdører, søke etter sårbarheter gjennom utbrudd av "404-feil".
• Injeksjonsangrep (for eksempel SQL-injeksjon) gjennom utbrudd av "500 feil".
• Kjente angrepsverktøy er sqlmap, nikto, w3af, nmap, etc. gjennom analyse av User Agent-feltet.

Amazon Web Services har også utviklet andre tjenester for cybersikkerhetsformål som lar deg løse mange andre problemer. For eksempel har AWS en innebygd tjeneste for revisjonspolicyer og konfigurasjoner - AWS Config. Denne tjenesten gir kontinuerlig revisjon av AWS-ressursene dine og deres konfigurasjoner. La oss ta et enkelt eksempel: La oss si at du vil forsikre deg om at brukerpassord er deaktivert på alle serverne dine og at tilgang kun er mulig basert på sertifikater. AWS Config gjør det enkelt å sjekke dette for alle serverne dine. Det er andre retningslinjer som kan brukes på skyserverne dine: "Ingen server kan bruke port 22", "Bare administratorer kan endre brannmurregler" eller "Bare brukeren Ivashko kan opprette nye brukerkontoer, og han kan gjøre det bare på tirsdager. " Sommeren 2016 ble AWS Config-tjenesten utvidet for å automatisere oppdagelsen av brudd på utviklede retningslinjer. AWS Config Rules er i hovedsak kontinuerlige konfigurasjonsforespørsler for Amazon-tjenestene du bruker, som genererer hendelser hvis de tilsvarende retningslinjene brytes. For eksempel, i stedet for periodisk å kjøre AWS Config-spørringer for å bekrefte at alle disker på en virtuell server er kryptert, kan AWS Config Rules brukes til kontinuerlig å sjekke serverdisker for å sikre at denne betingelsen er oppfylt. Og viktigst av alt, i forbindelse med denne publikasjonen, genererer eventuelle brudd hendelser som kan analyseres av informasjonssikkerhetstjenesten din.

AWS har også sitt tilsvar til tradisjonelle bedriftsinformasjonssikkerhetsløsninger, som også genererer sikkerhetshendelser som du kan og bør analysere:

• Intrusion Detection - AWS GuardDuty
• Informasjonslekkasjekontroll - AWS Macie
• EDR (selv om det snakker om endepunkter i skyen litt merkelig) - AWS Cloudwatch + åpen kildekode 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
• sikkerhetsanalyse - AWS Inspector
• konfigurasjonsadministrasjon - AWS Config
• WAF - AWS WAF.

Jeg vil ikke beskrive i detalj alle Amazon-tjenester som kan være nyttige i forbindelse med informasjonssikkerhet. Hovedsaken er å forstå at alle av dem kan generere hendelser som vi kan og bør analysere i sammenheng med informasjonssikkerhet, ved å bruke for dette formålet både de innebygde egenskapene til Amazon selv og eksterne løsninger, for eksempel SIEM, som kan ta sikkerhetshendelser til overvåkingssenteret ditt og analyser dem der sammen med hendelser fra andre skytjenester eller fra intern infrastruktur, perimeter eller mobile enheter.

Uansett starter det hele med datakildene som gir deg informasjonssikkerhetshendelser. Disse kildene inkluderer, men er ikke begrenset til:

• CloudTrail - API-bruk og brukerhandlinger
• Trusted Advisor - sikkerhetssjekk mot beste praksis
• Config - inventar og konfigurasjon av kontoer og tjenesteinnstillinger
• VPC Flow Logger - tilkoblinger til virtuelle grensesnitt
• IAM - identifikasjon og autentiseringstjeneste
• ELB tilgangslogger - Lastbalanserer
• Inspektør - applikasjonssårbarheter
• S3 - fillagring
• CloudWatch – Applikasjonsaktivitet
• SNS er en varslingstjeneste.

Selv om Amazon tilbyr et slikt utvalg av hendelseskilder og verktøy for deres generasjon, er det svært begrenset i sin evne til å analysere de innsamlede dataene i sammenheng med informasjonssikkerhet. Du må uavhengig studere de tilgjengelige loggene og se etter relevante indikatorer på kompromiss i dem. AWS Security Hub, som Amazon nylig lanserte, har som mål å løse dette problemet ved å bli en sky-SIEM for AWS. Men så langt er det bare i begynnelsen av reisen og er begrenset både av antall kilder den fungerer med og av andre begrensninger etablert av arkitekturen og abonnementene til Amazon selv.

Eksempel: Informasjonssikkerhetsovervåking i IaaS basert på Azure

Jeg ønsker ikke å gå inn i en lang debatt om hvilken av de tre skyleverandørene (Amazon, Microsoft eller Google) som er best (spesielt siden hver av dem fortsatt har sine egne spesifikke detaljer og er egnet for å løse sine egne problemer); La oss fokusere på overvåkingsfunksjonene for informasjonssikkerhet som disse spillerne tilbyr. Det må innrømmes at Amazon AWS var en av de første i dette segmentet og derfor har kommet lengst når det gjelder informasjonssikkerhetsfunksjonene (selv om mange innrømmer at de er vanskelige å bruke). Men dette betyr ikke at vi vil ignorere mulighetene som Microsoft og Google gir oss.

Microsoft-produkter har alltid vært preget av deres "åpenhet", og i Azure er situasjonen lik. For eksempel, hvis AWS og GCP alltid går ut fra konseptet "det som ikke er tillatt er forbudt", så har Azure den stikk motsatte tilnærmingen. For eksempel, når du oppretter et virtuelt nettverk i skyen og en virtuell maskin i den, er alle porter og protokoller åpne og tillatt som standard. Derfor må du bruke litt mer krefter på det første oppsettet av tilgangskontrollsystemet i skyen fra Microsoft. Og dette stiller også strengere krav til deg når det gjelder overvåking av aktivitet i Azure-skyen.

AWS har en særegenhet knyttet til det faktum at når du overvåker de virtuelle ressursene dine, hvis de er lokalisert i forskjellige regioner, har du problemer med å kombinere alle hendelser og deres enhetlige analyse, for å eliminere hvilke du trenger å ty til forskjellige triks, som f.eks. Lag din egen kode for AWS Lambda som skal transportere arrangementer mellom regioner. Azure har ikke dette problemet – aktivitetsloggmekanismen sporer all aktivitet på tvers av hele organisasjonen uten begrensninger. Det samme gjelder AWS Security Hub, som nylig ble utviklet av Amazon for å konsolidere mange sikkerhetsfunksjoner innenfor et enkelt sikkerhetssenter, men kun innenfor sin region, som imidlertid ikke er relevant for Russland. Azure har sitt eget sikkerhetssenter, som ikke er bundet av regionale restriksjoner, og gir tilgang til alle sikkerhetsfunksjonene til skyplattformen. Dessuten kan den for forskjellige lokale lag tilby sitt eget sett med beskyttelsesfunksjoner, inkludert sikkerhetshendelser administrert av dem. AWS Security Hub er fortsatt på vei til å bli lik Azure Security Center. Men det er verdt å legge til en flue i salven - du kan presse ut av Azure mye av det som tidligere er beskrevet i AWS, men dette gjøres mest praktisk bare for Azure AD, Azure Monitor og Azure Security Center. Alle andre Azure-sikkerhetsmekanismer, inkludert analyse av sikkerhetshendelser, er ennå ikke administrert på den mest praktiske måten. Problemet er delvis løst av API-en, som gjennomsyrer alle Microsoft Azure-tjenester, men dette vil kreve ekstra innsats fra deg for å integrere skyen din med SOC-en din og tilstedeværelsen av kvalifiserte spesialister (faktisk, som med alle andre SIEM som fungerer med skyen). APIer). Noen SIEM-er, som vil bli diskutert senere, støtter allerede Azure og kan automatisere oppgaven med å overvåke det, men det har også sine egne vanskeligheter - ikke alle kan samle alle loggene som Azure har.

Innsamling og overvåking av hendelser i Azure leveres ved hjelp av Azure Monitor-tjenesten, som er hovedverktøyet for å samle, lagre og analysere data i Microsoft-skyen og dens ressurser – Git-repositories, containere, virtuelle maskiner, applikasjoner, etc. Alle data som samles inn av Azure Monitor er delt inn i to kategorier - beregninger, samlet inn i sanntid og som beskriver nøkkelytelsesindikatorer for Azure-skyen, og logger, som inneholder data organisert i poster som karakteriserer visse aspekter av aktiviteten til Azure-ressurser og -tjenester. I tillegg, ved å bruke Data Collector API, kan Azure Monitor-tjenesten samle inn data fra enhver REST-kilde for å bygge sine egne overvåkingsscenarier.

Her er noen sikkerhetshendelseskilder som Azure tilbyr deg og som du kan få tilgang til via Azure Portal, CLI, PowerShell eller REST API (og noen bare gjennom Azure Monitor/Insight API):

• Aktivitetslogger - denne loggen svarer på de klassiske spørsmålene "hvem", "hva" og "når" angående enhver skriveoperasjon (PUT, POST, DELETE) på skyressurser. Hendelser knyttet til lesetilgang (GET) er ikke inkludert i denne loggen, som en rekke andre.
• Diagnostiske logger - inneholder data om operasjoner med en bestemt ressurs inkludert i abonnementet ditt.
• Azure AD-rapportering – inneholder både brukeraktivitet og systemaktivitet knyttet til gruppe- og brukeradministrasjon.
• Windows Event Log og Linux Syslog - inneholder hendelser fra virtuelle maskiner som er vert i skyen.
• Beregninger – inneholder telemetri om ytelsen og helsestatusen til skytjenestene og ressursene dine. Målt hvert minutt og lagret. innen 30 dager.
• Nettverkssikkerhetsgruppeflytlogger - inneholder data om nettverkssikkerhetshendelser samlet inn ved hjelp av Network Watcher-tjenesten og ressursovervåking på nettverksnivå.
• Lagringslogger - inneholder hendelser knyttet til tilgang til lagerfasiliteter.

For overvåking kan du bruke eksterne SIEM-er eller den innebygde Azure Monitor og dens utvidelser. Vi skal snakke om hendelsesadministrasjonssystemer for informasjonssikkerhet senere, men la oss nå se hva Azure selv tilbyr oss for dataanalyse i forbindelse med sikkerhet. Hovedskjermen for alt sikkerhetsrelatert i Azure Monitor er Log Analytics Security and Audit Dashboard (gratisversjonen støtter en begrenset mengde hendelseslagring i bare én uke). Dette dashbordet er delt inn i 5 hovedområder som visualiserer oppsummeringsstatistikk over hva som skjer i skymiljøet du bruker:

• Sikkerhetsdomener - nøkkelkvantitative indikatorer knyttet til informasjonssikkerhet - antall hendelser, antall kompromitterte noder, upatchede noder, nettverkssikkerhetshendelser, etc.
• Bemerkelsesverdige problemer - viser antallet og viktigheten av aktive informasjonssikkerhetsproblemer
• Deteksjoner - viser mønstre av angrep brukt mot deg
• Threat Intelligence - viser geografisk informasjon på eksterne noder som angriper deg
• Vanlige sikkerhetsspørringer - typiske spørringer som vil hjelpe deg å bedre overvåke informasjonssikkerheten din.

Azure Monitor-utvidelser inkluderer Azure Key Vault (beskyttelse av kryptografiske nøkler i skyen), Malware Assessment (analyse av beskyttelse mot ondsinnet kode på virtuelle maskiner), Azure Application Gateway Analytics (analyse av blant annet skybrannmurlogger), etc. . Disse verktøyene, beriket med visse regler for behandling av hendelser, lar deg visualisere ulike aspekter av aktiviteten til skytjenester, inkludert sikkerhet, og identifisere visse avvik fra driften. Men som ofte skjer, krever tilleggsfunksjonalitet et tilsvarende betalt abonnement, som vil kreve tilsvarende økonomiske investeringer fra deg, som du må planlegge på forhånd.

Azure har en rekke innebygde trusselovervåkingsfunksjoner som er integrert i Azure AD, Azure Monitor og Azure Security Center. Blant dem, for eksempel, deteksjon av interaksjon av virtuelle maskiner med kjente ondsinnede IP-er (på grunn av tilstedeværelsen av integrasjon med Threat Intelligence-tjenester fra Microsoft), deteksjon av skadelig programvare i skyinfrastrukturen ved å motta alarmer fra virtuelle maskiner som er vert i skyen, passord gjette angrep på virtuelle maskiner, sårbarheter i konfigurasjonen av brukeridentifikasjonssystemet, innlogging på systemet fra anonymiserende eller infiserte noder, kontolekkasjer, innlogging på systemet fra uvanlige steder, etc. Azure er i dag en av få skyleverandører som tilbyr innebygde Threat Intelligence-funksjoner for å berike innsamlede informasjonssikkerhetshendelser.

Som nevnt ovenfor er ikke sikkerhetsfunksjonaliteten og, som et resultat, sikkerhetshendelsene som genereres av den, tilgjengelig for alle brukere likt, men krever et bestemt abonnement som inkluderer funksjonaliteten du trenger, som genererer passende hendelser for informasjonssikkerhetsovervåking. For eksempel er noen av funksjonene beskrevet i forrige avsnitt for overvåking av uregelmessigheter i kontoer kun tilgjengelig i P2 premium-lisensen for Azure AD-tjenesten. Uten det vil du, som i tilfellet med AWS, måtte analysere de innsamlede sikkerhetshendelsene "manuelt". Og, avhengig av typen Azure AD-lisens, vil ikke alle hendelser være tilgjengelige for analyse.

På Azure-portalen kan du administrere både søk etter logger av interesse for deg og sette opp dashbord for å visualisere viktige informasjonssikkerhetsindikatorer. I tillegg kan du der velge Azure Monitor-utvidelser, som lar deg utvide funksjonaliteten til Azure Monitor-logger og få en dypere analyse av hendelser fra et sikkerhetssynspunkt.

Hvis du ikke bare trenger muligheten til å jobbe med logger, men et omfattende sikkerhetssenter for Azure-skyplattformen din, inkludert administrasjon av informasjonssikkerhetspolitikk, kan du snakke om behovet for å jobbe med Azure Security Center, hvor de fleste av de nyttige funksjonene er tilgjengelig for noen penger, for eksempel trusseldeteksjon, overvåking utenfor Azure, samsvarsvurdering, etc. (i gratisversjonen har du kun tilgang til en sikkerhetsvurdering og anbefalinger for å eliminere identifiserte problemer). Den konsoliderer alle sikkerhetsproblemer på ett sted. Faktisk kan vi snakke om et høyere nivå av informasjonssikkerhet enn Azure Monitor gir deg, siden i dette tilfellet blir dataene som samles inn gjennom nettskyfabrikken din beriket med mange kilder, 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), der ulike sofistikerte maskinlærings- og atferdsanalysealgoritmer er lagt over hverandre, noe som til slutt skal forbedre effektiviteten til å oppdage og svare på trusler .

Azure har også sin egen SIEM - den dukket opp i begynnelsen av 2019. Dette er Azure Sentinel, som er avhengig av data fra Azure Monitor og også kan integreres med. eksterne sikkerhetsløsninger (for eksempel NGFW eller WAF), listen over disse vokser stadig. I tillegg, gjennom integreringen av Microsoft Graph Security API, har du muligheten til å koble dine egne Threat Intelligence-feeder til Sentinel, noe som beriker mulighetene for å analysere hendelser i Azure-skyen din. Det kan hevdes at Azure Sentinel er den første "native" SIEM som dukket opp fra skyleverandører (den samme Splunk eller ELK, som kan hostes i skyen, for eksempel AWS, er fortsatt ikke utviklet av tradisjonelle skytjenesteleverandører). Azure Sentinel and Security Center kan kalles SOC for Azure-skyen og kan begrenses til dem (med visse forbehold) hvis du ikke lenger hadde noen infrastruktur og du overførte alle dataressursene dine til skyen, og det ville være Microsoft-skyen Azure.

Men siden de innebygde egenskapene til Azure (selv om du har et abonnement på Sentinel) ofte ikke er nok til å overvåke informasjonssikkerhet og integrere denne prosessen med andre kilder til sikkerhetshendelser (både skyen og interne), er det en trenger å eksportere de innsamlede dataene til eksterne systemer, som kan inkludere SIEM. Dette gjøres både ved hjelp av API og ved hjelp av spesielle utvidelser, som foreløpig kun er offisielt tilgjengelige for følgende SIEM-er - Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight og ELK. Inntil nylig var det flere slike SIEM-er, men fra 1. juni 2019 sluttet Microsoft å støtte Azure Log Integration Tool (AzLog), som ved begynnelsen av eksistensen av Azure og i fravær av normal standardisering av arbeid med logger (Azure) Monitor eksisterte ikke engang ennå) gjorde det enkelt å integrere ekstern SIEM med Microsoft-skyen. Nå har situasjonen endret seg og Microsoft anbefaler Azure Event Hub-plattformen som hovedintegrasjonsverktøy for andre SIEM-er. Mange har allerede implementert en slik integrasjon, men vær forsiktig - de fanger kanskje ikke opp alle Azure-logger, men bare noen (se i dokumentasjonen for din SIEM).

Avsluttende en kort ekskursjon til Azure, vil jeg gi en generell anbefaling om denne skytjenesten - før du sier noe om informasjonssikkerhetsovervåkingsfunksjonene i Azure, bør du konfigurere dem veldig nøye og teste at de fungerer som skrevet i dokumentasjonen og som konsulentene fortalte deg Microsoft (og de kan ha forskjellige syn på funksjonaliteten til Azure-funksjoner). Hvis du har økonomiske ressurser, kan du presse ut mye nyttig informasjon fra Azure når det gjelder overvåking av informasjonssikkerhet. Hvis ressursene dine er begrenset, må du, som i tilfellet med AWS, kun stole på din egen styrke og rådataene som Azure Monitor gir deg. Og husk at mange overvåkingsfunksjoner koster penger og det er bedre å gjøre seg kjent med prispolitikken på forhånd. For eksempel, gratis kan du lagre 31 dager med data opp til maksimalt 5 GB per kunde - overskridelse av disse verdiene vil kreve at du punger ut ekstra penger (omtrent $2+ for å lagre hver ekstra GB fra kunden og $0,1 for lagring av 1 GB hver ekstra måned). Arbeid med applikasjonstelemetri og beregninger kan også kreve ekstra midler, samt arbeid med varsler og varsler (en viss grense er tilgjengelig gratis, som kanskje ikke er nok for dine behov).

Eksempel: Informasjonssikkerhetsovervåking i IaaS basert på Google Cloud Platform

Google Cloud Platform ser ut som en unggutt sammenlignet med AWS og Azure, men dette er delvis bra. I motsetning til AWS, som økte sine evner, inkludert sikkerhet, gradvis, med problemer med sentralisering; GCP, som Azure, administreres mye bedre sentralt, noe som reduserer feil og implementeringstid på tvers av bedriften. Fra et sikkerhetssynspunkt er GCP merkelig nok mellom AWS og Azure. Han har også en enkelt arrangementsregistrering for hele organisasjonen, men den er ufullstendig. Noen funksjoner er fortsatt i betamodus, men gradvis bør denne mangelen elimineres og GCP vil bli en mer moden plattform når det gjelder overvåking av informasjonssikkerhet.

Hovedverktøyet for logging av hendelser i GCP er Stackdriver Logging (ligner på Azure Monitor), som lar deg samle hendelser på tvers av hele skyinfrastrukturen din (så vel som fra AWS). Fra et sikkerhetsperspektiv i GCP har hver organisasjon, prosjekt eller mappe fire logger:

• Admin Activity - inneholder alle hendelser knyttet til administrativ tilgang, for eksempel opprettelse av en virtuell maskin, endring av tilgangsrettigheter, etc. Denne loggen skrives alltid, uavhengig av ditt ønske, og lagrer dataene i 400 dager.
• Datatilgang - inneholder alle hendelser knyttet til arbeid med data av skybrukere (oppretting, modifikasjon, lesing, etc.). Som standard skrives ikke denne loggen, siden volumet svulmer veldig raskt. Av denne grunn er holdbarheten bare 30 dager. Dessuten er ikke alt skrevet i dette bladet. For eksempel skrives ikke hendelser knyttet til ressurser som er offentlig tilgjengelige for alle brukere eller som er tilgjengelige uten å logge på GCP til den.
• Systemhendelse - inneholder systemhendelser som ikke er relatert til brukere, eller handlinger til en administrator som endrer konfigurasjonen av skyressurser. Den er alltid skrevet og lagret i 400 dager.
• Access Transparency er et unikt eksempel på en logg som fanger opp alle handlinger til Google-ansatte (men ennå ikke for alle GCP-tjenester) som har tilgang til infrastrukturen din som en del av jobboppgavene deres. Denne loggen lagres i 400 dager og er ikke tilgjengelig for alle GCP-klienter, men bare hvis en rekke betingelser er oppfylt (enten gull- eller platinanivåstøtte, eller tilstedeværelsen av 4 roller av en bestemt type som en del av bedriftsstøtten). En lignende funksjon er også tilgjengelig for eksempel i Office 365 - Lockbox.

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

Tilgang til disse loggene er mulig på flere måter (på omtrent samme måte som tidligere diskutert Azure og AWS) - gjennom Log Viewer-grensesnittet, gjennom API-en, gjennom Google Cloud SDK, eller gjennom aktivitetssiden til prosjektet ditt som du er interessert i arrangementer. På samme måte kan de eksporteres til eksterne løsninger for tilleggsanalyse. Sistnevnte gjøres ved å eksportere logger til BigQuery eller Cloud Pub/Sub-lagring.

I tillegg til Stackdriver Logging, tilbyr GCP-plattformen også Stackdriver Monitoring-funksjonalitet, som lar deg overvåke nøkkeltall (ytelse, MTBF, generell helse, etc.) for skytjenester og applikasjoner. Behandlet og visualisert data kan gjøre det lettere å finne problemer i skyinfrastrukturen din, inkludert i sikkerhetssammenheng. Men det skal bemerkes at denne funksjonaliteten ikke vil være særlig rik i informasjonssikkerhetssammenheng, siden GCP i dag ikke har en analog av samme AWS GuardDuty og ikke kan identifisere dårlige blant alle registrerte hendelser (Google har utviklet Event Threat Detection, men det er fortsatt under utvikling i beta, og det er for tidlig å snakke om nytten). Stackdriver Monitoring kan brukes som et system for å oppdage anomalier, som deretter vil bli undersøkt for å finne årsakene til at de oppstår. Men gitt mangelen på personell kvalifisert innen GCP-informasjonssikkerhet i markedet, ser denne oppgaven for øyeblikket vanskelig ut.

Det er også verdt å gi en liste over noen informasjonssikkerhetsmoduler som kan brukes i din GCP-sky, og som ligner på det AWS tilbyr:

• Cloud Security Command Center er en analog av AWS Security Hub og Azure Security Center.
• Cloud DLP - Automatisk oppdagelse og redigering (f.eks. maskering) av data som er vert i skyen ved bruk av mer enn 90 forhåndsdefinerte klassifiseringspolicyer.
• Cloud Scanner er en skanner for kjente sårbarheter (XSS, Flash Injection, upatchede biblioteker, etc.) i App Engine, Compute Engine og Google Kubernetes.
• Cloud IAM - Kontroller tilgang til alle GCP-ressurser.
• Cloud Identity - Administrer GCP-bruker-, enhets- og applikasjonskontoer fra én enkelt konsoll.
• Cloud HSM - beskyttelse av kryptografiske nøkler.
• Cloud Key Management Service - administrasjon av kryptografiske nøkler i GCP.
• VPC Service Control - Lag en sikker omkrets rundt GCP-ressursene dine for å beskytte dem mot lekkasjer.
• Titan Security Key - beskyttelse mot phishing.

Mange av disse modulene genererer sikkerhetshendelser som kan sendes til BigQuery-lagring for analyse eller eksport til andre systemer, inkludert SIEM. Som nevnt ovenfor er GCP en aktivt utviklende plattform og Google utvikler nå en rekke nye informasjonssikkerhetsmoduler for sin plattform. Blant dem er Event Threat Detection (nå tilgjengelig i beta), som skanner Stackdriver-logger på jakt etter spor etter uautorisert aktivitet (analogt med GuardDuty i AWS), eller Policy Intelligence (tilgjengelig i alfa), som lar deg utvikle intelligente retningslinjer for tilgang til GCP-ressurser.

Jeg laget en kort oversikt over de innebygde overvåkingsmulighetene i populære skyplattformer. Men har du spesialister som er i stand til å jobbe med «rå» IaaS-leverandørlogger (ikke alle er klare til å kjøpe de avanserte egenskapene til AWS eller Azure eller Google)? I tillegg er mange kjent med ordtaket «tillit, men verifiser», som er sannere enn noen gang innen sikkerhet. Hvor mye stoler du på de innebygde egenskapene til skyleverandøren som sender deg informasjonssikkerhetshendelser? Hvor mye fokuserer de på informasjonssikkerhet i det hele tatt?

Noen ganger er det verdt å se på overvåkingsløsninger for skyinfrastruktur som kan utfylle innebygd skysikkerhet, og noen ganger er slike løsninger det eneste alternativet for å få innsikt i sikkerheten til dine data og applikasjoner som er vert i skyen. I tillegg er de rett og slett mer praktiske, siden de tar på seg alle oppgavene med å analysere de nødvendige loggene generert av forskjellige skytjenester fra forskjellige skyleverandører. Et eksempel på en slik overleggsløsning er Cisco Stealthwatch Cloud, som er fokusert på en enkelt oppgave – overvåking av informasjonssikkerhetsavvik i skymiljøer, inkludert ikke bare Amazon AWS, Microsoft Azure og Google Cloud Platform, men også private skyer.

Eksempel: Informasjonssikkerhetsovervåking ved hjelp av Stealthwatch Cloud

AWS gir en fleksibel dataplattform, men denne fleksibiliteten gjør det lettere for bedrifter å gjøre feil som fører til sikkerhetsproblemer. Og den delte informasjonssikkerhetsmodellen bidrar bare til dette. Kjøre programvare i skyen med ukjente sårbarheter (kjente kan bekjempes, for eksempel av AWS Inspector eller GCP Cloud Scanner), svake passord, feil konfigurasjoner, innsidere, etc. Og alt dette gjenspeiles i oppførselen til skyressurser, som kan overvåkes av Cisco Stealthwatch Cloud, som er et overvåkings- og angrepsdeteksjonssystem for informasjonssikkerhet. offentlige og private skyer.

En av nøkkelfunksjonene til Cisco Stealthwatch Cloud er muligheten til å modellere enheter. Med den kan du lage en programvaremodell (det vil si en simulering i nesten sanntid) av hver av skyressursene dine (det spiller ingen rolle om det er AWS, Azure, GCP eller noe annet). Disse kan inkludere servere og brukere, samt ressurstyper som er spesifikke for skymiljøet ditt, for eksempel sikkerhetsgrupper og automatisk skaleringsgrupper. Disse modellene bruker strukturerte datastrømmer levert av skytjenester 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. Entitetsmodellering oppdager automatisk rollen og oppførselen til alle ressursene dine (du kan snakke om profilering av all skyaktivitet). Disse rollene inkluderer Android- eller Apple-mobilenheter, Citrix PVS-server, RDP-server, e-postgateway, VoIP-klient, terminalserver, domenekontroller, etc. Den overvåker deretter kontinuerlig oppførselen deres for å finne ut når risikofylt eller sikkerhetstruende atferd oppstår. Du kan identifisere passordgjetting, DDoS-angrep, datalekkasjer, ulovlig fjerntilgang, ondsinnet kodeaktivitet, sårbarhetsskanning og andre trusler. For eksempel ser det slik ut å oppdage et eksternt tilgangsforsøk fra et land som er atypisk for organisasjonen din (Sør-Korea) til en Kubernetes-klynge via SSH:

Og slik ser den påståtte lekkasjen av informasjon fra Postgress-databasen til et land som vi ikke tidligere har vært i kontakt med:

Til slutt, dette er hvordan for mange mislykkede SSH-forsøk fra Kina og Indonesia fra en ekstern ekstern enhet ser ut:

Eller anta at serverforekomsten i VPC, ifølge policy, aldri skal være en destinasjon for ekstern pålogging. La oss videre anta at denne datamaskinen opplevde en ekstern pålogging på grunn av en feilaktig endring i retningslinjene for brannmurregler. Entity Modeling-funksjonen vil oppdage og rapportere denne aktiviteten ("Uvanlig fjerntilgang") i nesten sanntid og peke til det spesifikke AWS CloudTrail-, Azure Monitor- eller GCP Stackdriver Logging API-kallet (inkludert brukernavn, dato og klokkeslett, blant andre detaljer ), som førte til endringen av ITU-regelen. Og så kan denne informasjonen sendes til SIEM for analyse.

Lignende funksjoner er implementert for alle skymiljøer som støttes av Cisco Stealthwatch Cloud:

Entitetsmodellering er en unik form for sikkerhetsautomatisering som kan avdekke et tidligere ukjent problem med dine folk, prosesser eller teknologi. For eksempel lar den deg oppdage blant annet sikkerhetsproblemer som:

• Har noen oppdaget en bakdør i programvaren vi bruker?
• Er det noen tredjepartsprogramvare eller -enhet i skyen vår?
• Misbruker den autoriserte brukeren privilegier?
• Var det en konfigurasjonsfeil som tillot ekstern tilgang eller annen utilsiktet bruk av ressurser?
• Er det en datalekkasje fra serverne våre?
• Prøvde noen å koble til oss fra et atypisk geografisk sted?
• Er skyen vår infisert med ondsinnet kode?

En oppdaget informasjonssikkerhetshendelse kan sendes i form av en tilsvarende billett til Slack, Cisco Spark, PagerDuty-hendelsesstyringssystemet, og også sendes til ulike SIEM-er, inkludert Splunk eller ELK. For å oppsummere kan vi si at hvis bedriften din bruker en strategi for flere skyer og ikke er begrenset til én nettskyleverandør, er overvåkingsfunksjonene for informasjonssikkerhet beskrevet ovenfor, og bruk av Cisco Stealthwatch Cloud et godt alternativ for å få et enhetlig sett med overvåking funksjoner for de ledende nettsky-aktørene - Amazon , Microsoft og Google. Det mest interessante er at hvis du sammenligner prisene for Stealthwatch Cloud med avanserte lisenser for informasjonssikkerhetsovervåking i AWS, Azure eller GCP, kan det vise seg at Cisco-løsningen blir enda billigere enn de innebygde egenskapene til Amazon, Microsoft og Google-løsninger. Det er paradoksalt, men det er sant. Og jo flere skyer og deres evner du bruker, desto tydeligere vil fordelen med en konsolidert løsning være.

I tillegg kan Stealthwatch Cloud overvåke private skyer utplassert i organisasjonen din, for eksempel basert på Kubernetes-containere eller ved å overvåke Netflow-flyter eller nettverkstrafikk mottatt gjennom speiling i nettverksutstyr (selv innenlandsprodusert), AD-data eller DNS-servere og så videre. Alle disse dataene vil bli beriket med Threat Intelligence-informasjon samlet inn av Cisco Talos, verdens største ikke-statlige gruppe av cybersikkerhetstrusselforskere.

Dette lar deg implementere et enhetlig overvåkingssystem for både offentlige og hybride skyer som din bedrift kan bruke. Den innsamlede informasjonen kan deretter analyseres ved hjelp av Stealthwatch Clouds innebygde funksjoner eller sendes til SIEM-en din (Splunk, ELK, SumoLogic og flere andre støttes som standard).

Med dette vil vi fullføre den første delen av artikkelen, der jeg gjennomgikk de innebygde og eksterne verktøyene for overvåking av informasjonssikkerhet til IaaS/PaaS-plattformer, som lar oss raskt oppdage og svare på hendelser som oppstår i skymiljøene som vår bedrift har valgt. I den andre delen vil vi fortsette temaet og se på alternativer for overvåking av SaaS-plattformer ved å bruke eksemplet Salesforce og Dropbox, og vi vil også prøve å oppsummere og sette alt sammen ved å lage et enhetlig overvåkingssystem for informasjonssikkerhet for ulike skyleverandører.

Kilde: www.habr.com