Nuba Sekureca Monitorado

Movi datumojn kaj aplikojn al la nubo prezentas novan defion por kompaniaj SOC-oj, kiuj ne ĉiam pretas monitori la infrastrukturon de aliaj homoj. Laŭ Netoskope, la averaĝa entrepreno (ŝajne en Usono) uzas 1246 22 malsamajn nubajn servojn, kio estas 1246% pli ol antaŭ unu jaro. 175 nubaj servoj!!! 170 el ili rilatas al HR-servoj, 110 rilatas al merkatado, 76 estas en la kampo de komunikado kaj 700 estas en financo kaj CRM. Cisco uzas "nur" XNUMX eksterajn nubajn servojn. Do mi estas iom konfuzita de ĉi tiuj nombroj. Sed ĉiukaze, la problemo ne estas ĉe ili, sed pri tio, ke la nubo komencas esti uzata sufiĉe aktive de kreskanta nombro da kompanioj, kiuj ŝatus havi la samajn kapablojn por monitori nuban infrastrukturon kiel en sia propra reto. Kaj ĉi tiu tendenco kreskas - laŭ laŭ la Usona Ĉambro de Kontoj Ĝis 2023, 1200 6250 datumcentroj estos fermitaj en Usono (XNUMX XNUMX jam fermiĝis). Sed la transiro al la nubo ne estas nur "ni movu niajn servilojn al ekstera provizanto." Nova IT-arkitekturo, nova programaro, novaj procezoj, novaj limigoj... Ĉio ĉi alportas signifajn ŝanĝojn al la laboro de ne nur IT, sed ankaŭ informa sekureco. Kaj se provizantoj lernis iel trakti certigi la sekurecon de la nubo mem (feliĉe estas multaj rekomendoj), tiam kun nuba informa sekureco monitorado, precipe sur SaaS-platformoj, estas gravaj malfacilaĵoj, pri kiuj ni parolos.

Ni diru, ke via kompanio movis parton de sia infrastrukturo al la nubo... Ĉesu. Ne tiel. Se la infrastrukturo estis translokigita, kaj vi nur nun pensas pri kiel vi kontrolos ĝin, tiam vi jam perdis. Krom se ĝi estas Amazon, Google aŭ Microsoft (kaj poste kun rezervoj), vi verŝajne ne havos multe da kapablo kontroli viajn datumojn kaj aplikojn. Estas bone, se vi ricevas la ŝancon labori kun ŝtipoj. Kelkfoje sekurecaj eventodatenoj estos disponeblaj, sed vi ne havos aliron al ĝi. Ekzemple, Oficejo 365. Se vi havas la plej malmultekostan E1-licencon, tiam sekurecaj eventoj tute ne haveblas al vi. Se vi havas E3-licencon, viaj datumoj estas konservitaj nur dum 90 tagoj, kaj nur se vi havas E5-licencon, la daŭro de la protokoloj disponeblas por jaro (tamen, ĉi tio ankaŭ havas siajn proprajn nuancojn rilatajn al la bezono aparte peti kelkajn funkciojn por labori kun protokoloj de Microsoft-subteno). Cetere, la E3-licenco estas multe pli malforta laŭ monitoraj funkcioj ol kompania Interŝanĝo. Por atingi la saman nivelon, vi bezonas E5-licencon aŭ kroman Advanced Compliance-licencon, kiu povas postuli plian monon, kiu ne estis enkalkulita en vian financan modelon por translokiĝi al nuba infrastrukturo. Kaj ĉi tio estas nur unu ekzemplo de subtaksado de aferoj ligitaj al monitorado pri nuba informa sekureco. En ĉi tiu artikolo, sen ŝajnigi esti kompleta, mi volas atentigi iujn nuancojn, kiujn oni devas konsideri kiam oni elektas nuban provizanton el sekureca vidpunkto. Kaj ĉe la fino de la artikolo, oni donos kontrolan liston, kiu indas kompletigi antaŭ ol konsideri, ke la afero pri monitorado de nuba informa sekureco estis solvita.

Estas pluraj tipaj problemoj, kiuj kondukas al incidentoj en nubaj medioj, al kiuj informasekurecaj servoj ne havas tempon por respondi aŭ tute ne vidas ilin:

• Sekurecaj protokoloj ne ekzistas. Ĉi tio estas sufiĉe ofta situacio, precipe inter komencaj ludantoj en la merkato de nubaj solvoj. Sed vi ne devus rezigni pri ili tuj. Malgrandaj ludantoj, precipe hejmaj, estas pli sentemaj al klientpostuloj kaj povas rapide efektivigi kelkajn postulatajn funkciojn ŝanĝante la aprobitan vojmapon por siaj produktoj. Jes, ĉi tio ne estos analogo de GuardDuty de Amazon aŭ la modulo "Proactive Protection" de Bitrix, sed almenaŭ io.
• Informa sekureco ne scias kie la protokoloj estas konservitaj aŭ ne estas aliro al ili. Ĉi tie necesas eniri intertraktadon kun la provizanto de nuba servo - eble li provizos tiajn informojn, se li konsideras la klienton grava por li. Sed ĝenerale, ne estas tre bone kiam aliro al protokoloj estas provizita "per speciala decido."
• Okazas ankaŭ, ke la nuba provizanto havas protokolojn, sed ili provizas limigitan monitoradon kaj registradon de eventoj, kiuj ne sufiĉas por detekti ĉiujn okazaĵojn. Ekzemple, vi povas nur ricevi protokolojn de ŝanĝoj en retejo aŭ protokolojn de uzantaŭtentigaj provoj, sed ne aliajn eventojn, kiel rettrafikon, kiuj kaŝos de vi tutan tavolon da eventoj, kiuj karakterizas provojn haki vian nuban infrastrukturon.
• Estas protokoloj, sed aliro al ili estas malfacile aŭtomatigebla, kio devigas ilin esti monitoritaj ne kontinue, sed laŭhoraro. Kaj se vi ne povas elŝuti protokolojn aŭtomate, tiam elŝuti protokolojn, ekzemple, en Excel-formato (kiel ĉe kelkaj hejmaj nubaj solvprovizantoj), eĉ povas konduki al malemo de la kompania informa sekureca servo prilabori ilin.
• Neniu registro monitorado. Ĉi tio eble estas la plej neklara kialo por la okazo de informsekurecaj okazaĵoj en nubaj medioj. Ŝajnas, ke ekzistas protokoloj, kaj eblas aŭtomatigi aliron al ili, sed neniu faras tion. Kial?

Komuna nuba sekureca koncepto

La transiro al la nubo ĉiam estas serĉo de ekvilibro inter la deziro konservi kontrolon super la infrastrukturo kaj transdoni ĝin al la pli profesiaj manoj de nuba provizanto, kiu specialiĝas pri konservado de ĝi. Kaj en la kampo de nuba sekureco, ĉi tiu ekvilibro ankaŭ devas esti serĉata. Krome, depende de la nuba servo-livermodelo uzata (IaaS, PaaS, SaaS), ĉi tiu ekvilibro estos malsama la tutan tempon. Ĉiukaze, ni devas memori, ke ĉiuj nubaj provizantoj hodiaŭ sekvas la tiel nomatan komunan respondecon kaj komunan informsekurecan modelon. La nubo respondecas pri iuj aferoj, kaj pri aliaj respondecas la kliento, metante siajn datumojn, siajn aplikojn, siajn virtualajn maŝinojn kaj aliajn rimedojn en la nubon. Estus malzorge atendi, ke irante al la nubo, ni transdonos ĉian respondecon al la provizanto. Sed ankaŭ estas malprudente konstrui la tutan sekurecon mem kiam moviĝas al la nubo. Necesas ekvilibro, kiu dependos de multaj faktoroj: - strategio pri administrado de risko, modelo de minaco, mekanismoj de sekureco disponeblaj por la provizanto de nubo, leĝaro ktp.

