Varnost na koncu proti varnosti od začetka: odločitev, ki določa tveganje dostave

Dve ekipi. Isti cilj. Zelo različni rezultati.

Ekipa A gradi rešitev v izolaciji in varnostnega vodjo vključi šele, ko je razvoj v veliki meri zaključen, medtem ko Ekipa B vključi Varnost v pogovor v trenutku, ko se rešitev še oblikuje ter se določajo arhitektura, podatkovni tokovi in modeli dostopa.

Na prvi pogled se zdi, da obe ekipi sledita istemu cilju, in sicer dostaviti funkcionalno programsko opremo, ki bo na koncu izpolnila varnostne zahteve, vendar ima v praksi pot, ki jo izbereta, neposreden in merljiv vpliv na stroške, tveganje in čas dostave.

Ko varnost pride na koncu

Ekipa A običajno pokaže močno začetno hitrost, ker se odločitve sprejemajo brez omejitev, arhitektura se definira hitro, funkcionalnosti pa se uvajajo brez potrebe po upoštevanju zunanje validacije; vendar je ta zaznana hitrost začasna, ker se, ko je sistem izpostavljen formalnemu varnostnemu pregledu, začnejo kazati osnovne težave, ki niso površinske, temveč strukturne v samem načinu zasnove sistema.

Modeli avtentikacije morda ne izpolnjujejo zahtevanih standardov, pristopi k obdelavi podatkov lahko uvajajo tveganja skladnosti, mehanizmi nadzora dostopa so lahko nezadostni, in v mnogih primerih ne gre za izolirane napake, temveč za težave na ravni zasnove, ki zahtevajo dodatno delo v več komponentah sistema namesto preprostih popravkov.

V tej fazi je varnost pogosto dojeta kot ovira, vendar v resnici deluje kot korektivna sila, ki prepoznava vrzeli, uvedene prej, ko so bile odločitve sprejete brez popolnega konteksta; posledica je predvidljiva: zamude, višji stroški, podvojeno delo in naraščajoča trenja med ekipami za razvoj in varnost, ko pritisk na dostavo narašča.

Ko varnost oblikuje zasnovo

Ekipa B deluje po bistveno drugačnem modelu, saj Varnost vključi v fazo zasnove in poskrbi, da se modeliranje groženj, razvrščanje podatkov, meje dostopa in vidiki skladnosti obravnavajo skupaj s funkcionalnimi zahtevami namesto naknadno.

To ne zmanjšuje hitrosti razvoja v kakršnemkoli pomembnem smislu, temveč spreminja samo naravo razvoja, saj se odločitve sprejemajo s popolnim razumevanjem omejitev, kompromisi so izrecni namesto naključni, arhitekturne odločitve pa so že od začetka usklajene tako z operativnimi kot varnostnimi zahtevami.

Posledično postane dostava bolj predvidljiva, dodatno delo se znatno zmanjša, sistem, ki pride v produkcijo, pa ni le funkcionalen, temveč tudi odporen, revizijsko sledljiv in sposoben delovati v realnih pogojih brez uvajanja nepotrebnega organizacijskega tveganja.

Razlika je v zrelosti operativnega modela

Razlika med obema pristopoma ni vprašanje procesnih preferenc, ampak zrelosti operativnega modela, v katerem Ekipa A obravnava Varnost kot končno kontrolno točko, ki potrjuje tisto, kar je že bilo zgrajeno, medtem ko Ekipa B obravnava Varnost kot partnerja pri zasnovi, ki oblikuje to, kar se gradi.

Le eden od teh modelov se učinkovito prilagaja, ko sistemi rastejo v kompleksnosti in ko organizacije postajajo vse bolj odvisne od zanesljivosti in integritete svoje programske opreme.

Če vaša organizacija še vedno deluje kot Ekipa A, vprašanje ni ali bo to vplivalo na dostavo, ampak kdaj.

Obrnite se na Libertas Software Research in preverite, kako vam lahko pomagamo preiti na model, ki dostavlja varno, predvidljivo in v merilu.