Sigurnost na kraju nasuprot sigurnosti od početka: odluka koja definira rizik isporuke

Dva tima. Isti cilj. Vrlo različiti ishodi.

Tim A gradi rješenje u izolaciji i uključuje službenika za sigurnost tek kada je razvoj uglavnom završen, dok Tim B uvodi Sigurnost u razgovor u trenutku kada se rješenje još oblikuje, dok se definiraju arhitektura, tokovi podataka i modeli pristupa.

Na površini se može činiti da oba tima slijede isti cilj, odnosno isporučiti funkcionalan softver koji će na kraju zadovoljiti sigurnosne zahtjeve, ali u praksi put kojim idu ima izravan i mjerljiv utjecaj na trošak, rizik i rokove isporuke.

Kada sigurnost dolazi na kraju

Tim A obično pokazuje snažnu početnu brzinu jer se odluke donose bez ograničenja, arhitektura se definira brzo, a značajke se implementiraju bez potrebe za razmatranjem vanjske validacije; međutim, ta percipirana brzina je privremena jer se, kada je sustav izložen formalnom sigurnosnom pregledu, počinju pojavljivati temeljni problemi koji nisu površinski, nego strukturni u načinu na koji je sustav dizajniran.

Modeli autentikacije možda ne zadovoljavaju tražene standarde, pristupi obradi podataka mogu unijeti rizike usklađenosti, mehanizmi kontrole pristupa mogu biti nedostatni, a u mnogim slučajevima to nisu izolirani nedostaci nego problemi na razini dizajna koji zahtijevaju doradu kroz više komponenti sustava umjesto jednostavnih ispravaka.

U toj fazi sigurnost se često doživljava kao prepreka, ali u stvarnosti djeluje kao korektivna sila koja identificira praznine nastale ranije, kada su odluke donesene bez potpunog konteksta; posljedica je predvidljiva: kašnjenja, povećani troškovi, duplicirani napor i rastuće trenje između razvojnih i sigurnosnih timova kako pritisak isporuke raste.

Kada sigurnost oblikuje dizajn

Tim B djeluje prema temeljno drukčijem modelu tako što integrira Sigurnost u fazu dizajna i osigurava da se modeliranje prijetnji, klasifikacija podataka, granice pristupa i pitanja usklađenosti rješavaju zajedno s funkcionalnim zahtjevima, a ne naknadno.

To ne smanjuje brzinu razvoja u ikakvom značajnom smislu, nego mijenja samu prirodu razvoja, jer se odluke donose uz potpuno razumijevanje ograničenja, kompromisi su eksplicitni umjesto slučajni, a arhitekturni izbori od početka se usklađuju i s operativnim i sa sigurnosnim zahtjevima.

Kao rezultat, isporuka postaje predvidljivija, dorada se znatno smanjuje, a sustav koji dolazi u produkciju nije samo funkcionalan nego i otporan, podložan reviziji i sposoban raditi u stvarnim uvjetima bez uvođenja nepotrebnog organizacijskog rizika.

Razlika je u zrelosti operativnog modela

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

Samo jedan od tih modela učinkovito se skalira kako sustavi postaju složeniji i kako organizacije postaju ovisnije o pouzdanosti i integritetu svojeg softvera.

Ako vaša organizacija još uvijek radi kao Tim A, pitanje nije hoće li to utjecati na isporuku, nego kada.

Javite se Libertas Software Researchu kako biste vidjeli kako vam možemo pomoći prijeći na model koji isporučuje sigurno, predvidljivo i u mjerilu.