Ekzemple, la klasifiko de datumoj gastigitaj en la nubo ĉiam estas la respondeco de la kliento. Nuba provizanto aŭ ekstera servoprovizanto povas helpi lin nur per iloj, kiuj helpos marki datumojn en la nubo, identigi malobservojn, forigi datumojn, kiuj malobservas la leĝon, aŭ maski ĝin per unu aŭ alia metodo. Aliflanke, fizika sekureco ĉiam estas la respondeco de la nuba provizanto, kiun ĝi ne povas dividi kun klientoj. Sed ĉio, kio estas inter datumoj kaj fizika infrastrukturo, estas ĝuste la temo de diskuto en ĉi tiu artikolo. Ekzemple, la havebleco de la nubo estas la respondeco de la provizanto, kaj starigi fajroŝirmigajn regulojn aŭ ebligi ĉifradon estas la respondeco de la kliento. En ĉi tiu artikolo ni provos rigardi, kiajn mekanismojn pri monitorado de sekureco de informado estas provizitaj hodiaŭ de diversaj popularaj nubaj provizantoj en Rusio, kiaj estas la trajtoj de ilia uzo, kaj kiam indas rigardi al eksteraj superkovraj solvoj (ekzemple, Cisco E- poŝta Sekureco) kiuj vastigas la kapablojn de via nubo laŭ cibersekureco. En iuj kazoj, precipe se vi sekvas multnuban strategion, vi ne havos alian elekton ol uzi eksterajn informsekurecajn monitoradsolvojn en pluraj nubaj medioj samtempe (ekzemple, Cisco CloudLock aŭ Cisco Stealthwatch Cloud). Nu, en iuj kazoj vi rimarkos, ke la nuba provizanto, kiun vi elektis (aŭ trudis al vi) tute ne ofertas monitorajn kapablojn pri informa sekureco. Ĉi tio estas malagrabla, sed ankaŭ ne malmulte, ĉar ĝi permesas al vi adekvate taksi la nivelon de risko asociita kun laboro kun ĉi tiu nubo.

Nuba Sekureca Monitorado de Vivociklo

Por kontroli la sekurecon de la nuboj, kiujn vi uzas, vi havas nur tri eblojn:

• fidu la ilojn provizitajn de via nuba provizanto,
• uzu solvojn de triaj partioj, kiuj kontrolos la platformojn IaaS, PaaS aŭ SaaS, kiujn vi uzas,
• konstruu vian propran nuban monitoradinfrastrukturon (nur por IaaS/PaaS-platformoj).

Ni vidu, kiajn funkciojn havas ĉiu el ĉi tiuj opcioj. Sed unue, ni devas kompreni la ĝeneralan kadron, kiu estos uzata dum monitorado de nubaj platformoj. Mi reliefigus 6 ĉefajn komponantojn de la informa sekureca monitorada procezo en la nubo:

• Preparado de infrastrukturo. Determinante la necesajn aplikojn kaj infrastrukturon por kolekti eventojn gravajn por informa sekureco en stokadon.
• Kolekto. En ĉi tiu etapo, sekurecaj eventoj estas kunigitaj de diversaj fontoj por posta dissendo por prilaborado, stokado kaj analizo.
• Traktado. En ĉi tiu etapo, la datumoj estas transformitaj kaj riĉigitaj por faciligi postan analizon.
• Stokado. Ĉi tiu komponanto respondecas pri mallongdaŭra kaj longdaŭra stokado de kolektitaj prilaboritaj kaj krudaj datumoj.
• Analizo. En ĉi tiu etapo, vi havas la kapablon detekti incidentojn kaj respondi al ili aŭtomate aŭ permane.
• Raportado. Ĉi tiu etapo helpas formuli ŝlosilajn indikilojn por koncernatoj (administrado, revizoroj, nuboprovizanto, klientoj, ktp.), kiuj helpas nin fari iujn decidojn, ekzemple ŝanĝi provizanton aŭ plifortigi informan sekurecon.

Kompreni ĉi tiujn komponantojn permesos al vi rapide decidi estonte, kion vi povas preni de via provizanto, kaj kion vi devos fari mem aŭ kun la implikiĝo de eksteraj konsultistoj.

Enkonstruitaj nubaj servoj

Mi jam skribis supre, ke multaj nubaj servoj hodiaŭ ne provizas ajnajn informajn sekurecajn monitoradkapablojn. Ĝenerale ili ne multe atentas la temon de informa sekureco. Ekzemple, unu el la popularaj rusaj servoj por sendi raportojn al registaraj agentejoj per Interreto (mi ne specife mencios ĝian nomon). La tuta sekcio pri la sekureco de ĉi tiu servo rondiras ĉirkaŭ la uzo de atestita CIPF. La sekcio pri informa sekureco de alia hejma nuba servo por elektronika dokumenta administrado ne diferencas. Ĝi parolas pri publikaj ŝlosilaj atestiloj, atestita kriptografio, forigo de retaj vundeblecoj, protekto kontraŭ DDoS-atakoj, uzado de fajroŝirmiloj, sekurkopioj kaj eĉ regulaj informsekurecaj revizioj. Sed ne estas vorto pri monitorado, nek pri la ebleco akiri aliron al informaj sekurecaj eventoj, kiuj povas interesi klientojn de ĉi tiu servoprovizanto.

Ĝenerale, laŭ la maniero, la nuba provizanto priskribas informojn pri sekureco en sia retejo kaj en sia dokumentaro, vi povas kompreni kiom serioze ĝi prenas ĉi tiun aferon. Ekzemple, se vi legas la manlibrojn por la produktoj "Mia Oficejo", tute ne estas vorto pri sekureco, sed en la dokumentado por la aparta produkto "Mia Oficejo". KS3", desegnita por protekti kontraŭ neaŭtorizita aliro, ekzistas kutima listo de punktoj de la 17-a ordo de la FSTEC, kiun "My Office.KS3" efektivigas, sed ne estas priskribite kiel ĝi efektivigas ĝin kaj, plej grave, kiel fari. integri ĉi tiujn mekanismojn kun kompania informa sekureco. Eble tia dokumentaro ekzistas, sed mi ne trovis ĝin en la publika domeno, en la retejo "Mia Oficejo". Kvankam eble mi simple ne havas aliron al ĉi tiu sekreta informo?...

Por Bitrix, la situacio estas multe pli bona. La dokumentaro priskribas la formatojn de la evento-protokoloj kaj, interese, la entrud-protokolo, kiu enhavas eventojn rilatajn al eblaj minacoj al la nuba platformo. De tie vi povas eltiri la IP-on, uzantan aŭ gaston, eventofonton, tempon, Uzantan Agenton, eventan tipon ktp. Vere, vi povas labori kun ĉi tiuj eventoj aŭ de la kontrolpanelo de la nubo mem, aŭ alŝuti datumojn en MS Excel-formato. Nun estas malfacile aŭtomatigi laboron per Bitrix-protokoloj kaj vi devos fari iom da la laboro permane (alŝuti la raporton kaj ŝarĝi ĝin en vian SIEM). Sed se ni memoras, ke ĝis relative lastatempe tia ŝanco ne ekzistis, tiam tio estas granda progreso. Samtempe, mi ŝatus noti, ke multaj eksterlandaj nubaj provizantoj ofertas similajn funkciojn "por komencantoj" - aŭ rigardu la protokolojn per viaj okuloj tra la kontrolpanelo, aŭ alŝutu la datumojn al vi mem (tamen la plej multaj alŝutas datumojn en . csv formato, ne Excel).

