Technológia

Miért az agilitás a biztonságos szoftver kulcsa?

A szoftver-beszállítóknak a kezdetektől fogva kell kialakítaniuk és fenntartaniuk a biztonságot, nem pedig arra kell várniuk, hogy a hiba kijavítása megtörténjen. Minél több szoftver szabadul fel anélkül, hogy megbizonyosodna róla, annál nagyobb az esély arra, hogy a biztonsági kockázatok teljes körű szabálysértésekké váljanak. Ezek a láthatatlan kockázatok olyan biztonsági adósságok, amelyeket minden kiadás előtt fel kell fedezni és kezelni kell.

A „Shift left” biztonság elősegíti a biztonság megvalósítását a szoftverfejlesztés életciklusának kezdetétől fogva. Attól a pillanattól kezdve, hogy egyértelmű termékértéket határoztak meg, a termékmenedzsereknek már jóval a szoftver tesztelése előtt mérlegelniük kell a biztonságot. A fenyegetés modellezése kiváló módszer erre a szoftver architektúra szakaszában.

A fenyegetés modellezése olyan, mint egy felderítő munka, amelyet egy bankrabló végez, mielőtt megpróbál betörni egy boltozatba, ellopni a pénzt és megúszni anélkül, hogy elkapnák. A szoftveres megoldások tervezésénél fontos felmérni a szoftver hasonló belépési pontjait.

– Milyen anyagokkal rögzítették a bank ablakait? „milyen nem funkcionális követelményeket valósítanak meg a webalkalmazás biztonsági architektúrájában úgy, hogy helyszíni szkriptek támadások nem történhetnek? Amit nem hajtottak végre, az a biztonsági adósság.

Mi van, ha a bank új szárnyat ad hozzá az ügyfelek támogatásához? Mi van, ha a szoftver új szolgáltatásokat ad hozzá, amelyeket az új mikroszolgáltatások támogatnak? A biztonsági adósság potenciálisan növekszik minden egyes alkalommal, amikor változás történik a terméken vagy annak infrastruktúráján.

A közelmúltban bekövetkezett nagyobb kibertámadások rávilágítottak a vállalkozások szükségességére a nulla bizalom biztonsági modell termékeikkel és szolgáltatásaikkal. Ha a bank alapértelmezés szerint nem bízhat meg látogatóiban vagy akár személyzetében – erős azonosítási és hitelesítési eljárások beépítésével a biztonságos területekhez, például a páncélszekrényhez való hozzáféréshez -, akkor a szoftvereknek nem szabad vakon bízniuk saját belső adatfolyamában.

Folyamatos biztonsági ellenőrzés

Az informatikai szakemberek azt várják, hogy a webes és mobilalkalmazásokat naprakészen tartsák a legjobb funkciókkal. Eredményeket várnak a biztonság feláldozása nélkül is. Az adatok megsértése, a jogszabályok betartása és a jó hírnév kockázata létrehozta az új normát. A vállalkozásoknak komolyan kell venniük a biztonsági fenyegetéseket, vagy el kell veszíteniük a fogyasztók, az üzleti vállalkozások és a szabályozók bizalmát.

Bizonyos esetekben a megfelelőségi előírások nem bízzák a bizalmat a választásra – a Fizetési kártya iparági adatbiztonsági szabvány megköveteli a fizetési kártyahálózatok megfelelőségi ellenőrzését a jóváhagyott letapogató szállító által végzett biztonsági rés-vizsgálatok révén.

A. Fokozott elfogadásával mozgékony szoftver-szállítási modellek támogatják a növekményes változásokat, kérik-e a vállalkozások penetrációs tesztek kéthetente-hetente előforduló kiadások esetén? A hagyományos tollvizsgálat mély biztonsági teszt lefedettséget biztosít az automatizált módszerek mellett statikus alkalmazás biztonsági tesztelése és dinamikus alkalmazásbiztonsági tesztelés, de rövidebb kioldási ciklusok esetén folyamatos biztonságra van szükség.

Legyen biztonságban, hogy releváns maradjon

Az informatikai szoftverek szállításáért felelős szoftver-szállítási és termékmenedzserek mind a termék relevanciáját, mind a termék biztonságát megtarthatják azzal, hogy integrálják a fenyegetésmodellezést, az alkalmazásbiztonsági tesztelést és az egyéb megfelelőségi garanciákat meglévő szállítási folyamatukba.

Anélkül, hogy ezeket a lépéseket megtennénk a kibocsátási ciklus alatt, a folyamatosan növekvő értékpapír-adósság kockázata továbbra is valós marad, és mire – csak azért, hogy releváns maradjon?

Miután kibertámadás következik be, különösen olyan, amely könnyen megelőzhető lett volna, elmondhatják-e az informatikai fejlesztők, hogy érdemes volt-e nem foglalkozni a kockázattal? Ha a kioldási ciklusok biztosításával ellapítják a biztonsági kockázati görbét, akkor soha nem kell kérdezniük.