Wolk sekuriteitsmonitering

Die skuif van data en toepassings na die wolk bied 'n nuwe uitdaging vir korporatiewe SOC's, wat nie altyd gereed is om ander mense se infrastruktuur te monitor nie. Volgens Netoskope gebruik die gemiddelde onderneming (blykbaar in die VSA) 1246 22 verskillende wolkdienste, wat 1246% meer is as 'n jaar gelede. 175 wolkdienste!!! 170 van hulle hou verband met MH-dienste, 110 hou verband met bemarking, 76 is op die gebied van kommunikasie en 700 is in finansies en CRM. Cisco gebruik “slegs” XNUMX eksterne wolkdienste. So ek is 'n bietjie verward deur hierdie syfers. Maar in elk geval is die probleem nie by hulle nie, maar by die feit dat die wolk redelik aktief begin gebruik word deur 'n toenemende aantal maatskappye wat graag dieselfde vermoëns vir die monitering van wolkinfrastruktuur wil hê as in hul eie netwerk. En hierdie tendens groei - volgens volgens die Amerikaanse Kamer van Rekeninge Teen 2023 gaan 1200 6250 datasentrums in die Verenigde State gesluit wees (XNUMX XNUMX het reeds gesluit). Maar die oorgang na die wolk is nie net "kom ons skuif ons bedieners na 'n eksterne verskaffer nie." Nuwe IT-argitektuur, nuwe sagteware, nuwe prosesse, nuwe beperkings... Dit alles bring aansienlike veranderinge aan die werk van nie net IT nie, maar ook inligtingsekuriteit. En as verskaffers geleer het om op een of ander manier die sekuriteit van die wolk self te verseker (gelukkig is daar baie aanbevelings), dan is daar met wolkinligtingsekuriteitmonitering, veral op SaaS-platforms, aansienlike probleme waaroor ons sal praat.

Kom ons sê jou maatskappy het 'n deel van sy infrastruktuur na die wolk geskuif... Stop. Nie op hierdie manier nie. As die infrastruktuur oorgedra is, en jy dink nou eers oor hoe jy dit gaan monitor, dan het jy reeds verloor. Tensy dit Amazon, Google of Microsoft is (en dan met besprekings), sal jy waarskynlik nie veel vermoë hê om jou data en toepassings te monitor nie. Dit is goed as jy die geleentheid kry om met logs te werk. Soms sal sekuriteitgebeurtenisdata beskikbaar wees, maar jy sal nie toegang daartoe hê nie. Byvoorbeeld, Office 365. As jy die goedkoopste E1-lisensie het, is sekuriteitsgeleenthede glad nie vir jou beskikbaar nie. As jy 'n E3-lisensie het, word jou data vir slegs 90 dae gestoor, en slegs as jy 'n E5-lisensie het, is die duur van die logs vir 'n jaar beskikbaar (dit het egter ook sy eie nuanses wat verband hou met die behoefte om afsonderlik versoek 'n aantal funksies om met logs van Microsoft-ondersteuning te werk). Terloops, die E3-lisensie is baie swakker in terme van moniteringsfunksies as korporatiewe Exchange. Om dieselfde vlak te bereik, benodig jy 'n E5-lisensie of 'n bykomende Gevorderde Voldoeningslisensie, wat dalk bykomende geld vereis wat nie in jou finansiële model ingereken is om na wolkinfrastruktuur te beweeg nie. En dit is net een voorbeeld van onderskatting van kwessies wat verband hou met wolkinligtingsekuriteitmonitering. In hierdie artikel wil ek, sonder om voor te gee dat dit volledig is, die aandag vestig op 'n paar nuanses wat in ag geneem moet word wanneer 'n wolkverskaffer uit 'n sekuriteitsoogpunt gekies word. En aan die einde van die artikel sal 'n kontrolelys gegee word wat die moeite werd is om te voltooi voordat daar in ag geneem word dat die kwessie van monitering van wolkinligtingsekuriteit opgelos is.

Daar is verskeie tipiese probleme wat lei tot voorvalle in wolkomgewings, waarop inligtingsekuriteitsdienste nie tyd het om te reageer nie of dit glad nie sien nie:

• Sekuriteit logs bestaan ​​nie. Dit is 'n redelik algemene situasie, veral onder beginnerspelers in die wolkoplossingsmark. Maar jy moet hulle nie dadelik opgee nie. Klein spelers, veral huishoudelikes, is meer sensitief vir klante se vereistes en kan vinnig sommige vereiste funksies implementeer deur die goedgekeurde padkaart vir hul produkte te verander. Ja, dit sal nie 'n analoog van GuardDuty van Amazon of die "Proactive Protection"-module van Bitrix wees nie, maar ten minste iets.
• Inligtingsekuriteit weet nie waar die logs gestoor word nie of daar is geen toegang daartoe nie. Hier is dit nodig om met die wolkdiensverskaffer te onderhandel – miskien sal hy sulke inligting verskaf as hy die kliënt vir hom betekenisvol ag. Maar oor die algemeen is dit nie baie goed as toegang tot logs "deur spesiale besluit" verskaf word nie.
• Dit gebeur ook dat die wolkverskaffer logs het, maar hulle verskaf beperkte monitering en gebeurtenisopname, wat nie voldoende is om alle voorvalle op te spoor nie. Byvoorbeeld, jy mag slegs logs van veranderinge op 'n webwerf of logs van gebruikerstawingpogings ontvang, maar nie ander gebeurtenisse, soos netwerkverkeer, wat 'n hele laag gebeurtenisse vir jou sal wegsteek wat pogings om jou wolkinfrastruktuur te hack, kenmerk nie.
• Daar is logs, maar toegang daartoe is moeilik om te outomatiseer, wat dwing om dit nie voortdurend gemonitor te word nie, maar volgens 'n skedule. En as jy nie logs outomaties kan aflaai nie, kan die aflaai van logs, byvoorbeeld in Excel-formaat (soos met 'n aantal plaaslike wolkoplossingverskaffers), selfs lei tot 'n onwilligheid by die korporatiewe inligtingsekuriteitsdiens om daarmee te peuter.
• Geen log monitering nie. Dit is miskien die mees onduidelikste rede vir die voorkoms van inligtingsekuriteitsinsidente in wolkomgewings. Dit blyk dat daar logs is, en dit is moontlik om toegang daartoe te outomatiseer, maar niemand doen dit nie. Hoekom?

Gedeelde wolksekuriteitskonsep

Die oorgang na die wolk is altyd 'n soeke na 'n balans tussen die begeerte om beheer oor die infrastruktuur te behou en die oordrag daarvan na die meer professionele hande van 'n wolkverskaffer wat spesialiseer in die instandhouding daarvan. En op die gebied van wolkbeveiliging moet hierdie balans ook gesoek word. Boonop, afhangend van die wolkdiensleweringsmodel wat gebruik word (IaaS, PaaS, SaaS), sal hierdie balans heeltyd anders wees. Ons moet in elk geval onthou dat alle wolkverskaffers vandag die sogenaamde gedeelde verantwoordelikheid en gedeelde inligtingsekuriteitsmodel volg. Die wolk is verantwoordelik vir sommige dinge, en vir ander is die kliënt verantwoordelik om sy data, sy toepassings, sy virtuele masjiene en ander hulpbronne in die wolk te plaas. Dit sal roekeloos wees om te verwag dat ons alle verantwoordelikheid na die verskaffer sal verskuif deur na die wolk te gaan. Maar dit is ook onverstandig om al die sekuriteit self te bou wanneer jy na die wolk beweeg. 'n Balans word vereis, wat van baie faktore sal afhang: - risikobestuurstrategie, bedreigingsmodel, sekuriteitsmeganismes beskikbaar vir die wolkverskaffer, wetgewing, ens.