Sen pripensi la opcion sen protokoloj, nubaj provizantoj kutime ofertas al vi tri eblojn por monitori sekurecajn eventojn - paneloj, alŝuto de datumoj kaj API-aliro. La unua ŝajnas solvi multajn problemojn por vi, sed tio ne estas tute vera - se vi havas plurajn revuojn, vi devas ŝanĝi inter la ekranoj montrantaj ilin, perdante la ĝeneralan bildon. Krome, la nuba provizanto verŝajne ne provizos al vi la kapablon korelacii sekurecajn eventojn kaj ĝenerale analizi ilin el sekureca vidpunkto (kutime vi traktas krudajn datumojn, kiujn vi bezonas mem kompreni). Estas esceptoj kaj ni parolos pri ili plu. Fine, indas demandi, kiaj eventoj estas registritaj de via nuba provizanto, en kia formato, kaj kiel ili respondas al via informa sekureca monitorado? Ekzemple, identigo kaj aŭtentigo de uzantoj kaj gastoj. La sama Bitrix permesas vin, surbaze de ĉi tiuj eventoj, registri la daton kaj horon de la evento, la nomon de la uzanto aŭ gasto (se vi havas la modulon "TTT-Analitiko"), la objekton alirita kaj aliajn elementojn tipaj por retejo. . Sed kompaniaj informsekurecaj servoj eble bezonas informojn pri ĉu la uzanto aliris la nubon de fidinda aparato (ekzemple, en kompania reto ĉi tiu tasko estas efektivigita de Cisco ISE). Kio pri tia simpla tasko kiel la geo-IP-funkcio, kiu helpos determini ĉu konto de uzanto de nuba servo estas ŝtelita? Kaj eĉ se la nuba provizanto provizas ĝin al vi, ĉi tio ne sufiĉas. La sama Cisco CloudLock ne nur analizas geolokigon, sed uzas maŝinlernadon por tio kaj analizas historiajn datumojn por ĉiu uzanto kaj kontrolas diversajn anomaliojn en provoj de identigo kaj aŭtentigo. Nur MS Azure havas similan funkciojn (se vi havas la taŭgan abonon).

Estas alia malfacilaĵo - ĉar por multaj nubaj provizantoj informa sekureca monitorado estas nova temo, kiun ili ĵus komencas trakti, ili konstante ŝanĝas ion en siaj solvoj. Hodiaŭ ili havas unu version de la API, morgaŭ alian, postmorgaŭ trian. Vi ankaŭ devas esti preta por ĉi tio. La sama estas vera kun funkcieco, kiu povas ŝanĝiĝi, kiu devas esti konsiderata en via informa sekurecmonitora sistemo. Ekzemple, Amazon komence havis apartajn nubajn eventojn monitoradservojn - AWS CloudTrail kaj AWS CloudWatch. Tiam aperis aparta servo por monitorado de informaj sekurecaj eventoj - AWS GuardDuty. Post iom da tempo, Amazon lanĉis novan administradsistemon, Amazon Security Hub, kiu inkluzivas analizon de datumoj ricevitaj de GuardDuty, Amazon Inspector, Amazon Macie kaj pluraj aliaj. Alia ekzemplo estas la ilo de integriĝo de Azure log kun SIEM - AzLog. Ĝi estis aktive uzata de multaj vendistoj de SIEM, ĝis en 2018 Microsoft anoncis la ĉesigon de ĝia disvolviĝo kaj subteno, kio alfrontis multajn klientojn, kiuj uzis ĉi tiun ilon kun problemo (ni parolos pri kiel ĝi estis solvita poste).

Tial zorge kontrolu ĉiujn monitorajn funkciojn, kiujn proponas al vi via nuba provizanto. Aŭ fidu al eksteraj solvprovizantoj, kiuj funkcios kiel perantoj inter via SOC kaj la nubo, kiun vi volas kontroli. Jes, ĝi estos pli multekosta (kvankam ne ĉiam), sed vi transdonos la tutan respondecon sur la ŝultrojn de iu alia. Aŭ ne ĉio?.. Ni memoru la koncepton de komuna sekureco kaj komprenu, ke ni ne povas ŝanĝi ion ajn - ni devos sendepende kompreni kiel malsamaj nubaj provizantoj provizas monitoradon de la informa sekureco de viaj datumoj, aplikoj, virtualaj maŝinoj kaj aliaj rimedoj. gastigita en la nubo. Kaj ni komencos kun tio, kion Amazon ofertas en ĉi tiu parto.

Ekzemplo: Monitorado pri informa sekureco en IaaS bazita sur AWS

Jes, jes, mi komprenas, ke Amazon ne estas la plej bona ekzemplo pro tio, ke tio estas usona servo kaj ĝi povas esti blokita kadre de la batalo kontraŭ ekstremismo kaj la disvastigo de informoj malpermesitaj en Rusio. Sed en ĉi tiu publikigado mi nur ŝatus montri kiel malsamaj nubaj platformoj diferencas en siaj informaj sekurecaj monitoradkapabloj kaj pri kio vi devus atenti kiam vi transdonas viajn ŝlosilajn procezojn al la nuboj de sekureca vidpunkto. Nu, se iuj el la rusaj programistoj de nubaj solvoj lernas ion utilan por si mem, tiam tio estos bonega.

La unua afero por diri estas, ke Amazono ne estas nepenetrebla fortikaĵo. Diversaj okazaĵoj regule okazas al liaj klientoj. Ekzemple, la nomoj, adresoj, datoj de naskiĝo kaj telefonnumeroj de 198 milionoj da balotantoj estis ŝtelitaj de Deep Root Analytics. Israela firmao Nice Systems ŝtelis 14 milionojn da rekordoj de Verizon-abonantoj. Tamen, la enkonstruitaj kapabloj de AWS permesas vin detekti larĝan gamon de okazaĵoj. Ekzemple:

• efiko al infrastrukturo (DDoS)
• noda kompromiso (komanda injekto)
• konta kompromiso kaj neaŭtorizita aliro
• malĝusta agordo kaj vundeblecoj
• nesekuraj interfacoj kaj APIoj.

Ĉi tiu diferenco estas pro la fakto, ke, kiel ni eksciis supre, la kliento mem respondecas pri la sekureco de klientdatenoj. Kaj se li ne ĝenis ŝalti protektajn mekanismojn kaj ne ŝaltis monitorajn ilojn, tiam li nur ekscios pri la okazaĵo de la amaskomunikilaro aŭ de siaj klientoj.

Por identigi incidentojn, vi povas uzi larĝan gamon de malsamaj monitoraj servoj evoluigitaj de Amazon (kvankam ĉi tiuj ofte estas kompletigitaj per eksteraj iloj kiel ekzemple oskrodado). Do, en AWS, ĉiuj agoj de uzantoj estas monitoritaj, sendepende de kiel ili estas efektivigitaj - per la administra konzolo, komandlinio, SDK aŭ aliaj AWS-servoj. Ĉiuj registroj pri la agado de ĉiu AWS-konto (inkluzive de uzantnomo, ago, servo, agadparametroj kaj rezulto) kaj API-uzado estas haveblaj per AWS CloudTrail. Vi povas vidi ĉi tiujn eventojn (kiel ekzemple AWS IAM-konzola ensalutojn) de la konzolo CloudTrail, analizi ilin per Amazon Athena aŭ "subkontrakti" ilin al eksteraj solvoj kiel Splunk, AlienVault, ktp. La AWS CloudTrail protokoloj mem estas metitaj en via AWS S3 sitelo.

Du aliaj AWS-servoj disponigas kelkajn aliajn gravajn monitoradkapablojn. Unue, Amazon CloudWatch estas monitora servo por rimedoj kaj aplikoj de AWS, kiu, interalie, ebligas al vi identigi diversajn anomaliojn en via nubo. Ĉiuj enkonstruitaj AWS-servoj, kiel Amazon Elastic Compute Cloud (serviloj), Amazon Relational Database Service (datumbazoj), Amazon Elastic MapReduce (datuma analizo), kaj 30 aliaj Amazon-servoj, uzas Amazon CloudWatch por konservi siajn protokolojn. Programistoj povas uzi la malferman API de Amazon CloudWatch por aldoni protokolan monitoradfunkciecon al kutimaj aplikoj kaj servoj, permesante al ili vastigi la amplekson de eventanalizo ene de sekureca kunteksto.

