Bezbednost na kraju naspram bezbednosti od početka: odluka koja definiše rizik isporuke

Dva tima. Isti cilj. Veoma različiti rezultati.

Tim A gradi rešenje izolovano i uključuje službenika za bezbednost tek kada je razvoj uglavnom završen, dok Tim B uvodi Bezbednost u razgovor u trenutku kada se rešenje još oblikuje, dok se definišu arhitektura, tokovi podataka i modeli pristupa.

Na površini izgleda da oba tima teže istom cilju, a to je isporuka funkcionalnog softvera koji će na kraju ispuniti bezbednosne zahteve, ali u praksi put koji biraju ima direktan i merljiv uticaj na trošak, rizik i rokove isporuke.

Kada bezbednost dolazi na kraju

Tim A obično pokazuje snažnu početnu brzinu jer se odluke donose bez ograničenja, arhitektura se definiše brzo, a funkcionalnosti se implementiraju bez potrebe da se uzme u obzir spoljna validacija; međutim, ta percipirana brzina je privremena, jer kada sistem prođe formalnu bezbednosnu proveru počinju da se pojavljuju problemi koji nisu površinski, već strukturni u samom načinu na koji je sistem projektovan.

Modeli autentikacije možda ne ispunjavaju tražene standarde, pristupi obradi podataka mogu uvoditi rizike usklađenosti, mehanizmi kontrole pristupa mogu biti nedovoljni, a u mnogim slučajevima to nisu izolovani nedostaci već problemi na nivou dizajna koji zahtevaju dorade kroz više komponenti sistema umesto jednostavnih ispravki.

U toj fazi se bezbednost često doživljava kao prepreka, ali u stvarnosti deluje kao korektivna sila koja identifikuje praznine uvedene ranije, kada su odluke donošene bez punog konteksta; posledica je predvidljiva: kašnjenja, veći troškovi, dupliran trud i rastuće trenje između razvojnih i bezbednosnih timova kako pritisak isporuke raste.

Kada bezbednost oblikuje dizajn

Tim B funkcioniše po fundamentalno drugačijem modelu time što integriše Bezbednost u fazu dizajna i obezbeđuje da se modelovanje pretnji, klasifikacija podataka, granice pristupa i pitanja usklađenosti rešavaju zajedno sa funkcionalnim zahtevima, a ne naknadno.

To ne smanjuje brzinu razvoja ni u jednom značajnom smislu, već menja samu prirodu razvoja, jer se odluke donose uz potpuno razumevanje ograničenja, kompromisi su eksplicitni umesto slučajni, a arhitektonske odluke su od početka usklađene i sa operativnim i sa bezbednosnim zahtevima.

Kao rezultat, isporuka postaje predvidljivija, dorade se značajno smanjuju, a sistem koji stiže u produkciju nije samo funkcionalan već i otporan, podložan reviziji i sposoban da radi u realnim uslovima bez uvođenja nepotrebnog organizacionog rizika.

Razlika je u zrelosti operativnog modela

Razlika između ova dva pristupa nije pitanje procesne preferencije, već zrelosti operativnog modela, gde Tim A tretira Bezbednost kao završnu kontrolnu tačku koja potvrđuje ono što je već izgrađeno, dok Tim B tretira Bezbednost kao partnera u dizajnu koji oblikuje ono što se gradi.

Samo jedan od tih modela efikasno se skalira kako sistemi rastu u složenosti i kako organizacije postaju sve zavisnije od pouzdanosti i integriteta svog softvera.

Ako vaša organizacija i dalje funkcioniše kao Tim A, pitanje nije da li će to uticati na isporuku, već kada.

Kontaktirajte Libertas Software Research da vidite kako možemo da vam pomognemo da pređete na model koji isporučuje bezbedno, predvidljivo i u meri.