Byvoorbeeld, die klassifikasie van data wat in die wolk gehuisves word, is altyd die verantwoordelikheid van die kliënt. ’n Wolkverskaffer of ’n eksterne diensverskaffer kan hom net help met gereedskap wat sal help om data in die wolk te merk, oortredings te identifiseer, data wat die wet oortree, uit te vee, of dit met een of ander metode te masker. Aan die ander kant is fisiese sekuriteit altyd die verantwoordelikheid van die wolkverskaffer, wat dit nie met kliënte kan deel nie. Maar alles wat tussen data en fisiese infrastruktuur is, is juis die onderwerp van bespreking in hierdie artikel. Byvoorbeeld, die beskikbaarheid van die wolk is die verantwoordelikheid van die verskaffer, en die opstel van firewall-reëls of die aktivering van enkripsie is die verantwoordelikheid van die kliënt. In hierdie artikel sal ons probeer kyk na watter inligtingsekuriteitmoniteringsmeganismes vandag deur verskeie gewilde wolkverskaffers in Rusland verskaf word, wat die kenmerke van hul gebruik is, en wanneer is dit die moeite werd om na eksterne oorlegoplossings te kyk (byvoorbeeld Cisco E- e-possekuriteit) wat die vermoëns van u wolk in terme van kuberveiligheid uitbrei. In sommige gevalle, veral as jy 'n multi-wolk-strategie volg, sal jy geen ander keuse hê as om eksterne inligtingsekuriteitmoniteringsoplossings in verskeie wolkomgewings gelyktydig te gebruik (byvoorbeeld Cisco CloudLock of Cisco Stealthwatch Cloud). Wel, in sommige gevalle sal jy besef dat die wolkverskaffer wat jy gekies het (of op jou afgedwing het) glad nie enige inligtingsekuriteitsmoniteringsvermoëns bied nie. Dit is onaangenaam, maar ook nie 'n bietjie nie, aangesien dit jou in staat stel om die risikovlak wat verband hou met die werk met hierdie wolk voldoende te assesseer.

Wolk Sekuriteit Monitering Lewensiklus

Om die sekuriteit van die wolke wat jy gebruik te monitor, het jy net drie opsies:

• staatmaak op die gereedskap wat deur jou wolkverskaffer verskaf word,
• gebruik oplossings van derde partye wat die IaaS-, PaaS- of SaaS-platforms wat jy gebruik sal monitor,
• bou jou eie wolkmonitering-infrastruktuur (slegs vir IaaS/PaaS-platforms).

Kom ons kyk watter kenmerke elk van hierdie opsies het. Maar eers moet ons die algemene raamwerk verstaan ​​wat gebruik sal word wanneer wolkplatforms gemonitor word. Ek sal 6 hoofkomponente van die inligtingsekuriteitmoniteringsproses in die wolk uitlig:

• Voorbereiding van infrastruktuur. Bepaling van die nodige toepassings en infrastruktuur vir die versameling van gebeurtenisse wat belangrik is vir inligtingsekuriteit in berging.
• Versameling. Op hierdie stadium word sekuriteitsgebeure uit verskeie bronne saamgevoeg vir daaropvolgende oordrag vir verwerking, berging en ontleding.
• Behandeling. Op hierdie stadium word die data getransformeer en verryk om daaropvolgende ontleding te vergemaklik.
• Berging. Hierdie komponent is verantwoordelik vir korttermyn- en langtermynberging van versamelde verwerkte en rou data.
• Ontleding. Op hierdie stadium het jy die vermoë om insidente op te spoor en outomaties of met die hand daarop te reageer.
• Verslagdoening. Hierdie stadium help om sleutelaanwysers vir belanghebbendes (bestuur, ouditeure, wolkverskaffer, kliënte, ens.) te formuleer wat ons help om sekere besluite te neem, byvoorbeeld om 'n verskaffer te verander of inligtingsekuriteit te versterk.

Om hierdie komponente te verstaan, sal jou in staat stel om vinnig in die toekoms te besluit wat jy van jou verskaffer kan neem, en wat jy self of met die betrokkenheid van eksterne konsultante sal moet doen.

Ingeboude wolkdienste

Ek het reeds hierbo geskryf dat baie wolkdienste vandag geen inligtingsekuriteitmoniteringsvermoëns bied nie. Oor die algemeen gee hulle nie veel aandag aan die onderwerp van inligtingsekuriteit nie. Byvoorbeeld, een van die gewilde Russiese dienste vir die stuur van verslae aan regeringsinstansies via die internet (ek sal nie spesifiek die naam daarvan noem nie). Die hele afdeling oor die sekuriteit van hierdie diens draai om die gebruik van gesertifiseerde CIPF. Die inligtingsekuriteitsafdeling van 'n ander binnelandse wolkdiens vir elektroniese dokumentbestuur is nie anders nie. Dit praat oor publieke sleutelsertifikate, gesertifiseerde kriptografie, die uitskakeling van webkwesbaarhede, beskerming teen DDoS-aanvalle, die gebruik van brandmure, rugsteun en selfs gereelde inligtingsekuriteitoudits. Maar daar is nie 'n woord oor monitering nie, ook nie oor die moontlikheid om toegang te verkry tot inligtingsekuriteitsgebeure wat vir kliënte van hierdie diensverskaffer van belang kan wees nie.

Oor die algemeen, deur die manier waarop die wolkverskaffer inligtingsekuriteitkwessies op sy webwerf en in sy dokumentasie beskryf, kan jy verstaan ​​hoe ernstig hy hierdie kwessie opneem. As jy byvoorbeeld die handleidings vir die "My Office"-produkte lees, is daar glad nie 'n woord oor sekuriteit nie, maar in die dokumentasie vir die aparte produk "My Office. KS3”, wat ontwerp is om teen ongemagtigde toegang te beskerm, is daar 'n gewone lys van punte van die 17de orde van die FSTEC, wat "My Office.KS3" implementeer, maar dit word nie beskryf hoe dit dit implementeer nie en, bowenal, hoe om integreer hierdie meganismes met korporatiewe inligtingsekuriteit. Miskien bestaan ​​sulke dokumentasie, maar ek het dit nie in die publieke domein op die "My Office"-webwerf gekry nie. Alhoewel ek dalk net nie toegang tot hierdie geheime inligting het nie? ..

Vir Bitrix is ​​die situasie baie beter. Die dokumentasie beskryf die formate van die gebeurtenislogboeke en, interessant genoeg, die inbraaklogboek, wat gebeure bevat wat verband hou met potensiële bedreigings vir die wolkplatform. Van daar af kan u die IP, gebruiker- of gasnaam, gebeurtenisbron, tyd, gebruikersagent, gebeurtenistipe, ens. Dit is waar, jy kan met hierdie gebeure werk óf vanaf die beheerpaneel van die wolk self, óf data in MS Excel-formaat oplaai. Dit is nou moeilik om werk met Bitrix-logs te outomatiseer en jy sal van die werk met die hand moet doen (laai die verslag op en laai dit in jou SIEM). Maar as ons onthou dat so 'n geleentheid tot relatief onlangs nie bestaan ​​het nie, dan is dit groot vordering. Terselfdertyd wil ek daarop let dat baie buitelandse wolkverskaffers soortgelyke funksionaliteit "vir beginners" bied - kyk óf na die logs met jou oë deur die beheerpaneel, óf laai die data na jouself op (die meeste laai egter data in . csv-formaat, nie Excel nie).

