Cloud Security Monitoring

It ferpleatsen fan gegevens en applikaasjes nei de wolk presintearret in nije útdaging foar bedriuws-SOC's, dy't net altyd ree binne om de ynfrastruktuer fan oare minsken te kontrolearjen. Neffens Netoskope brûkt de gemiddelde ûndernimming (neiskynlik yn 'e FS) 1246 ferskillende wolktsjinsten, wat 22% mear is as in jier lyn. 1246 wolktsjinsten!!! 175 fan harren relatearje oan HR-tsjinsten, 170 binne relatearre oan marketing, 110 binne op it mêd fan kommunikaasje en 76 binne yn finânsjes en CRM. Cisco brûkt "allinne" 700 eksterne wolk tsjinsten. Dat ik bin in bytsje yn 'e war troch dizze sifers. Mar yn alle gefallen is it probleem net by har, mar mei it feit dat de wolk frij aktyf begjint te brûken troch in tanimmend oantal bedriuwen dy't graach deselde mooglikheden hawwe wolle foar it kontrolearjen fan wolkinfrastruktuer as yn har eigen netwurk. En dizze trend groeit - neffens neffens de American Chamber of Accounts Tsjin 2023 sille 1200 datasintra yn 'e Feriene Steaten sletten wurde (6250 binne al sluten). Mar de oergong nei de wolk is net allinich "lit ús servers ferpleatse nei in eksterne provider." Nije IT-arsjitektuer, nije software, nije prosessen, nije beheiningen ... Dit alles bringt wichtige feroarings yn it wurk fan net allinich IT, mar ek ynformaasjefeiligens. En as providers leard hawwe om op ien of oare manier om te gean mei it garandearjen fan 'e feiligens fan' e wolk sels (gelokkich binne d'r in protte oanbefellings), dan binne d'r mei monitoring fan wolkynformaasjefeiligens, benammen op SaaS-platfoarms, wichtige swierrichheden, wêr't wy oer sille prate.

Litte wy sizze dat jo bedriuw in diel fan har ynfrastruktuer ferpleatst hat nei de wolk ... Stopje. Net dizze manier. As de ynfrastruktuer is oerdroegen, en jo tinke no pas oer hoe't jo it kontrolearje, dan hawwe jo al ferlern. Behalven as it Amazon, Google, of Microsoft is (en dan mei reservearrings), sille jo wierskynlik net folle mooglikheid hawwe om jo gegevens en applikaasjes te kontrolearjen. It is goed as jo de kâns krije om mei logs te wurkjen. Soms sille gegevens oer befeiligingseveneminten beskikber wêze, mar jo hawwe der gjin tagong ta. Bygelyks, Office 365. As jo ​​de goedkeapste E1-lisinsje hawwe, dan binne feiligenseveneminten hielendal net beskikber foar jo. As jo ​​in E3-lisinsje hawwe, wurde jo gegevens mar 90 dagen opslein, en allinich as jo in E5-lisinsje hawwe, is de doer fan 'e logs beskikber foar in jier (dit hat lykwols ek syn eigen nuânses yn ferbân mei de needsaak om apart freegje in oantal funksjes foar wurkjen mei logs fan Microsoft-stipe). Trouwens, de E3-lisinsje is folle swakker yn termen fan tafersjochfunksjes dan Corporate Exchange. Om itselde nivo te berikken, hawwe jo in E5-lisinsje nedich as in ekstra Advanced Compliance-lisinsje, dy't ekstra jild fereaskje kin dat net yn jo finansjele model opnommen is foar it ferpleatsen nei wolkinfrastruktuer. En dit is mar ien foarbyld fan ûnderskatting fan problemen yn ferbân mei monitoring fan wolkynformaasjefeiligens. Yn dit artikel, sûnder pretend te wêzen folslein, ik wol omtinken jaan oan guon nuânses dy't rekken holden wurde moatte by it kiezen fan in wolkprovider út in feiligenspunt. En oan 'e ein fan it artikel sil in checklist wurde jûn dy't it wurdich is om te foltôgjen foardat jo beskôgje dat it probleem fan tafersjoch op wolkynformaasjefeiligens is oplost.

D'r binne ferskate typyske problemen dy't liede ta ynsidinten yn wolkomjouwings, wêrop tsjinsten foar ynformaasjefeiligens gjin tiid hawwe om te reagearjen of se hielendal net sjogge:

• Feiligens logs bestean net. Dit is in frij gewoane situaasje, foaral ûnder begjinnende spilers yn 'e merk foar wolkoplossingen. Mar jo moatte net opjaan op harren daliks. Lytse spilers, foaral ynlânske, binne gefoeliger foar easken fan klanten en kinne wat fereaske funksjes fluch ymplementearje troch de goedkarde roadmap foar har produkten te feroarjen. Ja, dit sil gjin analoog wêze fan GuardDuty fan Amazon of de module "Proactive Protection" fan Bitrix, mar op syn minst wat.
• Ynformaasje feiligens wit net wêr't de logs wurde opslein of der is gjin tagong ta harren. Hjir is it nedich om ûnderhannelings oan te gean mei de cloud-tsjinstferliener - miskien sil hy sokke ynformaasje leverje as hy de kliïnt wichtich foar him fynt. Mar yn 't algemien is it net heul goed as tagong ta logs wurdt levere "troch spesjaal beslút."
• It bart ek dat de wolkprovider logs hat, mar se jouwe beheinde tafersjoch en evenemintopname, dy't net genôch binne om alle ynsidinten te ûntdekken. Jo kinne bygelyks allinich logs krije fan feroaringen op in webside of logs fan besykjen fan brûkersautentikaasje, mar net oare eveneminten, lykas netwurkferkear, dy't foar jo in hiele laach fan eveneminten ferbergje dy't besykjen om jo wolkynfrastruktuer te hacken karakterisearje.
• D'r binne logs, mar tagong ta har is lestich te automatisearjen, wat twingt om te kontrolearjen net kontinu, mar op in skema. En as jo logs net automatysk kinne downloade, dan kin it ynladen fan logs, bygelyks yn Excel-formaat (lykas by in oantal ynlânske providers fan wolkoplossing), sels liede ta in tsjinsin fan 'e kant fan' e bedriuwsynformaasjefeiligenstsjinst om mei har te tinken.
• Gjin log monitoring. Dit is miskien de meast ûndúdlike reden foar it foarkommen fan ynsidinten fan ynformaasjefeiligens yn wolkomjouwings. It liket derop dat d'r logs binne, en it is mooglik om tagong ta har te automatisearjen, mar gjinien docht dit. Wêrom?

Dielde wolkbefeiligingskonsept

De oergong nei de wolk is altyd in syktocht nei in lykwicht tusken de winsk om kontrôle te behâlden oer de ynfrastruktuer en it oerdragen nei de mear profesjonele hannen fan in wolkprovider dy't spesjalisearre is yn it ûnderhâld. En op it mêd fan wolkefeiligens moat dy balâns ek socht wurde. Boppedat, ôfhinklik fan it brûkte model foar levering fan wolktsjinsten (IaaS, PaaS, SaaS), sil dit lykwicht de hiele tiid oars wêze. Yn alle gefallen moatte wy betinke dat alle wolkproviders hjoeddedei it saneamde dielde ferantwurdlikens en dielde ynformaasjefeiligensmodel folgje. De wolk is ferantwurdlik foar guon dingen, en foar oaren is de kliïnt ferantwurdlik, it pleatsen fan syn gegevens, syn applikaasjes, syn firtuele masines en oare boarnen yn 'e wolk. It soe roekeloos wêze om te ferwachtsjen dat wy troch nei de wolk te gean, alle ferantwurdlikens sille ferpleatse nei de provider. Mar it is ek ûnferstannich om sels alle feiligens te bouwen by it ferpleatsen nei de wolk. In lykwicht is fereaske, dat sil ôfhingje fan in protte faktoaren: - risikobehearstrategy, bedrigingsmodel, feiligensmeganismen beskikber foar de wolkprovider, wetjouwing, ensfh.

Bygelyks, de klassifikaasje fan gegevens yn 'e wolk is altyd de ferantwurdlikens fan' e klant. In wolkprovider as in eksterne tsjinstferliener kin him allinich helpe mei ark dy't sille helpe om gegevens yn 'e wolk te markearjen, oertredings te identifisearjen, gegevens te wiskjen dy't de wet oertrêde, of masker it mei ien of oare metoade. Oan 'e oare kant is fysike feiligens altyd de ferantwurdlikens fan' e wolkprovider, dy't it net kin diele mei kliïnten. Mar alles dat is tusken gegevens en fysike ynfrastruktuer is krekt it ûnderwerp fan diskusje yn dit artikel. Bygelyks, de beskikberens fan 'e wolk is de ferantwurdlikens fan' e provider, en it opsetten fan firewall-regels of it ynskeakeljen fan fersifering is de ferantwurdlikens fan 'e kliïnt. Yn dit artikel sille wy besykje te sjen hokker meganismen foar monitoaring fan ynformaasjefeiligens hjoeddedei wurde levere troch ferskate populêre wolkproviders yn Ruslân, wat binne de funksjes fan har gebrûk, en wannear is it wurdich te sjen nei eksterne overlay-oplossingen (bygelyks Cisco E- mail Security) dy't de mooglikheden fan jo wolk útwreidzje yn termen fan cyberfeiligens. Yn guon gefallen, benammen as jo folgje in multi-wolk strategy, do silst hawwe gjin oare kar as in gebrûk eksterne ynformaasje feiligens monitoring oplossings yn ferskate wolk omjouwings tagelyk (Bygelyks, Cisco CloudLock of Cisco Stealthwatch Cloud). No, yn guon gefallen sille jo realisearje dat de wolkprovider dy't jo hawwe keazen (of jo oplein) hielendal gjin mooglikheden foar tafersjoch fan ynformaasjefeiligens biedt. Dit is onaangenaam, mar ek net in bytsje, om't jo it risikonivo adekwaat kinne beoardielje dat ferbûn is mei it wurkjen mei dizze wolk.

Cloud Security Monitoring Lifecycle

Om de feiligens fan 'e wolken dy't jo brûke te kontrolearjen, hawwe jo mar trije opsjes:

• fertrouwe op de ark oanbean troch jo wolkprovider,
• oplossings brûke fan tredden dy't de IaaS-, PaaS- of SaaS-platfoarms sille kontrolearje dy't jo brûke,
• bou jo eigen ynfrastruktuer foar wolkmonitoring (allinich foar IaaS / PaaS-platfoarms).

Litte wy sjen hokker funksjes elk fan dizze opsjes hat. Mar earst moatte wy it algemiene ramt begripe dat sil wurde brûkt by it kontrolearjen fan wolkplatfoarms. Ik soe 6 haadkomponinten markearje fan it tafersjochproses foar ynformaasjefeiligens yn 'e wolk:

• Tarieding fan ynfrastruktuer. It bepalen fan de nedige applikaasjes en ynfrastruktuer foar it sammeljen fan eveneminten dy't wichtich binne foar ynformaasjefeiligens yn opslach.
• Samling. Op dit stadium wurde befeiligingseveneminten aggregearre út ferskate boarnen foar folgjende oerdracht foar ferwurking, opslach en analyse.
• Behanneling. Op dit stadium wurde de gegevens omfoarme en ferrike om folgjende analyse te fasilitearjen.
• Opslach. Dizze komponint is ferantwurdlik foar koarte-termyn en lange termyn opslach fan sammele ferwurke en rauwe gegevens.
• Analyse. Op dit poadium hawwe jo de mooglikheid om ynsidinten te ûntdekken en automatysk of mei de hân te reagearjen.
• Ferslachjouwing. Dizze poadium helpt om wichtige yndikatoaren te formulearjen foar belanghawwenden (behear, auditors, wolkprovider, kliïnten, ensfh.) dy't ús helpe om bepaalde besluten te nimmen, bygelyks it feroarjen fan in provider of it fersterkjen fan ynformaasjefeiligens.

Troch dizze komponinten te begripen kinne jo yn 'e takomst fluch beslute wat jo fan jo provider kinne nimme en wat jo sels dwaan moatte of mei de belutsenens fan eksterne adviseurs.

Ynboude wolk tsjinsten

Ik haw hjirboppe al skreaun dat in protte wolktsjinsten hjoeddedei gjin mooglikheden foar tafersjoch foar ynformaasjefeiligens leverje. Yn 't algemien jouwe se net folle omtinken oan it ûnderwerp fan ynformaasjefeiligens. Bygelyks, ien fan de populêre Russyske tsjinsten foar it ferstjoeren fan rapporten oan oerheidsynstânsjes fia it ynternet (ik sil net spesifyk neame syn namme). De hiele paragraaf oer de feiligens fan dizze tsjinst draait om it brûken fan sertifisearre CIPF. De seksje ynformaasjefeiligens fan in oare ynlânske wolktsjinst foar elektroanysk dokumintbehear is net oars. It praat oer sertifikaten foar iepenbiere kaaien, sertifisearre kryptografy, eliminearjen fan webkwetsberens, beskerming tsjin DDoS-oanfallen, gebrûk fan firewalls, backups, en sels reguliere audits foar ynformaasjefeiligens. Mar der is gjin wurd oer tafersjoch, noch oer de mooglikheid om tagong te krijen ta ynformaasjefeiligenseveneminten dy't fan belang wêze kinne foar kliïnten fan dizze tsjinstferliener.

Yn 't algemien, troch de manier wêrop de wolkprovider ynformaasjefeiligensproblemen beskriuwt op har webside en yn syn dokumintaasje, kinne jo begripe hoe serieus it dit probleem nimt. As jo ​​​​bygelyks de hantliedingen foar de produkten "My Office" lêze, is d'r hielendal gjin wurd oer feiligens, mar yn 'e dokumintaasje foar it aparte produkt "My Office. KS3", ûntworpen om te beskermjen tsjin unautorisearre tagong, is d'r in gewoane list fan punten fan 'e 17e folchoarder fan' e FSTEC, dy't "My Office.KS3" ymplementearret, mar it wurdt net beskreaun hoe't it it ymplementearret en, it wichtichste, hoe't yntegrearje dizze meganismen mei Corporate ynformaasje feiligens. Miskien bestiet sa'n dokumintaasje, mar ik fûn it net yn it publike domein, op 'e webside "My Office". Hoewol ik miskien gewoan gjin tagong ha ta dizze geheime ynformaasje? ..

Foar Bitrix is ​​de situaasje folle better. De dokumintaasje beskriuwt de formaten fan 'e barrenslogboeken en, nijsgjirrich, it ynbraaklogboek, dat eveneminten befettet relatearre oan potensjele bedrigingen foar it wolkplatfoarm. Dêrwei kinne jo de IP, brûkers- of gastnamme, boarne fan evenemint, tiid, brûkersagint, type evenemint, ensfh. Wier, jo kinne mei dizze eveneminten wurkje of fanút it kontrôlepaniel fan 'e wolk sels, of gegevens uploade yn MS Excel-formaat. It is no lestich om wurk te automatisearjen mei Bitrix-logs en jo moatte wat fan it wurk manuell dwaan (it rapport uploade en it yn jo SIEM laden). Mar as wy betinke dat sa'n kâns oant relatyf koartlyn net bestie, dan is dit grutte foarútgong. Tagelyk wol ik opmerke dat in protte bûtenlânske wolkproviders ferlykbere funksjonaliteit biede "foar begjinners" - sjoch nei de logs mei jo eagen fia it kontrôlepaniel, of upload de gegevens nei josels (lykwols, de measte uploadgegevens yn . csv-formaat, net Excel).

Sûnder de opsje sûnder logs te beskôgjen, biede wolkproviders jo normaal trije opsjes foar it kontrolearjen fan feiligenseveneminten - dashboards, upload fan gegevens en API-tagong. De earste liket in protte problemen foar jo op te lossen, mar dit is net hielendal wier - as jo ferskate tydskriften hawwe, moatte jo wikselje tusken de skermen dy't se werjaan, it totale byld ferlieze. Dêrnjonken is it net wierskynlik dat de wolkprovider jo de mooglikheid biedt om befeiligingseveneminten te korrelearjen en se oer it algemien te analysearjen út in feiligenspunt (meastentiids hawwe jo te meitsjen mei rauwe gegevens, dy't jo sels moatte begripe). Der binne útsûnderingen en dêr sille wy fierder oer prate. Uteinlik is it de muoite wurdich te freegjen hokker eveneminten wurde opnommen troch jo wolkprovider, yn hokker formaat, en hoe komme se oerien mei jo proses foar tafersjoch op ynformaasjefeiligens? Bygelyks identifikaasje en autentikaasje fan brûkers en gasten. Deselde Bitrix lit jo, basearre op dizze eveneminten, de datum en tiid fan it barren opnimme, de namme fan 'e brûker of gast (as jo de module "Web Analytics" hawwe), it tagong ta objekt en oare eleminten typysk foar in webside . Mar bedriuwen ynformaasje feiligens tsjinsten kinne nedich ynformaasje oer oft de brûker tagong ta de wolk fan in fertroude apparaat (Bygelyks, yn in bedriuw netwurk dizze taak wurdt útfierd troch Cisco ISE). Hoe sit it mei sa'n ienfâldige taak as de geo-IP-funksje, dy't sil helpe om te bepalen oft in wolktsjinst-brûkersakkount stellen is? En sels as de wolkprovider it jo leveret, is dit net genôch. Itselde Cisco CloudLock analysearret net allinich geolokaasje, mar brûkt masine learen foar dit en analysearret histoaryske gegevens foar elke brûker en kontrolearret ferskate anomalies yn identifikaasje- en autentikaasjepogingen. Allinnich MS Azure hat ferlykbere funksjonaliteit (as jo it passende abonnemint hawwe).

D'r is in oare swierrichheid - om't foar in protte wolkproviders monitoring fan ynformaasjefeiligens in nij ûnderwerp is dat se krekt begjinne te behanneljen, feroarje se konstant wat yn har oplossingen. Hjoed hawwe se ien ferzje fan de API, moarn in oare, oermorgen in tredde. Jo moatte ek wêze taret op dit. Itselde is wier mei funksjonaliteit, dy't kin feroarje, dy't rekken holden wurde moat yn jo kontrôlesysteem foar ynformaasjefeiligens. Amazon hie bygelyks yn earste ynstânsje aparte tsjinsten foar monitoring fan wolkeveneminten - AWS CloudTrail en AWS CloudWatch. Doe ferskynde in aparte tsjinst foar it kontrolearjen fan eveneminten foar ynformaasjefeiligens - AWS GuardDuty. Nei in skoftke lansearre Amazon in nij behearsysteem, Amazon Security Hub, dat analyse omfettet fan gegevens ûntfongen fan GuardDuty, Amazon Inspector, Amazon Macie en ferskate oaren. In oar foarbyld is it Azure-logyntegraasje-ark mei SIEM - AzLog. It waard aktyf brûkt troch in protte SIEM-leveransiers, oant yn 2018 Microsoft it stopjen fan har ûntwikkeling en stipe oankundige, dy't in protte kliïnten dy't dit ark brûkten konfrontearre mei in probleem (wy sille prate oer hoe't it letter waard oplost).

Kontrolearje dêrom soarchfâldich alle tafersjochfunksjes dy't jo wolkprovider jo biedt. Of fertrouwe op eksterne oplossingproviders dy't sille fungearje as tuskenpersoanen tusken jo SOC en de wolk dy't jo wolle kontrolearje. Ja, it sil djoerder wêze (hoewol net altyd), mar jo sille alle ferantwurdlikens op 'e skouders fan in oar ferpleatse. Of it net allegear? hosted yn 'e wolk. En wy sille begjinne mei wat Amazon biedt yn dit diel.

Foarbyld: Monitoring fan ynformaasjefeiligens yn IaaS basearre op AWS

Ja, ja, ik begryp dat Amazon net it bêste foarbyld is troch it feit dat dit in Amerikaanske tsjinst is en it kin wurde blokkearre as ûnderdiel fan 'e striid tsjin ekstremisme en de fersprieding fan ynformaasje dy't ferbean is yn Ruslân. Mar yn dizze publikaasje wol ik gewoan sjen litte hoe't ferskate wolkplatfoarms ferskille yn har monitoaringsmooglikheden foar ynformaasjefeiligens en wêr't jo op moatte betelje by it oerdragen fan jo kaaiprosessen nei de wolken út in feiligenspunt. No, as guon fan 'e Russyske ûntwikkelders fan wolkoplossingen wat nuttich foar harsels leare, dan sil dat geweldich wêze.

It earste ding om te sizzen is dat Amazon gjin ûntrochsichtbere festing is. Ferskate ynsidinten barre geregeld mei syn kliïnten. Bygelyks, de nammen, adressen, bertedatums en telefoannûmers fan 198 miljoen kiezers waarden stellen út Deep Root Analytics. Israelysk bedriuw Nice Systems stiel 14 miljoen records fan Verizon-abonnees. De ynboude mooglikheden fan AWS kinne jo lykwols in breed oanbod fan ynsidinten detectearje. Bygelyks:

• ynfloed op ynfrastruktuer (DDoS)
• knooppuntkompromis (kommando-ynjeksje)
• account kompromis en sûnder foech tagong
• ferkearde konfiguraasje en kwetsberens
• ûnfeilige ynterfaces en APIs.

Dizze diskrepânsje komt troch it feit dat, lykas wy hjirboppe fûnen, de klant sels ferantwurdlik is foar de feiligens fan klantgegevens. En as hy gjin muoite hat om beskermjende meganismen yn te skeakeljen en gjin tafersjochynstruminten ynskeakele, dan sil hy allinich leare oer it ynsidint fan 'e media of fan syn kliïnten.

Om ynsidinten te identifisearjen, kinne jo in breed oanbod fan ferskate monitoaringstsjinsten brûke dy't ûntwikkele binne troch Amazon (hoewol't dizze faak oanfolle wurde troch eksterne ark lykas osquery). Dat, yn AWS, wurde alle brûkersaksjes kontrolearre, nettsjinsteande hoe't se wurde útfierd - fia de behearkonsole, kommandorigel, SDK of oare AWS-tsjinsten. Alle records fan de aktiviteit fan elk AWS-akkount (ynklusyf brûkersnamme, aksje, tsjinst, aktiviteitsparameters en resultaat) en API-gebrûk binne beskikber fia AWS CloudTrail. Jo kinne dizze eveneminten besjen (lykas AWS IAM-konsole-logins) fan 'e CloudTrail-konsole, analysearje se mei Amazon Athena, of "outsource" se nei eksterne oplossingen lykas Splunk, AlienVault, ensfh. De AWS CloudTrail-logs sels wurde pleatst yn jo AWS S3-emmer.

Twa oare AWS-tsjinsten leverje in oantal oare wichtige tafersjochmooglikheden. As earste, Amazon CloudWatch is in kontrôletsjinst foar AWS-boarnen en applikaasjes dy't jo ûnder oare kinne ferskate anomalies yn jo wolk identifisearje. Alle ynboude AWS-tsjinsten, lykas Amazon Elastic Compute Cloud (servers), Amazon Relational Database Service (databases), Amazon Elastic MapReduce (data-analyse), en 30 oare Amazon-tsjinsten, brûke Amazon CloudWatch om har logs op te slaan. Untwikkelders kinne de iepen API fan Amazon CloudWatch brûke om funksjonaliteit foar logmonitoring ta te foegjen oan oanpaste applikaasjes en tsjinsten, wêrtroch't se de omfang fan analyse fan eveneminten kinne útwreidzje binnen in feiligenskontekst.

Twads lit de tsjinst VPC Flow Logs jo it netwurkferkear analysearje dat ferstjoerd of ûntfongen is troch jo AWS-tsjinners (ekstern as yntern), lykas tusken mikrotsjinsten. As ien fan jo AWS VPC-boarnen ynteraksje mei it netwurk, registrearret VPC Flow Logs details oer it netwurkferkear, ynklusyf de boarne- en bestimmingsnetwurkynterface, lykas ek de IP-adressen, havens, protokol, oantal bytes, en oantal pakketten dat jo hawwe sjo. Dejingen dy't ûnderfine mei lokale netwurkfeiligens sille dit werkenne as analoog oan threads NetFlow, dy't makke wurde kinne troch skeakels, routers en firewalls fan enterprise-grade. Dizze logs binne wichtich foar monitoaring fan ynformaasjebefeiliging, om't, yn tsjinstelling ta eveneminten oer de aksjes fan brûkers en applikaasjes, se jo ek tastean om netwurkynteraksjes net te missen yn 'e AWS firtuele privee wolkomjouwing.

Gearfetsjend jouwe dizze trije AWS-tsjinsten - AWS CloudTrail, Amazon CloudWatch, en VPC Flow Logs - tegearre frij krêftich ynsjoch yn jo akkountgebrûk, brûkersgedrach, ynfrastruktuerbehear, applikaasje- en tsjinstaktiviteit, en netwurkaktiviteit. Se kinne bygelyks brûkt wurde om de folgjende anomalies te ûntdekken:

• Besiket de side te scannen, sykje nei efterdoarren, sykje nei kwetsberens troch bursts fan "404 flaters".
• Ynjeksje oanfallen (bygelyks SQL-ynjeksje) troch bursts fan "500 flaters".
• Bekende oanfalsark binne sqlmap, nikto, w3af, nmap, ensfh. troch analyze fan it fjild User Agent.

Amazon Web Services hat ek oare tsjinsten ûntwikkele foar cybersecurity-doelen wêrmei jo in protte oare problemen kinne oplosse. Bygelyks, AWS hat in ynboude tsjinst foar it kontrolearjen fan belied en konfiguraasjes - AWS Config. Dizze tsjinst leveret kontinu kontrôle fan jo AWS-boarnen en har konfiguraasjes. Litte wy in ienfâldich foarbyld nimme: Litte wy sizze dat jo derfoar soargje wolle dat brûkerswachtwurden op al jo servers útskeakele binne en dat tagong allinich mooglik is op basis fan sertifikaten. AWS Config makket it maklik om dit te kontrolearjen foar al jo servers. Der binne oare belied dat kin tapast wurde op jo wolk tsjinners: "Gjin tsjinner kin brûke haven 22", "Allinne administrators kinne feroarje firewall regels" of "Allinne brûker Ivashko kin meitsje nije brûkers akkounts, en hy kin dwaan It is allinnich op tiisdeis. " Yn 'e simmer fan 2016 waard de AWS Config-tsjinst útwreide om de deteksje fan oertredings fan ûntwikkele belied te automatisearjen. AWS-konfiguraasjeregels binne yn essinsje trochgeande konfiguraasjeoanfragen foar de Amazon-tsjinsten dy't jo brûke, dy't eveneminten generearje as it oerienkommende belied wurdt skeind. Bygelyks, ynstee fan periodyk útfiere AWS Config queries om te kontrolearjen dat alle skiven op in firtuele tsjinner binne fersifere, AWS Config Regels kinne brûkt wurde om kontinu kontrolearje tsjinner skiven om te soargjen dat dizze betingst wurdt foldien. En, it wichtichste, yn 'e kontekst fan dizze publikaasje generearje alle oertredings eveneminten dy't kinne wurde analysearre troch jo tsjinst foar ynformaasjefeiligens.

AWS hat ek syn lykweardich oan tradisjonele oplossings foar bedriuwsgegevensfeiligens, dy't ek befeiligingseveneminten generearje dy't jo kinne en moatte analysearje:

• Ynbraakdeteksje - AWS GuardDuty
• Ynformaasje Leak Control - AWS Macie
• EDR (hoewol it in bytsje nuver oer einpunten yn 'e wolk praat) - AWS Cloudwatch + iepen boarne osquery as GRR-oplossingen
• Netflow-analyse - AWS Cloudwatch + AWS VPC Flow
• DNS-analyze - AWS Cloudwatch + AWS Route53
• AD - AWS Directory Service
• Account Management - AWS IAM
• SSO - AWS SSO
• feiligens analyze - AWS Inspector
• konfiguraasje behear - AWS Config
• WAF - AWS WAF.

Ik sil net alle Amazon-tsjinsten yn detail beskriuwe dy't nuttich kinne wêze yn 'e kontekst fan ynformaasjefeiligens. It wichtichste is om te begripen dat se allegear eveneminten kinne generearje dy't wy kinne en moatte analysearje yn 'e kontekst fan ynformaasjefeiligens, en brûke foar dit doel sawol de ynboude mooglikheden fan Amazon sels as eksterne oplossingen, bygelyks SIEM, dy't kinne nim feiligenseveneminten nei jo tafersjochsintrum en analysearje se dêr tegearre mei eveneminten fan oare wolktsjinsten of fan ynterne ynfrastruktuer, perimeter of mobile apparaten.

Yn alle gefallen begjint it allegear mei de gegevensboarnen dy't jo eveneminten foar ynformaasjefeiligens leverje. Dizze boarnen omfetsje, mar binne net beheind ta:

• CloudTrail - API-gebrûk en brûkersaksjes
• Trusted Advisor - feiligenskontrôle tsjin bêste praktiken
• Config - ynventarisaasje en konfiguraasje fan akkounts en tsjinstynstellingen
• VPC Flow Logs - ferbiningen mei firtuele ynterfaces
• IAM - identifikaasje en autentikaasje tsjinst
• ELB Access Logs - Load Balancer
• Ynspekteur - applikaasje kwetsberens
• S3 - triem opslach
• CloudWatch - Applikaasjeaktiviteit
• SNS is in notifikaasjetsjinst.

Amazon, wylst it oanbieden fan sa'n oanbod fan eveneminteboarnen en ark foar har generaasje, is heul beheind yn har fermogen om de sammele gegevens te analysearjen yn 'e kontekst fan ynformaasjefeiligens. Jo sille de beskikbere logs selsstannich moatte studearje, op syk nei relevante yndikatoaren fan kompromis yn har. AWS Security Hub, dy't Amazon koartlyn lansearre, is fan doel dit probleem op te lossen troch in wolk SIEM foar AWS te wurden. Mar oant no ta is it allinich oan it begjin fan har reis en wurdt beheind sawol troch it oantal boarnen wêrmei't it wurket en troch oare beheiningen fêststeld troch de arsjitektuer en abonneminten fan Amazon sels.

Foarbyld: Monitoring fan ynformaasjefeiligens yn IaaS basearre op Azure

Ik wol net yn in lange diskusje komme oer hokker fan 'e trije wolkproviders (Amazon, Microsoft of Google) better is (benammen om't elk fan har noch har eigen spesifike spesifikaasjes hat en geskikt is foar it oplossen fan har eigen problemen); Litte wy ús konsintrearje op de monitoaringsmooglikheden fan ynformaasjefeiligens dy't dizze spilers leverje. It moat wurde talitten dat Amazon AWS wie ien fan de earste yn dit segmint en dêrom hat advanced it fierst yn termen fan syn ynformaasje feiligens funksjes (hoewol't in protte tajaan dat se binne lestich te brûken). Mar dit betsjut net dat wy de kânsen sille negearje dy't Microsoft en Google ús jouwe.

