Myslíte si, že ve složitém světě cloudové bezpečnosti stačí tradiční detekční metody založené na pravidlech k boji proti neustále se vyvíjejícím kybernetickým hrozbám? Vezměme si například hrozbu sprejování hesel, kdy se aktéři hrozeb pokoušejí získat neoprávněný přístup systematickým zkoušením několika běžně používaných hesel napříč mnoha účty. Abychom tyto anomálie zachytili, náš počáteční přístup zahrnoval sledování náhlého nárůstu neúspěšných pokusů o přihlášení překračujících definovaný práh. Problém však měl více komplikací, například co když je aktérem nový uživatel nebo administrátor provádějící testy napříč mnoha účty? Takže jsme upravili naše pravidlo tak, aby vyhovovalo těmto scénářům, ale toto ruční ladění bylo velmi neefektivní.
Ve společnosti Oracle Cloud Infrastructure (OCI), abychom si udrželi náskok ve složitém prostředí cloudového zabezpečení, jsme přepsali strategie detekce hrozeb integrací strojového učení (ML) do arzenálu Cloud Guard. Cloud Guard je impozantní strážce, který používá modely ML nejen k reakci na hrozby, ale také k jejich předvídání a předcházení pro transformativní detekci bezpečnostních hrozeb. Náš první model ML v rámci Cloud Guard zahrnoval datové body, jako je reputace IP, neznámá umístění a chování událostí při uzamčení.
Během toho jsme strávili nespočet hodin laděním toho, proč model nefungoval tak, jak se očekávalo v produkčním prostředí. Jaký byl trend přesnosti našeho modelu v průběhu času a jaké faktory způsobily její zvýšení nebo snížení? Při hledání odpovědí na tyto otázky jsme si uvědomili, že ke skutečné revoluci v zabezpečení cloudu potřebujeme víc než jen špičkovou technologii. Potřebovali jsme holistický přístup, abychom zefektivnili a zautomatizovali celý životní cyklus strojového učení, což podnítilo zrod našich operací strojového učení (MLOps). Každý krok, od školení a nasazení modelu až po průběžné monitorování a optimalizaci, byl zásadní v naší snaze zůstat o krok napřed před protivníky.
V tomto příspěvku na blogu vás provedeme cestou, jak jsme rozvinuli řešení mnoha problémů s budováním, údržbou, nasazením a monitorováním těchto modelů ML, abychom transformovali zabezpečení cloudu pomocí síly MLOps.
Začátek MLO v rámci ekosystému Cloud Guard
Měli jste někdy problémy s monitorováním a reakcí na bezpečnostní hrozby pro tisíce zákazníků? Průběh detekce hrozeb Cloud Guard nepřetržitě monitoruje bezpečnostní hrozby v cloudových prostředích a reaguje na ně. Jak se však zákaznická základna OCI rozšiřovala, složitost monitorování, detekce a reakce na hrozby si vyžádala změnu paradigmatu od konvenčních metod. Vydali jsme se na cestu vývoje modelů ML s cílem transformovat detekci bezpečnostních hrozeb pro naše stovky tisíc zákazníků.
Jak se modely ML používají k detekci hrozeb? Představte si, že bezpečnostní analytik zkoumá bezpečnostní incident. Analytik obvykle posuzuje současné chování herce jeho porovnáním s historickými aktivitami herce, což je proces známý jako individuální profilování. Analytik může také porovnat chování herce s chováním jejich kolegů v organizaci, známé jako skupinové profilování. Automatizace těchto strategií pomocí ML nám pomohla nejen generovat výsledky, ale také poskytnout promyšlené úvahy.
Tyto modely ML analyzují data, aby detekovaly anomálie, chování a signatury hrozeb a přiřazovaly skóre rizik pro stanovení priorit. Obrázek 1 znázorňuje kanál detekce hrozeb od příjmu dat po zobrazení bezpečnostních problémů v konzole Oracle Cloud Console. Neustálým učením se z nových dat a přizpůsobováním se vyvíjejícím se hrozbám pomáhají modely ML v Cloud Guard zlepšit schopnost platformy efektivně chránit cloudová prostředí. Prostřednictvím skupinových metod a prediktivní analýzy přispívají ke komplexnímu zabezpečení, zmírňují rizika a zavádějí proaktivní obranné strategie.
Obrázek 1: Průběh detekce hrozeb Cloud Guard
Každý model ML je nedílnou součástí tohoto složitého systému a prochází mnohostrannou cestou známou jako životní cyklus modelu ML. Tato cesta zahrnuje fáze od počátečního nápadu a sběru dat po modelový trénink, nasazení, průběžné monitorování a zlepšování. Stupně jsou propojeny a jakákoliv neefektivita nebo problémy v jedné fázi se mohou projevit v celém systému, což podtrhuje zásadní potřebu zefektivnit životní cyklus modelu ML při konstrukci platformy.
Obrázek 2: Životní cyklus modelu ML
Když jsme se vydali na cestu vývoje modelu ML, detektor sprejování hesel byl prvním detektorem ML, který jsme vyvinuli v rámci Cloud Guard pro boj s rostoucí hrozbou pokusů o neoprávněný přístup. Tento projekt byl zahájen návrhem nastíněným s cíli detekce, potenciálními datovými sadami, navrženými modely ML a výsledky práce na proof-of-concept (PoC). To připravilo půdu pro inkluzivní diskusi zahrnující projektové manažery, datové vědce a inženýry, aby zhodnotili proveditelnost návrhu.
Po schválení návrhu jsme přešli z ideové fáze do fáze zpracování dat. Jako hlavní zdroj dat jsme zvolili protokol OCI Audit, protože zahrnoval přihlašovací aktivity a související IP adresy, které jsou pro nás užitečné pro extrakci funkcí, jako jsou úspěšné a neúspěšné pokusy o přihlášení, reputace IP adresy a geolokace. Vytvoření profilů prvků pro každého uživatele se stalo stěžejním předpokladem pro následující fázi modelování.
Když jsme se ponořili do vývoje modelu, škálovatelnost se objevila jako kritický faktor. Naši datoví vědci navrhli analýzu hlavních komponent (PCA) k zachycení anomálií porovnáním chyby rekonstrukce každého datového bodu. Body, které mají vyšší chyby při rekonstrukci, jsou považovány za potenciální odlehlé hodnoty nebo anomálie. Spuštění tohoto modelu však bylo výpočetně nákladné a náročné na paměť, takže použití na velmi velké datové sady, které se nemusí vejít do paměti, bylo obtížné. Diskutovali jsme s datovými vědci a prozkoumali alternativy a nakonec jsme objevili inkrementální PCA (IPCA), rozšíření PCA navržené pro zpracování velkých datových sad zpracováním dat v menších dávkách, které nabízí škálovatelnost bez kompromisů ve výpočetní efektivitě.
Když jsme se posunuli za vývojovou fázi, ověřili jsme naše modely ve srovnání se scénáři reálného světa začleněním metrik. Naše metriky obvykle zahrnují objem dat, latenci procesu, míru detekce, falešné poplachy a tak dále. Poté, co jsme zaškrtli všechny tyto metriky, jsme přešli k procesu nasazení. Vzhledem k dynamické povaze produkčních dat, která může vést k degradaci modelu a snížení spokojenosti zákazníků, jsme zavedli experimentální režim, který je vysvětlen v části „Posílení nasazení modelu ML“.
Jako inženýři jsme pochopili, že fáze nasazení není konečným bodem, ale začátkem optimalizace. Hodnocení po nasazení mělo velký význam, protože nám umožnilo skutečně pochopit dopad našich detektorů rozprašujících hesla v reálném prostředí. Během této cesty jsme se aktivně podíleli na nepřetržitém monitorování výkonu detekce, neustále zdokonalovali a přizpůsobovali náš detektor sprejování hesel na základě cenných poznatků odvozených ze zpětné vazby od zákazníků a nově vznikajících případů použití.
Během naší cesty vývoje pokročilých modelů ML pro zjišťování hrozeb rychlejším tempem jsme čelili výzvám při zavádění a údržbě těchto modelů a při zajišťování jejich účinnosti při různé povaze dat. Na rozdíl od tradičního softwaru je nasazení a údržba modelů ML složité, včetně potenciální degradace v průběhu času, a vyžaduje neustálé sledování a ladění modelu. V důsledku toho se náš čas uvádění na trh rozšířil, protože jsme trávili stále více času dolaďováním našich modelů ML.
Abychom tyto výzvy řešili komplexně, začali jsme pracovat na zefektivnění životního cyklu našeho modelu ML, čímž jsme zahájili naši cestu v MLOps.
Výzvy MLOps: Navigace neznámým
Během naší expedice MLOps jsme se setkali s kritickými problémy, jako je degradace modelu, latence zpracování a nedostatek hotových nástrojů pro škálovatelné inženýrství funkcí a modelování hrozeb. V tomto příspěvku se zabýváme všemi těmito výzvami, ale nejprve se podívejme, jak jsme při nasazování modelů do produkčních prostředí obcházeli nekonzistence prostředí.
Posílení nasazení modelu ML
Model ML, který vytváříme, obvykle prochází různými vývojovými a testovacími prostředími, než je nasazen do našeho produkčního prostředí. Modely vždy testujeme pomocí různých testovacích dat a vytváříme podobná prostředí, jako je naše produkční prostředí.
Navzdory našim přísným testovacím protokolům odhalila produkční fáze řadu problémů, od nekonzistentnosti prostředí a složitosti správy závislostí po problémy s integrací dat a problémy se škálovatelností. Degradace modelu v produkčním prostředí vedla k falešným pozitivním výsledkům při detekci hrozeb.
Prvním krokem při ladění těchto problémů bylo pochopení podstatného dopadu těchto modelů a hlavní příčina byla většinou identifikována jako změna v datech. Tato potřeba řešení, které nejen řeší složitosti, ale také poskytuje záchrannou síť proti potenciálnímu narušení, byla naprosto nezbytná. V reakci na identifikované výzvy jsme konceptualizovali a implementovali to, co nyní označujeme jako experimentální režim. Tento inovativní přístup zahrnuje nasazení nového modelu ML do našeho produkčního prostředí při zachování diskrétnosti jeho operací. Primární cíl je jasný: Umožnit modelu bezproblémově plnit určené úkoly s vlastní schopností deaktivovat se, pokud nastanou nějaké nepředvídatelné problémy.
Obrázek 3: Ilustrace experimentálního modelu
Jak funguje experimentální režim? Obrázek 3 znázorňuje kanál detekce hrozeb integrací tří modelů ML. ML modely 1 a 2 jsou označeny jako produkční modely, zatímco ML model 3 pracuje v experimentálním režimu). Zpočátku začleňujeme experimentální modely do procesu trénování a vyvozování modelů, aniž bychom je oddělovali od produkčních modelů. Tato metoda nám umožňuje získat výsledky generované těmito modely trénovanými na nejnovějších výrobních datech.
Jak je znázorněno na obrázku 3, s modelem 3 se zachází stejně jako s ostatními dvěma modely. Klíčový rozdíl je v tom, že když vytvoříme bezpečnostní problém korelací všech výstrah z různých modelů, výsledky získané z experimentálních modelů (v tomto příkladu model 3) jsou vyloučeny. Abychom tohoto cíle dosáhli, zavedli jsme příznak nazvaný „experimentální“, který označuje, zda výsledek pochází z experimentálního režimu či nikoli. Z tohoto důvodu je model 3 ve sloupci Experimentální označen jako „Y“. V důsledku toho zůstává konečný bezpečnostní problém hlášený zákazníkům přítomností těchto experimentálních modelů nedotčen.
Mezitím mohou datoví vědci k těmto výsledkům přistupovat a průběžně sledovat jejich výkon s předdefinovanými metrikami. Experimentální model obvykle prochází minimální inkubační dobou jeden měsíc a je nasazen pouze v případě, že trvale vykazuje uspokojivý výkon. Následně přepneme příznak experimentálního režimu na false, čímž se model stane plnohodnotným produkčním modelem. Ve spodní části obrázku 3 byl model 3 přeměněn na produkční model s experimentálním příznakem přepnutým z Y na N. V budoucnu budou všechny tři modely používat bezpečnostní detekci k vytváření bezpečnostních zjištění pro zákazníky.
Experimentální model nám umožnil nasadit různé modely současně a změřit jejich výkon. Model pak vybereme, zrušíme nebo přeladíme na základě jejich výkonu. Zavedení experimentálního režimu do našeho produkčního procesu nasazení nám pomohlo zefektivnit proces nasazení, zrychlit cyklus nasazení, lépe předvídat modely a především zvýšit flexibilitu nasazení, což nám umožnilo vyzkoušet různé modely s různou mírou rizika.
Vzhledem k tomu, že nasazení modelu ML je nyní zefektivněno, zaměřme svou pozornost na problémy, se kterými jsme se setkali, a zároveň sledujme výkon těchto modelů, abychom zajistili trvalou dokonalost.
Sledování výkonu modelu
V raných fázích se náš přístup k monitorování modelů ML velmi podobal přístupu mnoha jiných platforem. Pečlivě jsme sledovali metriky časových řad v každém kroku procesu extrahování, transformace, načítání (ETL) a zahrnovaly klíčové ukazatele, jako je objem příjmu dat, zpoždění zpracování a selhání úlohy. Jak však objemy našich dat a složitost algoritmů neustále rostly, objevila se nová výzva: Problémy s kvalitou mikrodat.
Tyto drobné problémy se neprojevovaly konzistentně, ale vyskytovaly se sporadicky ve specifických scénářích rohových případů. Přes jejich vzácnost byl jejich dopad na výkon modelu hluboký. Tento jev je běžnou výzvou v oblasti strojového učení, kde i drobné změny ve vektoru prvků mohou vést ke znatelnému poklesu kvality modelu.
Uvědomujeme si zásadní důležitost řešení těchto problémů s kvalitou mikrodat, rozhodli jsme se pro inovativní přístup. Naše řešení zahrnovalo zavedení vysokorozměrných metrik do našeho monitorovacího rámce. Tento proces znamenal začlenění specializovaných úloh monitorování dat navržených tak, aby pečlivě zkoumaly odchylky a odchylky různých zdrojů dat a jejich souvisejících vektorů vlastností.
Obrázek 4: Monitorovací kanál
Jak je znázorněno na obrázku 4, abychom tyto problémy s kvalitou mikrodat odhalili dříve, implementovali jsme novou úlohu monitorování. Tato úloha zkoumá různé soubory dat, včetně nezpracovaných dat, vektorů prvků, nálezů z různých detektorů a korelovaných výsledků z korelačních úloh. Průběžně sleduje jejich odchylky a výsledky publikuje do monitorovací služby OCI a bucketu OCI Object Storage k další analýze. Úloha monitorování je také zodpovědná za provádění kontrol kvality dat a generování vysoce dimenzionálních metrik, které vědcům poskytujícím datové údaje jasně porozumí rozptylu dat. Například zkoumání 3D bodového grafu umožňuje vědcům dat získat hlubší pochopení toho, jak se rozložení dat mění v průběhu času.
Obrázek 5 ukazuje významný posun tří funkcí (standardizované využití zdrojů, požadavky, trvání přihlášení) od minulého týdne do tohoto týdne. Tento pozorovaný posun dat může být hlavní příčinou pozorované degradace výkonu modelu.
Obrázek 5: Bodový graf vizualizující posun dat
Tyto vysokorozměrné metriky otevřely nové cesty pro naše datové vědce. Vyzbrojeni hlubším pochopením složitých vzorů ve vektorech prvků, byli naši datoví vědci oprávněni doladit parametry a optimalizovat modely s úrovní přesnosti, která byla dříve nedosažitelná. Abychom zajistili trvalou dokonalost našich modelů strojového učení, naši datoví vědci proaktivně monitorují sestavy generované z těchto vysokorozměrných metrik. Tyto zprávy, automaticky generované a každý týden nahrávané do úložiště objektů OCI, poskytovaly konzistentní a ostražitý dohled, aby bylo možné detekovat jakékoli potenciální zhoršení výkonu modelu v průběhu času.
V rámci našeho závazku komplexního monitorování využívá Cloud Guard službu OCI Monitoring. To zahrnuje nejen vytváření alarmů, ale také využívá sílu sofistikovaného monitorovacího dotazovacího jazyka (MQL) pro vizualizaci metrik časových řad. Tento integrovaný přístup se nejen vypořádal s výzvami, které představuje vyvíjející se povaha dat a algoritmická složitost, ale povýšil naše monitorování modelu ML na nový standard excelence. Je to důkaz našeho závazku k inovacím a neustálému zlepšování v dynamickém prostředí strojového učení.
Zatímco se snažíme zachytit degradaci modelu pomocí různých výše uvedených metrik a monitorovacích nástrojů, degradace modelu je vždy možná kvůli změně povahy dat v reálném světě.
Zlepšení výkonu modelu
Zpětná vazba uživatelů je pokladnicí postřehů, které čekají na objevení. Ať už vyvíjíte motory doporučení, chatboty, prediktivní analýzy nebo jakoukoli jinou aplikaci strojového učení, zkušenosti a interakce vašich uživatelů poskytují velké množství informací o silných a slabých stránkách vašich modelů.
Vytváříme náš model detekce zabezpečení pomocí historických dat a předpokladů o tom, jak budou fungovat v reálných scénářích. Vzhledem k tomu, že dynamická povaha dat se často mění, zvláště když máme co do činění se stovkami tisíc uživatelů, začali jsme být svědky některých falešně pozitivních detekcí, což začalo přidávat spoustu šumu do skutečných detekcí.
Povaha dat se také u každého uživatele liší, ovlivněna rozsahem jejich dat a konkrétními případy použití. Proto se pro nás stalo zásadní porozumět jedinečným charakteristikám dat pro každého zákazníka a vložit tento náhled do našeho modelu ML. V reakci na tuto výzvu jsme implementovali mechanismus zpětné vazby od uživatelů, abychom od zákazníků shromažďovali informace týkající se bezpečnostních incidentů.
Obrázek 6: Smyčka zpětné vazby od zákazníka
Nyní se pojďme ponořit do detailů jednoho z našich vydaných detektorů, nazývaného nemožné cestování. Tento detektor je navržen tak, aby označil účet, když jsou přihlašovací údaje použity k přístupu k účtu příliš rychle ze dvou samostatných geografických míst, což znamená nelegitimní použití. Dostali jsme nějakou zpětnou vazbu od uživatelů, kteří říkali, že nevědí, proč jejich aktivity spustily tento detektor, protože volali API pouze z jednoho místa. Při našem šetření jsme zjistili, že přihlašovací údaje byly použity s VPN, která hlásila z různých míst. Abychom problém vyřešili, obohatili jsme naše data o geografický zdroj, abychom získali skutečnou polohu namísto umístění VPN. Bez tak cenné zpětné vazby od uživatelů by pro nás byla identifikace a řešení takových výjimečných scénářů významnou výzvou.
Obrázek 6 ilustruje fungování našeho mechanismu zpětné vazby. Když detektor hrozeb detekuje jakýkoli bezpečnostní incident, zobrazí se to na konzole Cloud Guard jako problém pro naše uživatele. Uživatelé pak mohou poskytnout zpětnou vazbu k individuálnímu problému a tato zpětná vazba bude předána všem detektorům použitelným v daném uživatelském pronájmu. Uživatelé tak nemusí explicitně poskytovat stejnou zpětnou vazbu pro každý problém.
Závěr
Naše cesta do sféry operací strojového učení (MLOps) v rámci ekosystému Cloud Guard Oracle Cloud Infrastructure (OCI) byla osvětlující. Od zrodu Cloud Guard jako obránce cloudových prostředí až po jeho evoluci ve strážce s podporou ML, náš průzkum odhalil složitosti a výzvy, které jsou MLOps vlastní.
Toto jsou klíčové poznatky:
- Tradiční detekční metody založené na pravidlech jsou nedostatečné v boji proti vyvíjejícím se kybernetickým hrozbám, kterým čelí cloudová prostředí, zejména při jednání s rozsáhlými zákaznickými základnami.
- Vývoj modelů ML v rámci Cloud Guard zahrnoval složité kroky, od počáteční myšlenky a sběru dat až po školení modelů, nasazení, průběžné monitorování a zlepšování.
- Jak podniky stále více spoléhají na strojové učení, aby posílily svou konkurenční výhodu, nutnost zefektivnit životní cyklus ML je stále naléhavější.
- Výzvy, jako jsou nekonzistence prostředí během nasazování modelu, latence zpracování a problémy s kvalitou mikrodat, byly řešeny prostřednictvím inovativních řešení, jako je experimentální režim pro bezproblémové nasazení modelu a monitorování vysokorozměrných metrik.
- Při práci s různými daty pro stovky tisíc uživatelů jedno řešení nevyhovuje všem a využití zpětné vazby od uživatelů nám umožnilo vylepšit a optimalizovat naše detekční modely, což zajišťuje přesnost a relevanci při identifikaci hrozeb.
- Naše cesta MLOps odráží odhodlání k neustálému zlepšování a inovacím v oblasti cloudového zabezpečení a směřujeme k trvalé dokonalosti v detekci a zmírňování hrozeb.
Když se vydáte na svou vlastní cestu v říši MLOps, nezapomeňte, že úspěch není jen o cíli, ale o neustálém vývoji a zlepšování vašich postupů strojového učení.
Zdroj: Oracle
