Sof­t­u­jte soft­ly, ale přede­vším BEZPEČNĚ! Všichni!

Pro­ces vývo­je soft­waru SDLC (Soft­ware Devel­op­ment Life Cycle) je už dnes samozře­j­mostí snad všude, kde se touto čin­nos­tí zabý­va­jí. (Zejmé­na u vodopá­dově řízených pro­jek­tů.) Nedíl­nou součástí každé z jeho etap – od plánování, analýzy poža­davků, návrhu, vývo­je, testování až po nasazení a údržbu – by měla být bezpečnost. Prodej, mar­ket­ing, sprá­va rizik a mno­há další odd­ělení k ní vždy mají co říct, jejich pod­ně­ty jsou pro vývo­jáře kru­ciál­ní. Napřík­lad když sales­mani tlačí na zave­dení nových funkcionalit, které by jim pomohly prodá­vat, je určitě tře­ba juknout na ně bezpečnos­t­ní optik­ou. Ochra­nou osob­ních úda­jů počí­na­je a reg­u­lační­mi stan­dardy nekonče. A před­jí­mat! Pro­tože ve fázi, kdy je bezpečnost již naruše­na, bývá větši­nou na záchranu pozdě. Pokud byste měli zájem se o prob­lem­at­ice SDLC dozvědět více, můžete navštívit odkaz pod tím­to odstavcem. 
Zají­mavosti k prob­lem­at­ice: https://​github​.com/​r​e​s​o​u​r​c​e​s​/​a​r​t​i​c​l​e​s​/​s​o​f​t​w​a​r​e​-​d​e​v​e​l​o​p​m​e​n​t​/​w​h​a​t​-​i​s​-sdlc

Kon­cept Shift Left (posun dol­e­va ve smys­lu k začátku, nikoli pol­i­ticky) je pro Mirosla­va Horáč­ka klíčový. Apelu­je, aby se otázky bezpečnos­ti při vývo­ji soft­waru výrazněji pře­sunuly z ​„chvos­tu“ pro­ce­su již na jeho prvopočátek. A poté se zdokon­alo­valy a zdokon­alo­valy. Pokud bychom použili para­lelu s onto­genezí (vývoj lid­ského jed­ince), chy­ba či opomenutí při početí se můžou při zro­du pro­duk­tu pro­je­vit jako fatál­ní, neo­pravitel­né apod. Mno­hdy je tře­ba začít úplně zno­va… (A všich­ni víme, jak je další dítě nákladné!)

Jak ale na to? Kupřík­ladu autom­a­ti­zo­vaný­mi testy zran­itel­nos­ti, které mohou být součástí CI/CD (Con­tin­u­ous Integration/​Continuous Deploy­ment) pipeline. Vývo­jový pro­ces nik­ter­ak nezpo­ma­lí, ale výz­nam­ně ho jistí dokonce i z hlediska poten­ciál­ních hrozeb. Kon­cept Shift Left jako takový sdílí něk­teré vlast­nos­ti a může být i dobře ilus­tro­ván W mod­elem, který se používá k testování aplikací od prvopočátku až do úspěšného konce. 
Zají­mavosti k prob­lem­at­ice: https://www.testbytes.net/blog/v‑model-and-w-model-software-testing

Bezpečnos­t­ní spe­cial­isté by měli být bráni jako pomoc­ní­ci, part­neři, služeb­ní­ci. Nikoli jako trou­ble­makeři a prudiči, jak tomu mno­hdy bývá. Což se lehko řekne, jenže ztěž­ka mění. ​„Zažra­nost“ neg­a­tivního vnímání ​„bezpečáků“ do našich pod­vě­domí jako by byla ​„nevypratel­ná“. Ces­ta k očistě je vzh­le­dem k tech­nologiím, o nichž je řeč, pras­tará, až pravěká: Mlu­vit spolu, komu­niko­vat, naslouchat, spolupra­co­v­at, chá­pat. Rozví­jet mez­itý­mové družení. 