Microsoft-produkten binne altyd ûnderskieden troch har "iepenheid" en yn Azure is de situaasje fergelykber. Bygelyks, as AWS en GCP altyd útgean fan it konsept fan "wat net tastien is is ferbean", dan hat Azure de krekte tsjinoerstelde oanpak. Bygelyks, by it meitsjen fan in firtuele netwurk yn 'e wolk en in firtuele masine dêryn, binne alle havens en protokollen standert iepen en tastien. Dêrom moatte jo in bytsje mear muoite besteegje oan 'e earste opset fan it tagongskontrôlesysteem yn' e wolk fan Microsoft. En dit stelt ek strangere easken oan jo yn termen fan tafersjochaktiviteit yn 'e Azure-wolk.

AWS hat in eigenaardichheid ferbûn mei it feit dat as jo jo firtuele boarnen kontrolearje, as se yn ferskate regio's lizze, jo swierrichheden hawwe by it kombinearjen fan alle eveneminten en har unifoarme analyze, om te eliminearjen wat jo moatte taflecht ta ferskate trúkjes, lykas Meitsje jo eigen koade foar AWS Lambda dy't eveneminten sil ferfiere tusken regio's. Azure hat dit probleem net - syn Activity Log-meganisme folget alle aktiviteiten oer de heule organisaasje sûnder beheiningen. Itselde jildt foar AWS Security Hub, dy't koartlyn ûntwikkele waard troch Amazon om in protte feiligensfunksjes te konsolidearjen binnen ien befeiligingssintrum, mar allinich binnen har regio, dy't lykwols net relevant is foar Ruslân. Azure hat in eigen Feiligenssintrum, dat net bûn is troch regionale beheiningen, en jout tagong ta alle feiligensfunksjes fan it wolkplatfoarm. Boppedat kin it foar ferskate pleatslike teams in eigen set fan beskermjende mooglikheden leverje en ûnder oare befeiligingseveneminten beheard troch har. AWS Security Hub is noch op 'e manier om fergelykber te wurden mei Azure Security Center. Mar it is it wurdich om in fly yn 'e salve ta te foegjen - jo kinne in protte út Azure drukke fan wat earder beskreaun is yn AWS, mar dit wurdt it meast handich allinich dien foar Azure AD, Azure Monitor en Azure Security Center. Alle oare Azure-feiligensmeganismen, ynklusyf analyse fan befeiligingseveneminten, wurde noch net op 'e meast handige manier beheard. It probleem wurdt foar in part oplost troch de API, dy't alle Microsoft Azure-tsjinsten trochkringt, mar dit sil ekstra ynspanningen fan jo fereaskje om jo wolk te yntegrearjen mei jo SOC en de oanwêzigens fan kwalifisearre spesjalisten (feitlik, krekt as mei elke oare SIEM dy't wurket mei wolk API's). Guon SIEM's, dy't letter sille wurde besprutsen, stypje al Azure en kinne de taak om it te kontrolearjen automatisearje, mar it hat ek syn eigen swierrichheden - net allegear kinne alle logs sammelje dy't Azure hat.