Sonder om die geen-logs-opsie in ag te neem, bied wolkverskaffers jou gewoonlik drie opsies om sekuriteitsgebeurtenisse te monitor – kontroleskerms, data-oplaai en API-toegang. Dit lyk asof die eerste baie probleme vir jou oplos, maar dit is nie heeltemal waar nie - as jy verskeie tydskrifte het, moet jy wissel tussen die skerms wat hulle vertoon, en die algehele prentjie verloor. Daarbenewens is dit onwaarskynlik dat die wolkverskaffer jou die vermoë sal bied om sekuriteitsgebeurtenisse te korreleer en dit oor die algemeen vanuit 'n sekuriteitsoogpunt te ontleed (gewoonlik het jy te doen met rou data, wat jy self moet verstaan). Daar is uitsonderings en ons sal verder daaroor praat. Ten slotte is dit die moeite werd om te vra watter gebeure deur u wolkverskaffer aangeteken word, in watter formaat, en hoe stem dit ooreen met u inligtingsekuriteitmoniteringsproses? Byvoorbeeld, identifikasie en verifikasie van gebruikers en gaste. Dieselfde Bitrix stel jou in staat om, gebaseer op hierdie gebeurtenisse, die datum en tyd van die gebeurtenis, die naam van die gebruiker of gas (as jy die "Web Analytics"-module het), die voorwerp waartoe toegang verkry is en ander elemente tipies vir 'n webwerf aan te teken. . Maar korporatiewe inligtingsekuriteitsdienste benodig dalk inligting oor of die gebruiker toegang tot die wolk verkry het vanaf 'n vertroude toestel (byvoorbeeld, in 'n korporatiewe netwerk word hierdie taak deur Cisco ISE geïmplementeer). Wat van so 'n eenvoudige taak soos die geo-IP-funksie, wat sal help om te bepaal of 'n wolkdiensgebruikersrekening gesteel is? En selfs al verskaf die wolkverskaffer dit aan jou, is dit nie genoeg nie. Dieselfde Cisco CloudLock ontleed nie net geoligging nie, maar gebruik masjienleer hiervoor en analiseer historiese data vir elke gebruiker en monitor verskeie afwykings in identifikasie- en verifikasiepogings. Slegs MS Azure het soortgelyke funksionaliteit (as jy die toepaslike intekening het).

Daar is nog 'n probleem - aangesien inligtingsekuriteitmonitering vir baie wolkverskaffers 'n nuwe onderwerp is waarmee hulle net begin omgaan, verander hulle voortdurend iets in hul oplossings. Vandag het hulle een weergawe van die API, môre 'n ander, oormôre 'n derde. Hiervoor moet jy ook voorbereid wees. Dieselfde geld met funksionaliteit, wat kan verander, wat in ag geneem moet word in jou inligtingsekuriteitmoniteringstelsel. Amazon het byvoorbeeld aanvanklik aparte wolkgebeurtenismoniteringdienste gehad—AWS CloudTrail en AWS CloudWatch. Toe het 'n aparte diens verskyn om inligtingsekuriteitsgebeure te monitor - AWS GuardDuty. Na 'n ruk het Amazon 'n nuwe bestuurstelsel, Amazon Security Hub, bekendgestel, wat ontleding van data insluit wat ontvang is van GuardDuty, Amazon Inspector, Amazon Macie en verskeie ander. Nog 'n voorbeeld is die Azure log-integrasie-instrument met SIEM - AzLog. Dit is aktief deur baie SIEM-verskaffers gebruik, totdat Microsoft in 2018 die staking van sy ontwikkeling en ondersteuning aangekondig het, wat baie kliënte wat hierdie hulpmiddel gebruik het, met 'n probleem gekonfronteer het (ons sal later praat oor hoe dit opgelos is).

Monitor dus noukeurig al die moniteringskenmerke wat jou wolkverskaffer jou bied. Of maak staat op eksterne oplossingverskaffers wat as tussengangers sal optree tussen jou SOC en die wolk wat jy wil monitor. Ja, dit sal duurder wees (hoewel nie altyd nie), maar jy sal al die verantwoordelikheid op iemand anders se skouers afskuif. Of nie alles nie? .. Kom ons onthou die konsep van gedeelde sekuriteit en verstaan ​​dat ons niks kan verskuif nie - ons sal onafhanklik moet verstaan ​​hoe verskillende wolkverskaffers monitering van die inligtingsekuriteit van jou data, toepassings, virtuele masjiene en ander hulpbronne verskaf in die wolk gehuisves. En ons begin met wat Amazon in hierdie deel bied.

Voorbeeld: Inligtingsekuriteitsmonitering in IaaS gebaseer op AWS

Ja, ja, ek verstaan ​​dat Amazon nie die beste voorbeeld is nie as gevolg van die feit dat dit 'n Amerikaanse diens is en dit kan geblokkeer word as deel van die stryd teen ekstremisme en die verspreiding van inligting wat in Rusland verbied word. Maar in hierdie publikasie wil ek net wys hoe verskillende wolkplatforms verskil in hul inligtingsekuriteitmoniteringvermoëns en waaraan jy moet let wanneer jy jou sleutelprosesse vanuit 'n sekuriteitsoogpunt na die wolke oordra. Wel, as sommige van die Russiese ontwikkelaars van wolkoplossings iets nuttigs vir hulself leer, dan sal dit wonderlik wees.

Die eerste ding om te sê is dat Amazon nie 'n ondeurdringbare vesting is nie. Verskeie voorvalle gebeur gereeld met sy kliënte. Byvoorbeeld, die name, adresse, geboortedatums en telefoonnommers van 198 miljoen kiesers is van Deep Root Analytics gesteel. Israeliese maatskappy Nice Systems het 14 miljoen rekords van Verizon-intekenare gesteel. AWS se ingeboude vermoëns laat jou egter toe om 'n wye reeks insidente op te spoor. Byvoorbeeld:

• impak op infrastruktuur (DDoS)
• nodus kompromie (opdrag inspuiting)
• rekening kompromie en ongemagtigde toegang
• verkeerde konfigurasie en kwesbaarhede
• onveilige koppelvlakke en API's.

Hierdie teenstrydigheid is te wyte aan die feit dat, soos ons hierbo uitgevind het, die kliënt self verantwoordelik is vir die sekuriteit van klantdata. En as hy nie die moeite gedoen het om beskermingsmeganismes aan te skakel nie en nie moniteringsinstrumente aangeskakel het nie, dan sal hy net van die voorval uit die media of van sy kliënte leer.

Om voorvalle te identifiseer, kan jy 'n wye reeks verskillende moniteringsdienste gebruik wat deur Amazon ontwikkel is (hoewel dit dikwels aangevul word deur eksterne nutsmiddels soos osquery). Dus, in AWS word alle gebruikeraksies gemonitor, ongeag hoe dit uitgevoer word - deur die bestuurskonsole, opdragreël, SDK of ander AWS-dienste. Alle rekords van elke AWS-rekening se aktiwiteit (insluitend gebruikernaam, aksie, diens, aktiwiteitparameters en resultaat) en API-gebruik is beskikbaar deur AWS CloudTrail. U kan hierdie gebeurtenisse (soos AWS IAM-konsole-aanmeldings) vanaf die CloudTrail-konsole bekyk, dit ontleed met behulp van Amazon Athena, of dit “uitkontrakteer” na eksterne oplossings soos Splunk, AlienVault, ens. Die AWS CloudTrail-logs self word in jou AWS S3-emmer geplaas.

Twee ander AWS-dienste bied 'n aantal ander belangrike moniteringsvermoëns. Eerstens, Amazon CloudWatch is 'n moniteringsdiens vir AWS-hulpbronne en -toepassings wat jou onder andere toelaat om verskeie afwykings in jou wolk te identifiseer. Alle ingeboude AWS-dienste, soos Amazon Elastic Compute Cloud (bedieners), Amazon Relational Database Service (databasisse), Amazon Elastic MapReduce (data-analise), en 30 ander Amazon-dienste, gebruik Amazon CloudWatch om hul logs te stoor. Ontwikkelaars kan die oop API van Amazon CloudWatch gebruik om log-monitering-funksionaliteit by pasgemaakte toepassings en dienste te voeg, wat hulle in staat stel om die omvang van gebeurtenisanalise binne 'n sekuriteitskonteks uit te brei.

