IT bezpečnost v agilním světě

IT bezpečnost je v agilním světě „enabler“, který jednotlivým týmům a tribeům (viz nomenklatura agilně řízených organizací či DevOps seriál v DSM [1]) umožňuje dosahovat jejich business cílů při zachování akceptovatelné míry IT rizik.

S-SDLC             bezpečný vývoj             statická analýza kódu             agile

Následující text se pokusí pro mnohé kontroverzní tvrzení zasadit do reálného prostředí agilně řízených a na technologie silně orientovaných společností a pojmenovat kulturní i technické aspekty činnosti týmu IT bezpečnosti.

Kultura

Ve světě „před agilem“ se užívala zejména kontrolní nebo oponentní role IT bezpečnosti (i bezpečnosti obecně), tzn. IT bezpečnost vydávala směrnice a nařízení (definovala poměrně obecné požadavky na bezpečnost) a kontrolovala jejich dodržování. Tento koncept skvěle vyhovoval požadavkům na rozdělení kompetencí („separation of duties“ [2]), ale nutně generoval jisté tření mezi IT bezpečností a tvůrčími silami organizace (ať už IT vývojem a provozem či vlastníky projektů).

V organizacích, jejichž velikost to dovoluje, se někdy vyskytuje ještě další členění oddělení IT bezpečnosti na „design bezpečnosti“ a „implementaci bezpečnosti“ (pozn. byť zde lze mluvit zejména o síťové a infrastrukturní bezpečnosti, ale nikoli o aplikační), což ještě více podtrhuje koncept rozdělení kompetencí, ale zároveň to některé třecí plochy zapouzdřuje dovnitř samotného týmu IT bezpečnosti.

Agilní prostředí v jistém smyslu navazuje na koncept zapouzdření designu a implementace bezpečnosti do týmu IT bezpečnosti; tendence zapouzdření zůstává, avšak nikoli do týmu IT bezpečnosti, ale přímo do výkonných týmů a tribeů. Celá koncepce uvažování o IT bezpečnosti se tak přesouvá od „aby mohl být realizován můj projekt, potřebuji schválení/oponenturu od týmu IT bezpečnosti, že projekt nese pouze akceptovatelná bezpečnostní rizika“ k „mám v týmu kompetentního delegáta týmu IT bezpečnosti, který detailně porozumí rizikům daného projektu a zajistí, abychom v projektu udrželi akceptovatelnou míru rizik“.

V praktické rovině pak tým IT bezpečnosti čelí manažerské výzvě, jak tuto roli personálně zajistit. Typickým krokem je vedení zejména zkušených technických pracovníků k porozumění podstatě relevantních bezpečnostních rizik a jejich včasné identifikaci. Tuto schopnost lze rozvíjet jak koncentrovaným vzděláváním, tak přátelskou diskusí a objasňováním podstaty rizik, na které týmy samotné neupozornily.

Funkční a efektivní plnění role IT bezpečnosti v agilním prostředí je též zajímavým testem kvality implementace agilního řízení v organizaci. Agilní řízení totiž neznamená chaos a bezvládí, nýbrž práci řízenou v relativně krátkých cyklech, které dodávají malé objemy změn. Delegáti IT bezpečnosti by měli mít jistotu, že jsou účastni všech relevantních aktivit (designu, implementace i testování) u všech jim příslušných týmů.

Rizikovou oblastí jsou pak dodávky změn s dopadem na vícero týmů (např. změny sdílených microservices). Jako efektivní se ukazuje organizace fór s přesahem do všech týmů, kde probíhá identifikace dopadů změn na ostatní týmy. Vlastník změny prezentuje svůj záměr a ostatní týmy mají prostor proklamovat dopady na jimi vlastněná aktiva. Pokud nelze rychle najít shodu na dalším postupu, je vhodné delegovat rozhodnutí na ad hoc vzniklou skupinu zástupců dotčených teamů. Je důležité nezapomenout, že diskuse několika málo účastníků nad konkrétními technickými detaily činí fórum pro ostatní účastníky neatraktivní. Stěžejní pro funkčnost systému je dobře vedená a předem známá agenda setkání, která umožňuje jednotlivým týmům rozhodnout o nutnosti své účasti a výběru nejvhodnějších zástupců. Pro IT bezpečnost je toto fórum vhodným prostředím pro identifikaci rizik, která přesahují jednotlivé týmy.