Event-kolleksje en -monitoring yn Azure wurdt levere mei de Azure Monitor-tsjinst, dat is it wichtichste ark foar it sammeljen, opslaan en analysearjen fan gegevens yn 'e Microsoft-wolk en har boarnen - Git-repositories, konteners, firtuele masines, applikaasjes, ensfh. Alle gegevens sammele troch Azure Monitor binne ferdield yn twa kategoryen - metriken, sammele yn echte tiid en beskriuwende wichtige prestaasjes fan 'e Azure-wolk, en logs, mei gegevens organisearre yn records dy't bepaalde aspekten fan' e aktiviteit fan Azure-boarnen en tsjinsten karakterisearje. Derneist, mei help fan de Data Collector API, kin de Azure Monitor-tsjinst gegevens sammelje fan elke REST-boarne om syn eigen tafersjochscenario's te bouwen.

Hjir binne in pear boarnen foar befeiligingseveneminten dy't Azure jo biedt en dat jo tagong kinne fia de Azure Portal, CLI, PowerShell, of REST API (en guon allinich fia de Azure Monitor/Insight API):

• Aktiviteitslogboeken - dit log beantwurdet de klassike fragen fan "wa", "wat," en "wannear" oangeande elke skriuwoperaasje (PUT, POST, DELETE) op wolkboarnen. Eveneminten yn ferbân mei lêzen tagong (GET) binne net opnommen yn dit log, lykas in oantal oaren.
• Diagnostyske logs - befettet gegevens oer operaasjes mei in bepaalde boarne opnommen yn jo abonnemint.
• Azure AD-rapportaazje - befettet sawol brûkersaktiviteit as systeemaktiviteit relatearre oan groep- en brûkersbehear.
• Windows Event Log en Linux Syslog - befettet eveneminten fan firtuele masines hosted yn 'e wolk.
• Metriken - befettet telemetry oer de prestaasjes en sûnensstatus fan jo wolktsjinsten en boarnen. Elke minút mjitten en opslein. binnen 30 dagen.
• Network Security Group Flow Logs - befettet gegevens oer netwurkfeiligenseveneminten sammele mei de Network Watcher-tsjinst en boarnemonitoring op netwurknivo.
• Storage Logs - befettet eveneminten yn ferbân mei tagong ta opslachfasiliteiten.