Tweedens laat die VPC Flow Logs-diens jou toe om die netwerkverkeer wat deur jou AWS-bedieners (ekstern of intern) gestuur of ontvang word, sowel as tussen mikrodienste te ontleed. Wanneer enige van jou AWS VPC-hulpbronne met die netwerk interaksie het, teken VPC Flow Logs besonderhede oor die netwerkverkeer aan, insluitend die bron- en bestemmingnetwerkkoppelvlak, sowel as die IP-adresse, poorte, protokol, aantal grepe en aantal pakkies wat jy gesien het. Diegene wat ervaar is met plaaslike netwerksekuriteit sal dit erken as analoog aan drade NetFlow, wat geskep kan word deur skakelaars, routers en ondernemingsgraad-firewalls. Hierdie logs is belangrik vir inligtingsekuriteitmonitering, want anders as gebeure oor die aksies van gebruikers en toepassings, laat hulle jou ook toe om nie netwerkinteraksies in die AWS virtuele private wolkomgewing te mis nie.

Samevattend bied hierdie drie AWS-dienste—AWS CloudTrail, Amazon CloudWatch en VPC Flow Logs—saam redelike kragtige insig in jou rekeninggebruik, gebruikersgedrag, infrastruktuurbestuur, toepassing- en diensaktiwiteit en netwerkaktiwiteit. Hulle kan byvoorbeeld gebruik word om die volgende afwykings op te spoor:

• Pogings om die webwerf te skandeer, soek na agterdeure, soek na kwesbaarhede deur sarsies van "404-foute".
• Inspuitingsaanvalle (byvoorbeeld SQL-inspuiting) deur sarsies van "500 foute".
• Bekende aanvalnutsmiddels is sqlmap, nikto, w3af, nmap, ens. deur ontleding van die Gebruikersagent-veld.

Amazon Web Services het ook ander dienste vir kuberveiligheidsdoeleindes ontwikkel wat jou toelaat om baie ander probleme op te los. Byvoorbeeld, AWS het 'n ingeboude diens vir ouditbeleide en konfigurasies - AWS Config. Hierdie diens bied deurlopende ouditering van u AWS-hulpbronne en hul konfigurasies. Kom ons neem 'n eenvoudige voorbeeld: Kom ons sê jy wil seker maak dat gebruikerswagwoorde op al jou bedieners gedeaktiveer is en dat toegang slegs moontlik is op grond van sertifikate. AWS Config maak dit maklik om dit vir al jou bedieners na te gaan. Daar is ander beleide wat op jou wolkbedieners toegepas kan word: “Geen bediener kan poort 22 gebruik nie”, “Slegs administrateurs kan brandmuurreëls verander” of “Slegs gebruiker Ivashko kan nuwe gebruikersrekeninge skep, en hy kan dit net op Dinsdae doen. " In die somer van 2016 is die AWS Config-diens uitgebrei om die opsporing van oortredings van ontwikkelde beleide te outomatiseer. AWS Config Reëls is in wese deurlopende konfigurasieversoeke vir die Amazon-dienste wat jy gebruik, wat gebeure genereer as die ooreenstemmende beleide oortree word. Byvoorbeeld, in plaas daarvan om AWS Config-navrae gereeld te laat loop om te verifieer dat alle skywe op 'n virtuele bediener geïnkripteer is, kan AWS Config-reëls gebruik word om deurlopend bedienerskywe na te gaan om te verseker dat aan hierdie voorwaarde voldoen word. En, die belangrikste, in die konteks van hierdie publikasie genereer enige oortredings gebeurtenisse wat deur jou inligtingsekuriteitsdiens ontleed kan word.

AWS het ook sy ekwivalent aan tradisionele korporatiewe inligtingsekuriteitsoplossings, wat ook sekuriteitsgebeurtenisse genereer wat jy kan en moet ontleed:

• Intrusion Detection - AWS GuardDuty
• Inligtinglekbeheer - AWS Macie
• EDR (alhoewel dit 'n bietjie vreemd oor eindpunte in die wolk praat) - AWS Cloudwatch + open source osquery of GRR-oplossings
• Netvloei-analise - AWS Cloudwatch + AWS VPC Flow
• DNS-analise - AWS Cloudwatch + AWS Route53
• AD - AWS-gidsdiens
• Rekeningbestuur - AWS IAM
• SSO - AWS SSO
• sekuriteitsanalise - AWS Inspekteur
• konfigurasiebestuur - AWS Config
• WAF - AWS WAF.

Ek sal nie alle Amazon-dienste wat nuttig kan wees in die konteks van inligtingsekuriteit in detail beskryf nie. Die belangrikste ding is om te verstaan ​​dat almal van hulle gebeurtenisse kan genereer wat ons kan en behoort te ontleed in die konteks van inligtingsekuriteit, en gebruik vir hierdie doel beide die ingeboude vermoëns van Amazon self en eksterne oplossings, byvoorbeeld SIEM, wat kan neem sekuriteitsgebeurtenisse na jou moniteringsentrum en ontleed dit daar saam met gebeure van ander wolkdienste of van interne infrastruktuur, omtrek of mobiele toestelle.

In elk geval, dit begin alles by die databronne wat jou voorsien van inligtingsekuriteitsgebeure. Hierdie bronne sluit in, maar is nie beperk nie tot:

• CloudTrail - API-gebruik en gebruikersaksies
• Trusted Advisor - sekuriteitskontrole teen beste praktyke
• Config - voorraad en konfigurasie van rekeninge en diensinstellings
• VPC Flow Logs - verbindings met virtuele koppelvlakke
• IAM - identifikasie en verifikasie diens
• ELB Toegang Logs - Load Balancer
• Inspekteur - toepassings kwesbaarhede
• S3 - lêerberging
• CloudWatch - Toepassingsaktiwiteit
• SNS is 'n kennisgewingdiens.

Amazon, terwyl dit so 'n reeks gebeurtenisbronne en gereedskap vir hul generasie bied, is baie beperk in sy vermoë om die versamelde data in die konteks van inligtingsekuriteit te ontleed. U sal die beskikbare logboeke onafhanklik moet bestudeer, op soek na relevante aanwysers van kompromie daarin. AWS Security Hub, wat Amazon onlangs van stapel gestuur het, poog om hierdie probleem op te los deur 'n wolk-SIEM vir AWS te word. Maar tot dusver is dit net aan die begin van sy reis en word dit beperk deur beide die aantal bronne waarmee dit werk en deur ander beperkings wat deur die argitektuur en subskripsies van Amazon self vasgestel is.

Voorbeeld: Inligtingsekuriteitsmonitering in IaaS gebaseer op Azure

Ek wil nie 'n lang debat voer oor watter van die drie wolkverskaffers (Amazon, Microsoft of Google) beter is nie (veral aangesien elkeen van hulle steeds sy eie spesifieke besonderhede het en geskik is om sy eie probleme op te los); Kom ons fokus op die inligtingsekuriteitmoniteringsvermoëns wat hierdie spelers bied. Daar moet erken word dat Amazon AWS een van die eerstes in hierdie segment was en daarom die verste gevorder het wat sy inligtingsekuriteitsfunksies betref (hoewel baie erken dat dit moeilik is om te gebruik). Maar dit beteken nie dat ons die geleenthede wat Microsoft en Google ons bied, sal ignoreer nie.

Microsoft-produkte is nog altyd deur hul "openheid" onderskei en in Azure is die situasie soortgelyk. Byvoorbeeld, as AWS en GCP altyd uitgaan van die konsep van "wat nie toegelaat word nie, is verbode", dan het Azure presies die teenoorgestelde benadering. Byvoorbeeld, wanneer 'n virtuele netwerk in die wolk en 'n virtuele masjien daarin geskep word, is alle poorte en protokolle oop en by verstek toegelaat. Daarom sal u 'n bietjie meer moeite moet spandeer aan die aanvanklike opstelling van die toegangsbeheerstelsel in die wolk van Microsoft. En dit stel ook strenger vereistes aan u ten opsigte van monitering van aktiwiteit in die Azure-wolk.

AWS het 'n eienaardigheid wat verband hou met die feit dat wanneer jy jou virtuele hulpbronne monitor, as hulle in verskillende streke geleë is, jy probleme ondervind om alle gebeurtenisse en hul verenigde ontleding te kombineer, om uit te skakel wat jy na verskeie truuks moet toevlug, soos Skep jou eie kode vir AWS Lambda wat gebeure tussen streke sal vervoer. Azure het nie hierdie probleem nie - sy aktiwiteitslogmeganisme volg alle aktiwiteit oor die hele organisasie sonder beperkings. Dieselfde geld vir AWS Security Hub, wat onlangs deur Amazon ontwikkel is om baie sekuriteitsfunksies binne 'n enkele sekuriteitsentrum te konsolideer, maar slegs binne sy streek, wat egter nie vir Rusland relevant is nie. Azure het sy eie sekuriteitsentrum, wat nie deur streeksbeperkings gebonde is nie, wat toegang bied tot al die sekuriteitskenmerke van die wolkplatform. Boonop kan dit vir verskillende plaaslike spanne sy eie stel beskermende vermoëns verskaf, insluitend sekuriteitsgebeurtenisse wat deur hulle bestuur word. AWS Security Hub is steeds op pad om soortgelyk aan Azure Security Center te word. Maar dit is die moeite werd om 'n vlieg in die salf by te voeg - jy kan baie uit Azure druk van wat voorheen in AWS beskryf is, maar dit word die mees gerieflike slegs gedoen vir Azure AD, Azure Monitor en Azure Security Center. Alle ander Azure-sekuriteitsmeganismes, insluitend sekuriteitsgebeurtenisontleding, word nog nie op die gerieflikste manier bestuur nie. Die probleem word gedeeltelik opgelos deur die API, wat alle Microsoft Azure-dienste deurdring, maar dit sal bykomende moeite van jou verg om jou wolk met jou SOC te integreer en die teenwoordigheid van gekwalifiseerde spesialiste (in werklikheid, soos met enige ander SIEM wat met wolk werk API's). Sommige SIEM's, wat later bespreek sal word, ondersteun reeds Azure en kan die taak om dit te monitor outomatiseer, maar dit het ook sy eie probleme - nie almal van hulle kan al die logs wat Azure het, versamel nie.