Chce-li tým IT bezpečnosti dosahovat svých cílů v agilně řízené organizaci, tzn. systematicky udržovat na akceptovatelné úrovni míru bezpečnostních rizik plynoucích z podnikatelských aktivit organizace,

1. musí se stát důvěryhodnou autoritou, tvůrcem řešení/ zmírnění identifikovaných rizik, za kterým kolegové s důvěrou jdou, mají-li podezření či pochybnost o bezpečnosti,
2. musí být schopen rozšiřovat mezi kolegy porozumění podstatě identifikovaných rizik a problémů, čímž kolem sebe buduje síť „očí a uší“, které mu v budoucnu pomohou se soustředit právě na ty důležité momenty, 
3. musí být schopen najít „businessové“ dopady rizik či problémů ryze technické povahy a komunikovat o nich s netechnickými kolegy tak, aby porozuměli jejich závažnosti.

Aby byl tým IT bezpečnosti schopen celou zmíněnou plejádu rolí naplňovat a stát se skutečným „enablerem“, musí získat relevantní měkké dovednosti, znalosti technologických konceptů užívaných IT v jeho organizaci („application stack“) a zejména výbornou znalost nástrojů, které mu umožní jeho práci co nejvíce automatizovat a dlouhodobě automatismy zdokonalovat.

Role IT bezpečnosti v přípravných fázích IT projektů (v rámci vodopádové metodologie vývoje softwaru odpovídají „studii proveditelnosti“ a „technickému designu“) je poněkud ztížena absencí formalizovaných procesů a dokumentů. Pracovníci si do jisté míry musejí přístup k informacím vydobýt akcentováním svého přínosu pro projekty, systematickým budování image pro-zákaznické orientace i rozvojem mezilidských vztahů alespoň s některými členy jednotlivých týmů a tribeů.

Jakmile ale začnou v projektech vznikat hmatatelné artefakty, viditelnost do změn i schopnost jejich dalšího vyhodnocování se zásadně rozšíří. Agilně řízené organizace už ze své povahy směrují k co největší míře automatizace, což zcela nutně vede k tomu, že se čím dál více artefaktů stává kódem.

V dalším textu se zaměříme na klíčové vlastnosti některých „application stacks“ i na některé nástroje, které mohou IT bezpečnosti umožnit držet krok s rychlým tempem agilního vývoje.

Moderní prostředí Infrastructure-as-Code, Docker, Kubernetes