Foar tafersjoch kinne jo eksterne SIEM's brûke as de ynboude Azure Monitor en syn tafoegings. Wy sille letter oer ynformaasjefeiligens-evenemintbehearsystemen prate, mar litte wy no sjen wat Azure sels ús biedt foar gegevensanalyse yn 'e kontekst fan feiligens. It haadskerm foar alles befeiligingsrelatearre yn Azure Monitor is it Log Analytics Feiligens en Audit Dashboard (de fergese ferzje stipet in beheinde hoemannichte evenemint opslach foar mar ien wike). Dit dashboard is ferdield yn 5 haadgebieten dy't gearfettingsstatistiken visualisearje fan wat der bart yn 'e wolkomjouwing dy't jo brûke:

• Feiligensdomeinen - wichtige kwantitative yndikatoaren yn ferbân mei ynformaasjefeiligens - it oantal ynsidinten, it oantal kompromitteare knopen, unpatched knopen, eveneminten foar netwurkfeiligens, ensfh.
• Opmerklike problemen - toant it oantal en belang fan aktive ynformaasjefeiligensproblemen
• Deteksjes - toant patroanen fan oanfallen brûkt tsjin jo
• Threat Intelligence - toant geografyske ynformaasje oer eksterne knooppunten dy't jo oanfalle
• Algemiene befeiligingsfragen - typyske fragen dy't jo helpe om jo ynformaasjefeiligens better te kontrolearjen.