Gebeurtenisversameling en -monitering in Azure word verskaf met behulp van die Azure Monitor-diens, wat die hoofinstrument is vir die versameling, berging en ontleding van data in die Microsoft-wolk en sy hulpbronne - Git-bewaarplekke, houers, virtuele masjiene, toepassings, ens. Alle data wat deur Azure Monitor ingesamel word, word in twee kategorieë verdeel - statistieke, wat intyds ingesamel word en wat sleutelprestasie-aanwysers van die Azure-wolk beskryf, en logs, wat data bevat wat in rekords georganiseer is wat sekere aspekte van die aktiwiteit van Azure-hulpbronne en -dienste kenmerk. Daarbenewens kan die Azure Monitor-diens met behulp van die Data Collector API data van enige REST-bron insamel om sy eie moniteringscenario's te bou.

Hier is 'n paar sekuriteitsgebeurtenisbronne wat Azure jou bied en waartoe jy toegang kan kry deur die Azure Portal, CLI, PowerShell of REST API (en sommige slegs deur die Azure Monitor/Insight API):

• Aktiwiteitslogboeke - hierdie logboek beantwoord die klassieke vrae van "wie", "wat" en "wanneer" met betrekking tot enige skryfbewerking (PUT, POST, DELETE) op wolkbronne. Gebeurtenisse wat verband hou met leestoegang (GET) is nie ingesluit in hierdie logboek nie, soos 'n aantal ander.
• Diagnostiese logs - bevat data oor bedrywighede met 'n spesifieke hulpbron wat by u intekening ingesluit is.
• Azure AD-verslaggewing - bevat beide gebruikersaktiwiteit en stelselaktiwiteit wat verband hou met groep- en gebruikersbestuur.
• Windows Event Log en Linux Syslog - bevat gebeurtenisse vanaf virtuele masjiene wat in die wolk gehuisves word.
• Metrieke - bevat telemetrie oor die werkverrigting en gesondheidstatus van jou wolkdienste en hulpbronne. Elke minuut gemeet en gestoor. binne 30 dae.
• Network Security Group Flow Logs - bevat data oor netwerksekuriteitsgebeurtenisse wat ingesamel is met behulp van die Network Watcher-diens en hulpbronmonitering op netwerkvlak.
• Bergingslogboeke - bevat gebeurtenisse wat verband hou met toegang tot stoorfasiliteite.

Vir monitering kan u eksterne SIEM's of die ingeboude Azure Monitor en sy uitbreidings gebruik. Ons sal later oor inligtingsekuriteitgebeurtenisbestuurstelsels praat, maar kom ons kyk nou eers wat Azure self ons bied vir data-analise in die konteks van sekuriteit. Die hoofskerm vir alles wat met sekuriteit verband hou in Azure Monitor is die Log Analytics Security and Audit Dashboard (die gratis weergawe ondersteun 'n beperkte hoeveelheid gebeurtenisberging vir net een week). Hierdie kontroleskerm is verdeel in 5 hoofareas wat opsommende statistieke visualiseer van wat gebeur in die wolkomgewing wat jy gebruik:

• Sekuriteitsdomeine - sleutel kwantitatiewe aanwysers wat verband hou met inligtingsekuriteit - die aantal insidente, die aantal gekompromitteerde nodusse, onverwerkte nodusse, netwerksekuriteitsgebeurtenisse, ens.
• Noemenswaardige kwessies - vertoon die aantal en belangrikheid van aktiewe inligtingsekuriteitskwessies
• Bespeurings - vertoon patrone van aanvalle wat teen jou gebruik word
• Bedreigingsintelligensie - vertoon geografiese inligting oor eksterne nodusse wat jou aanval
• Algemene sekuriteitsnavrae - tipiese navrae wat jou sal help om jou inligtingsekuriteit beter te monitor.

Azure Monitor-uitbreidings sluit in Azure Key Vault (beskerming van kriptografiese sleutels in die wolk), Malware Assessment (ontleding van beskerming teen kwaadwillige kode op virtuele masjiene), Azure Application Gateway Analytics (ontleding van onder meer wolk-brandmuurlogboeke), ens. . Hierdie instrumente, verryk met sekere reëls vir die verwerking van gebeure, stel jou in staat om verskeie aspekte van die aktiwiteit van wolkdienste, insluitend sekuriteit, te visualiseer en sekere afwykings van werking te identifiseer. Maar, soos dikwels gebeur, vereis enige bykomende funksionaliteit 'n ooreenstemmende betaalde intekening, wat ooreenstemmende finansiële beleggings van u sal vereis, wat u vooraf moet beplan.

