Začněte hrozbami pro konkrétní produkt
Seznam obecných zranitelností je užitečný, ale neříká, co je nejdůležitější pro vaši aplikaci. Mapujte nejprve aktiva, uživatele, důležité datové toky a hranice důvěry. Kdo se přihlašuje, kdo mění finanční údaje, odkud přicházejí soubory a jak se chová externí služba? U každého kroku zvažte zneužití, chybu i únik dat. Vznikne krátký threat model, který pomáhá určit priority testů a ochranných opatření.
NIST Secure Software Development Framework doporučuje začlenit bezpečné postupy do běžného procesu vývoje. Pro malý tým to nemusí znamenat nový složitý aparát. Stačí mít vlastníka rizika, pravidla revize změn a cestu od nálezu k opravě. Model hrozeb se aktualizuje, když přibude nové oprávnění, integrace nebo třída dat. Bez této aktualizace může stará kontrola vytvořit dojem jistoty, přestože produkt mezitím změnil své hranice.
Identita a oprávnění mají obchodní význam
Autentizace ověřuje, kdo člověk je; autorizace určuje, co smí udělat. V praxi vzniká mnoho chyb právě ve druhé části. Uživatel může oprávněně otevřít portál, ale nesmí zobrazit objednávku jiné firmy ani změnit roli sám sobě. Sepište matici rolí nad skutečnými operacemi a daty. Každý serverový požadavek musí ověřit příslušné pravidlo, i když rozhraní tlačítko skryje. Viditelnost prvku není bezpečnostní hranice.
Administrátorské účty potřebují přiměřeně silné přihlášení, omezený počet pokusů a možnost zrušit aktivní relaci. Účty služeb mají mít úzký rozsah práv a pravidelnou rotaci tajemství. Když se změní zaměstnanecká role, přístup musí skončit také v cache, exportech a dalších systémech. Při návrhu se ptejte, jak organizace řeší ztrátu zařízení, odchod pracovníka a nouzový přístup. Odpovědi ovlivní implementaci více než samotný výběr knihovny pro login.
Požadavky převeďte na testovatelné kontroly
Věta „aplikace musí být bezpečná“ se nedá ověřit. Požadavek „běžný uživatel nesmí číst záznam jiné organizace“ už lze testovat. OWASP ASVS nabízí strukturovaný seznam kontrol pro webové aplikace, který lze přizpůsobit riziku. Vyberte relevantní oblasti: správa relací, kontrola vstupů, přístup k datům, konfigurace a další. Každou kontrolu spojte s konkrétním testem, odpovědnou osobou a výsledkem.
Automatický skener najde některé známé chyby, ale nepozná vždy porušení obchodního pravidla. Doplňte ho ruční revizí rizikových změn a testy hranic mezi rolemi. U integračního API ověřte duplicitní požadavky, podpisy a chování při chybě. U souborů typ, velikost a bezpečné zpracování. Výsledek kontroly zaznamenejte i s omezením: co bylo testováno, co chybělo a co bude potřeba před veřejným spuštěním zopakovat.
Bezpečnostní testy patří do dodávky
Během vývoje má smysl automaticky kontrolovat typy, závislosti a základní vzory rizikového kódu. Tyto nástroje však produkují i falešné poplachy a nepokrývají celou aplikaci. Tým musí nálezy třídit podle dopadu a skutečné dosažitelnosti chyby. Kritický problém v přístupových právech má větší prioritu než nízké skóre knihovny, která se v aplikaci vůbec nespouští. Pravidlo pro uzavření nálezu musí být jasné.
Před významným spuštěním otestujte scénáře odpovídající threat modelu, včetně pokusů obejít role, nahrát nečekaný soubor a zneužít chybové stavy. Pokud je potřeba nezávislý penetrační test, určete rozsah, oprávnění a dodavatele; neprezentujte interní revizi jako externí audit. Po opravě se vraťte k původnímu scénáři a ověřte, že funguje také legitimní cesta uživatele. Bezpečnostní opatření, které rozbije hlavní proces, potřebuje lepší návrh.
Kód a závislosti mají původ
Produkt používá knihovny, build nástroje, obrazy a automatizované pipeline. Jejich původ a verze ovlivňují výsledný software. Zamkněte verze závislostí, omezte práva v CI a oddělte tajemství od běžných kroků. Zaznamenávejte, z jakého commitu a konfigurace vznikl artefakt. SLSA popisuje postupné zvyšování záruk dodavatelského řetězce; cílem pro malý tým nemusí být nejvyšší úroveň, ale vědět, co lze o původu buildu skutečně doložit.
Při aktualizaci neřešte pouze počet nalezených zranitelností. Zvažte, zda se závislost používá v produkci, zda existuje oprava a jak bezpečně se dá nasadit. Starý balíček bez podpory může být větší problém než krátkodobě nepříjemný upgrade. Zaznamenejte výjimky s termínem přehodnocení. Build prostředí samo potřebuje revizi přístupů, protože kompromitovaný release proces může obejít ochranu aplikace.
Logování pomáhá, ale může i škodit
Záznam událostí je důležitý pro vyšetření neoprávněné změny a chyb v provozu. Vyberte události, které pomáhají odpovědět kdo, co, kdy a s jakým výsledkem. Patří sem změny oprávnění, administrátorské zásahy nebo opakované neúspěšné přihlášení. Záznam má být strukturovaný a bezpečný proti vložení falešného řádku cizím vstupem. Každý zdroj logu potřebuje přiměřenou dobu uchování a omezený přístup.
OWASP upozorňuje, že do logů zpravidla nepatří hesla, tokeny relací, klíče, citlivé osobní údaje ani celé platební instrukce. Je možné zachovat užitečný korelační identifikátor a typ chyby bez obsahu, který by sám vytvořil nový incident. Zkontrolujte také analytiku, chybové reporty a zálohy logů. Odstranění citlivého pole z hlavního logu nepomůže, pokud ho jiný nástroj automaticky kopíruje do externí služby.
Plánujte reakci na nález i incident
Žádný test nezaručí, že po spuštění nevznikne chyba. Potřebujete cestu pro nahlášení zranitelnosti, odpovědného člověka, způsob posouzení dopadu a plán opravy. Při incidentu oddělte zastavení škody, zachování potřebných důkazů, obnovení služby a komunikaci. Postup má odpovídat typu dat i smluvním povinnostem; právní oznamovací povinnosti se určují podle konkrétní situace a jurisdikce.
Po opravě zkoumejte, proč problém prošel procesem: chyběl test, byla nejasná role, nebo se změnila integrace bez aktualizace modelu hrozeb? Přidejte kontrolu tam, kde přinese opakovatelný přínos. U malé aplikace může být výsledkem jeden nový integrační test a lepší provozní upozornění. U kritické služby může být potřeba zásadní změna architektury. Důležitá je schopnost se z problému poučit, ne počet dokumentů vytvořených po incidentu.
Jak vymezit bezpečnostní práci
Při úvodním zadání uveďte typ produktu, třídy dat, uživatelské role, externí integrace, prostředí a plánované spuštění. Získejte také informaci o dosavadních testech, přístupech k repozitáři a provozních omezeních. Potom lze určit, zda je prvním krokem threat model, revize architektury, zavedení kontrol do vývoje nebo nezávislé posouzení. Každá varianta má jiný výstup a nesmí být zaměňována.
EXCOIN zde vysvětluje postup pro bezpečnější software, neprohlašuje nedoložené certifikace, auditní oprávnění ani nulové riziko. Pokud má být nutný formální audit nebo právní posouzení, je třeba jasně určit kvalifikovaného vykonavatele a rozsah. Technický tým může připravit inventář důkazů a odstranit nalezené chyby. Úspěch znamená, že rizika jsou pojmenovaná, kontroly mají vlastníka a zásadní scénáře jsou skutečně ověřené.
První bezpečnostní přezkum může skončit seznamem rozhodnutí místo dlouhého seznamu nástrojů. U každého závažného rizika uveďte, jak by se projevilo uživateli, která data by zasáhlo, zda už existuje kontrola a jak poznáte, že oprava funguje. Pokud část systému provozuje partner, dohodněte cestu k jeho důkazům a reakci na nález. Neověřený předpoklad o cizí službě označte otevřeně. Priorita se pak dá určit společně s vlastníkem produktu podle skutečného dopadu. Takto vznikne bezpečnostní plán, který pomáhá každodenním změnám a lze jej udržovat i po předání aplikace. Pravidelná krátká revize po významném releasu udrží tento plán použitelný.