Zřejmě největší posun nastal v přístupu ke správě infrastruktury a její konfiguraci. I v prostředí, kde jsou nadále provozovány jednotlivé fyzické servery, lze s použitím nástrojů typu Puppet (https://puppet.com/) dosáhnout toho, že změny v konfiguraci jednotlivých tříd serverů jsou prováděny automatizovaně na základě konfigurací (kódu) daného nástroje.

A přesune-li se provoz do modernějších prostředí veřejných či privátních cloudů či Dockeru a Kubernetes, rozsah i abstrakce konfigurace se ještě rozšíří. Z podstaty fungování Dockeru je minimalizována chybovost provádění změn, jelikož se nejedná o přidání funkčnosti/služby do již existujícího operačního systému, ale o spuštění (typicky) jednoúčelového, standardizovaného binárního obrazu, který poskytuje právě a jen tu službu/funkčnost. Technicky se jedná o binární obraz souborového systému obvykle s operačním systémem typu Linux a několika balíčky vlastní výroby či třetích stran, které dohromady poskytují kýženou funkcionalitu. Prostředí typu Kubernetes jde ještě dál a umožňuje definovat jako kód celkovou architekturu systému ať již na úrovni virtuální sítě, abstraktních entit typu služba (množina Docker kontejnerů, které dohromady navenek poskytují funkcionalitu) a dalšího logického členění sítí, služeb a interakcí či vztahů mezi nimi (např. lze vytvářet pravidla týkající se vyvažování zátěže a propustnosti systému).

Téma Dockeru a Kubernetes značně přesahuje záběr tohoto článku. Rovněž se nejedná o jediné technologie tohoto typu, jejich popis zde je pouze přehledový a poukazuje na vlastnosti platformy zajímavé z pohledu řízení bezpečnosti. Obdobné úrovně abstrakce lze dosáhnout u všech světových poskytovatelů cloudové infrastruktury. Čtenář už jistě tuší, jaké možnosti výše popsaná prostředí přinášejí pro funkci bezpečnostního oddělení:

1. Kompletní IT infrastruktura předmětného systému je 100% zdokumentovaná kódem/konfigurací, z níž ji dané dockerizované prostředí, resp. Kubernetes, sestaví.
2. Díky standardizovanému jazyku lze definici infrastruktury dále programově zpracovávat – z popisu generovat víc čtenářsky orientované dokumenty vhodné i pro doložení shody s vnitřními směrnicemi či oborovou legislativou.
3. Infrastruktura bude sestavena vždy stejně, jelikož se jedná o automatizovaný proces. O dopadech na migraci na jiný HW či obnovu po katastrofických situacích zřejmě není potřeba dlouze psát.
4. Povaha konfigurace takového prostředí umožňuje její uložení do obvyklých repositářů zdrojových kódů (např. git či SVN).
5. A pak už je jen krůček ke stavu, kdy dojde k nasazení nové architektury na produkční prostředí na základě přiřazení specifické značky („tag“) dané verzi konfigurace či zařazení dané verze konfigurace do specifické větve („branch“) v repositáři zdrojových kódů, kde lze zajistit i schvalovací proceduru. Vzniká tak jasná auditní stopa o tom, jaká verze konfigurace prostředí byla v jaký moment v čase provozována a jakým rozhodnutím se tam dostala.
6. Vyspělá implementace bodu 5 pak vede k nezvyklé situaci, kdy samotní členové týmů nepotřebují (a v rámci minimalizace vlastní expozice rizik ani nechtějí) přístupy na produkční instance; veškerá jejich činnost probíhá na úrovni vložení („commit“) nové verze některé části konfigurace prostředí do repositáře zdrojových kódů či schválení změn zanesených jinými kolegy.
7. Pro čtenáře bude zřejmě jen triviálním konstatováním, že je lehké idenfitikovat jednotlivé změny i mezi vzdálenými verzemi konfigurací a o všem existuje auditní stopa. Vzhledem ke strojové zpracovatelnosti meta dat repositářů zdrojových kódů se opět nabízejí možnosti automatizace dokumentace.

I samotní tvůrci repositářů zdrojových kódů vycházejí mnohým z výše uvedených bodů vstříc. Např. GitLab [3] nabízí přímou integraci na prostředí Kubernetes i funkci tzv. GitLab Runners čili agentů (služeb operačního systému) řídících nasazení nových verzí na základě specifických konfigurací obsažených v samotném zdrojovém kódu daného SW. Detailní analýza schopností Gitlabu přesahuje rozsah tohoto článku, ale zadáním klíčového slova „.gitlab-ci.yml“ do oblíbeného vyhledávače získá čtenář mnoho zdrojů informací. Obdobných výsledků lze dosáhnout i na jiných platformách, za zmínku stojí např. nedávno spuštěné GitHub Actions [4].

Ať už padne výběr řešení na variantu integrovanou v repositáři zdrojových kódů, samostatný build server, vlastní řešení či kombinaci, skrývá automatizace procesu nasazení nové verze potenciál pro další synergie s IT bezpečností. Synergie se nabízejí jednak před sestavením výsledného binárního obrazu (byť u mnoha dnes moderních jazyků se nejedná o binární obraz v pravém slova smyslu) k testům, během samotného testování i ve fázích nasazení binárních obrazů, které úspěšně prošly testy, na cílové prostředí.

Porozumění a další práce s kódem v mnohých formách se v agilně řízeném prostředí stává nutností a porozumění terminologii a zejména dynamice architektury bude klíčové pro získání, udržení a rozvoj důvěry tvůrčích týmů vůči IT bezpečnosti. Jenom takové pojetí IT bezpečnosti, které bude umět navrhovat a implementovat bezpečnostní mechanismy v souladu s klíčovými koncepty používaného „application stacku“ může získat respekt vývojářů. A právě zlepšení vztahu mezi vývojáři a IT bezpečností mohou pomoci v další části popsané nástroje.

SAST a lintery

Už nad samotným zdrojovým kódem aplikací lze provést řadu bezpečnostních testů. Tyto testy mohou být realizovány textovým zpracováním zdrojového kódu nebo komplexnějším modelováním stromů volání jednotlivých komponent/ tříd mezi sebou a identifikací bezpečnostních mechanismů v jednotlivých průchodech (nástroje typu SAST – Static Application Security Testing).

První varianty typicky představují různé „lintery“, které mohou být exekuovány už v rámci vývojového prostředí na pracovní stanici vývojáře a upozorňují na případné nekonsistence či rizikové konstrukty. Z povahy jejich fungování je rámec zpracování typicky omezen na jednu třídu/soubor zdrojového kódu, který je značně limitován. Komplexnější, byť pořád pouze textové zpracování zdrojových kódů s větším důrazem na bezpečnost nabízí třeba open source systém Sonarqube [5].

U nástrojů typu SAST probíhá komplexnější zpracování zdrojových kódů, kdy dochází k analýze toku dat od jednotlivých vstupních rozhraní až po výstupní rozhraní skrze všechny toku se účastnící třídy a funkce. Hloubka zkoumání je z podstaty nesrovnatelná s výše popsanými lintery. Autor si není vědom existence efektivních open source řešení. Společnost Gartner za rok 2019 v kvadrantu „Leaders“ jmenuje výrobce Synopsys, Mirco Focus, Veracode a Checkmarx [6].

V neposlední řadě přináší moderní build frameworky (např. Maven či Graddle v prostředí Javy, npm v prostředí Javascriptu) jasnou a přehlednou definici závislostí na knihovnách třetích stran. Je tedy možno automatizovat kontrolu existence známých zranitelností v používaných verzích knihoven. Tuto funkci často zajišťují i výše zmíněné nástroje. Pokud to printová verze dovolí, lze uvést třeba nasledující (viz Obr. 2).

Z pohledu začlenění IT bezpečnosti do tvůrčích týmů je kritické zmínit, že výše popsané postupy nezajišťují pouze tok informací k IT bezpečnosti, ale typicky i zpětnou smyčku k samotnému vývojáři. Psychologicky nepříjemný moment, kdy musí IT bezpečnost přednést oponenturu k výstupu tvůrčích složek, se tak zcela vytrácí a namísto něj vzniká spíše jakási hra, kdy vývojář vytváří kód vyhovující testovacím scénářům, v tomto případě specificky testovacím scénářům bezpečnostním (zajímavé klíčové slovo „test-driven programming“).

Tým IT bezpečnosti konfigurací zmíněných nástrojů vytváří jednu ze „security gates“ a vynucuje implementaci bezpečnostních mechanismů ve zdrojových kódech projektu nebo celé organizace. Zásadní změnou paradigmatu je, že IT bezpečnost nese plnou odpovědnost za to, aby se vývojář včas (tedy během vývoje) dozvěděl, že jeho kód nese bezpečnostní nedostatky. IT bezpečnost musí přijmout za své, že bezpečnostní zranitelnosti plynoucí z kódu, odhalené teprve ve finálních binárních obrazech, jsou nedostatkem testování zdrojových kódů, nikoli nedostatkem jejich autora. A právě transfer odpovědnosti působí jako katalyzátor sounáležitosti mezi tvůrčími silami a IT bezpečností.

Za předpokladu volby vhodného nástroje a systematického budování know-how v uvedených oblastech může IT bezpečnost promítat poučení z jakýchkoli bezpečnostních incidentů do definice nových či úpravy stávajících pravidel vynucovaných uvedenými nástroji. Přechodem na moderní způsoby virtualizace typu Infrastructure-as-Code, kde zdrojový kód projektu pokrývá celé IT prostředí a všechny jeho administrátorsky definované vlastnosti, pak činí ze zpracování zdrojových kódů nesmírně silný nástroj zajištění bezpečnosti dodávek, které teprve vstupují do procesu testování, o němž bude řeč v následující části textu.

Testování

S ohledem na krátké sprinty, v nichž vývoj probíhá, je i fáze testování typicky vysoce automatizovaná. IT bezpečnost tak má možnost vyžadovat implementaci testů zaměřených na zabezpečení aplikace, a to zejména ve smyslu ověření logických a procesních omezení klíčových interakcí se systémem např. pro různé uživatelské role či jednotlivé stavy vybraných procesů.

Mnohem zajímavější je zahrnout do řetězce („pipeline“) testování spuštění specializovaných bezpečnostních nástrojů pro dynamickou analýzu bezpečnosti, tzv. DAST – Dynamic Application Security Testing. Zejména v prostředí webových aplikací je dnes na trhu poměrně běžné, že scannery nabízejí (typicky RESTfull) API, kterým je možné programově ovládat funkce scanneru. Využít lze např. dříve v DSM recenzovaný BurpSuite či open source OWASP ZAP, byť ani zde se rozhodně nejedná o komplexní výčet potenciálně využitelných nástrojů. Zapojením tohoto typu nástroje lze vytvořit další ze „security gates“, na nichž může být IT bezpečnost vynucována. Potenciálním úskalím integrace tohoto typu nástrojů do řetězce testů může být větší časová náročnost provedení.

Pro některé jazyky (na trhu jsou dostupná zejména řešení pro Javu) může být extrémně zajímavé využití injektáže doplňku („plug-in“) scanneru přímo do runtime aplikace. Scanner tak získá viditelnost do událostí odehrávajících se v runtime aplikace, které ale nemusejí aplikace na svých výstupních rozhraních nijak propagovat. Lze tak docílit odhalení některých nových typů chyb, např. v integracích na straně serveru, i eliminovat některé druhy „false positives“. Opět platí, že zmíněný BurpSuite rozhodně není jediným kandidátem a zajímavé klíčové slovo pro vyhledávání představuje IAST – Integrated Application Security Testing.

Je též nevyhnutelné brát ohled na specifika architektury moderních webových (single page – SPA) či mobilních aplikací. Vstupní body interakce mezi SPA a serverovou částí jsou definovány abstraktními syntaktickými konstrukty, typicky v Javascriptu, nikoli pevně danými HTML tagy známými z dob formulářových aplikací. A byť se většina scannerů snaží veškerý Javascript kód vykonat v jakémsi simulovaném prohlížeči a identifikovat jednotlivá rozhraní, je víceméně pravidlem, že se to zdaří zčásti nebo vůbec. U mobilních aplikací je situace podobná, byť schopnosti scannerů jsou ještě o poznání slabší či zcela absentují.

Serverové rozhraní SPA typicky představuje množina (RESTfull či SOAP) webových služeb, ke kterým může existovat strojově zpracovatelná dokumentace (dnes populární Swagger pro RESTfull či WSDL pro SOAP), s níž dokážou pracovat i scannery. Není to ale pravidlem, a tak zůstává mnoho aplikací pro automatizovaný scanner neuchopitelných.

Pro tyto případy lze využít synergii s automatizovanými funkčními a integračními testy. Typické testovací frameworky simulující práci uživatele v aplikaci dle předem daných scénářů, např. Selenium, umožňují využití proxy serveru pro přístup klientské („frontend“) k serverové části („backend“). Např. pro webovou aplikaci lze programově nastavit proxy server browseru, ve kterém je vykreslena klientská část aplikace a prováděny uživatelské akce.

Oba výše zmíněné nástroje, BurpSuite a OWASP ZAP, nabízejí rozhraní proxy serveru, které lze v tomto scénáři efektivně využít k získání ukázek jednotlivých interakcí klientské a serverové části aplikace. Scannery pak dokážou nad množinou ukázkových volání provést alespoň na server- -side orientovanou část testů. Kombinací DAST a SAST nástrojů získává tým IT bezpečnosti, ale i vývojáři samotní, množství informací o potenciálních či potvrzených bezpečnostních rizicích v aktuálním sestavení a mají prostor kvalifikovaněji (než bez těchto informací) rozhodnout o nasazení binárního obrazu systému na produkční prostředí.

Artefakty

Před samotným nasazením na cílové prostředí je obvykle vyžadováno ověření integrity a původu nasazovaného binárního obrazu. Pro IT bezpečnost se nabízí zajímavá synergie v podobě zajištění důvěryhodnosti zdroje samotného artefaktu či ověření některých vlastností daného artefaktu za použití kryptografie. Triviální scénář této strategie představuje kontrola, zda digitální podpis daného artefaktu náleží autorizovanému zdroji tohoto typu artefaktů (např. build serveru) v momentě nasazení na cílové prostředí.

Zajímavější a přínosnější je pak rozšíření scénáře tak, aby byly artefakty opatřovány různými digitálními podpisy, pokud úspěšně projdou jednotlivými částmi řetězce sestavení („build pipeline“). Ilustrativním příkladem může být kontrola, zda z binárního obrazu mobilní aplikace byly odstraněny lidsky čitelné řetězce („obfuskace“) před umístěním do veřejné distribuce (čili k artefaktu existuje digitální podpis komponenty zajišťující odstranění lidsky čitelných řetězců). V případě sestavení binárního obrazu pro účely testů je naopak odstranění lidsky čitelných řetězců nejen zbytečné, ale dokonce kontraproduktivní, a tedy artefakt nesmí být tímto digitálním podpisem opatřen.

Praktické užití tohoto konceptu bude odlišné u každé organizace, v některých případech dokonce projekt od projektu. Pro všechny scénáře ale bude společné, že jsou na předmětná prostředí prokazatelně a nepopiratelně nasazovány pouze artefakty pocházející z autorizovaných zdrojů (čili zdrojů s přístupem k příslušnému privátnímu klíči, kterým je pak zajištěn podpis). Právě v oblasti zajištění integrity na produkční prostředí nasazovaných artefaktů může IT bezpečnost poměrně rychle a jednoduše získat kredit, jelikož nasazení popsaných či obdobných mechanismů vede k nahrazení administrativy automatizací, a to je u tvůrčích pozic ceněno obzvláště.

Závěr

Téma agilního řízení, a to nejen ve vztahu k softwaru, nepopiratelně přineslo světu množství progresivních technologií a postupů, které však nesou i změnu paradigmatu, a to jak v rovině technické, tak v rovině organizační a kulturní. Jednotlivé části článku na jedné straně upozorňují na ústup formalismu v rámci dodávek projektů a s tím související nutnost změny orientace IT bezpečnosti v agilně řízených organizacích. Na druhé straně článek nabízí cesty, nástroje a postupy, jak a kde může IT bezpečnost upevnit svoji pozici v agilních strukturách nabídkou takových služeb a výstupů, které nebudou stát v cestě agilním postupům, ale naopak je podporovat, aniž by došlo k celkovému zvýšení míry akceptovaných rizik jednotlivých dodávek.

Pojem „enabler“ v kontextu tohoto článku tak především odpovídá roli, v níž IT bezpečnost přebírá odpovědnost za bezpečnostní aspekty výstupů projektů („deliverables“) a odměnou jí je nejen deklarativní, ale i reálné docenění jejího přispění k úspěchu jednotlivých projektů i organizace jako celku.

Relevance článku je podpořena praktickými zkušenostmi Davida Doležala a Jana Horalíka ze Zonky a Martina Mačoka z GoodData.

Použité zdroje:

[ 1 ] Data Security Management, 2018/03–2020/02

[ 2 ] Separation of duties , 12 April 2019, at 21:36, https://en.wikipedia.org/wiki/Separation_of_duties

[ 3 ] gitlab Homepage, https://about.gitlab.com/

[ 4 ] About continuous integration https://help.github.com/en/actions/automating-your-workflow-with-github-actions/about-continuous-integration

[ 5 ] Sonarqube homepage, https://www.sonarqube.org/

[ 6 ] Synopsys named a Leader in the 2020 Gartner Magic Quadrant for Application Security Testing for the 4th year, https://www.synopsys.com/ blogs/software-security/gartner-mq-ast-2020/#:~:text=Synopsys%20named%20a%20Leader%20in,Testing%20for%20the%204th%20year&text =May%201st%2C%202020-,In%20the%202020%20Gartner%20Magic%20Quadrant%20for%20Application%20Security%20Testing,and%20our%20 completeness%20of%20vision.

[ 7 ] Twitter post, https://twitter.com/gabro27/status/1173547934132178944?lang=en