Azure het 'n aantal ingeboude bedreigingsmonitering-vermoëns wat geïntegreer is in Azure AD, Azure Monitor en Azure Security Center. Onder hulle, byvoorbeeld, opsporing van interaksie van virtuele masjiene met bekende kwaadwillige IP's (as gevolg van die teenwoordigheid van integrasie met Threat Intelligence-dienste van Microsoft), opsporing van wanware in die wolkinfrastruktuur deur alarms te ontvang van virtuele masjiene wat in die wolk gehuisves word, wagwoord raai aanvalle ” op virtuele masjiene, kwesbaarhede in die konfigurasie van die gebruiker-identifikasiestelsel, aanmeld by die stelsel vanaf anonimiseerders of besmette nodusse, rekeninglekkasies, aanmeld by die stelsel vanaf ongewone liggings, ens. Azure is vandag een van die min wolkverskaffers wat jou ingeboude bedreigingsintelligensie-vermoëns bied om versamelde inligtingsekuriteitsgebeure te verryk.

Soos hierbo genoem, is die sekuriteitsfunksionaliteit en, gevolglik, die sekuriteitsgebeurtenisse wat daardeur gegenereer word, nie gelyk vir alle gebruikers beskikbaar nie, maar vereis 'n sekere intekening wat die funksionaliteit insluit wat u benodig, wat die toepaslike gebeurtenisse vir inligtingsekuriteitsmonitering genereer. Byvoorbeeld, sommige van die funksies wat in die vorige paragraaf beskryf is vir die monitering van afwykings in rekeninge is slegs beskikbaar in die P2-premielisensie vir die Azure AD-diens. Daarsonder sal jy, soos in die geval van AWS, die versamelde sekuriteitsgebeurtenisse "handmatig" moet ontleed. En ook, afhangende van die tipe Azure AD-lisensie, sal nie alle gebeurtenisse vir ontleding beskikbaar wees nie.

Op die Azure-portaal kan jy beide soeknavrae bestuur vir logboeke wat vir jou belangstel en kontroleskerms opstel om sleutelinligtingsekuriteitsaanwysers te visualiseer. Daarbenewens kan u daar Azure Monitor-uitbreidings kies, wat u toelaat om die funksionaliteit van Azure Monitor-logboeke uit te brei en 'n dieper ontleding van gebeure vanuit 'n sekuriteitsoogpunt te kry.

As jy nie net die vermoë nodig het om met logs te werk nie, maar ook 'n omvattende sekuriteitsentrum vir jou Azure-wolkplatform, insluitend inligtingsekuriteitbeleidbestuur, dan kan jy praat oor die behoefte om met Azure Security Center te werk, waarvan die meeste nuttige funksies is beskikbaar vir 'n bietjie geld, byvoorbeeld bedreigingsopsporing, monitering buite Azure, voldoeningsbeoordeling, ens. (in die gratis weergawe het u slegs toegang tot 'n sekuriteitsbeoordeling en aanbevelings om geïdentifiseerde probleme uit te skakel). Dit konsolideer alle sekuriteitskwessies op een plek. Trouens, ons kan praat oor 'n hoër vlak van inligtingsekuriteit as wat Azure Monitor jou bied, aangesien in hierdie geval die data wat deur jou wolkfabriek ingesamel word, verryk word met baie bronne, soos Azure, Office 365, Microsoft CRM aanlyn, Microsoft Dynamics AX , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) en Microsoft Security Response Centre (MSRC), waarop verskeie gesofistikeerde masjienleer- en gedragsanalise-algoritmes gesuperponeer is, wat uiteindelik die doeltreffendheid van die opsporing en reaksie op bedreigings behoort te verbeter .

Azure het ook sy eie SIEM - dit het aan die begin van 2019 verskyn. Dit is Azure Sentinel, wat staatmaak op data van Azure Monitor en kan ook integreer met. eksterne sekuriteitsoplossings (byvoorbeeld NGFW of WAF), waarvan die lys voortdurend groei. Daarbenewens, deur die integrasie van die Microsoft Graph Security API, het jy die vermoë om jou eie Threat Intelligence-feeds aan Sentinel te koppel, wat die vermoëns verryk om insidente in jou Azure-wolk te ontleed. Daar kan aangevoer word dat Azure Sentinel die eerste “inheemse” SIEM is wat van wolkverskaffers verskyn het (dieselfde Splunk of ELK, wat in die wolk gehuisves kan word, byvoorbeeld AWS, word steeds nie deur tradisionele wolkdiensverskaffers ontwikkel nie). Azure Sentinel en Sekuriteitsentrum kan SOC genoem word vir die Azure-wolk en kan daartoe beperk word (met sekere voorbehoude) as jy nie meer enige infrastruktuur gehad het nie en jy al jou rekenaarhulpbronne na die wolk oorgedra het en dit sou die Microsoft-wolk Azure wees.

Maar aangesien die ingeboude vermoëns van Azure (selfs al het jy 'n intekening op Sentinel) dikwels nie genoeg is vir die doeleindes van die monitering van inligtingsekuriteit en die integrasie van hierdie proses met ander bronne van sekuriteitsgebeurtenisse (beide wolk en intern), is daar 'n nodig het om die versamelde data uit te voer na eksterne stelsels, wat SIEM kan insluit. Dit word gedoen met beide die API en met spesiale uitbreidings, wat tans amptelik slegs vir die volgende SIEM's beskikbaar is - Splunk (Azure Monitor-byvoeging vir Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight en ELK. Tot onlangs was daar meer sulke SIEM's, maar vanaf 1 Junie 2019 het Microsoft opgehou om die Azure Log Integration Tool (AzLog) te ondersteun, wat aan die begin van die bestaan ​​van Azure en in die afwesigheid van normale standaardisering van werk met logs (Azure) Monitor het nog nie eers bestaan ​​nie) het dit maklik gemaak om eksterne SIEM met die Microsoft-wolk te integreer. Nou het die situasie verander en Microsoft beveel die Azure Event Hub-platform aan as die hoofintegrasie-instrument vir ander SIEM's. Baie het reeds sulke integrasie geïmplementeer, maar wees versigtig - hulle sal dalk nie alle Azure-logboeke vaslê nie, maar net sommige (kyk in die dokumentasie vir jou SIEM).

Ter afsluiting van 'n kort uitstappie na Azure, wil ek 'n algemene aanbeveling oor hierdie wolkdiens gee - voordat jy iets sê oor die inligtingsekuriteitmoniteringfunksies in Azure, moet jy dit baie noukeurig konfigureer en toets dat hulle werk soos geskryf in die dokumentasie en soos die konsultante vir jou gesê het Microsoft (en hulle kan verskillende sienings oor die funksionaliteit van Azure-funksies hê). As jy die finansiële hulpbronne het, kan jy baie nuttige inligting uit Azure uitdruk in terme van inligtingsekuriteitmonitering. As u hulpbronne beperk is, sal u, soos in die geval van AWS, slegs moet staatmaak op u eie krag en die rou data wat Azure Monitor u verskaf. En onthou dat baie moniteringsfunksies geld kos en dit is beter om jouself vooraf met die prysbeleid te vergewis. Byvoorbeeld, jy kan gratis 31 dae se data stoor tot 'n maksimum van 5 GB per kliënt - as jy hierdie waardes oorskry, sal jy bykomende geld moet opdok (ongeveer $2+ vir die stoor van elke bykomende GB van die kliënt en $0,1 vir stoor 1 GB elke bykomende maand ). Werk met toepassingstelemetrie en -metriek kan ook bykomende fondse vereis, sowel as om met waarskuwings en kennisgewings te werk ('n sekere limiet is gratis beskikbaar, wat dalk nie genoeg is vir jou behoeftes nie).

Voorbeeld: Inligtingsekuriteitmonitering in IaaS gebaseer op Google Wolkplatform

