Turvalisus lõpus versus turvalisus algusest peale: otsus, mis määrab tarneriski

Kaks meeskonda. Sama eesmärk. Väga erinevad tulemused.

Meeskond A ehitab lahendust isoleeritult ja kaasab turbejuhi alles siis, kui arendus on suures osas lõpetatud, samal ajal kui Meeskond B toob Turvalisuse vestlusse hetkel, mil lahendus alles kujuneb ning arhitektuur, andmevood ja juurdepääsumudelid määratletakse.

Pinnapealselt näivad mõlemad meeskonnad taotlevat sama eesmärki – tarnida toimiv tarkvara, mis lõpuks vastab turvanõuetele –, kuid praktikas on valitud teel otsene ja mõõdetav mõju kulule, riskile ja tarnetähtaegadele.

Kui turvalisus tuleb mängu alles lõpus

Meeskond A näitab tavaliselt tugevat algset kiirust, sest otsuseid tehakse ilma piiranguteta, arhitektuur määratakse kiiresti ja funktsioone rakendatakse ilma välise valideerimise vajadust arvestamata; see tajutud kiirus on siiski ajutine, sest niipea kui süsteem puutub kokku ametliku turbeülevaatusega, hakkavad ilmnema probleemid, mis ei ole pealiskaudsed, vaid struktuursed selles, kuidas süsteem on kujundatud.

Autentimismudelid ei pruugi vastata nõutud standarditele, andmetöötluse lähenemised võivad tuua kaasa vastavusriske, juurdepääsukontrolli mehhanismid võivad olla ebapiisavad ning paljudel juhtudel ei ole tegemist üksikute vigade, vaid disainitasandi probleemidega, mis nõuavad ümbertööd mitmes süsteemi komponendis, mitte lihtsaid parandusi.

Selles etapis tajutakse turvalisust sageli takistusena, kuid tegelikult toimib see korrigeeriva jõuna, tuvastades lüngad, mis viidi sisse varem, kui otsuseid tehti ilma täieliku kontekstita; tagajärg on etteaimatav: viivitused, suuremad kulud, dubleeritud töö ja kasvav hõõrdumine arendus- ja turvemeeskondade vahel, kui tarnesurve suureneb.

Kui turvalisus kujundab disaini

Meeskond B töötab põhimõtteliselt teistsuguse mudeli järgi, integreerides Turvalisuse disainifaasi ning tagades, et ohumudeldamine, andmete klassifitseerimine, juurdepääsupiirid ja vastavuskaalutlused käsitletakse koos funktsionaalsete nõuetega, mitte tagantjärele.

See ei vähenda arenduse kiirust üheski olulises mõttes, vaid muudab hoopis arenduse olemust ennast, sest otsuseid tehakse piirangutest täielikult aru saades, kompromissid on selgesõnalised, mitte juhuslikud, ning arhitektuurivalikud joondatakse algusest peale nii operatiivsete kui ka turvanõuetega.

Selle tulemusel muutub tarne prognoositavamaks, ümbertöö väheneb märkimisväärselt ja süsteem, mis jõuab tootmisse, ei ole mitte ainult toimiv, vaid ka vastupidav, auditeeritav ja suuteline toimima reaalsetes tingimustes ilma tarbetut organisatsioonilist riski tekitamata.

Erinevus seisneb tegevusmudeli küpsuses

Nende kahe lähenemise erinevus ei seisne protsessieelistuses, vaid tegevusmudeli küpsuses, kus Meeskond A käsitleb Turvalisust viimase kontrollpunktina, mis valideerib selle, mis on juba ehitatud, samal ajal kui Meeskond B käsitleb Turvalisust disainipartnerina, kes kujundab seda, mida ehitatakse.

Ainult üks neist mudelitest skaleerub tõhusalt, kui süsteemid muutuvad keerukamaks ja organisatsioonid sõltuvad üha enam oma tarkvara töökindlusest ja terviklikkusest.

Kui teie organisatsioon töötab endiselt nagu Meeskond A, ei ole küsimus selles, kas see mõjutab tarnet, vaid millal.

Võtke ühendust Libertas Software Researchiga, et näha, kuidas saame aidata teil liikuda mudeli poole, mis tarnib turvaliselt, prognoositavalt ja mastaabis.