Stručně: Řízení zranitelností ve středních a malých firmách je štíhlý, opakující se cyklus: znát své systémy, cíleně sledovat hlášení, hodnotit podle rizika, rozhodovat, provádět a dokládat. Rozhodující nejsou drahé nástroje, ale jasné odpovědnosti a stanovení priorit, které bere v úvahu dostupnost systému, data a situaci s útoky. PHP2Shell je dobrý cvičný příklad, protože se v něm vyskytují všechny kroky.
Stovky hlášení, málo lidí
Každý týden se zveřejňují nové bezpečnostní zranitelnosti, v operačních systémech, programovacích jazycích, aplikacích i pluginech. Koncern na to má tým. Střední firma má často jednoho vedoucího IT, jednoho či dva administrátory a několik externích dodavatelů. Nikdo nemůže přečíst každé hlášení, a není to ani nutné.
Je potřeba filtr: Která hlášení se týkají našich systémů, která z nich jsou naléhavá a kdo se o ně postará? Pokud tento filtr chybí, nastane jedno ze dvou. Buď se vše ignoruje, dokud se něco nestane, nebo každé hlášení vyvolá poplach a skutečně kritické zapadne v šumu.
Cyklus řízení zranitelností
Funkční postup pro malé a střední firmy lze popsat v šesti krocích:
- Zjistit, co běží. Bez inventáře není co porovnávat. Jaké weby, servery, verze PHP a aplikace provozujete a kde? Jak na to, ukazuje Vědět, co běží: inventář všech webů a serverů.
- Sledovat hlášení. Odebírat několik spolehlivých zdrojů: varování BSI (německého Spolkového úřadu pro informační bezpečnost), hlášení výrobců vašeho softwaru, bezpečnostní stránky vaší linuxové distribuce a u PHP úvodní stránku php.net.
- Hodnotit. Týká se hlášení nás? Pokud ano, jak naléhavě? Více níže.
- Rozhodnout. Odstranit, dočasně zabezpečit, systém izolovat, nebo riziko vědomě nést. Kdo smí o čem rozhodovat?
- Provést. Nainstalovat aktualizaci, nasadit přechodné opatření, pověřit dodavatele.
- Doložit a dohlížet. Je zranitelnost skutečně uzavřena? Kdy bude přechodné řešení nahrazeno?
Poté cyklus začíná znovu. Přibývají nové systémy, staré mizí a objevují se nová hlášení.
U kroku 2 pomáhá jednoduché pravidlo: raději pravidelně číst málo zdrojů než příležitostně mnoho. Pro typické středně velké webové prostředí zpravidla stačí varovná hlášení CERT-Bund při BSI (německého vládního CERT), bezpečnostní hlášení používané linuxové distribuce, stránky výrobců CMS a e-shopů a úvodní stránka php.net. Určete, kdo tyto zdroje čte, a zřiďte k tomu společnou schránku nebo kanál, který nezávisí na jedné osobě.
Užitečný je i pohled zvenčí. Pravidelný sken zranitelností veřejně dostupných systémů ukáže, zda je vidět zastaralý software nebo zbytečně otevřené služby. Nenahrazuje inventář ani aktualizace, ale odhalí systémy, které nejsou v žádném seznamu.
Hodnotit: co přijde na řadu první
Hodnota CVSS, standardizované zařazení závažnosti, je dobrým výchozím bodem. Pro pořadí ve vlastní firmě ale nestačí. Rozhodují další tři otázky:
| Otázka | Zvyšuje naléhavost | Snižuje naléhavost |
|---|---|---|
| Je systém dostupný z internetu? | veřejný web, e-shop, portál | pouze interně, za VPN |
| Je k zneužití zranitelnosti nutné přihlášení? | ne, bez ověření | ano, jen pro administrátory |
| Jaká data systém zpracovává? | data zákazníků, platby, přístupy | veřejný obsah bez účtů |
| Existují zprávy o útocích? | hlášeny pokusy o útok | žádné známé pokusy |
| Existuje přechodné opatření? | ne | ano, s doloženým účinkem |
PHP2Shell ukazuje, jak to do sebe zapadá. Obě zranitelnosti mají hodnotu CVSS v4.0 9.2, umožňují spuštění kódu bez přihlášení a týkají se veřejně dostupných webových serverů. Cloudflare a Patchstack podle médií hlásily pokusy o útok, BSI zařadilo situaci do výstražného stupně 3. Přechodná opatření z php.net výslovně neposkytují úplnou ochranu. Všechny otázky ukazují stejným směrem: jednat okamžitě. Co BSI konkrétně doporučilo, najdete v Co BSI k PHP2Shell doporučuje.
Rozhodnout a zdokumentovat
Ne každou zranitelnost lze uzavřít okamžitě. Starší systém běží na PHP 8.1, pro které už neexistují oficiální aktualizace (viz PHP 8.1 a starší: co nyní platí), odborná aplikace aktualizaci ještě nesnese. Pak je potřeba rozhodnutí a to nepatří jen technikům.
Dobrý záznam o rozhodnutí obsahuje dotčený systém, zranitelnost, hodnocení, zvolenou variantu, přechodná opatření, odpovědnou osobu a termín opětovného posouzení. Pokud se riziko vědomě nese, rozhoduje vedení, nikoli sám administrátor. Také OWASP Cheat Sheet k práci se zranitelnými závislostmi doporučuje výslovně ukotvit akceptaci rizika na úrovni vedení.
Veďte jediný seznam otevřených zranitelností se stavem, odpovědnou osobou a termínem. Stačí tabulka. Důležité je, aby se pravidelně procházela, například na měsíční poradě s vedením firmy.
Co s tím mají společného NIS2 a dodavatelé
Pro firmy, na které se vztahuje NIS2, je práce se zranitelnostmi součástí povinností v oblasti řízení rizik. Podrobnosti popisuje NIS2 a bezpečnost webového serveru. Ale i bez zákonné povinnosti je zdokumentovaný postup výhodou, například vůči zákazníkům, pojišťovnám a vlastnímu vedení.
Mnoho kroků lze outsourcovat, například sledování hlášení nebo instalaci aktualizací. Rozhodování o rizicích a celkový přehled by ale měly zůstat ve firmě. Kdo celý cyklus předá dodavateli, v krizovém případě už neví, jaké systémy vůbec má. Jak zorganizovat provedení jako rutinu, popisuje Správa záplat jako proces, ne hašení požárů.
Jak konkrétně pomáhá PHP SOS?
- Společně s vámi vytvoříme inventář vašich webů a serverů jako základ každého porovnání.
- Pro vaše systémy sledujeme relevantní hlášení a dodáváme hodnocení srozumitelnými slovy s doporučením.
- Připravujeme záznamy o rozhodnutí pro případy, kdy aktualizace není možná okamžitě.
- Prostřednictvím bezpečnostního monitoringu průběžně kontrolujeme, zda systémy nejsou nápadné, dokud je zranitelnost otevřená.
Závěr: Řízení zranitelností ve středních firmách nemusí být velké, ale musí být závazné. Kdo zná své systémy, čte několik dobrých zdrojů a zaznamenává rozhodnutí, reaguje při příštím kritickém hlášení rychle a správně.
Časté dotazy
Co je řízení zranitelností?
Opakující se postup, kterým se firma dozvídá o bezpečnostních zranitelnostech ve svých systémech, hodnotí je, odstraňuje je nebo je vědomě akceptuje a výsledek zaznamenává. Nejde o nástroj, ale o odpovědnosti a rozhodnutí.
Stačí k určení priorit hodnota CVSS?
Je to dobrý výchozí bod, ale nestačí. Rozhodující je navíc to, zda je dotčený systém dostupný z internetu, jaká data zpracovává a zda už byly pozorovány útoky. Zranitelnost s vysokým skóre na interním testovacím systému může počkat, na e-shopu ne.
Potřebuje k tomu malá firma vlastní nástroj?
Na začátek ne. Stačí udržovaný seznam systémů, odebíraná bezpečnostní hlášení a tabulka otevřených bodů. Skenery zranitelností se vyplatí, když počet systémů roste nebo když je třeba pravidelně dokládat kontroly.
Smí se zranitelnost vědomě neodstranit?
Ano, pokud je riziko ohodnoceno, rozhodnutí učiní příslušné vedení a je písemně zaznamenáno, ideálně s přechodnými opatřeními a termínem opětovného posouzení.