Google Cloud Platform lyk soos 'n jongeling in vergelyking met AWS en Azure, maar dit is deels goed. Anders as AWS, wat sy vermoëns, insluitend sekuriteitsselle, geleidelik vergroot het, met probleme met sentralisasie; GCP, soos Azure, word baie beter sentraal bestuur, wat foute en implementeringstyd oor die hele onderneming verminder. Vanuit 'n sekuriteitsoogpunt is GCP, vreemd genoeg, tussen AWS en Azure. Hy het ook 'n enkele geleentheidregistrasie vir die hele organisasie, maar dit is onvolledig. Sommige funksies is steeds in beta-modus, maar hierdie tekortkoming moet geleidelik uitgeskakel word en GCP sal 'n meer volwasse platform word in terme van inligtingsekuriteitmonitering.

Die hoofinstrument vir die aanteken van gebeure in GCP is Stackdriver Logging (soortgelyk aan Azure Monitor), wat jou toelaat om gebeurtenisse oor jou hele wolkinfrastruktuur (sowel as vanaf AWS) te versamel. Vanuit 'n sekuriteitsperspektief in GCP het elke organisasie, projek of gids vier logs:

• Admin-aktiwiteit - bevat alle gebeurtenisse wat verband hou met administratiewe toegang, byvoorbeeld die skep van 'n virtuele masjien, die verandering van toegangsregte, ens. Hierdie logboek word altyd geskryf, ongeag jou begeerte, en stoor sy data vir 400 dae.
• Datatoegang - bevat alle gebeurtenisse wat verband hou met die werk met data deur wolkgebruikers (skepping, wysiging, lees, ens.). By verstek word hierdie logboek nie geskryf nie, aangesien die volume daarvan baie vinnig swel. Om hierdie rede is die raklewe daarvan slegs 30 dae. Boonop word nie alles in hierdie tydskrif geskryf nie. Gebeurtenisse wat verband hou met hulpbronne wat publiek toeganklik is vir alle gebruikers of wat toeganklik is sonder om by GCP aan te meld, word byvoorbeeld nie daaraan geskryf nie.
• Stelselgebeurtenis - bevat stelselgebeurtenisse wat nie met gebruikers verband hou nie, of aksies van 'n administrateur wat die opstelling van wolkhulpbronne verander. Dit word altyd geskryf en vir 400 dae gestoor.
• Access Transparency is 'n unieke voorbeeld van 'n logboek wat alle handelinge van Google-werknemers vaslê (maar nog nie vir alle GCP-dienste nie) wat toegang tot jou infrastruktuur het as deel van hul werkspligte. Hierdie logboek word vir 400 dae gestoor en is nie vir elke GCP-kliënt beskikbaar nie, maar slegs as 'n aantal voorwaardes nagekom word (óf Goud- of Platinumvlak-ondersteuning, of die teenwoordigheid van 4 rolle van 'n sekere tipe as deel van korporatiewe ondersteuning). 'n Soortgelyke funksie is ook beskikbaar, byvoorbeeld, in Office 365 - Lockbox.

Log voorbeeld: Toegang Deursigtigheid

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

Toegang tot hierdie logs is op verskeie maniere moontlik (op dieselfde manier as wat voorheen bespreek is Azure en AWS) - deur die Log Viewer-koppelvlak, deur die API, deur die Google Wolk SDK, of deur die Aktiwiteitbladsy van jou projek waarvoor jy stel belang in geleenthede. Op dieselfde manier kan hulle na eksterne oplossings uitgevoer word vir bykomende ontleding. Laasgenoemde word gedoen deur logs na BigQuery of Cloud Pub/Sub-berging uit te voer.

Benewens Stackdriver Logging, bied die GCP-platform ook Stackdriver-monitering-funksionaliteit, waarmee u sleutelmaatstawwe (prestasie, MTBF, algehele gesondheid, ens.) van wolkdienste en toepassings kan monitor. Verwerkte en gevisualiseerde data kan dit makliker maak om probleme in jou wolkinfrastruktuur te vind, insluitend in die konteks van sekuriteit. Maar daar moet kennis geneem word dat hierdie funksionaliteit nie baie ryk sal wees in die konteks van inligtingsekuriteit nie, aangesien GCP vandag nie 'n analoog van dieselfde AWS GuardDuty het nie en nie slegtes onder alle geregistreerde gebeurtenisse kan identifiseer nie (Google het Event Threat Detection ontwikkel, maar dit is nog onder ontwikkeling in beta en dit is te vroeg om oor die bruikbaarheid daarvan te praat). Stackdriver-monitering kan gebruik word as 'n stelsel om afwykings op te spoor, wat dan ondersoek sal word om die oorsake van hul voorkoms te vind. Maar gegewe die gebrek aan personeel wat gekwalifiseer is op die gebied van GCP-inligtingsekuriteit in die mark, lyk hierdie taak tans moeilik.

Dit is ook die moeite werd om 'n lys te gee van sommige inligtingsekuriteitsmodules wat binne jou GCP-wolk gebruik kan word, en wat soortgelyk is aan wat AWS bied:

• Cloud Security Command Center is 'n analoog van AWS Security Hub en Azure Security Center.
• Wolk DLP - Outomatiese ontdekking en redigering (bv. maskering) van data wat in die wolk gehuisves word deur meer as 90 voorafbepaalde klassifikasiebeleide te gebruik.
• Wolkskandeerder is 'n skandeerder vir bekende kwesbaarhede (XSS, Flash Injection, unpatched biblioteke, ens.) in App Engine, Compute Engine en Google Kubernetes.
• Wolk IAM - Beheer toegang tot alle GCP hulpbronne.
• Wolkidentiteit - Bestuur GCP-gebruiker-, toestel- en toepassingrekeninge vanaf 'n enkele konsole.
• Wolk HSM - beskerming van kriptografiese sleutels.
• Wolksleutelbestuurdiens - bestuur van kriptografiese sleutels in GCP.
• VPC Service Control - Skep 'n veilige omtrek rondom jou GCP-hulpbronne om hulle teen lekkasies te beskerm.
• Titan-sekuriteitsleutel - beskerming teen uitvissing.

Baie van hierdie modules genereer sekuriteitsgebeurtenisse wat na BigQuery-berging gestuur kan word vir ontleding of uitvoer na ander stelsels, insluitend SIEM. Soos hierbo genoem, is GCP 'n aktief ontwikkelende platform en Google ontwikkel nou 'n aantal nuwe inligtingsekuriteitsmodules vir sy platform. Onder hulle is Event Threat Detection (nou beskikbaar in beta), wat Stackdriver-logboeke skandeer op soek na spore van ongemagtigde aktiwiteit (analoog aan GuardDuty in AWS), of Policy Intelligence (beskikbaar in alfa), wat jou sal toelaat om intelligente beleide te ontwikkel vir toegang tot GCP-hulpbronne.

Ek het 'n kort oorsig gemaak van die ingeboude moniteringsvermoëns in gewilde wolkplatforms. Maar het jy spesialiste wat met “rou” IaaS-verskafferlogboeke kan werk (nie almal is gereed om die gevorderde vermoëns van AWS of Azure of Google te koop nie)? Daarbenewens is baie vertroud met die spreekwoord "vertrou, maar verifieer," wat waar as ooit tevore op die gebied van sekuriteit is. Hoeveel vertrou jy die ingeboude vermoëns van die wolkverskaffer wat vir jou inligtingsekuriteitsgebeure stuur? Hoeveel fokus hulle enigsins op inligtingsekuriteit?

Soms is dit die moeite werd om te kyk na oplossings vir monitering van wolkinfrastruktuur wat ingeboude wolksekuriteit kan aanvul, en soms is sulke oplossings die enigste opsie om insig te kry in die sekuriteit van jou data en toepassings wat in die wolk gehuisves word. Boonop is dit eenvoudig meer gerieflik, aangesien hulle al die take opneem om die nodige logs wat deur verskillende wolkdienste van verskillende wolkverskaffers gegenereer word, te ontleed. 'n Voorbeeld van so 'n oorlegoplossing is Cisco Stealthwatch Cloud, wat op 'n enkele taak gefokus is - die monitering van inligtingsekuriteitsafwykings in wolkomgewings, insluitend nie net Amazon AWS, Microsoft Azure en Google Cloud Platform nie, maar ook private wolke.