Pro­gram Secu­ri­ty Cham­pi­ons je jed­nou z akcep­to­vatel­ných lid­ských pák, jak rel­a­tivně bezbolest­ně budovat bezpečnos­t­ní firem­ní kul­tu­ru. Zjednodušeně řečeno: Jde o ses­tavení týmu komu­nikačně obdařenějších ​„šam­pi­onů“ – úderníků expor­tu nezbyt­nos­ti bezpečnos­t­ních opatření. Kam toto posel­ství expor­tu­jí? Do mozkoven svých týmů. I když tře­ba nej­sou odborníky na bezpečnost… (Ani oni, ani ti, které ovlivňují). 

Pro soft­warové ​„bezpečáky“ plní funkci tiskových mlu­vků, tlu­močníků, mediá­torů… Je ostat­ně jed­no, jak se jim rozhod­nete říkat. Muse­jí však plnit roli ​„mostu“ mezi bezpečnos­t­ní­mi exper­ty a vývo­jáři a v rám­ci možnos­tí garan­to­vat, že budou opatření nejen správně komu­niková­na, ale také imple­men­tová­na. Samozře­jmě bez zpo­ma­lení vývo­jového pro­ce­su! A v neposled­ní řadě šířit evan­geli­um bezpečnos­ti i v týmech, které za ni nej­sou pří­mo odpovědné. 

Threat Mod­el­ing je něco jako brain storm­ing v oblasti tvor­by katas­trofick­ých scénářů. Respek­tive skupinová iden­ti­fikace a analýza poten­ciál­ních rizik, tj. bezpečnos­t­ních hrozeb spo­jených s nový­mi funkce­mi nebo aplikace­mi. A zahrnu­je i mudrování o možnos­tech jejich elim­i­nace. Chcete-li dát těm­to pre­ven­tivním seancím ale­spoň zák­lad­ní kostru, Miroslav Horáček doporuču­je položit si a pos­tup­ně pro­brat tyto otázky: 

1. Na čem pracu­jeme? / Zák­lad­ní pochopení funkce a datových toků. 

2. Co se může pokaz­it? / Iden­ti­fikace poten­ciál­ních bezpečnos­t­ních prob­lémů. 

3. Co s tím uděláme? / Defi­nování opatření k min­i­mal­izaci 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čnos­ti v budoucnosti. 

Ano, i k užívání metody Threat Mod­el­ing exis­tu­jí návody, manuá­ly, metodiky. Jako snad ke vše­mu. Není se jich však prý tře­ba držet jako fekálie košile. Každý tým si tato sezení může přizpů­so­bit svým potře­bám, ba i úchylkám. Jednoduché nástro­je např. typu dia­gra­mu v MS Paint určitě nej­sou tabu ani na indexu. 
Co je důležitější, je ukládání. Výsled­ky před­jímání katas­trofick­ých tornád by nemě­ly pro­fučet ven­tilá­to­ry klima­ti­za­cí do ztra­ce­na. ​„Já vám to říkal,“ není argu­ment, není-li doložitel­ný. Nespoléhe­jte na paměť, práce s výs­tupy Threat Mod­el­ingů je nezbyt­ná k úspěchu vytyčené bezpečnos­t­ní strate­gie. Určitě také neza­pomíne­jte na zpět­nou vazbu od ostat­ních týmů a aktualizace. 

Zajištění nejlepšího možného zabezpečení sto­jí a padá s per­ma­nent­ní spoluprací mezi bezpečnos­t­ní­mi týmy a vývo­jáři. Nikdy není hoto­vo, nikdy není ​„pad­la“. Stále je nebyt­né aktu­al­i­zo­vat, zlepšo­vat, vyví­jet nové metodiky. Čer­ti a ​„hack­eři nikdy nespí! Bez vzá­jem­né mez­itý­mové empatie však bezpečného, ale zároveň efek­tivního vývo­je soft­waru pravděpodob­ně nikdy nedosáh­nete. I v dig­itál­ním věku je to zkrát­ka o mezilid­ských vztazích ve fir­mě a vzá­jem­ném pochopení. O bezpečné lásce, chcete-li.