Azure Monitor-útwreidingen omfetsje Azure Key Vault (beskerming fan kryptografyske kaaien yn 'e wolk), Malware Assessment (analyze fan beskerming tsjin kweade koade op firtuele masines), Azure Application Gateway Analytics (analyze fan ûnder oaren wolk-firewall-logs), ensfh. . Dizze ark, ferrike mei bepaalde regels foar it ferwurkjen fan eveneminten, kinne jo ferskate aspekten fan 'e aktiviteit fan wolktsjinsten fisualisearje, ynklusyf feiligens, en bepaalde ôfwikingen fan operaasje identifisearje. Mar, lykas faaks bart, fereasket elke ekstra funksjonaliteit in korrespondearjend betelle abonnemint, dat sil fereaskje oerienkommende finansjele ynvestearrings fan jo, dy't jo moatte planne foarôf.

Azure hat in oantal ynboude mooglikheden foar bedrigingsmonitoring dy't binne yntegrearre yn Azure AD, Azure Monitor, en Azure Security Center. Under harren, bygelyks, deteksje fan ynteraksje fan firtuele masines mei bekende kweade IP's (fanwege de oanwêzigens fan yntegraasje mei Threat Intelligence tsjinsten fan Microsoft), detectie fan malware yn 'e wolk ynfrastruktuer troch ûntfangst fan alaarms fan firtuele masines hosted yn' e wolk, wachtwurd rieden oanfallen ” op firtuele masines, kwetsberens yn 'e konfiguraasje fan it brûkersidentifikaasjesysteem, ynlogge op it systeem fan anonymizers of ynfekteare knopen, accountlekken, ynlogge yn it systeem fan ûngewoane lokaasjes, ensfh. Azure is hjoed ien fan 'e pear wolkproviders dy't jo ynboude Threat Intelligence-mooglikheden biedt om sammele eveneminten foar ynformaasjefeiligens te ferrykjen.

Lykas hjirboppe neamde, binne de befeiligingsfunksjonaliteit en, as gefolch, de befeiligingseveneminten dy't dêrtroch generearre binne net beskikber foar alle brûkers, mar fereaskje in bepaald abonnemint dat de funksjonaliteit omfettet dy't jo nedich binne, dy't de passende eveneminten genereart foar monitoring fan ynformaasjefeiligens. Bygelyks, guon fan 'e funksjes beskreaun yn' e foarige paragraaf foar it kontrolearjen fan anomalies yn akkounts binne allinich beskikber yn 'e P2 premium lisinsje foar de Azure AD-tsjinst. Sûnder it sille jo, lykas yn it gefal fan AWS, de sammele feiligenseveneminten "hânmjittich" moatte analysearje. En ek, ôfhinklik fan it type Azure AD-lisinsje, sille net alle eveneminten beskikber wêze foar analyse.

Op it Azure-portaal kinne jo sawol sykfragen beheare foar logs fan belang foar jo en dashboards ynstelle om wichtige yndikatoaren foar ynformaasjefeiligens te visualisearjen. Dêrnjonken kinne jo Azure Monitor-útwreidingen selektearje, wêrtroch jo de funksjonaliteit fan Azure Monitor-logs útwreidzje kinne en in djippere analyze fan eveneminten krije fan in feiligenspunt.

As jo ​​​​net allinich de mooglikheid hawwe om te wurkjen mei logs, mar in wiidweidich befeiligingssintrum foar jo Azure-wolkplatfoarm, ynklusyf behear fan ynformaasjefeiligensbelied, dan kinne jo prate oer de needsaak om te wurkjen mei Azure Security Center, wêrfan de measte nuttige funksjes binne beskikber foar wat jild, Bygelyks, bedriging detection, tafersjoch bûten Azure, compliance assessment, etc. (yn 'e fergese ferzje hawwe jo allinich tagong ta in befeiligingsbeoardieling en oanbefellings foar it eliminearjen fan identifisearre problemen). It konsolidearret alle feiligensproblemen op ien plak. Yn feite kinne wy ​​​​prate oer in heger nivo fan ynformaasjefeiligens dan Azure Monitor jo leveret, om't yn dit gefal de gegevens sammele yn jo wolkfabryk wurde ferrike mei in protte boarnen, lykas Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX . .

Azure hat ek in eigen SIEM - it ferskynde oan it begjin fan 2019. Dit is Azure Sentinel, dy't fertrout op gegevens fan Azure Monitor en kin ek yntegrearje mei. eksterne feiligens oplossings (Bygelyks, NGFW of WAF), de list fan dat wurdt hieltyd groeit. Derneist, troch de yntegraasje fan 'e Microsoft Graph Security API, hawwe jo de mooglikheid om jo eigen Threat Intelligence-feeds te ferbinen mei Sentinel, dy't de mooglikheden ferriket foar it analysearjen fan ynsidinten yn jo Azure-wolk. It kin beweare wurde dat Azure Sentinel de earste "native" SIEM is dy't ferskynde fan wolkproviders (deselde Splunk as ELK, dy't yn 'e wolk kinne wurde host, bygelyks AWS, binne noch altyd net ûntwikkele troch tradisjonele wolktsjinstferlieners). Azure Sentinel en Feiligenssintrum kinne SOC wurde neamd foar de Azure-wolk en kinne wurde beheind ta har (mei bepaalde reservearrings) as jo gjin ynfrastruktuer mear hawwe en jo al jo komputerboarnen oerbrocht hawwe nei de wolk en it soe de Microsoft cloud Azure wêze.

Mar om't de ynboude mooglikheden fan Azure (sels as jo in abonnemint op Sentinel hawwe) faak net genôch binne foar it kontrolearjen fan ynformaasjefeiligens en it yntegrearjen fan dit proses mei oare boarnen fan feiligenseveneminten (sawol wolk as ynterne), is d'r in moatte de sammele gegevens eksportearje nei eksterne systemen, wêryn SIEM kin omfetsje. Dit wurdt dien sawol mei it brûken fan de API as it brûken fan spesjale tafoegings, dy't op it stuit offisjeel allinich beskikber binne foar de folgjende SIEM's - Splunk (Azure Monitor Add-On foar Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight en ELK. Oant koartlyn wiene d'r mear sokke SIEM's, mar fan 1 juny 2019 stoppe Microsoft it stypjen fan it Azure Log Integration Tool (AzLog), dat by it begjin fan it bestean fan Azure en by it ûntbrekken fan normale standerdisearring fan wurkjen mei logs (Azure) Monitor bestie noch net iens) makke it maklik yntegrearjen fan eksterne SIEM mei de Microsoft-wolk. No is de situaasje feroare en Microsoft advisearret it Azure Event Hub-platfoarm as it haadyntegraasje-ark foar oare SIEM's. In protte hawwe sa'n yntegraasje al ymplementearre, mar wês foarsichtich - se kinne net alle Azure-logs fange, mar allinich guon (sjoch yn 'e dokumintaasje foar jo SIEM).

As ôfsluting fan in koarte ekskurzje nei Azure, wol ik in algemiene oanbefelling jaan oer dizze wolktsjinst - foardat jo wat sizze oer de funksjes foar kontrôle fan ynformaasjefeiligens yn Azure, moatte jo se tige foarsichtich konfigurearje en testen dat se wurkje lykas skreaun yn 'e dokumintaasje en lykas de adviseurs jo Microsoft fertelden (en se kinne ferskate werjeften hawwe oer de funksjonaliteit fan Azure-funksjes). As jo ​​​​de finansjele middels hawwe, kinne jo in protte nuttige ynformaasje fan Azure útdrukke yn termen fan tafersjoch op ynformaasjefeiligens. As jo ​​​​boarnen beheind binne, dan moatte jo, lykas yn it gefal fan AWS, allinich fertrouwe op jo eigen krêft en de rauwe gegevens dy't Azure Monitor jo leveret. En tink derom dat in protte tafersjochfunksjes jild kostje en it is better om jo fan tefoaren bekend te meitsjen mei it priisbelied. Jo kinne bygelyks fergees 31 dagen oan gegevens opslaan oant in maksimum fan 5 GB per klant - it oersjen fan dizze wearden sil jo ekstra jild fereaskje (sawat $2+ foar it opslaan fan elke ekstra GB fan 'e klant en $0,1 foar opslach fan 1 GB elke ekstra moanne). Wurkje mei applikaasje-telemetry en metriken kin ek ekstra fûnsen fereaskje, en ek wurkje mei warskôgings en notifikaasjes (in bepaalde limyt is fergees beskikber, wat miskien net genôch is foar jo behoeften).

Foarbyld: Monitoring fan ynformaasjefeiligens yn IaaS basearre op Google Cloud Platform

Google Cloud Platform liket op in jongere yn ferliking mei AWS en Azure, mar dit is foar in part goed. Oars as AWS, dy't har mooglikheden fergrutte, ynklusyf feiligens, stadichoan, problemen mei sintralisaasje; GCP, lykas Azure, wurdt folle better sintraal beheard, wat flaters en ymplemintaasjetiid yn 'e ûndernimming ferminderet. Ut in feiligens eachpunt is GCP, frjemd genôch, tusken AWS en Azure. Hy hat ek in inkele evenemint registraasje foar de hiele organisaasje, mar it is net kompleet. Guon funksjes binne noch yn beta-modus, mar stadichoan moat dit tekoart elimineare wurde en GCP sil in mear folwoeksen platfoarm wurde yn termen fan tafersjoch op ynformaasjefeiligens.

It wichtichste ark foar it loggen fan eveneminten yn GCP is Stackdriver Logging (lykas Azure Monitor), wêrtroch jo eveneminten kinne sammelje oer jo heule wolkynfrastruktuer (lykas fan AWS). Fanút in feiligensperspektyf yn GCP hat elke organisaasje, projekt of map fjouwer logs:

• Admin Activity - befettet alle eveneminten yn ferbân mei bestjoerlike tagong, bygelyks it meitsjen fan in firtuele masine, wizigjen fan tagongsrjochten, ensfh. Dit log wurdt altyd skreaun, nettsjinsteande jo winsk, en bewarret syn gegevens foar 400 dagen.
• Gegevens tagong - befettet alle eveneminten yn ferbân mei wurkjen mei gegevens troch wolk brûkers (oanmeitsjen, wizigjen, lêzen, ensfh.). Standert wurdt dit log net skreaun, om't syn folume tige fluch opswelt. Om dizze reden is har houdbaarheid mar 30 dagen. Boppedat stiet net alles yn dit blêd. Bygelyks, eveneminten yn ferbân mei boarnen dy't iepenbier tagonklik binne foar alle brûkers of dy't tagonklik binne sûnder oan te melden by GCP wurde der net nei skreaun.
• Systeemevenemint - befettet systeemeveneminten dy't net relatearre binne oan brûkers, of aksjes fan in behearder dy't de konfiguraasje fan wolkboarnen feroaret. It wurdt altyd skreaun en bewarre foar 400 dagen.
• Access Transparency is in unyk foarbyld fan in loch dat alle aksjes fan Google-meiwurkers (mar noch net foar alle GCP-tsjinsten) fange dy't tagong krije ta jo ynfrastruktuer as ûnderdiel fan har wurktaken. Dit log wurdt opslein foar 400 dagen en is net beskikber foar elke GCP-kliïnt, mar allinich as oan in oantal betingsten foldien wurdt (stipe Gold of Platinum nivo, of de oanwêzigens fan 4 rollen fan in bepaald type as ûnderdiel fan bedriuwsstipe). In ferlykbere funksje is ek beskikber, bygelyks yn Office 365 - Lockbox.

Log foarbyld: Access Transparency

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

Tagong ta dizze logs is mooglik op ferskate manieren (op deselde manier as earder besprutsen Azure en AWS) - fia de Log Viewer-ynterface, fia de API, fia de Google Cloud SDK, of fia de Aktiviteitsside fan jo projekt wêrfoar jo binne ynteressearre yn eveneminten. Op deselde wize kinne se eksportearre wurde nei eksterne oplossingen foar ekstra analyse. Dat lêste wurdt dien troch logs te eksportearjen nei BigQuery of Cloud Pub / Sub-opslach.

Neist Stackdriver Logging biedt it GCP-platfoarm ek Stackdriver Monitoring-funksjonaliteit, wêrtroch jo wichtige metriken (prestaasjes, MTBF, algemiene sûnens, ensfh.) fan wolktsjinsten en applikaasjes kinne kontrolearje. Ferwurke en fisualisearre gegevens kinne it makliker meitsje om problemen te finen yn jo wolkynfrastruktuer, ynklusyf yn 'e kontekst fan feiligens. Mar it moat opmurken wurde dat dizze funksjonaliteit net heul ryk sil wêze yn 'e kontekst fan ynformaasjefeiligens, om't hjoed GCP gjin analoog hat fan deselde AWS GuardDuty en kin gjin minne identifisearje ûnder alle registrearre eveneminten (Google hat Event Threat Detection ûntwikkele, mar it is noch yn ûntwikkeling yn beta en it is te betiid om te praten oer syn nut. Stackdriver Monitoring koe wurde brûkt as in systeem foar it opspoaren fan anomalies, dat soe dan wurde ûndersocht om de oarsaken fan har foarkommen te finen. Mar sjoen it gebrek oan personiel dat kwalifisearre is op it mêd fan GCP-ynformaasjefeiligens op 'e merke, sjocht dizze taak op it stuit dreech.

It is ek de muoite wurdich om in list te jaan fan guon ynformaasjebefeiligingsmodules dy't kinne wurde brûkt yn jo GCP-wolk, en dy't fergelykber binne mei wat AWS biedt:

• Cloud Security Command Center is in analoog fan AWS Security Hub en Azure Security Center.
• Cloud DLP - Automatysk ûntdekken en bewurkjen (bygelyks maskering) fan gegevens hosted yn 'e wolk mei mear dan 90 foarôf definieare klassifikaasjebelied.
• Cloud Scanner is in scanner foar bekende kwetsberens (XSS, Flash Injection, unpatched bibleteken, ensfh.) yn App Engine, Compute Engine en Google Kubernetes.
• Cloud IAM - Kontrolearje tagong ta alle GCP-boarnen.
• Cloud Identity - Behear GCP-brûkers-, apparaat- en applikaasjeakkounts fanút ien konsole.
• Cloud HSM - beskerming fan kryptografyske kaaien.
• Cloud Key Management Service - behear fan kryptografyske kaaien yn GCP.
• VPC Service Control - Meitsje in feilige perimeter om jo GCP-boarnen om se te beskermjen tsjin lekken.
• Titan Security Key - beskerming tsjin phishing.

In protte fan dizze modules generearje befeiligingseveneminten dy't kinne wurde stjoerd nei BigQuery opslach foar analyse of eksportearje nei oare systemen, ynklusyf SIEM. Lykas hjirboppe neamd, is GCP in aktyf ûntwikkeljen platfoarm en Google ûntwikkelet no in oantal nije ynformaasjebefeiligingsmodules foar har platfoarm. Under harren binne Event Threat Detection (no beskikber yn beta), dy't Stackdriver-logboeken scant op syk nei spoaren fan net-autorisearre aktiviteit (analooch oan GuardDuty yn AWS), of Policy Intelligence (beskikber yn alfa), wêrtroch jo yntelligint belied kinne ûntwikkelje foar tagong ta GCP-boarnen.

Ik makke in koart oersjoch fan de ynboude tafersjochmooglikheden yn populêre wolkplatfoarms. Mar hawwe jo spesjalisten dy't kinne wurkje mei "rauwe" IaaS provider logs (net elkenien is ree om te keapjen de avansearre mooglikheden fan AWS of Azure of Google)? Derneist binne in protte bekend mei it adage "fertrouwe, mar ferifiearje", dat wierer is dan ea op it mêd fan feiligens. Hoefolle fertrouwe jo de ynboude mooglikheden fan 'e wolkprovider dy't jo eveneminten foar ynformaasjefeiligens stjoere? Hoefolle rjochtsje se har überhaupt op ynformaasjefeiligens?

Soms is it de muoite wurdich om te sjen nei oplossings foar monitoring fan overlay-wolkynfrastruktuer dy't de ynboude wolkfeiligens kinne oanfolje, en soms binne sokke oplossingen de ienige opsje om ynsjoch te krijen yn 'e feiligens fan jo gegevens en applikaasjes dy't yn 'e wolk wurde host. Derneist binne se gewoan handiger, om't se alle taken nimme om de nedige logs te analysearjen dy't generearre binne troch ferskate wolktsjinsten fan ferskate wolkproviders. In foarbyld fan sa'n overlay-oplossing is Cisco Stealthwatch Cloud, dy't rjochte is op ien taak - it kontrolearjen fan anomalies fan ynformaasjefeiligens yn wolkomjouwings, ynklusyf net allinich Amazon AWS, Microsoft Azure en Google Cloud Platform, mar ek privee wolken.

Foarbyld: Monitoring fan ynformaasjefeiligens mei Stealthwatch Cloud

AWS biedt in fleksibele kompjûterplatfoarm, mar dizze fleksibiliteit makket it makliker foar bedriuwen om flaters te meitsjen dy't liede ta feiligensproblemen. En it model foar dielde ynformaasjebefeiliging draacht dêr allinich by oan. It útfieren fan software yn 'e wolk mei ûnbekende kwetsberens (bekende kinne wurde bestriden, bygelyks troch AWS Inspector of GCP Cloud Scanner), swakke wachtwurden, ferkearde konfiguraasjes, ynsiders, ensfh. En dit alles wurdt wjerspegele yn it gedrach fan wolk boarnen, dat kin wurde kontrolearre troch Cisco Stealthwatch Cloud, dat is in ynformaasje feiligens tafersjoch en oanfal detection systeem. iepenbiere en partikuliere wolken.

Ien fan 'e wichtichste skaaimerken fan Cisco Stealthwatch Cloud is de mooglikheid om entiteiten te modellearjen. Mei it kinne jo in softwaremodel meitsje (dat is, in hast-real-time simulaasje) fan elk fan jo wolkboarnen (it makket net út oft it AWS, Azure, GCP, of wat oars is). Dizze kinne servers en brûkers omfetsje, lykas boarnetypen spesifyk foar jo wolkomjouwing, lykas feiligensgroepen en auto-skaalgroepen. Dizze modellen brûke struktureare gegevensstreamen levere troch wolktsjinsten as ynfier. Foar AWS soene dit bygelyks VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda, en AWS IAM wêze. Entiteitsmodellering ûntdekt automatysk de rol en gedrach fan ien fan jo boarnen (jo kinne prate oer profilearjen fan alle wolkaktiviteiten). Dizze rollen omfetsje Android as Apple mobyl apparaat, Citrix PVS-tsjinner, RDP-tsjinner, e-postpoarte, VoIP-kliïnt, terminaltsjinner, domeincontroller, ensfh. It folget dan kontinu har gedrach om te bepalen wannear't risikofolle of feilichheidsbedreigend gedrach optreedt. Jo kinne it rieden fan wachtwurden, DDoS-oanfallen, gegevenslekken, yllegale tagong op ôfstân, kweade koadeaktiviteit, kwetsberens skennen en oare bedrigingen identifisearje. Dit is bygelyks wat it ûntdekken fan in besykjen op ôfstân tagong fan in lân dat atypysk is foar jo organisaasje (Súd-Korea) nei in Kubernetes-kluster fia SSH derút sjocht:

En dit is hoe't it sabeare lek fan ynformaasje út 'e Postgress-database nei in lân sjocht wêrmei't wy net earder ynteraksje hawwe tsjinkaam:

Uteinlik, dit is wat tefolle mislearre SSH-pogingen út Sina en Yndoneezje fan in ekstern apparaat op ôfstân sjogge:

Of stel dat de servereksimplaar yn 'e VPC, troch belied, nea in bestimming foar oanmelding op ôfstân is. Litte wy fierders oannimme dat dizze kompjûter in oanmelding op ôfstân ûnderfûn fanwegen in ferkearde feroaring yn it belied foar firewallregels. De funksje Entity Modeling sil dizze aktiviteit (“Ungewoane tagong op ôfstân”) yn hast realtime detektearje en rapportearje en ferwize nei de spesifike AWS CloudTrail, Azure Monitor, of GCP Stackdriver Logging API-oprop (ynklusyf brûkersnamme, datum en tiid, ûnder oare details ). dy't de wiziging yn 'e ITU-regel frege. En dan kin dizze ynformaasje stjoerd wurde nei SIEM foar analyse.

Fergelykbere mooglikheden wurde ymplementearre foar elke wolkomjouwing stipe troch Cisco Stealthwatch Cloud:

Entiteitsmodellering is in unike foarm fan feiligensautomatisearring dy't in earder ûnbekend probleem mei jo minsken, prosessen of technology kin ûntdekke. Sa kinne jo bygelyks befeiligingsproblemen opspoare lykas:

• Hat immen in efterdoar ûntdutsen yn 'e software dy't wy brûke?
• Is d'r software of apparaat fan tredden yn ús wolk?
• Misbrûkt de autorisearre brûker rjochten?
• Wie der in konfiguraasjeflater dy't tagong op ôfstân of oar ûnbedoeld gebrûk fan boarnen tastien?
• Is d'r in gegevenslek fan ús servers?
• Wie immen besocht te ferbinen mei ús út in atypyske geografyske lokaasje?
• Is ús wolk besmet mei kweade koade?

In ûntdutsen evenemint foar ynformaasjefeiligens kin stjoerd wurde yn 'e foarm fan in oerienkommende ticket nei Slack, Cisco Spark, it PagerDuty-ynsidintbehearsysteem, en ek stjoerd nei ferskate SIEM's, ynklusyf Splunk of ELK. Om gearfetsje kinne wy ​​​​sizze dat as jo bedriuw in multi-wolkstrategy brûkt en net beheind is ta ien wolkprovider, de hjirboppe beskreaune mooglikheden foar tafersjoch fan ynformaasjefeiligens, dan is it brûken fan Cisco Stealthwatch Cloud in goede opsje om in unifoarme set fan tafersjoch te krijen mooglikheden foar de liedende wolkspilers - Amazon, Microsoft en Google. It meast nijsgjirrige is dat as jo de prizen foar Stealthwatch Cloud fergelykje mei avansearre lisinsjes foar monitoring fan ynformaasjefeiligens yn AWS, Azure of GCP, kin it blike dat de Cisco-oplossing noch goedkeaper sil wêze as de ynboude mooglikheden fan Amazon, Microsoft en Google oplossingen. It is paradoksaal, mar it is wier. En hoe mear wolken en har mooglikheden jo brûke, hoe dúdliker it foardiel fan in konsolidearre oplossing sil wêze.

Dêrnjonken kin Stealthwatch Cloud privee wolken kontrolearje dy't yn jo organisaasje ynset binne, bygelyks op basis fan Kubernetes-konteners of troch te kontrolearjen fan Netflow-streamen of netwurkferkear ûntfongen troch spegeljen yn netwurkapparatuer (sels binnenlânsk produsearre), AD-gegevens of DNS-tsjinners ensfh. Al dizze gegevens sille wurde ferrike mei Threat Intelligence-ynformaasje sammele troch Cisco Talos, de grutste net-regearingsgroep fan cybersecurity-bedrigingsûndersikers yn 'e wrâld.

Hjirmei kinne jo in unifoarm tafersjochsysteem ymplementearje foar sawol iepenbiere as hybride wolken dy't jo bedriuw kin brûke. De sammele ynformaasje kin dan analysearre wurde mei de ynboude mooglikheden fan Stealthwatch Cloud of stjoerd nei jo SIEM (Splunk, ELK, SumoLogic en ferskate oaren wurde standert stipe).

Hjirmei sille wy it earste diel fan it artikel foltôgje, wêryn't ik de ynboude en eksterne ark beoardiele foar it kontrolearjen fan ynformaasjefeiligens fan IaaS / PaaS-platfoarms, wêrtroch't wy fluch detectearje en reagearje op ynsidinten dy't foarkomme yn 'e wolkomjouwings dy't ús bedriuw hat keazen. Yn it twadde diel sille wy it ûnderwerp trochgean en besjen op opsjes foar it kontrolearjen fan SaaS-platfoarms mei it foarbyld fan Salesforce en Dropbox, en wy sille ek besykje alles gearfetsje en te kombinearjen troch it meitsjen fan in unifoarme kontrôlesysteem foar ynformaasjefeiligens foar ferskate wolkproviders.

Boarne: www.habr.com