Vzhledem k tomu, že tolik bezpečnostních a vývojářských týmů provádí pitvu při fiasku s bezpečnostní zranitelností Log4j, které se odehrálo na konci roku 2021, pouhých 10 dní před Vánocemi, hlavní otázka zní:jak se tomuto typu bolesti v budoucnu vyhnout? Odpověď je bohužel… je to složité.
Pokrytí zabezpečení, které je nutné přečíst
Podle nových údajů (ISC)2, největšího světového neziskového sdružení certifikovaných profesionálů v oblasti kybernetické bezpečnosti, se téměř polovina (48 %) týmů kybernetické bezpečnosti vzdala dovolené a víkendů, aby pomohli s nápravou, a 52 % týmů strávilo „týdny nebo více“. ” opravující Log4j. Není to přesně tak, jak už tak natahovaní vývojáři chtěli strávit prázdniny.
Na druhou stranu však bolest z této zkušenosti vyvolala zásadní přehodnocení zabezpečení dodavatelského řetězce softwaru ze strany vývojářů a bezpečnostních týmů.
Oprava zranitelností bez porušení staršího kódu
Jedním z nejproblematičtějších aspektů Log4j nebyla samotná zranitelnost, ale to, jak hluboce je technologie zakořeněna v původním kódu. Koneckonců, Java je jednou z nejpopulárnějších platforem na světě a Log4j je neuvěřitelně populární protokolovací systém Java, jehož první vydání se datuje až do roku 2001. Log4J se tedy dotýká nejen tuny produkčních systémů, ale také mnoha dědictví. kód.
„Nikdo se nechce dotknout starého kódu,“ řekl Sergej Egorov, generální ředitel společnosti AtomicJar, nového startupu stojícího za open source integračním testovacím rámcem Testcontainers. „Nepotřebujete pouze opravit zranitelnost zabezpečení, musíte vědět, že jste zranitelnost opravili, aniž byste narušili svůj systém. Když máte zranitelnost se super populární protokolovací knihovnou, jako je Log4j, mluvíte o závislostech na starším kódu, který obvykle postrádá jakékoli testování, a kde někdy vývojáři, kteří kód napsali a pochopili, jak to funguje, ve společnosti ani nefungují. už."
Podle Egorova je Log4j často přechodnou závislostí jiných knihoven, které je třeba aktualizovat. Na rozdíl od platforem, které poskytují statické binární soubory, u systémů Java dochází k propojení kódu za běhu, takže neexistuje žádný způsob, jak mít 100% jistotu, že se aplikace bude chovat správně, dokud ji skutečně nespustíte a neotestujete propojení mezi závislostmi a závislostmi v reálném čase. kompilace.
Egorov řekl, že Log4j zrychlil zájem o již populární platformu Testcontainers jako způsob, jak otestovat tyto interakce před produkčním nasazením. Vidí, že vývojáři, kteří byli ohromeni Log4j, nyní vytvářejí integrační testy mezi systémy a externími závislostmi, takže až příště přijde bezpečnostní zranitelnost, vývojáři mohou otestovat, že jejich opravy při nasazení nesundají produkční systémy. Testcontainers se stávají oblíbeným párováním se Snykem, protože vývojáři mohou dostávat požadavky na automatizované zabezpečení a testování integrace jim dává jistotu, že je mohou sloučit, aniž by cokoli porušili.
Co je horší… zranitelnost nebo rušení uživatelů?
Příchod bezpečnostní zranitelnosti Log4j a její hrozné načasování během hlavní prázdninové sezóny vytvořilo pro vývojářské týmy zvrácenou volbu – nasadit opravy hned a riskovat odstranění systémů během špičkových prázdninových cyklů elektronického obchodování nebo přesunout nasazování oprav do méně komerčně rizikových intervalů. ?
Je to rozhodnutí, které není možné učinit, pokud nemáte správný kontext.
„Log4j vyvolal u mnoha inženýrských týmů paniku, protože nedokázaly předvídat, jak bude mít oprava dopad na jejich uživatele,“ řekl Marcin Kurc, generální ředitel startupu Nobl9 pro spolehlivost softwaru, mezi jehož zákazníky patří velcí e-prodejci. „Existuje analýza nákladů a přínosů, kterou je třeba provést u jakékoli nápravy zabezpečení. Musíte určit správný interval pro nasazení opravy, což vyžaduje úplné pochopení rizika z hlediska počtu uživatelů, které by mohla ovlivnit, a přijatelné úrovně nespolehlivosti, kterou můžete akceptovat.“
Kurcova společnost prosazuje hnutí nazývané cíle na úrovni služeb (SLO), které se zrodily v postupech inženýrství spolehlivosti stránek společnosti Google a které Nobl9 komercializoval do platformy.
SLO umožňují vývojářům modelovat dobu provozuschopnosti a míru úspěšnosti v rámci softwarových interakcí a definovat prahové hodnoty pro uživatelské výsledky – řekněme například, jaké procento pokladen v nákupním košíku je provedeno správně. Společnosti, které modelují SLO, říká Kurc, mohou vést skutečnou konverzaci o riziku záplatování versus neopravování.
Taková řešení však přicházejí až poté, co byl napsán open source software. Ale co uděláme pro to, aby byla ze své podstaty bezpečnější?
Širší problém:kdo vlastní zabezpečení pro open source?
Nikdo nepřestane používat open source. Bylo by absurdní budovat logovací řešení od nuly, než sáhnout po nástrojích jako Log4j. Vývojáři dnes píší méně logiky a integrují více rámců, knihoven a rozhraní API, a to se nezmění.
Jak napsal Filippo Valsorda z Googlu ve virálním příspěvku, mnoho z těchto správců open source „spadá do jedné ze dvou kategorií:dobrovolníci nebo zaměstnanci velkých společností. Někdy obojí. Ani jeden model není zdravý.“
Log4j objasnil skutečnost, že velká část moderního softwarového dodavatelského řetězce je podepřena na open source projektech s hrstkou správců, nebo dokonce s jedním správcem, který často vytvořil technologii jako vedlejší projekt. (A řekněme si to jasně:nedávné údaje naznačují, že drtivou většinu veškerého softwaru s otevřeným zdrojovým kódem píše méně než 10 lidí.)
„Moderní aplikace jsou sestaveny z mnoha komponent, z nichž mnohé nejsou vyvíjeny interně, ale jsou spíše sestavovány pomocí „off the police“ řešení,“ říká John France, CISO at (ISC)2. „Velkou částí kvalifikace a identifikace problémů je znalost toho, jaké komponenty a knihovny váš software používá, a vedení kusovníku softwaru (SBOM).“
Ale podle jednoho anonymního bezpečnostního odborníka v průzkumu nápravy Log4 (ISC)2:„Vývojáři obecně byli velmi laxní, pokud jde o sledování toho, co používají ve svém softwaru. Když událost, jako je tato, vyžaduje, abychom identifikovali, zda je nějaká knihovna nebo komponenta používána naším kódem, stává se nedostatek sledovatelnosti velkým problémem. Z jednoduchého cvičení kontroly zásob a SBOM se stává komplexní proces skenování s mnoha příležitostmi pro falešně pozitivní a falešně negativní výsledky. Kdybychom někdy potřebovali budíček, dostali jsme velký s Log4j.“
Google a další těžké váhy se vrhají do této výzvy zranitelnosti zabezpečení s otevřeným zdrojovým kódem a čas ukáže, zda hlubší investice a spolupráce s dodavateli mohou pomoci snížit frekvenci a bolestivost incidentů, jako je Log4j. Mezitím ale vývojáři vymýšlejí strategie, jak se příští prázdniny vyhnout strašlivým bezpečnostním překvapením.
Zveřejnění:Pracuji pro MongoDB, ale tyto názory jsou pouze moje.
Odkaz na zdroj