Tento podrobný průvodce pojednává o tom, proč jsou bezpečnostní týmy zahlceny zranitelnostmi, o nebezpečí, které se skrývá za dvojitým hlášením o zranitelnosti, a o tom, jak takové zranitelnosti zmírnit pomocí živých záplatovacích nástrojů, jako je KernelCare.
Víme, že kyberbezpečnostní hrozba roste a s tím souvisí i úsilí o zmírnění hrozby a souvisejících nákladů. Důkazy však naznačují, že zmírňování nepostupuje dostatečně rychle.
Podle společnéanalýzy provádí McAfee a Centrum strategických a mezinárodních studií , v roce 2020 vzrostou celosvětové náklady na počítačovou kriminalitu přes 1 bilion dolarů poprvé – masivní nárůst o 50 % oproti celkovému počtu v roce 2018. To je míra změny, která jasně předčí jakoukoli srovnatelnou metriku, jako je růst HDP nebo růst výdajů na IT.
Problémem není informovanost – společnosti koneckonců utrácejí obrovské částky na obranu před kybernetickými hrozbami.
Místo toho v tomto článku tvrdíme, že hráči v oblasti kybernetické bezpečnosti jsou v podstatě zavaleni výzvami, kterým čelí. Jako jasný důkaz poukazujeme na nedávný výskyt dvojího hlášení známých zranitelností.
Pokračujte ve čtení a zjistěte, proč jsou bezpečnostní týmy zavaleny zranitelnostmi, jaký to má dopad na záplatování a co mohou týmy udělat, aby záplatovaly konzistentně tváří v tvář neúnavnému náporu zranitelností a exploitů.
Ještě další chyba zabezpečení?
V druhé polovině minulého roku byla objevena a nahlášena zranitelnost linuxového jádra. Bylo mu přiděleno C ommon V zranitelnosti a E číslo xposures (CVE), CVE-2020-29369 a chyba zabezpečení byla opravena podle očekávání. Zatím nic neobvyklého.
Ani na samotné zranitelnosti nebylo nic neobvyklého. V každém operačním systému musí jádro pečlivě spravovat paměť – přidělovat (mapovat) paměťový prostor, když to aplikace potřebuje, a správně odebírat alokace a znovu přiřazovat volnou paměť, když ji aplikace již nepotřebuje.
Tento proces správy paměťového prostoru však může být náchylný k závadám. Při kódování bez potřebné péče mohou procesy zpracování paměti jádra poskytnout kyberzločincům příležitost. V případě CVE-2020-29369 se problém vyskytl ve funkci mmap, která se používá pro mapování paměti v Linuxu.
Povaha zranitelnosti znamenala, že dvě různé aplikace mohly požadovat přístup ke stejnému paměťovému prostoru, což vedlo k havárii jádra.
Pokud by útočník zahrál své karty správně – jinými slovy, vytvořil exploit – útočník by byl schopen získat data, která by jinak byla chráněna jádrem. Mohou to být zcela neškodná data – nebo něco cennějšího, jako jsou cenná osobní data nebo hesla.
Příběh dvou zpráv o zranitelnosti
Můžeme tedy vidět, že typická chyba zabezpečení byla nahlášena a přijata obvyklými postupy. Ale pak se stalo něco znepokojivého.
Jen o několik měsíců později byla hlášena přesně stejná zranitelnost. Opět bylo přiděleno číslo CVE, tentokrát CVE-2020-20200 . Brzy se však ukázalo, že nové upozornění na zranitelnost je duplikátem jiné zranitelnosti – CVE-2020-29369.
Výzkumníci, kteří z nějakého důvodu „našli“ zranitelnost podruhé, nebo z jiného důvodu, nedokázali najít první výskyt zranitelnosti, než požádali o další rezervaci CVE pro to, co objevili. Jedním z primárních záměrů databází CVE je vyhnout se dvojímu hlášení, ale v tomto konkrétním případě bylo přesto požadováno další CVE.
Tento případ se nazývá „dvojité hlášení“ není prvním ani jediným případem, kdy byla zranitelnost hlášena dvakrát. Horší je, že když vyšetřování zranitelnosti dospěje do bodu, kdy bylo přiděleno CVE, zranitelnost již bude zkontrolována mnoha vysoce vyškolenými bezpečnostními experty.
Dokonce i bezpečnostní výzkumníci to mohou pomíchat
V tomto příkladu dvojitého hlášení je jasné, že bezpečnostní výzkumníci si měli buď být vědomi stávající zranitelnosti, nebo měli najít stávající CVE, pokud dostatečně prozkoumali „novou“ zranitelnost, než požádali o nové číslo CVE.
Je to znepokojivá myšlenka. Tato zranitelnost mapování paměti leží v jádru linuxového jádra, ale bezpečnostní výzkumníci si toho zjevně nebyli vědomi, proto je uveden dvojitý seznam. A co je horší, není to tak, že by mezi jednotlivými nabídkami bylo deset nebo dokonce roky:jednotlivé zápisy se stejnou zranitelností byly vytvořeny jen několik měsíců od sebe, jeden v srpnu 2020 a jeden v listopadu 2020.
Jsou bezpečnostní výzkumníci nedbalí? Ne. Bezpečnostní výzkumníci jsou prostě zcela ohromeni obrovským množstvím výzev v oblasti kybernetické bezpečnosti. To je důvod, proč v tomto příkladu bezpečnostní experti linuxového jádra vynechali existující zprávu o potenciálně kritické zranitelnosti.
Skryté nebezpečí za dvojitým hlášením zranitelností
Jasné důkazy, že hrozba kybernetické bezpečnosti roste, v kombinaci s příklady, kdy se i bezpečnostní experti mýlí, naznačují, že dvojité hlášení má větší důsledky, než se na první pohled zdá.
Neznamená to, že by bezpečnostní experti Linuxu byli náchylní k chybám a přehlédnutím. Jednoduše to naznačuje, že práce se správou bezpečnostních zranitelností se stala tak neuvěřitelně obtížnou, že i experti mají problém držet krok.
Představte si na chvíli typický interní technologický tým, který má komplexní pravomoci – ano, včetně zabezpečení, ale také údržby, provozu a nekonečného množství dalších povinností.
I tam, kde podnikové týmy mají specializované odborníky na bezpečnost, je pravděpodobné, že odborné znalosti musí být aplikovány na celou řadu hrozeb a technologických nástrojů. I pro velký podnik by bylo extrémně vzácné zaměstnávat bezpečnostního experta linuxového jádra. A i kdyby ano, jak jsme viděli, tito bezpečnostní experti se mohou mýlit.
Týmy IT čekají těžké časy
Týmy na místě budou vždy do určité míry spravovat zranitelnosti zabezpečení. Například tím, že budete reagovat na zprávy o hlavních exploitech a podle toho aplikovat záplaty. Varování od dodavatelů mohou také vést k akci a většina dobrých IT oddělení bude mít nějaký typ záplatovacího režimu, který zajistí, že záplaty budou aplikovány v nastavených intervalech.
Ale jak mohou IT týmy reálně držet krok s rostoucí hromadou CVE, které ovlivňují linuxové distribuce napříč všemi a přicházejí každý den? Poskytuje, řekněme, režim čtvrtletních oprav skutečně dostatečné zabezpečení? A ano, záplatování je důležité , ale měla by dominovat aktivitě za cenu všeho ostatního – což se může snadno stát vzhledem k objemu záplat?
Je snadné vidět, že pro IT týmy bude těžké udržet náskok před neustále rostoucím seznamem zranitelností.
Upravte svůj režim záplatování
Formalizace vašeho záplatovacího režimu je prvním krokem ve snaze vyrovnat se s horou CVE. Záplaty ad-hoc založené na poplašných zprávách nejsou správnou cestou – zranitelností je prostě příliš mnoho a relativně málo z nich se stalo široce známým, což zanechává bezpočet skrytých zranitelností a souvisejících zneužití, které představují nebezpečí.
Nicméně jedním z klíčových kroků při vytváření záplatovacího režimu je upřednostňování záplat. Kritická, široce známá zranitelnost musí být opravena rychle – bez zpoždění a v případě potřeby obětovat dostupnost. Opravy zranitelností se středním a nízkým rizikem by mohly být naplánovány tak, aby vyhovovaly pracovní zátěži technických týmů nebo aby se předešlo problémům s dostupností.
Dalším klíčovým krokem je vytvoření dostatečně kompletního inventáře hardwaru a softwaru, který vyžaduje záplatování. Některé cíle pro opravy budou okamžitě zřejmé, ale jiné lze snadno minout.
Při vytváření inventáře můžete také identifikovat určitý prostor pro standardizaci – jinými slovy, upgrade softwaru na stejnou verzi nebo konsolidaci prodejců, aby byla správa záplatování snazší.
Nakonec stojí za to kodifikovat váš režim záplatování do formální zásady záplatování. Patchování je těžké provádět důsledně a vše, co je potřeba, je jediné selhání, které otevře dveře katastrofě. Kódovaný režim oprav může vašemu týmu pomoci zůstat na správné cestě s opravami – rok co rok.
Kompromis s opravou
U jakéhokoli režimu záplatování je obvykle nutné provést kompromis mezi dostupností a zabezpečením. Ano, můžete záplatovat vysoce bezpečným způsobem – přidávat záplaty tak rychle, jak jsou vydány. Záplatování má však nevyhnutelně dopad na dostupnost, protože záplatování často vyžaduje restartování serveru.
Ve skutečnosti mohou mít některé společnosti specifické obchodní požadavky, které zabraňují odstranění služeb nebo serverů za účelem použití záplat, i když se objeví kritické CVE, což může způsobit, že služby budou zranitelné vůči novému zneužití.
I tam, kde můžete přepnout servery do stavu offline kvůli údržbě, se služby zhorší a v důsledku toho se zhorší i zkušenost koncového uživatele. Představte si online prodejce s tisíci online zákazníky, kteří najednou například kvůli údržbě odpojí polovinu svých serverů.
Pak je tu také zátěž na technické týmy, které nevyhnutelně obětují čas strávený jinými úkoly, aby trávily čas opravami. Bezpečnostní týmy by mohly být jednoduše zcela zavaleny břemenem záplatování. Existuje však alternativa.
Zvažte nástroje pro automatické opravy
Identifikovali jsme dva klíčové problémy za standardními režimy záplatování:čas a úsilí, které záplatování vyžaduje, a narušení související s opravováním. Jedním z řešení, které stojí za zvážení, je automatické záplatování – a ještě více, pokud se jedná o automatické záplatování bez restartu která aplikuje záplaty bez nutnosti restartování serveru.
Automatizované záplatovací nástroje nepřetržitě monitorují vydání záplat a aplikují tyto záplaty automaticky bez zásahu. Odstraňuje potřebu věnovat lidskou sílu opravám serverových flotil – záplaty se jednoduše odehrávají bez problémů na pozadí. Díky automatickému záplatování nejsou technické týmy nikdy zavaleny bezpočtem záplatovacích úkolů a technické týmy ani nemusejí zkoušet a předvídat, které záplaty jsou nejdůležitější. Místo toho jsou všechny záplaty aplikovány hladce, rovnoměrně a konzistentně.
Některé nástroje pro automatické opravy, jako je KernelCare může aplikovat záplaty za běhu – záplatování živě, za běhu počítače a bez nutnosti restartu. Živé záplatování omezuje narušení, protože počítače nejsou kvůli zpracování záplaty přepnuty do režimu offline. Pokud existuje minimální riziko narušení, konzistence oprav se pravděpodobně zlepší.
Jinými slovy, správný automatický záplatovací nástroj může vyřešit dva z největších problémů, kterým společnosti při záplatování čelí:potřebné úsilí a přerušení.
Záplatování je kritické, bez ohledu na to, jak to uděláte
Ať už vaše společnost dělá cokoli, aby se zakryla pro záplatování, nebo jakkoli zařídíte režim záplatování, jedinou jistotou je, že záplatování je kritické. Záplaty musí být aplikovány, ale je třeba rozhodnout o tom, jak často a jak záplaty provádíte.
Vzhledem k velikosti hrozby kybernetické bezpečnosti existuje silný argument pro automatické opravy. Technické týmy i bezpečnostní výzkumníci jsou stále více zahlceni a problém zdrojů a dostupnosti překlenuje automatizované záplatování.
Vždy je to možnost jednoduše použít více pracovních sil na záplatování a pro některé úlohy to může být jediná možnost. Přesto ve většině případů může automatizovaná oprava bez restartu přinést velké vítězství proti dnešním obrovským výzvám v oblasti kybernetické bezpečnosti.
Doporučeno:
- Opravte linuxové jádro Raspberry Pi pomocí KernelCare ZDARMA!
- Detekce zastaralých sdílených knihoven v paměti pomocí UChecker