Due, la servo de VPC Flow Logs permesas analizi la retan trafikon senditan aŭ ricevitan de viaj AWS-serviloj (ekstere aŭ interne), same kiel inter mikroservoj. Kiam iu el viaj AWS-VPC-resursoj interagas kun la reto, VPC Flow Logs registras detalojn pri la rettrafiko, inkluzive de la fonta kaj cel-reta interfaco, same kiel la IP-adresojn, havenojn, protokolon, nombron da bajtoj kaj nombron da pakaĵoj kiujn vi. vidis. Tiuj spertaj pri loka reto-sekureco rekonos tion kiel analoga al fadenoj NetFlow, kiu povas esti kreita per ŝaltiloj, enkursigiloj kaj entrepren-nivelaj fajroŝirmiloj. Ĉi tiuj protokoloj estas gravaj por monitorado de informoj pri sekureco ĉar, male al eventoj pri la agoj de uzantoj kaj aplikoj, ili ankaŭ permesas vin ne maltrafi retajn interagojn en la virtuala privata nuba medio de AWS.

Resume, ĉi tiuj tri AWS-servoj—AWS CloudTrail, Amazon CloudWatch kaj VPC Flow Logs—kune provizas sufiĉe potencajn sciojn pri via konto-uzado, uzantkonduto, infrastruktura administrado, aplikaĵo kaj serva agado kaj reto-agado. Ekzemple, ili povas esti uzataj por detekti la sekvajn anomaliojn:

• Provoj skani la retejon, serĉi malantaŭajn pordojn, serĉi vundeblecojn per eksplodoj de "404-eraroj".
• Injektaj atakoj (ekzemple, SQL-injekto) per eksplodoj de "500 eraroj".
• Konataj atakiloj estas sqlmap, nikto, w3af, nmap, ktp. per analizo de la kampo de Uzanto Agento.

Amazon Web Services ankaŭ evoluigis aliajn servojn por cibersekurecaj celoj, kiuj permesas vin solvi multajn aliajn problemojn. Ekzemple, AWS havas enkonstruitan servon por revizii politikojn kaj agordojn - AWS Config. Ĉi tiu servo provizas kontinuan revizion de viaj AWS-resursoj kaj iliaj agordoj. Ni prenu simplan ekzemplon: Ni diru, ke vi volas certigi, ke uzantpasvortoj estas malŝaltitaj en ĉiuj viaj serviloj kaj ke aliro estas ebla nur surbaze de atestiloj. AWS Config faciligas kontroli ĉi tion por ĉiuj viaj serviloj. Estas aliaj politikoj, kiuj povas esti aplikataj al viaj nubaj serviloj: "Neniu servilo povas uzi pordon 22", "Nur administrantoj povas ŝanĝi fajroŝirmigajn regulojn" aŭ "Nur uzanto Ivashko povas krei novajn uzantkontojn, kaj li povas fari Ĝi estas nur marde. " En la somero de 2016, la servo AWS Config estis vastigita por aŭtomatigi la detekton de malobservoj de evoluintaj politikoj. AWS Config Reguloj estas esence kontinuaj agordaj petoj por la Amazon-servoj, kiujn vi uzas, kiuj generas eventojn se la respondaj politikoj estas malobservitaj. Ekzemple, anstataŭ periode ruli AWS Config-demandojn por kontroli, ke ĉiuj diskoj sur virtuala servilo estas ĉifritaj, AWS Config Rules povas esti uzataj por kontinue kontroli servildiskojn por certigi, ke ĉi tiu kondiĉo estas plenumita. Kaj, plej grave, en la kunteksto de ĉi tiu publikigado, ajnaj malobservoj generas eventojn, kiuj povas esti analizitaj de via informa sekureca servo.

AWS ankaŭ havas sian ekvivalenton al tradiciaj kompaniaj informsekurecaj solvoj, kiuj ankaŭ generas sekurecajn eventojn, kiujn vi povas kaj devas analizi:

• Entruddetekto - AWS GuardDuty
• Kontrolo de Informo-Fludo - AWS Macie
• EDR (kvankam ĝi parolas pri finpunktoj en la nubo iom strange) - AWS Cloudwatch + malfermfonteca oskro aŭ GRR-solvoj
• Netflow-analizo - AWS Cloudwatch + AWS VPC Flow
• DNS-analizo - AWS Cloudwatch + AWS Route53
• AD - AWS Directory Service
• Administrado de kontoj - AWS IAM
• SSO - AWS SSO
• sekureca analizo - AWS-Inspektisto
• agorda administrado - AWS Config
• WAF - AWS WAF.

Mi ne detale priskribos ĉiujn Amazon-servojn, kiuj povas esti utilaj en la kunteksto de informa sekureco. La ĉefa afero estas kompreni, ke ĉiuj el ili povas generi eventojn, kiujn ni povas kaj devas analizi en la kunteksto de informa sekureco, uzante por ĉi tiu celo kaj la enkonstruitajn kapablojn de Amazon mem kaj eksterajn solvojn, ekzemple SIEM, kiuj povas. prenu sekurecajn eventojn al via monitora centro kaj analizu ilin tie kune kun eventoj de aliaj nubaj servoj aŭ de interna infrastrukturo, perimetro aŭ porteblaj aparatoj.

Ĉiukaze, ĉio komenciĝas per la datumfontoj, kiuj provizas al vi informajn sekurecajn eventojn. Ĉi tiuj fontoj inkluzivas, sed ne estas limigitaj al:

• CloudTrail - API-Uzado kaj Uzanto-Agoj
• Fidinda Konsilisto - sekureca kontrolo kontraŭ plej bonaj praktikoj
• Agordo - inventaro kaj agordo de kontoj kaj servo-agordoj
• VPC Flow Logs - konektoj al virtualaj interfacoj
• IAM - identiga kaj aŭtentikiga servo
• ELB Access Logs - Ŝarĝbalancilo
• Inspektisto - aplikvundeblecoj
• S3 - stokado de dosieroj
• CloudWatch - Aplika Agado
• SNS estas sciiga servo.

Amazon, proponante tian gamon da okazaĵfontoj kaj iloj por ilia generacio, estas tre limigita en sia kapablo analizi la kolektitajn datumojn en la kunteksto de informa sekureco. Vi devos sendepende studi la disponeblajn protokolojn, serĉante koncernajn indikilojn de kompromiso en ili. AWS Security Hub, kiun Amazon lastatempe lanĉis, celas solvi ĉi tiun problemon fariĝante nubo SIEM por AWS. Sed ĝis nun ĝi estas nur en la komenco de sia vojaĝo kaj estas limigita kaj de la nombro da fontoj kun kiuj ĝi funkcias kaj de aliaj limigoj establitaj de la arkitekturo kaj abonoj de Amazon mem.

Ekzemplo: Monitorado pri informa sekureco en IaaS bazita sur Azure

Mi ne volas eniri longan debaton pri kiu el la tri nubaj provizantoj (Amazon, Microsoft aŭ Guglo) estas pli bona (precipe ĉar ĉiu el ili ankoraŭ havas siajn specifajn specifaĵojn kaj taŭgas por solvi siajn proprajn problemojn); Ni koncentriĝu pri la informaj sekurecmonitoradkapabloj kiujn ĉi tiuj ludantoj provizas. Oni devas konfesi, ke Amazon AWS estis unu el la unuaj en ĉi tiu segmento kaj tial plej progresis laŭ siaj informaj sekurecaj funkcioj (kvankam multaj konfesas, ke ili estas malfacile uzeblaj). Sed ĉi tio ne signifas, ke ni ignoros la ŝancojn, kiujn Microsoft kaj Google provizas al ni.

