Biztonság a végén kontra biztonság a kezdetektől: a döntés, amely meghatározza a szállítási kockázatot

Két csapat. Ugyanaz a cél. Nagyon eltérő eredmények.

Az A csapat elszigetelten építi a megoldást, és csak akkor vonja be a biztonsági vezetőt, amikor a fejlesztés már nagyrészt befejeződött, míg a B csapat már abban a szakaszban bevonja a Biztonságot a beszélgetésbe, amikor a megoldás még formálódik, és az architektúra, az adatfolyamok valamint a hozzáférési modellek meghatározása zajlik.

Felszínesen nézve mindkét csapat ugyanazt a célt követi, vagyis működő szoftvert szállítani, amely végül megfelel a biztonsági követelményeknek, a gyakorlatban azonban az általuk választott út közvetlen és mérhető hatással van a költségre, a kockázatra és a szállítási ütemezésre.

Amikor a biztonság csak a végén érkezik

Az A csapat jellemzően erős korai tempót mutat, mert a döntések korlátozások nélkül születnek, az architektúra gyorsan meghatározásra kerül, és a funkciókat úgy vezetik be, hogy nincs szükség külső validáció figyelembevételére; ez az érzékelt gyorsaság azonban átmeneti, mert amikor a rendszert formális biztonsági felülvizsgálatnak vetik alá, olyan alapvető problémák kezdenek felszínre kerülni, amelyek nem felszínesek, hanem magában a rendszer tervezési módjában gyökereznek.

Előfordulhat, hogy a hitelesítési modellek nem felelnek meg az elvárt szabványoknak, az adatkezelési megközelítések megfelelőségi kockázatokat vezetnek be, a hozzáférés-vezérlési mechanizmusok elégtelenek, és sok esetben nem elszigetelt hibákról van szó, hanem tervezési problémákról, amelyek egyszerű javítások helyett a rendszer több komponensén átívelő utómunkát igényelnek.

Ebben a szakaszban a biztonságot gyakran akadályként érzékelik, valójában azonban korrekciós erőként működik, azonosítva azokat a hiányosságokat, amelyek korábban keletkeztek, amikor a döntéseket teljes kontextus nélkül hozták meg; a következmény kiszámítható: késedelmek, magasabb költségek, párhuzamos munka és növekvő súrlódás a fejlesztési és a biztonsági csapatok között, ahogy a szállítási nyomás fokozódik.

Amikor a biztonság formálja a tervezést

A B csapat alapvetően más modell szerint működik azzal, hogy a Biztonságot a tervezési fázisba integrálja, biztosítva, hogy a fenyegetésmodellezés, az adatosztályozás, a hozzáférési határok és a megfelelőségi szempontok a funkcionális követelményekkel együtt kerüljenek kezelésre, ne utólag.

Ez nem csökkenti a fejlesztési sebességet semmilyen lényeges értelemben, hanem magának a fejlesztésnek a természetét változtatja meg, mert a döntések a korlátok teljes megértésével születnek, a kompromisszumok explicitek a véletlenszerűség helyett, és az architekturális döntések már a kezdetektől összehangoltak mind az üzemi, mind a biztonsági követelményekkel.

Ennek eredményeként a szállítás kiszámíthatóbbá válik, az utómunka jelentősen csökken, és a produkcióba kerülő rendszer nemcsak működőképes, hanem ellenálló, auditálható és képes valós körülmények között működni anélkül, hogy szükségtelen szervezeti kockázatot vezetne be.

A különbség az operációs modell érettsége

A két megközelítés közötti különbség nem folyamati preferencia kérdése, hanem az operációs modell érettségéé, ahol az A csapat a Biztonságot egy végső ellenőrzési pontként kezeli, amely azt validálja, ami már megépült, míg a B csapat a Biztonságot tervezési partnerként kezeli, amely alakítja azt, ami épül.

Csak az egyik ilyen modell skálázódik hatékonyan, ahogy a rendszerek összetettebbé válnak, és a szervezetek egyre inkább szoftverük megbízhatóságától és integritásától függnek.

Ha a szervezete még mindig úgy működik, mint az A csapat, a kérdés nem az, hogy ez hatással lesz-e a szállításra, hanem az, hogy mikor.

Lépjen kapcsolatba a Libertas Software Research-csel, hogy megtudja, hogyan segíthetünk olyan modellre váltani, amely biztonságosan, kiszámíthatóan és skálázhatóan szállít.