Voorbeeld: Monitering van inligtingsekuriteit met behulp van Stealthwatch Cloud

AWS bied 'n buigsame rekenaarplatform, maar hierdie buigsaamheid maak dit makliker vir maatskappye om foute te maak wat tot sekuriteitskwessies lei. En die gedeelde inligtingsekuriteitsmodel dra net hiertoe by. Om sagteware in die wolk te laat loop met onbekende kwesbaarhede (bekendes kan bekamp word, byvoorbeeld deur AWS Inspector of GCP Wolkskandeerder), swak wagwoorde, verkeerde konfigurasies, insiders, ens. En dit alles word weerspieël in die gedrag van wolkbronne, wat gemonitor kan word deur Cisco Stealthwatch Cloud, wat 'n inligtingsekuriteitmonitering- en aanvalopsporingstelsel is. openbare en private wolke.

Een van die belangrikste kenmerke van Cisco Stealthwatch Cloud is die vermoë om entiteite te modelleer. Daarmee kan u 'n sagtewaremodel (dit wil sê 'n byna-intydse simulasie) van elkeen van u wolkbronne skep (dit maak nie saak of dit AWS, Azure, GCP of iets anders is nie). Dit kan bedieners en gebruikers insluit, sowel as hulpbrontipes spesifiek vir jou wolkomgewing, soos sekuriteitsgroepe en outoskaalgroepe. Hierdie modelle gebruik gestruktureerde datastrome wat deur wolkdienste as insette verskaf word. Byvoorbeeld, vir AWS sal dit VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda en AWS IAM wees. Entiteitsmodellering ontdek outomaties die rol en gedrag van enige van jou hulpbronne (jy kan praat oor die profilering van alle wolkaktiwiteite). Hierdie rolle sluit in Android- of Apple-mobiele toestel, Citrix PVS-bediener, RDP-bediener, e-pospoort, VoIP-kliënt, terminaalbediener, domeinbeheerder, ens. Dit monitor dan voortdurend hul gedrag om te bepaal wanneer riskante of veiligheidsbedreigende gedrag voorkom. U kan wagwoordraai, DDoS-aanvalle, datalekkasies, onwettige afstandtoegang, kwaadwillige kode-aktiwiteit, kwesbaarheidskandering en ander bedreigings identifiseer. Dit is byvoorbeeld hoe die opsporing van 'n afstandtoegangpoging vanaf 'n land wat nie tipies is vir jou organisasie (Suid-Korea) na 'n Kubernetes-kluster via SSH lyk:

En dit is hoe die beweerde lek van inligting uit die Postgress-databasis na 'n land lyk waarmee ons nie voorheen interaksie teëgekom het nie:

Ten slotte, dit is hoe te veel mislukte SSH-pogings van China en Indonesië vanaf 'n eksterne afgeleë toestel lyk:

Of veronderstel dat die bedienerinstansie in die VPC, volgens beleid, nooit 'n afgeleë aanmeldbestemming moet wees nie. Kom ons neem verder aan dat hierdie rekenaar 'n afstandaanmelding ervaar het as gevolg van 'n foutiewe verandering in die firewall-reëlsbeleid. Die Entiteitsmodellering-kenmerk sal hierdie aktiwiteit ("Ongewone Afstandtoegang") byna intyds opspoor en rapporteer en na die spesifieke AWS CloudTrail, Azure Monitor of GCP Stackdriver Logging API-oproep wys (insluitend gebruikersnaam, datum en tyd, onder andere besonderhede wat die verandering aan die ITU-reël veroorsaak het. En dan kan hierdie inligting na SIEM gestuur word vir ontleding.

Soortgelyke vermoëns word geïmplementeer vir enige wolkomgewing wat deur Cisco Stealthwatch Cloud ondersteun word:

Entiteitsmodellering is 'n unieke vorm van sekuriteitsoutomatisering wat 'n voorheen onbekende probleem met jou mense, prosesse of tegnologie kan ontbloot. Dit laat jou byvoorbeeld toe om onder andere sekuriteitsprobleme op te spoor soos:

• Het iemand 'n agterdeur ontdek in die sagteware wat ons gebruik?
• Is daar enige derdeparty sagteware of toestel in ons wolk?
• Misbruik die gemagtigde gebruiker regte?
• Was daar 'n konfigurasiefout wat afstandtoegang of ander onbedoelde gebruik van hulpbronne toegelaat het?
• Is daar 'n datalek vanaf ons bedieners?
• Het iemand probeer om met ons in verbinding te tree vanaf 'n atipiese geografiese ligging?
• Is ons wolk met kwaadwillige kode besmet?

'n Bespeurde inligtingsekuriteitsgebeurtenis kan in die vorm van 'n ooreenstemmende kaartjie na Slack, Cisco Spark, die PagerDuty-voorvalbestuurstelsel gestuur word, en ook na verskeie SIEM's gestuur word, insluitend Splunk of ELK. Om op te som, kan ons sê dat as u onderneming 'n multi-wolk-strategie gebruik en nie beperk is tot enige enkele wolkverskaffer nie, die inligtingsekuriteitmoniteringsvermoëns hierbo beskryf, dan is die gebruik van Cisco Stealthwatch Cloud 'n goeie opsie om 'n verenigde stel monitering te kry vermoëns vir die voorste wolkspelers - Amazon, Microsoft en Google. Die interessantste ding is dat as jy die pryse vir Stealthwatch Cloud vergelyk met gevorderde lisensies vir inligtingsekuriteitmonitering in AWS, Azure of GCP, kan dit blyk dat die Cisco-oplossing selfs goedkoper sal wees as die ingeboude vermoëns van Amazon, Microsoft en Google-oplossings. Dit is paradoksaal, maar dit is waar. En hoe meer wolke en hul vermoëns jy gebruik, hoe duideliker sal die voordeel van 'n gekonsolideerde oplossing wees.

Boonop kan Stealthwatch Cloud private wolke monitor wat in jou organisasie ontplooi word, byvoorbeeld, gebaseer op Kubernetes-houers of deur Netflow-vloeie of netwerkverkeer wat ontvang word, te monitor deur middel van spieëling in netwerktoerusting (selfs binnelands vervaardig), AD-data of DNS-bedieners ensovoorts. Al hierdie data sal verryk word met Threat Intelligence-inligting wat ingesamel is deur Cisco Talos, die wêreld se grootste nie-regeringsgroep kuberveiligheidsbedreigingsnavorsers.

Dit stel u in staat om 'n verenigde moniteringstelsel te implementeer vir beide openbare en hibriede wolke wat u onderneming kan gebruik. Die versamelde inligting kan dan ontleed word met behulp van Stealthwatch Cloud se ingeboude vermoëns of na jou SIEM gestuur word (Splunk, ELK, SumoLogic en verskeie ander word by verstek ondersteun).

Hiermee voltooi ons die eerste deel van die artikel, waarin ek die ingeboude en eksterne gereedskap vir die monitering van inligtingsekuriteit van IaaS/PaaS-platforms nagegaan het, wat ons in staat stel om vinnig op te spoor en te reageer op voorvalle wat in die wolkomgewings voorkom wat ons onderneming gekies het. In die tweede deel gaan ons voort met die onderwerp en kyk na opsies vir die monitering van SaaS-platforms deur die voorbeeld van Salesforce en Dropbox te gebruik, en ons sal ook probeer om alles op te som en saam te stel deur 'n verenigde inligtingsekuriteitmoniteringstelsel vir verskillende wolkverskaffers te skep.

Bron: will.com