Mikrosoftaj produktoj ĉiam distingiĝis pro sia "malfermo" kaj en Azure la situacio estas simila. Ekzemple, se AWS kaj GCP ĉiam procedas de la koncepto de "kio ne estas permesita estas malpermesita", tiam Azure havas la ĝustan kontraŭan aliron. Ekzemple, dum kreado de virtuala reto en la nubo kaj virtuala maŝino en ĝi, ĉiuj havenoj kaj protokoloj estas malfermitaj kaj permesitaj defaŭlte. Sekve, vi devos elspezi iom pli da penado por la komenca agordo de la alirkontrola sistemo en la nubo de Microsoft. Kaj ĉi tio ankaŭ trudas pli striktajn postulojn al vi rilate al monitorado de agado en la Azure-nubo.

AWS havas proprecon asociita kun la fakto, ke kiam vi kontrolas viajn virtualajn rimedojn, se ili situas en malsamaj regionoj, tiam vi havas malfacilaĵojn en kombini ĉiujn eventojn kaj ilian unuigitan analizon, por forigi, kiujn vi bezonas uzi diversajn lertaĵojn, kiel ekzemple. Kreu vian propran kodon por AWS Lambda, kiu transportos eventojn inter regionoj. Azure ne havas ĉi tiun problemon - ĝia Activity Log-mekanismo spuras ĉiun agadon tra la tuta organizo sen limigoj. La sama validas por AWS Security Hub, kiu estis lastatempe evoluigita de Amazon por solidigi multajn sekurecajn funkciojn ene de ununura sekureca centro, sed nur ene de sia regiono, kiu tamen ne gravas por Rusio. Azure havas sian propran Sekureccentron, kiu ne estas ligita per regionaj limigoj, provizante aliron al ĉiuj sekurecaj funkcioj de la nuba platformo. Krome, por malsamaj lokaj teamoj ĝi povas disponigi sian propran aron de protektaj kapabloj, inkluzive de sekurecaj eventoj administritaj de ili. AWS Security Hub daŭre estas survoje al iĝi simila al Azure Security Center. Sed indas aldoni muŝon en la ungventon - vi povas elpremi el Azure multe da tio, kio antaŭe estis priskribita en AWS, sed ĉi tio estas plej oportune farita nur por Azure AD, Azure Monitor kaj Azure Security Center. Ĉiuj aliaj Azure-sekurecaj mekanismoj, inkluzive de sekureca evento-analizo, ankoraŭ ne estas administritaj laŭ la plej oportuna maniero. La problemo estas parte solvita de la API, kiu trapenetras ĉiujn servojn de Microsoft Azure, sed ĉi tio postulos plian penon de vi por integri vian nubon kun via SOC kaj la ĉeesto de kvalifikitaj specialistoj (fakte, same kiel kun iu ajn alia SIEM kiu funkcias kun nubaj APIoj). Iuj SIEM-oj, pri kiuj diskutos poste, jam subtenas Azure kaj povas aŭtomatigi la taskon de ĝi kontrolas, sed ĝi ankaŭ havas siajn proprajn malfacilaĵojn - ne ĉiuj povas kolekti ĉiujn protokolojn, kiujn Azure havas.

Kolekto kaj monitorado de eventoj en Azure estas provizitaj per la servo Azure Monitor, kiu estas la ĉefa ilo por kolekti, stoki kaj analizi datumojn en la Microsoft-nubo kaj ĝiaj rimedoj - Git-deponejoj, ujoj, virtualaj maŝinoj, aplikoj ktp. Ĉiuj datumoj kolektitaj de Azure Monitor estas dividitaj en du kategoriojn - metrikoj, kolektitaj en reala tempo kaj priskribanta ŝlosilajn agado-indikilojn de la Azure-nubo, kaj protokoloj, enhavantaj datumojn organizitajn en rekordojn karakterizantajn iujn aspektojn de la agado de Azure-resursoj kaj servoj. Krome, uzante la Data Collector API, la Azure Monitor-servo povas kolekti datumojn de iu ajn REST-fonto por konstrui siajn proprajn monitorajn scenarojn.

Jen kelkaj sekurecaj eventofontoj, kiujn Azure ofertas al vi kaj kiujn vi povas aliri per la Azure Portal, CLI, PowerShell aŭ REST API (kaj iuj nur per la Azure Monitor/Insight API):

• Aktivaj Protokoloj - ĉi tiu protokolo respondas la klasikajn demandojn de "kiu", "kio" kaj "kiam" pri ajna skriba operacio (PUT, POST, DELETE) sur nubaj rimedoj. Eventoj rilataj al legado (GET) ne estas inkluzivitaj en ĉi tiu protokolo, kiel kelkaj aliaj.
• Diagnozaj Protokoloj - enhavas datumojn pri operacioj kun aparta rimedo inkluzivita en via abono.
• Azure AD-raportado - enhavas kaj uzantan agadon kaj sisteman agadon rilate al grupo kaj uzantadministrado.
• Windows Event Log kaj Linux Syslog - enhavas eventojn de virtualaj maŝinoj gastigitaj en la nubo.
• Metriko - enhavas telemetrion pri la rendimento kaj sano de viaj nubaj servoj kaj rimedoj. Mezurita ĉiun minuton kaj konservita. ene de 30 tagoj.
• Network Security Group Flow Logs - enhavas datumojn pri retsekurecaj eventoj kolektitaj per la servo de Network Watcher kaj monitorado de rimedoj ĉe la reto.
• Stokado-Protokoloj - enhavas eventojn rilatajn al aliro al stokejoj.

Por monitorado, vi povas uzi eksterajn SIEM-ojn aŭ la enkonstruitan Azure Monitoron kaj ĝiajn etendaĵojn. Ni parolos pri informaj sekurecaj evento-administradaj sistemoj poste, sed nuntempe ni vidu, kion Azure mem proponas al ni por analizo de datumoj en la kunteksto de sekureco. La ĉefa ekrano por ĉio sekurec-rilata en Azure Monitor estas la Log Analytics Security and Audit Dashboard (la senpaga versio subtenas limigitan kvanton da evento-stokado dum nur unu semajno). Ĉi tiu panelo estas dividita en 5 ĉefajn areojn, kiuj bildigas resumajn statistikojn pri tio, kio okazas en la nuba medio, kiun vi uzas:

• Sekurecaj Domajnoj - ŝlosilaj kvantaj indikiloj rilataj al informa sekureco - la nombro da okazaĵoj, la nombro da kompromititaj nodoj, neflakitaj nodoj, retaj sekurecaj eventoj ktp.
• Rimarkindaj Problemoj - montras la nombron kaj gravecon de aktivaj informaj sekurecproblemoj
• Detektoj - montras ŝablonojn de atakoj uzataj kontraŭ vi
• Minaca Inteligenteco - montras geografiajn informojn pri eksteraj nodoj, kiuj atakas vin
• Oftaj sekurecaj demandoj - tipaj demandoj, kiuj helpos vin pli bone kontroli vian informan sekurecon.

Etendaĵoj de Azure Monitor inkluzivas Azure Key Vault (protekto de ĉifrikaj ŝlosiloj en la nubo), Malware Assessment (analizo de protekto kontraŭ malica kodo sur virtualaj maŝinoj), Azure Application Gateway Analytics (analizo de, interalie, nubaj fajroŝirmiloj), ktp. . Ĉi tiuj iloj, riĉigitaj per certaj reguloj por prilaborado de eventoj, permesas al vi vidi diversajn aspektojn de la agado de nubaj servoj, inkluzive de sekureco, kaj identigi iujn deviojn de operacio. Sed, kiel ofte okazas, ĉiu plia funkcieco postulas respondan pagitan abonon, kiu postulos respondajn financajn investojn de vi, kiujn vi devas antaŭplani.

