Softujte softly, ale především BEZPEČNĚ! Všichni!
Jak integrovat maximální možné zabezpečení do celého životního cyklu vývoje softwaru (SDLC)? Jak zapojit do ochrany opravdu každého ve firmě? Jak nenechávat toto břímě jen na bezpečnostních týmech? Jak proměnit inovace v zabezpečení z překážky a „zdržovačky“ v hnací sílu byznysu? Na všechny tyto otázky hledá – a navrhuje – odpověď Miroslav Horáček, Senior Security Engineer z MEWS.
Proč je bezpečnost věcí nás všech?
Proces vývoje softwaru SDLC (Software Development Life Cycle) je už dnes samozřejmostí snad všude, kde se touto činností zabývají. (Zejména u vodopádově řízených projektů.) Nedílnou součástí každé z jeho etap – od plánování, analýzy požadavků, návrhu, vývoje, testování až po nasazení a údržbu – by měla být bezpečnost. Prodej, marketing, správa rizik a mnohá další oddělení k ní vždy mají co říct, jejich podněty jsou pro vývojáře kruciální. Například když salesmani tlačí na zavedení nových funkcionalit, které by jim pomohly prodávat, je určitě třeba juknout na ně bezpečnostní optikou. Ochranou osobních údajů počínaje a regulačními standardy nekonče. A předjímat! Protože ve fázi, kdy je bezpečnost již narušena, bývá většinou na záchranu pozdě. Pokud byste měli zájem se o problematice SDLC dozvědět více, můžete navštívit odkaz pod tímto odstavcem.
Zajímavosti k problematice: https://github.com/resources/articles/software-development/what-is-sdlc
Shift Left aneb Čím dříve bezpečně, tím lépe
Koncept Shift Left (posun doleva ve smyslu k začátku, nikoli politicky) je pro Miroslava Horáčka klíčový. Apeluje, aby se otázky bezpečnosti při vývoji softwaru výrazněji přesunuly z „chvostu“ procesu již na jeho prvopočátek. A poté se zdokonalovaly a zdokonalovaly. Pokud bychom použili paralelu s ontogenezí (vývoj lidského jedince), chyba či opomenutí při početí se můžou při zrodu produktu projevit jako fatální, neopravitelné apod. Mnohdy je třeba začít úplně znova… (A všichni víme, jak je další dítě nákladné!)
Jak ale na to? Kupříkladu automatizovanými testy zranitelnosti, které mohou být součástí CI/CD (Continuous Integration/Continuous Deployment) pipeline. Vývojový proces nikterak nezpomalí, ale významně ho jistí dokonce i z hlediska potenciálních hrozeb. Koncept Shift Left jako takový sdílí některé vlastnosti a může být i dobře ilustrován W modelem, který se používá k testování aplikací od prvopočátku až do úspěšného konce.
Zajímavosti k problematice: https://www.testbytes.net/blog/v‑model-and-w-model-software-testing
Budování kultury bezpečnosti
Bezpečnostní specialisté by měli být bráni jako pomocníci, partneři, služebníci. Nikoli jako troublemakeři a prudiči, jak tomu mnohdy bývá. Což se lehko řekne, jenže ztěžka mění. „Zažranost“ negativního vnímání „bezpečáků“ do našich podvědomí jako by byla „nevypratelná“. Cesta k očistě je vzhledem k technologiím, o nichž je řeč, prastará, až pravěká: Mluvit spolu, komunikovat, naslouchat, spolupracovat, chápat. Rozvíjet mezitýmové družení.
We have the Champions, my friend
Program Security Champions je jednou z akceptovatelných lidských pák, jak relativně bezbolestně budovat bezpečnostní firemní kulturu. Zjednodušeně řečeno: Jde o sestavení týmu komunikačně obdařenějších „šampionů“ – úderníků exportu nezbytnosti bezpečnostních opatření. Kam toto poselství exportují? Do mozkoven svých týmů. I když třeba nejsou odborníky na bezpečnost… (Ani oni, ani ti, které ovlivňují).
Pro softwarové „bezpečáky“ plní funkci tiskových mluvků, tlumočníků, mediátorů… Je ostatně jedno, jak se jim rozhodnete říkat. Musejí však plnit roli „mostu“ mezi bezpečnostními experty a vývojáři a v rámci možností garantovat, že budou opatření nejen správně komunikována, ale také implementována. Samozřejmě bez zpomalení vývojového procesu! A v neposlední řadě šířit evangelium bezpečnosti i v týmech, které za ni nejsou přímo odpovědné.
Threat Modeling: Namodelujte si hrozby
Threat Modeling je něco jako brain storming v oblasti tvorby katastrofických scénářů. Respektive skupinová identifikace a analýza potenciálních rizik, tj. bezpečnostních hrozeb spojených s novými funkcemi nebo aplikacemi. A zahrnuje i mudrování o možnostech jejich eliminace. Chcete-li dát těmto preventivním seancím alespoň základní kostru, Miroslav Horáček doporučuje položit si a postupně probrat tyto otázky:
1. Na čem pracujeme? / Základní pochopení funkce a datových toků.
2. Co se může pokazit? / Identifikace potenciálních bezpečnostních problémů.
3. Co s tím uděláme? / Definování opatření k minimalizaci rizik.
4. Jaký to má vliv na náš vývoj? / Určení, jakým způsobem může analýza ovlivnit vývoj a jak ji využít k dalším vylepšením bezpečnosti v budoucnosti.
Jak na Threat Modeling
Ano, i k užívání metody Threat Modeling existují návody, manuály, metodiky. Jako snad ke všemu. Není se jich však prý třeba držet jako fekálie košile. Každý tým si tato sezení může přizpůsobit svým potřebám, ba i úchylkám. Jednoduché nástroje např. typu diagramu v MS Paint určitě nejsou tabu ani na indexu.
Co je důležitější, je ukládání. Výsledky předjímání katastrofických tornád by neměly profučet ventilátory klimatizací do ztracena. „Já vám to říkal,“ není argument, není-li doložitelný. Nespoléhejte na paměť, práce s výstupy Threat Modelingů je nezbytná k úspěchu vytyčené bezpečnostní strategie. Určitě také nezapomínejte na zpětnou vazbu od ostatních týmů a aktualizace.
Kontinuální kooperace a zlepšovatelské hnutí – váš cíl!
Zajištění nejlepšího možného zabezpečení stojí a padá s permanentní spoluprací mezi bezpečnostními týmy a vývojáři. Nikdy není hotovo, nikdy není „padla“. Stále je nebytné aktualizovat, zlepšovat, vyvíjet nové metodiky. Čerti a „hackeři nikdy nespí! Bez vzájemné mezitýmové empatie však bezpečného, ale zároveň efektivního vývoje softwaru pravděpodobně nikdy nedosáhnete. I v digitálním věku je to zkrátka o mezilidských vztazích ve firmě a vzájemném pochopení. O bezpečné lásce, chcete-li.
