Architekti a vývojáři aplikací, které jsou provozovány zejména s přístupem přes veřejnou sít, se začínají stále častěji obracet na bezpečnostní specialisty s požadavkem na spolupráci. Taková spolupráce zpravidla znamená penetrační testy aplikace před uvedením do ostrého provozu. Zejména při velkých aplikacích typu internetový portál/bankovnictví se však často stává, že odstranění nalezených zranitelností je komplikované a obvykle znamená i změnu vlastního designu aplikace. Tyto změny pak zasahují do všech úrovní architektury aplikace (Business, IS, Data, Technology) a redesign vyžaduje zapojení mnoha architektonických a vývojových týmů.

Implementujte bezpečnost do vývojového cyklu aplikace

Souvisejícím problémem jsou rovněž zpoždění celých transition architektur, neboť postižená aplikace může být součástí širší Road mapy aplikací. Pozdní dodání dílčí postižené aplikace může mít tedy za následek neplnění business strategie se všemi finančními dopady. Tomuto problému se lze vyhnout pomocí SSDLC (Secure Software Development Life Cycle), tedy implementováním bezpečnosti do vývojového cyklu aplikace. Existuje více různých metodik, které popisují přístup k implementaci bezpečnosti do projektu, jako jsou například BSIMM (Building Security In Maturity Model), Microsoft SDL, NIST SDLC, OWASP OpenSAMM (Software Assurance Maturity Model), nebo Security část TOGAFu. Zapojení bezpečnosti znamená také snížení celkových nákladů na vlastnictví (TCO) a vyšší návratnost. Gartner uvádí, že odstranění 50% zranitelností ve fázi vývoje znamená pro společnost 75% snížení nákladů na odstranění zranitelností až po uvedení do produkce. Analýza Fortify Software zase ukázala, že odstranění bezpečnostních zranitelností ve fázi vývoje je stokrát levnější než oprava hotového softwaru.

Dobře nastavená komunikace urychluje realizaci bezpečnostních požadavků

Hlavním cílem SSDLC je zabezpečit, aby aplikace byla efektivní, stabilní, bezpečná, udržovatelná a vyvinutá v souladu s definovanými požadavky. Implementaci bezpečnostních požadavků, kontrol a opatření do vývojového cyklu pomáhá zabezpečit, aby bezpečnost byla součástí designu a aby náklady na vývoj a produkční prostředí zahrnovaly také bezpečnost.

Dříve než začnete bezpečnost implementovat do vývojového cyklu softwaru, musíte porozumět architektonické vizi aplikace, organizační struktuře projektu a vývojovému prostředí. Společné meetingy a workshopy vývojářů a bezpečnostních specialistů jsou klíčovým faktorem seznámení se se strukturou vývojového týmu a pomáhají při komunikaci s jednotlivými odděleními. Četné zkušenosti při podobných projektech potvrzují, že dobře nastavená komunikace mezi vývojem a bezpečností ulehčuje a urychluje realizaci jednotlivých bezpečnostních požadavků a opatření.

Plán implementace bezpečnosti

Na základě získaných informací vytvoříme plán implementace bezpečnosti do projektu, který obsahuje jednotlivé fáze vývoje konkrétní aplikace a s tím spojené aktivity security týmu. Tento plán by měl obsahovat všechny aktivity, počínaje analýzou rizik, bezpečnostními požadavky a konče penetračními testy, plány údržby a likvidace spolu s jejich časovým plánem. V závislosti na velikosti projektu se standardní SSDLC upravuje dle potřeby. Některé fáze je možné vypustit nebo sloučit, aby bylo možné zaručit přiměřenou míru bezpečnosti s ohledem na omezený rozpočet projektu.

Základní fáze implementace bezpečnosti

Podrobně popsat všechny SSDLC aktivity přesahuje rámec tohoto článku. Stručně si je však můžeme shrnout.