Azure havas kelkajn enkonstruitajn minacajn monitoradkapablojn, kiuj estas integritaj en Azure AD, Azure Monitor kaj Azure Security Center. Inter ili, ekzemple, detekto de interago de virtualaj maŝinoj kun konataj malicaj IP-oj (pro la ĉeesto de integriĝo kun Threat Intelligence-servoj de Microsoft), detekto de malware en la nuba infrastrukturo per ricevado de alarmoj de virtualaj maŝinoj gastigitaj en la nubo, pasvorto. diveni atakojn ” sur virtualaj maŝinoj, vundeblecoj en la agordo de la uzantidentsistemo, ensaluti en la sistemon de anonimigantoj aŭ infektitaj nodoj, konto-fuĝoj, ensaluti en la sistemon de nekutimaj lokoj, ktp. Azure hodiaŭ estas unu el la malmultaj nubaj provizantoj, kiuj ofertas al vi enkonstruitajn Threat Intelligence-kapablojn por riĉigi kolektitajn informsekurecajn eventojn.

Kiel menciite supre, la sekureca funkcio kaj, kiel rezulto, la sekurecaj eventoj generitaj de ĝi ne estas disponeblaj por ĉiuj uzantoj egale, sed postulas certan abonon, kiu inkluzivas la funkciojn, kiujn vi bezonas, kiu generas la taŭgajn eventojn por informa sekureca monitorado. Ekzemple, iuj el la funkcioj priskribitaj en la antaŭa alineo por monitorado de anomalioj en kontoj estas disponeblaj nur en la premio P2 por la servo Azure AD. Sen ĝi, vi, kiel en la kazo de AWS, devos analizi la kolektitajn sekurecajn eventojn "mane". Kaj, ankaŭ, depende de la speco de Azure AD-licenco, ne ĉiuj eventoj estos disponeblaj por analizo.

En la portalo Azure, vi povas administri ambaŭ serĉajn demandojn pri protokoloj interesaj por vi kaj agordi instrumentpanelojn por bildigi ŝlosilajn sekurecajn indikilojn. Krome, tie vi povas elekti etendojn de Azure Monitor, kiuj ebligas al vi vastigi la funkciojn de protokoloj de Azure Monitor kaj akiri pli profundan analizon de eventoj el sekureca vidpunkto.

Se vi bezonas ne nur la kapablon labori kun protokoloj, sed ampleksan sekureccentron por via Azure-nuba platformo, inkluzive de informa sekureca politika administrado, tiam vi povas paroli pri la bezono labori kun Azure Security Center, kies plej multaj utilaj funkcioj. estas disponeblaj por iom da mono, ekzemple, minaco-detekto, monitorado ekster Azure, plenumo-takso, ktp. (en la senpaga versio, vi nur havas aliron al sekureca takso kaj rekomendoj por forigi identigitajn problemojn). Ĝi solidigas ĉiujn sekurecajn problemojn en unu loko. Fakte, ni povas paroli pri pli alta nivelo de informa sekureco ol Azure Monitoro provizas al vi, ĉar ĉi-kaze la datumoj kolektitaj tra via nuba fabriko estas riĉigitaj uzante multajn fontojn, kiel Azure, Office 365, Microsoft CRM interrete, Microsoft Dynamics AX. , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) kaj Microsoft Security Response Center (MSRC), sur kiuj estas supermetitaj diversaj kompleksaj maŝinlernado kaj kondutismaj analizaj algoritmoj, kiuj finfine devus plibonigi la efikecon de detektado kaj respondado al minacoj. .

Azure ankaŭ havas sian propran SIEM - ĝi aperis komence de 2019. Ĉi tio estas Azure Sentinel, kiu dependas de datumoj de Azure Monitor kaj ankaŭ povas integri kun. eksteraj sekurecaj solvoj (ekzemple NGFW aŭ WAF), kies listo konstante kreskas. Krome, per la integriĝo de la Microsoft Graph Security API, vi havas la kapablon konekti viajn proprajn Threat Intelligence-fluojn al Sentinel, kiu riĉigas la kapablojn por analizi okazaĵojn en via Azure-nubo. Oni povas argumenti, ke Azure Sentinel estas la unua "denaska" SIEM, kiu aperis de nubaj provizantoj (la sama Splunk aŭ ELK, kiuj povas esti gastigitaj en la nubo, ekzemple, AWS, ankoraŭ ne estas evoluigitaj de tradiciaj nubaj servoprovizantoj). Azure Sentinel kaj Sekureca Centro povus esti nomitaj SOC por la Azure-nubo kaj povus esti limigitaj al ili (kun certaj rezervoj) se vi ne plu havis ajnan infrastrukturon kaj vi translokigis ĉiujn viajn komputikajn rimedojn al la nubo kaj ĝi estus la Microsoft-nubo Azure.

Sed ĉar la enkonstruitaj kapabloj de Azure (eĉ se vi havas abonon al Sentinel) ofte ne sufiĉas por kontroli informan sekurecon kaj integri ĉi tiun procezon kun aliaj fontoj de sekurecaj eventoj (kaj nubo kaj interna), ekzistas bezonas eksporti la kolektitajn datumojn al eksteraj sistemoj, al kiuj povas inkluzivi SIEM. Ĉi tio estas farita ambaŭ uzante la API kaj uzante specialajn etendaĵojn, kiuj nuntempe estas oficiale disponeblaj nur por la sekvaj SIEM-oj - Splunk (Azure Monitor Add-On por Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight kaj ELK. Ĝis antaŭ nelonge, ekzistis pli da tiaj SIEM-oj, sed de la 1-a de junio 2019, Microsoft ĉesis subteni la Azure Log Integration Tool (AzLog), kiu ĉe la krepusko de la ekzisto de Azure kaj sen normala normigo de laboro kun ŝtipoj (AzLog). Monitoro eĉ ne ekzistis ankoraŭ) faciligis integri eksteran SIEM kun la Microsoft-nubo. Nun la situacio ŝanĝiĝis kaj Microsoft rekomendas la platformon Azure Event Hub kiel la ĉefan integrigan ilon por aliaj SIEM-oj. Multaj jam efektivigis tian integriĝon, sed atentu - ili eble ne kaptas ĉiujn Azure protokolojn, sed nur kelkajn (serĉu en la dokumentado por via SIEM).

Finante mallongan ekskurson en Azure, mi ŝatus doni ĝeneralan rekomendon pri ĉi tiu nuba servo - antaŭ ol vi diras ion pri la informasekurecaj monitoraj funkcioj en Azure, vi devas agordi ilin tre zorge kaj provi ke ili funkcias kiel skribite en la dokumentado kaj kiel la konsultistoj diris al vi Microsoft (kaj ili eble havas malsamajn vidojn pri la funkcieco de Azure-funkcioj). Se vi havas la financajn rimedojn, vi povas elpremi multajn utilajn informojn de Azure koncerne informsekurecan monitoradon. Se viaj rimedoj estas limigitaj, tiam, kiel en la kazo de AWS, vi devos fidi nur al via propra forto kaj al la krudaj datumoj, kiujn Azure Monitor provizas al vi. Kaj memoru, ke multaj monitoraj funkcioj kostas monon kaj estas pli bone konatiĝi kun la prezo-politiko anticipe. Ekzemple, senpage vi povas stoki 31 tagojn da datumoj ĝis maksimumo de 5 GB per kliento - superi ĉi tiujn valorojn postulos, ke vi forspezu plian monon (ĉirkaŭ $2+ por stoki ĉiun aldonan GB de la kliento kaj $0,1 por stokante 1 GB ĉiun kroman monaton). Labori kun aplikaj telemetrioj kaj metrikoj ankaŭ povas postuli pliajn financojn, same kiel labori kun atentigoj kaj sciigoj (certa limo disponeblas senpage, kio eble ne sufiĉas por viaj bezonoj).

Ekzemplo: Monitorado pri informa sekureco en IaaS bazita sur Google Cloud Platform

