Saugumas pabaigoje prieš saugumą nuo pradžių: sprendimas, kuris apibrėžia pristatymo riziką

Dvi komandos. Tas pats tikslas. Labai skirtingi rezultatai.

Komanda A kuria sprendimą izoliuotai ir įtraukia saugumo vadovą tik tada, kai kūrimas jau iš esmės baigtas, o Komanda B įtraukia Saugumą į pokalbį tuo metu, kai sprendimas dar tik formuojamas, kai apibrėžiama architektūra, duomenų srautai ir prieigos modeliai.

Iš pirmo žvilgsnio abi komandos siekia to paties tikslo – pristatyti funkcionalią programinę įrangą, kuri galiausiai atitiks saugumo reikalavimus, tačiau praktiškai jų pasirinktas kelias turi tiesioginį ir pamatuojamą poveikį kainai, rizikai ir pristatymo terminams.

Kai saugumas ateina tik pabaigoje

Komanda A paprastai rodo stiprų pradinį tempą, nes sprendimai priimami be apribojimų, architektūra apibrėžiama greitai, o funkcijos įgyvendinamos neatsižvelgiant į išorinį validavimą; tačiau šis suvokiamas greitis yra laikinas, nes vos sistemai patekus į formalų saugumo vertinimą pradeda ryškėti problemos, kurios nėra paviršinės, bet struktūrinės pačiame sistemos projektavimo būde.

Autentifikavimo modeliai gali neatitikti reikalaujamų standartų, duomenų tvarkymo metodai gali sukurti atitikties rizikų, prieigos kontrolės mechanizmai gali būti nepakankami, o daugeliu atvejų tai nėra pavieniai defektai, o projektavimo lygmens problemos, reikalaujančios perdarymo keliuose sistemos komponentuose, o ne paprastų pataisymų.

Šiame etape saugumas dažnai suvokiamas kaip kliūtis, tačiau iš tikrųjų jis veikia kaip koreguojanti jėga, identifikuojanti spragas, kurios atsirado anksčiau, kai sprendimai buvo priimti neturint viso konteksto; pasekmė nuspėjama: vėlavimai, didesnės sąnaudos, dubliuojamos pastangos ir auganti trintis tarp kūrimo ir saugumo komandų didėjant pristatymo spaudimui.

Kai saugumas formuoja projektavimą

Komanda B dirba pagal iš esmės kitokį modelį, integruodama Saugumą į projektavimo etapą ir užtikrindama, kad grėsmių modeliavimas, duomenų klasifikavimas, prieigos ribos ir atitikties klausimai būtų sprendžiami kartu su funkciniais reikalavimais, o ne po jų.

Tai nemažina kūrimo greičio jokia reikšminga prasme, bet keičia pačią kūrimo prigimtį, nes sprendimai priimami visiškai suprantant apribojimus, kompromisai yra aiškūs, o ne atsitiktiniai, o architektūriniai pasirinkimai nuo pat pradžių derinami tiek su veiklos, tiek su saugumo reikalavimais.

Dėl to pristatymas tampa labiau nuspėjamas, perdarymo žymiai sumažėja, o sistema, kuri pasiekia produkciją, yra ne tik funkcionali, bet ir atspari, audituojama bei pajėgi veikti realiomis sąlygomis neįvesdama nereikalingos organizacinės rizikos.

Skirtumas yra veiklos modelio brandume

Skirtumas tarp šių dviejų požiūrių nėra proceso preferencijos klausimas, bet veiklos modelio brandumo klausimas, kai Komanda A saugumą laiko galutiniu kontrolės tašku, patvirtinančiu tai, kas jau sukurta, o Komanda B saugumą laiko projektavimo partneriu, kuris formuoja tai, kas kuriama.

Tik vienas iš šių modelių efektyviai plečiasi sistemoms sudėtingėjant ir organizacijoms vis labiau priklausant nuo savo programinės įrangos patikimumo ir vientisumo.

Jei jūsų organizacija vis dar veikia kaip Komanda A, klausimas yra ne ar tai paveiks pristatymą, o kada.

Susisiekite su Libertas Software Research ir sužinokite, kaip galime padėti jums pereiti prie modelio, kuris pristato saugiai, nuspėjamai ir masteliu.