V úvodní fázi projektu začínáme se sběrem informací o vyvíjené aplikaci. Znalosti o funkcionalitách, citlivosti zpracovávaných dat, potencionálních hrozbách, organizačních politikách, zákonech a předpisech nám slouží jako vstupní data pro analýzu rizik. Analýza rizik identifikuje zranitelnosti a doporučuje vhodná protiopatření. Tato opatření spolu s požadavky zadavatele, požadavky z norem a zákonů jsou zdokumentované jako seznam NFR (non-functional requirements). Na pomoc při tvorbě bezpečnostních požadavků si můžeme vzít standardy organizace NIST, konkrétně SP 800-53 (Recommended Security Controls for Federal Information Systems and Organizations). Tato publikace obsahuje detailní seznam bezpečnostních požadavků seřazených do logických celků podle oblasti využití spolu s odhadnutou prioritizací. Vybráním relevantních požadavků zmíněného standardu NIST a doplněním o další požadavky, které byly identifikovány předešlými aktivitami, vzniká kompletní seznam bezpečnostních požadavků na vyvíjenou aplikaci. Seznam NFR je dále komunikovaný do projektu, aby se zaručilo, že každý člen projektového týmu bezpečnostním požadavkům rozumí a umí je zapracovat do své části aplikace. Novela ISO/IEC 27001 zavádí povinnost projekt manažera zajišťovat implementaci těchto NFR.

V další etapě, ve spolupráci s projektovým týmem, je vhodné navrhnout a popsat, jak budou jednotlivá NFR splněna. Například, jak se implementuje požadavek na bezpečnostní komunikaci mezi frontendem a backendem. Tyto informace se využijí nejen při plánovaném auditu a penetračních testech, ale také při troubleshootingu případných chyb. Návrh implementace bezpečnostních požadavků se odsouhlasuje na projektové úrovni a následně bezpečnostní specialisté poskytují svoje konzultace vývojářům.

Revizí technické dokumentace se security tým zapojuje do procesu vývoje aplikace, kde upravuje a doplňuje bezpečnostní hledisko. Samotný kód aplikace je možné kontrolovat manuálně nebo pomocí různých automatizovaných nástrojů. Na trhu je jich dostatek, od opensource až po velká řešení renomovaných značek jako je IBM nebo HP. Bezpečnost a čistotu kódu umíme vylepšit i vypracováním metodik bezpečného programování a školením programátorů, což je rovněž nový požadavek novely ISO/IEC 27001.

Fáze testování z hlediska bezpečnosti znamená zejména penetrační testy. Ty je potřeba dopředu naplánovat a odsouhlasit na projektové úrovni. Penetrační testy vyžadují dostatek času na odladěném a hardenovaném prostředí s potřebnou součinností. Pokud není možné provést hardening na budoucím produkčním prostředí, pak je nutné pomocí konfiguračního managementu (CMDB) přesně zafixovat testovací prostředí a penetrační testy provést zde. Na produkčním prostředí lze pak ověřit shodu konfigurace s testovacím prostředím. Pokud to provozní podmínky umožní, pak můžeme prosadit provedení alespoň ověřovacích testů nedestruktivní povahy (Safe Check) i na produkčním prostředí. Vyvíjenou aplikaci je potřeba z pohledu vektorů útoku otestovat interně i externě, aplikačně i infrastrukturně. K fixaci identifikovaných zranitelností musíme mít v projektovém plánu vyhrazen dostatek času.

Po realizaci výše uvedených aktivit může bezpečnostní tým projektu odsouhlasit, že aplikace je vhodná pro provoz v produkčním prostředí. Zaručit stoprocentní bezpečnost aplikace, v průběhu jejího provozu, však nelze. Pouze pravidelným testováním a opravami je možné provozovanou aplikaci udržovat v relativně bezpečném stavu, vhodném pro provoz ve veřejně přístupné síti.

Juraj Porubčan, Maroš Barabas