Google Cloud Platform aspektas kiel junulo kompare kun AWS kaj Azure, sed ĉi tio estas parte bona. Male al AWS, kiu pliigis siajn kapablojn, inkluzive de sekureco, iom post iom, havante problemojn kun centralizo; GCP, kiel Azure, estas multe pli bone administrita centre, kio reduktas erarojn kaj efektivigtempon tra la entrepreno. De sekureca vidpunkto, GCP estas, strange, inter AWS kaj Azure. Li ankaŭ havas ununuran evento-registradon por la tuta organizo, sed ĝi estas nekompleta. Iuj funkcioj ankoraŭ estas en beta-reĝimo, sed iom post iom ĉi tiu manko devas esti forigita kaj GCP fariĝos pli matura platformo rilate al informasekureca monitorado.

La ĉefa ilo por registri eventojn en GCP estas Stackdriver Logging (simila al Azure Monitor), kiu permesas vin kolekti eventojn tra via tuta nuba infrastrukturo (same kiel de AWS). De sekureca perspektivo en GCP, ĉiu organizo, projekto aŭ dosierujo havas kvar protokolojn:

• Administra Agado - enhavas ĉiujn eventojn rilatajn al administra aliro, ekzemple, krei virtualan maŝinon, ŝanĝi alirrajtojn, ktp. Ĉi tiu protokolo ĉiam estas skribita, sendepende de via deziro, kaj konservas ĝiajn datumojn dum 400 tagoj.
• Datuma Aliro - enhavas ĉiujn eventojn rilatajn al laborado kun datumoj de nubaj uzantoj (kreado, modifo, legado ktp.). Defaŭlte, ĉi tiu protokolo ne estas skribita, ĉar ĝia volumeno tre rapide ŝveliĝas. Tial, ĝia breta vivo estas nur 30 tagoj. Krome, ne ĉio estas skribita en ĉi tiu revuo. Ekzemple, eventoj rilataj al rimedoj, kiuj estas publike alireblaj por ĉiuj uzantoj aŭ kiuj estas alireblaj sen ensaluti en GCP, ne estas skribitaj al ĝi.
• Sistema Evento - enhavas sistemajn eventojn ne rilatajn al uzantoj, aŭ agojn de administranto, kiu ŝanĝas la agordon de nubaj rimedoj. Ĝi ĉiam estas skribita kaj konservita dum 400 tagoj.
• Access Transparency estas unika ekzemplo de protokolo, kiu kaptas ĉiujn agojn de Google-dungitoj (sed ankoraŭ ne por ĉiuj GCP-servoj) kiuj aliras vian infrastrukturon kiel parto de siaj labordevoj. Ĉi tiu protokolo estas konservita dum 400 tagoj kaj ne disponeblas por ĉiu GCP-kliento, sed nur se kelkaj kondiĉoj estas plenumitaj (aŭ Ora aŭ Platena-nivela subteno, aŭ la ĉeesto de 4 roloj de certa tipo kiel parto de kompania subteno). Simila funkcio ankaŭ haveblas, ekzemple, en Office 365 - Lockbox.

Ekzemplo de protokolo: Aliri Travideblecon

{
 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"
}

Aliro al ĉi tiuj protokoloj estas ebla laŭ pluraj manieroj (en la sama maniero kiel antaŭe diskutitaj Azure kaj AWS) - per la interfaco de Log Viewer, per la API, per la Google Cloud SDK, aŭ per la paĝo Agado de via projekto, por kiu vi interesiĝas pri eventoj. De la sama maniero, ili povas esti eksportitaj al eksteraj solvoj por plia analizo. Ĉi-lasta estas farita eksportante protokolojn al BigQuery aŭ Cloud Pub/Sub-stokado.

Krom Stackdriver Logging, la GCP-platformo ankaŭ ofertas Stackdriver Monitoring-funkciecon, kiu ebligas al vi kontroli ŝlosilajn metrikojn (efikeco, MTBF, ĝenerala sano, ktp.) de nubaj servoj kaj aplikoj. Prilaboritaj kaj bildigitaj datumoj povas faciligi trovi problemojn en via nuba infrastrukturo, inkluzive en la kunteksto de sekureco. Sed oni devas rimarki, ke ĉi tiu funkcio ne estos tre riĉa en la kunteksto de informa sekureco, ĉar hodiaŭ GCP ne havas analogon de la sama AWS GuardDuty kaj ne povas identigi malbonajn inter ĉiuj registritaj eventoj (Google evoluigis Event Threat Detection, sed ĝi estas ankoraŭ evoluanta en beta kaj estas tro frue por paroli pri ĝia utileco). Stackdriver Monitoring povus esti utiligita kiel sistemo por detektado de anomalioj, kiuj tiam estus esploritaj por trovi la kialojn de ilia okazo. Sed pro la manko de dungitaro kvalifikita en la kampo de GCP-informa sekureco en la merkato, ĉi tiu tasko nuntempe aspektas malfacila.

Ankaŭ indas doni liston de iuj informsekurecaj moduloj, kiuj povas esti uzataj ene de via GCP-nubo, kaj kiuj similas al tio, kion AWS proponas:

• Cloud Security Command Center estas analogo de AWS Security Hub kaj Azure Security Center.
• Cloud DLP - Aŭtomata malkovro kaj redaktado (ekz. maskado) de datumoj gastigitaj en la nubo uzante pli ol 90 antaŭdifinitajn klasifikpolitikojn.
• Cloud Scanner estas skanilo por konataj vundeblecoj (XSS, Flash Injection, neflakitaj bibliotekoj, ktp.) en App Engine, Compute Engine kaj Google Kubernetes.
• Cloud IAM - Kontrolu aliron al ĉiuj GCP-resursoj.
• Nuba Identeco - Administri GCP-uzantoj, aparatoj kaj aplikaĵkontoj de ununura konzolo.
• Cloud HSM - protekto de ĉifrikaj ŝlosiloj.
• Cloud Key Management Service - administrado de kriptografaj ŝlosiloj en GCP.
• VPC-Serva Kontrolo - Kreu sekuran perimetron ĉirkaŭ viaj GCP-resursoj por protekti ilin kontraŭ likoj.
• Titan Security Key - protekto kontraŭ phishing.

Multaj el ĉi tiuj moduloj generas sekurecajn eventojn, kiuj povas esti senditaj al BigQuery-stokado por analizo aŭ eksporto al aliaj sistemoj, inkluzive de SIEM. Kiel menciite supre, GCP estas aktive evoluanta platformo kaj Google nun disvolvas kelkajn novajn informsekurecajn modulojn por sia platformo. Inter ili estas Event Threat Detection (nun havebla en beta), kiu skanas Stackdriver-programojn serĉante spurojn de neaŭtorizita agado (analoga al GuardDuty en AWS), aŭ Policy Intelligence (disponebla en alfa), kiu permesos al vi evoluigi inteligentajn politikojn por aliro al GCP-resursoj.

Mi faris mallongan superrigardon pri la enkonstruitaj monitoraj kapabloj en popularaj nubaj platformoj. Sed ĉu vi havas specialistojn, kiuj kapablas labori kun "krudaj" provizantoj de IaaS (ne ĉiuj pretas aĉeti la altnivelajn kapablojn de AWS aŭ Azure aŭ Google)? Krome, multaj konas la adaĝon "fidu, sed kontrolu", kiu estas pli vera ol iam ajn en la kampo de sekureco. Kiom vi fidas la enkonstruitajn kapablojn de la nuba provizanto, kiu sendas al vi informajn sekurecajn eventojn? Kiom ili entute koncentriĝas pri informa sekureco?

Kelkfoje indas rigardi superkovrajn nubajn infrastrukturajn monitoradsolvojn, kiuj povas kompletigi enkonstruitan nuban sekurecon, kaj foje tiaj solvoj estas la sola opcio por akiri enrigardon pri la sekureco de viaj datumoj kaj aplikoj gastigitaj en la nubo. Krome, ili estas simple pli oportunaj, ĉar ili prenas ĉiujn taskojn de analizo de la necesaj protokoloj generitaj de malsamaj nubaj servoj de malsamaj nubaj provizantoj. Ekzemplo de tia overlay solvo estas Cisco Stealthwatch Cloud, kiu estas koncentrita al ununura tasko - monitorado de informasekurecaj anomalioj en nubaj medioj, inkluzive de ne nur Amazon AWS, Microsoft Azure kaj Google Cloud Platform, sed ankaŭ privatajn nubojn.

