Drošība beigās pret drošību no paša sākuma: lēmums, kas nosaka piegādes risku

Divas komandas. Tas pats mērķis. Ļoti atšķirīgi rezultāti.

Komanda A veido risinājumu izolēti un iesaista drošības vadītāju tikai tad, kad izstrāde lielākoties jau ir pabeigta, savukārt Komanda B iesaista Drošību sarunā brīdī, kad risinājums vēl tikai tiek veidots, kamēr tiek noteikta arhitektūra, datu plūsmas un piekļuves modeļi.

Virspusēji abas komandas šķietami tiecas uz vienu un to pašu mērķi – piegādāt funkcionālu programmatūru, kas galu galā atbilst drošības prasībām, taču praksē ceļš, ko tās izvēlas, tieši un izmērāmi ietekmē izmaksas, risku un piegādes termiņus.

Kad drošība tiek iesaistīta tikai beigās

Komanda A parasti demonstrē lielu sākotnējo ātrumu, jo lēmumi tiek pieņemti bez ierobežojumiem, arhitektūra tiek noteikta ātri un funkcionalitāte tiek ieviesta bez nepieciešamības ņemt vērā ārēju validāciju; tomēr šis šķietamais ātrums ir īslaicīgs, jo, tiklīdz sistēma tiek pakļauta formālai drošības pārbaudei, sāk parādīties problēmas, kas nav virspusējas, bet strukturālas pašā sistēmas izstrādes veidā.

Autentifikācijas modeļi var neatbilst nepieciešamajiem standartiem, datu apstrādes pieejas var radīt atbilstības riskus, piekļuves kontroles mehānismi var būt nepietiekami, un daudzos gadījumos tie nav izolēti defekti, bet dizaina problēmas, kurām nepieciešama pārstrāde vairākās sistēmas komponentēs, nevis vienkārši labojumi.

Šajā posmā drošība bieži tiek uztverta kā šķērslis, taču patiesībā tā darbojas kā koriģējošs spēks, identificējot nepilnības, kas tika ieviestas agrāk, kad lēmumi tika pieņemti bez pilna konteksta; sekas ir paredzamas: kavēšanās, lielākas izmaksas, dubultots darbs un pieaugoša berze starp izstrādes un drošības komandām, palielinoties piegādes spiedienam.

Kad drošība veido dizainu

Komanda B darbojas pēc būtiski atšķirīga modeļa, integrējot Drošību projektēšanas fāzē un nodrošinot, ka draudu modelēšana, datu klasifikācija, piekļuves robežas un atbilstības apsvērumi tiek risināti kopā ar funkcionālajām prasībām, nevis pēc tam.

Tas nesamazina izstrādes ātrumu nevienā būtiskā nozīmē, bet maina pašu izstrādes būtību, jo lēmumi tiek pieņemti pilnīgi saprotot ierobežojumus, kompromisi ir skaidri, nevis nejauši, un arhitektūras izvēles jau no paša sākuma ir saskaņotas gan ar operatīvajām, gan ar drošības prasībām.

Tā rezultātā piegāde kļūst prognozējamāka, pārstrāde ievērojami samazinās, un sistēma, kas nonāk produkcijā, ir ne tikai funkcionāla, bet arī noturīga, auditējama un spējīga darboties reālos apstākļos, neieviešot nevajadzīgu organizatorisku risku.

Atšķirība ir operacionālā modeļa briedumā

Atšķirība starp abām pieejām nav procesa izvēles jautājums, bet operacionālā modeļa brieduma jautājums, kur Komanda A uztver Drošību kā galīgo kontrolpunktu, kas validē jau uzbūvēto, kamēr Komanda B uztver Drošību kā dizaina partneri, kas veido to, kas tiek būvēts.

Tikai viens no šiem modeļiem efektīvi mērogojas, sistēmām kļūstot sarežģītākām un organizācijām kļūstot arvien atkarīgākām no savas programmatūras uzticamības un integritātes.

Ja jūsu organizācija joprojām darbojas kā Komanda A, jautājums nav vai tas ietekmēs piegādi, bet kad.

Sazinieties ar Libertas Software Research, lai uzzinātu, kā mēs varam palīdzēt jums pāriet uz modeli, kas piegādā droši, prognozējami un mērogā.