KEDVES CISO-K! NE BABUSGASSUNK MINDEN FOLYAMATOT!

A biztonsági hiányosságok felfedezésének legkézenfekvőbbnek tűnő, de egyben a legkevésbé hatékony és „érett” módja az, amit én úgy hívok, hogy „minden folyamat babusgatása”. Ez az ellenőrzés „első szintjén” történik, ami azt jelenti, hogy a biztonság minden (informatikai) folyamaton belül közvetlenül reprezentálva van. Ez olyan, mint a következő történet egyik szereplője.

Egy kis faluban csak akkor volt víz, amikor esett az eső, ezért felbéreltek két fickót, hogy vizet hozzanak a faluba. Az első fickó vett két vödröt, és elkezdett naponta többször oda-vissza gyalogolni a folyótól a faluba, hogy vizet hozzon. Ez a folyamat minden nap megismétlődött, a fickó számos utat tett meg a faluból a folyóhoz és vissza.

A második kolléga több hónapra eltűnt, majd azzal a tervvel tért vissza, hogy csővezetéket épít a folyótól a faluba. Elkezdték követni a tervükben felvázolt lépéseket, és a következő évben felépítették a csővezetéket. Miután a csővezeték elkészült, a faluban a hét minden napján, a nap 24 órájában volt víz! Furcsa módon a második fickó egyetlen vödröt sem vitt el a folyótól a faluba.

Vegyük ilyen szemmel példának az informatikai változáskezelési folyamatot. Minden változtatást, a kisebbektől a nagyobbakig, az illetékes biztonsági személyzet által kötelezően jóváhagyandó csatornán keresztül kell vezetni. Ez nagyon körültekintő megoldás, de számos hátulütője van.

Az első és legnyilvánvalóbb, hogy minden változtatási kérelem válogatás nélküli feldolgozása a biztonsági osztály értékes erőforrásait veszi igénybe. Ilyenkor megpróbálhatunk gyakorlatiasabbak lenni, és csak a jelentős változtatások biztonsági felülvizsgálatát írhatjuk elő. Ez működhet, de ebben az esetben, akárcsak az összes módosítás felülvizsgálatakor, a biztonsági felülvizsgálat szűk keresztmetszet lesz a folyamatban. Ez pedig a szándékunk ellenkezője. Ráadásul így rossz üzenetet küldünk a „társosztályoknak”.

A biztonsági csapat által kikényszerített extra, operatív szintű ellenőrzés szigorú ellenőrzésnek tűnhet, de ehelyett inkább arról szól, hogy mi, a „security-sek” képtelenek vagyunk megfelelő irányítási struktúrát kialakítani! Ez a megközelítés az üzemeltetés és a többi IT-csapat részéről is erős függőséget fog teremteni a biztonsági ellenőrzések tekintetében. Ez adott esetben nem szándékolt szereptévesztésbe tolhatja a biztonsági kontrollszervezetet.

Egy idő után a biztonsági ellenőrzés a késedelmek ürügyévé válhat, és a mérnökök ahelyett, hogy elolvasnák(!), megértenék és alkalmaznák a biztonsági szabályokat, a biztonsági csapathoz fordulnak, hogy értelmezzék a rendszerarchitektúra vagy a megoldás minden egyes részletét, és eseti alapon hozzanak meg go/no-go döntéseket. E döntések túlnyomó többségét, megfelelően előkészítve a projektben egyébként dolgozó szakértők, vezetők is meghozhatják!

Az biztos, hogy ha a szabályzatok nincsenek jól elkészítve, nem egyértelműek vagy elavultak, akkor a fenti lehet az egyetlen módja annak, hogy a dolgokat ellenőrzés alatt tartsuk. Ez azonban ahhoz a végzetes pillanathoz vezet, amikor a biztonsági vezető elengedi a dolgot, és lemond a történések validálásáról; ezért ez a „megoldás” csak átmeneti lehet!

Minden folyamat babusgatása túlságosan úgy hangzik, mintha vödröket cipelnél. Nem inkább a csővezeték építésével kellene foglalkoznod?