Xlera8

Minimális életképes megfelelőség: mire kell törődnie és miért

Az informatikai biztonsági térben mindennel törődnünk kell. Bármilyen apró probléma, a távoli kódvégrehajtás eszközévé válhat, vagy legalábbis a fenyegetés szereplői számára kiindulópontot jelenthet a földből élni, és a saját eszközeinket ellenünk fordítani. Nem meglepő, hogy az IT biztonsági személyzet kiégéssel és stresszel szembesül. Alapján az Enterprise Stratégiai Csoport kutatása és az ISSA, az IT-biztonsági szakemberek körülbelül fele úgy gondolja, hogy a következő 12 hónapban elhagyja jelenlegi munkahelyét.

A biztonsági csapatok szakmailag felelősek – most pedig az információbiztonsági vezetőkért (CISO-k), személyesen felelős – szervezeteik biztonsága érdekében. Az IT és a technológia más területein azonban teljesen más a gondolkodásmód. Mark Zuckerberg mantrájából: „gyorsan mozogni és megtörni a dolgokatEric Ries-ig Lean indítás és a minimális életképes termék (MVP) modellje, ezeken a területeken az a gondolat, hogy gyorsan haladjunk, de egyúttal csak annyit is szállítsunk, hogy a szervezet előre tudjon lépni és fejlődni tudjon.

Most az IT-biztonsági csapatok nem tudják elfogadni ezt a modellt. Túl sok szabályozást kell figyelembe venni. De mit tanulhatunk a minimális életképes megfelelés (MVC) körüli mentális gyakorlatból, és hogyan használhatjuk fel ezt az információt a megközelítésünkben?

Mit tartalmazna az MVC?

Az MVC magában foglalja a hatékony biztonság érdekében szükséges dolgok fedezését. Ennek eléréséhez meg kell értenie, hogy mi van a helyén, és mi a legfontosabb, hogy biztonságban legyen, és milyen szabályokat vagy előírásokat kell bizonyítania, hogy megfelel.

A vagyonkezeléshez ideális esetben ismernie kell az összes telepített eszközt. Ilyen szintű felügyelet nélkül hogyan mondhatja magát biztonságosnak? Az MVC-megközelítéshez 100%-os betekintésre van szüksége a birtokában lévő dolgokba?

A valóságban az eszközkezelési projektek, például a konfigurációkezelési adatbázisok (CMDB) célja, hogy biztosítsák teljes áttekintést az informatikai eszközökről, de soha nem 100%-ban pontosak. A múltban az eszközök pontossága 70-80% körül mozgott, és még a mai legjobb telepítések sem képesek teljes láthatóságot elérni és ott tartani. Tehát költsük erre a területre az MVC költségvetésünket? Igen, de nem egészen úgy, ahogyan azt hagyományosan gondolnánk.

A CISO egyik helyettese azt mondta, hogy megérti a teljes lefedettség eszményét, de ez nem lehetséges; ehelyett törődik a szervezet kritikus infrastruktúrájának teljes és folyamatos láthatóságával – a teljes eszközállomány mintegy 2.5%-ával –, miközben a többi munkaterhelést a lehető leggyakrabban nyomon követték. Tehát bár a láthatóság továbbra is elengedhetetlen eleme az informatikai biztonsági programoknak, először a legnagyobb kockázatot jelentő eszközök védelmére kell törekedni. Ez azonban egy rövid távú cél, mivel csak egyetlen biztonsági résnyire van attól, hogy egy alacsony kockázatú eszköz magas kockázatúvá váljon. A folyamat során ne keverje össze a biztonsággal való megfelelést – ezek nem ugyanazok. Egy megfelelő vállalkozás nem biztos, hogy biztonságos.

Szabályozási tervezés

Az MVC részeként el kell gondolkodnunk az előírásokon és azok betartásán. A biztonsági csapatok számára az a kihívás, hogy hogyan gondolkodjanak előre ezekről a szabályokról. A tipikus megközelítés az, hogy a jogszabályokat bevezetjük, majd megnézzük, hogy az alkalmazásainkra hol vonatkozik, majd szükség szerint módosítjuk a rendszereket. Ez azonban egy nagyon „stop-start” megközelítés lehet, amely változtatással – és ezért költséggel – jár minden alkalommal, amikor új szabályozást vezetnek be, vagy jelentős változás történik.

Hogyan könnyíthetjük meg ezt a folyamatot csapataink számára? Ahelyett, hogy az egyes szabályozásokat külön-külön néznénk meg, megnézhetjük-e, hogy mi a közös az alkalmazandó szabályozásban, és ezt felhasználhatjuk-e az összes betartásához szükséges munka csökkentésére? Ahelyett, hogy a csapatot hatalmas gyakorlatokon kellene végrehajtani a rendszerek megfelelővé tétele érdekében, mit vonhatunk ki a hatókörből, vagy mit használhatunk szolgáltatásként az infrastruktúra biztonságos biztosítására? Hasonlóképpen, használhatunk-e olyan általános bevált módszereket, mint például a felhőalapú vezérlők a problémák egész csoportjának eltávolítására, ahelyett, hogy az egyes problémákat külön-külön vizsgálnánk meg?

Ennek a megközelítésnek a középpontjában a biztonsággal kapcsolatos általános költségeket kell csökkentenünk, és arra kell koncentrálnunk, hogy mi jelenti a legnagyobb kockázatot vállalkozásaink számára. Ahelyett, hogy konkrét technológiákra gondolnánk, ezeket a problémákat folyamatként és emberkérdésként vizsgálhatjuk, mert a szabályozások mindig fejlődnek és változnak a piac előrehaladtával. Ez a gondolkodásmód megkönnyíti a biztonsági tervezést, mert nem ragad meg néhány olyan részletben, amelyek megsínylhetik csapatainkat, amikor a folyamatokat a CVE-k és a fenyegetettségi adatok figyelembevételére építettük fel, nem pedig a gyakorlati kockázati szempontok alapján, ami valóban probléma.

Az az ötlet, hogy a piaci igények kielégítéséhez szükséges minimumot megtegyük, vagy szabályokat fogadjunk el, névértéken vonzó lehet. De az MVP gondolkodásmódja nem csak arról szól, hogy eljutunk egy adott szintre, majd ott letelepedünk. Ehelyett arról van szó, hogy elérjük ezt a minimális szabványt, majd a lehető leggyorsabban iteráljuk a helyzet további javítása érdekében. A biztonsági csapatok számára a folyamatos fejlesztés és a kockázatcsökkentési módszerek keresése a hagyományos IT-biztonsági modell hasznos alternatívája lehet. Ha arra összpontosít, hogy mely fejlesztéseknek lenne a legnagyobb kockázati hatása a legrövidebb időn belül, növelheti hatékonyságát és általánosságban csökkentheti a kockázatot.

Beszélj velünk

Szia! Miben segíthetek?