Ekzemplo: Monitorado pri Informa Sekureco Uzante Stealthwatch Cloud

AWS provizas flekseblan komputilan platformon, sed ĉi tiu fleksebleco faciligas al kompanioj fari erarojn, kiuj kondukas al sekurecaj problemoj. Kaj la komuna informsekureca modelo nur kontribuas al tio. Funkcianta programaron en la nubo kun nekonataj vundeblecoj (konataj povas esti kontraŭbatalitaj, ekzemple, de AWS Inspector aŭ GCP Cloud Scanner), malfortaj pasvortoj, malĝustaj agordoj, internuloj ktp. Kaj ĉio ĉi reflektiĝas en la konduto de nubaj rimedoj, kiuj povas esti monitoritaj de Cisco Stealthwatch Cloud, kiu estas informa sekureca monitorado kaj ataka detektado. publikaj kaj privataj nuboj.

Unu el la ĉefaj trajtoj de Cisco Stealthwatch Cloud estas la kapablo modeligi entojn. Per ĝi, vi povas krei programaran modelon (tio estas, preskaŭ realtempan simuladon) de ĉiu el viaj nubaj rimedoj (ne gravas ĉu ĝi estas AWS, Azure, GCP aŭ io alia). Ĉi tiuj povas inkluzivi servilojn kaj uzantojn, same kiel rimedajn tipojn specifajn por via nuba medio, kiel sekurecaj grupoj kaj aŭto-skalaj grupoj. Ĉi tiuj modeloj uzas strukturitajn datumfluojn provizitajn de nubaj servoj kiel enigaĵon. Ekzemple, por AWS ĉi tiuj estus VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda kaj AWS IAM. Entomodelado aŭtomate malkovras la rolon kaj konduton de iu ajn el viaj rimedoj (vi povas paroli pri profilado de ĉiu nuba agado). Ĉi tiuj roloj inkluzivas Android aŭ Apple moveblan aparaton, Citrix PVS-servilon, RDP-servilon, poŝtan enirejon, VoIP-klienton, terminalservilon, domajnan regilon ktp. Ĝi tiam ade monitoras ilian konduton por determini kiam riska aŭ sekurec-minaca konduto okazas. Vi povas identigi pasvorton divenadon, DDoS-atakojn, datumfluojn, kontraŭleĝan foran aliron, malican kodan agadon, vundeblecon skanadon kaj aliajn minacojn. Ekzemple, jen kiel aspektas detekti foran alirprovon de lando netipa por via organizo (Sud-Koreio) al Kubernetes-areo per SSH:

Kaj jen kiel aspektas la supozata liko de informoj de la datumbazo Postgress al lando kun kiu ni antaŭe ne renkontis interagon:

Fine, jen kiel aspektas tro multaj malsukcesaj SSH-provoj el Ĉinio kaj Indonezio de ekstera fora aparato:

Aŭ, supozu, ke la servila petskribo en la VPC estas, laŭ politiko, neniam esti fora ensalutcelloko. Ni plu supozu, ke ĉi tiu komputilo spertis malproksiman ensaluti pro erara ŝanĝo en la politiko pri fajroŝirmilo. La Entity Modeling-funkcio detektos kaj raportos ĉi tiun agadon ("Nekutima Fora Aliro") preskaŭ en reala tempo kaj montros la specifan alvokon de AWS CloudTrail, Azure Monitor aŭ GCP Stackdriver Logging API (inkluzive de uzantnomo, dato kaj horo, inter aliaj detaloj. ). kiu instigis la ŝanĝon al la ITU-regulo. Kaj tiam ĉi tiuj informoj povas esti senditaj al SIEM por analizo.

Similaj kapabloj estas efektivigitaj por ajna nuba medio subtenata de Cisco Stealthwatch Cloud:

Enta modelado estas unika formo de sekureca aŭtomatigo, kiu povas malkovri antaŭe nekonatan problemon kun viaj homoj, procezoj aŭ teknologio. Ekzemple, ĝi permesas vin detekti, interalie, sekurecajn problemojn kiel:

• Ĉu iu malkovris malantaŭan pordon en la programaro, kiun ni uzas?
• Ĉu ekzistas iu triaparta programaro aŭ aparato en nia nubo?
• Ĉu la rajtigita uzanto misuzas privilegiojn?
• Ĉu estis agorda eraro kiu permesis foran aliron aŭ alian neintencitan uzon de rimedoj?
• Ĉu estas datumfluo de niaj serviloj?
• Ĉu iu provis konektiĝi al ni de maltipa geografia loko?
• Ĉu nia nubo estas infektita per malica kodo?

Detektita informsekureca evento povas esti sendita en la formo de responda bileto al Slack, Cisco Spark, la PagerDuty-okazaĵmastruma sistemo, kaj ankaŭ sendita al diversaj SIEMoj, inkluzive de Splunk aŭ ELK. Por resumi, ni povas diri, ke se via kompanio uzas multnuban strategion kaj ne estas limigita al iu ajn nuba provizanto, la informaj sekurecaj monitoradkapabloj priskribitaj supre, tiam uzi Cisco Stealthwatch Cloud estas bona elekto por akiri unuigitan aron de monitorado. kapabloj por la ĉefaj nubaj ludantoj - Amazon, Microsoft kaj Google. La plej interesa afero estas, ke se vi komparas la prezojn por Stealthwatch Cloud kun altnivelaj licencoj por informa sekureca monitorado en AWS, Azure aŭ GCP, eble rezultos, ke la Cisco solvo estos eĉ pli malmultekosta ol la enkonstruitaj kapabloj de Amazon, Microsoft. kaj Guglo-solvoj. Ĝi estas paradoksa, sed ĝi estas vera. Kaj ju pli da nuboj kaj iliaj kapabloj vi uzas, des pli evidenta estos la avantaĝo de firmigita solvo.

Krome, Stealthwatch Cloud povas monitori privatajn nubojn deplojitaj en via organizo, ekzemple, surbaze de Kubernetes-ujoj aŭ monitorante Netflow-fluojn aŭ retan trafikon ricevitan per spegulado en retaj ekipaĵoj (eĉ enlande produktitaj), AD-datumoj aŭ DNS-serviloj ktp. Ĉiuj ĉi tiuj datumoj estos riĉigitaj per informoj pri Minaco-Inteligenteco kolektitaj de Cisco Talos, la plej granda neregistara grupo de esploristoj pri cibersekurecaj minacoj en la mondo.

Ĉi tio ebligas al vi efektivigi unuigitan monitoran sistemon por publikaj kaj hibridaj nuboj, kiujn via kompanio povas uzi. La kolektitaj informoj tiam povas esti analizitaj uzante la enkonstruitajn kapablojn de Stealthwatch Cloud aŭ senditaj al via SIEM (Splunk, ELK, SumoLogic kaj pluraj aliaj estas subtenataj defaŭlte).

Kun ĉi tio, ni kompletigos la unuan parton de la artikolo, en kiu mi reviziis la enkonstruitajn kaj eksterajn ilojn por monitorado de informa sekureco de platformoj IaaS/PaaS, kiuj ebligas al ni rapide detekti kaj respondi al incidentoj okazantaj en la nubaj medioj, kiuj nia entrepreno elektis. En la dua parto, ni daŭrigos la temon kaj rigardos eblojn por monitorado de SaaS-platformoj uzante la ekzemplon de Salesforce kaj Dropbox, kaj ni ankaŭ provos resumi kaj kunmeti ĉion kreante unuigitan informasekurecan monitoradsistemon por malsamaj nubaj provizantoj.

fonto: www.habr.com