DRP és BCP. Katasztrófa elhárítás és üzletmenet folytonosság. Sokszor használják együtt, néha egymás helyett ezeket a kifejezéseket. Helytelenül. Mi a különbség közöttük? Tényleg mindegyik az IT hatáskörébe tartozik?
Az informatikai biztonság mára nem csak külön szakma lett, de maga is szakágakra bomlott. Ennek egyik fő oka, hogy igen széles tudáskört foglal magában
Külön probléma, hogy sokszor olyan területekkel is "kénytelen" foglalkozni amely talán inkább tartozik az üzlethez, a működéshez mint az informatikai biztonság tárgykörébe.
Ilyen határterület az üzletmenet folytonosság tervezés (BCP) amely sokszor az informatikai biztonsági projektek scope-jának része, vagy ilyen jellegű igényből indul ezen feladat elvégzése. De hol a határ?
BCP, DRP: a különbség
Maga a feladat sem teljesen egyértelmű. Nem egy ajánlati felhívásban vagy tender anyagban olvashattunk ajánlatkérést BCP készítésre és persze a második mondatból kiderült, hogy katasztrófa elhárítási tervről (DRP) van szó. Pedig különbség óriási!
A DRP (többnyire informatikai) erőforrások visszaállítására vonatkozó tervezés (kissé egyszerűsítve).
A BCP nem az informatikából indul, hanem az üzleti folyamat bármilyen (!) okból való kiesése, sérülése esetére dolgoz ki alternatív eljárást a probléma elhárításának idejére. Mit jelent ez?
A BCP nem informatikai probléma
A következtetés igen egyszerű: a BCP elsősorban nem informatikai probléma. A megoldást sem informatikai biztonsági szakembernek kell megtalálnia.
Persze az igazság az, hogy az üzletmenet folytonosság tervezés jól illeszthető az IT biztonságszervezés feladataihoz mivel tanácsadói szinten sok hasonlóság fedezhető fel az egyes elvégzendő lépésekben. Mit tegyen az informatika, ha BCP tervezéssel bízzák meg?
Mit ne tegyen a CIO!
Hogyan járjon el az informatikai vezető, ha megkapja főnökétől (vagy a board-tól) a feladatot: gondoskodj az informatikai biztonságról és ne legyen kiesés az üzletmenetben?
Anélkül, hogy végigmennék az IT biztonságszervezés folyamatán inkább arról írnék, hogy mit ne tegyen:
- Ne kezdje el a biztonsági rések szigetszerű tömködését,
- ne rohanjon vírusvédelemért, vagy új tűzfalért a bevált szállítóhoz.
- Ne akarjon azonnali eredményeket produkálni,
Inkább gondolkozzon rendszer szinten, közelítsen a problémához felülről lefelé.
Biztos lehet abban, hogy ha csak egyes veszélyforrásokra koncentrál, ki fog hagyni tíz másikat. És innen fogják eredményes támadások érni.
A biztonság elsősorban szervezési és nem technikai kérdés. Közelítsen hát rendszerszemlélettel a feladatokhoz. Ismerje meg a helyzetét teljes körűen, csak így lehet a védelem is teljes körű, szakmailag és gazdaságilag is optimális.
A kialakítandó védelem legyen kockázat alapú és egyáltalán nem biztos, hogy csak technikai megoldásokat igényel.
Sok a módszertani hasonlóság, de...
Az üzletmenet-folytonosság területén pedig fel kell mérni az üzleti folyamatainkat, azok kapcsolatait, a kiszolgáló erőforrásokat, vagyis hasonló technikákat alkalmazunk mint egyes IT projektekben.
Fontos azonban, hogy az üzleti oldal a releváns adatszolgáltató, ők határozzák meg a folyamat fontosságát (kritikusságát), a kiesésének még elviselhető időintervallumát, vagy a kiesése esetén fellépő kár nagyságát. Miben segíthet a tanácsadó?
A tanácsadó a módszertant, a rendszerszemléletet és a tapasztalatot adja hozzá. Tipikus probléma lehet annak meghatározása, hogy mi egy folyamat, vagy milyen mélyen ássunk bele.
A kritikusság mint jellemző is eléggé szubjektív, hiszen minden folyamatgazdának a saját folyamata, felelősségköre a legkritikusabb. Tanácsadó legyen a talpán aki közös nevezőre, egyenszilárdságúra hozza ezt a halmazt. Mi kell tehát a sikerhez?
A siker egyik feltétele:
Legyenek jól meghatározott folyamatok és ismerjük kapcsolataikat!
Segíteni kell az üzleti oldalt a kritikusság mértékének, valamint a maximálisan elviselhető kiesési idő meghatározásakor. Ennek az időnek a nagysága erősen befolyásolja a veszteségek
nagyságát, valamint azt az eljárást amelynek ezen idő alatt kell biztosítania az átmeneti működést.
Az alternatív eljárás kidolgozása nem minden folyamatra értelmezhető. Ilyenkor arról kell gondoskodni, hogy a probléma elhárítása után a folyamat eredményei pótlólag előállíthatóak
legyenek (pl. adatok megőrzése).
A fentiek megfogalmazása és ezek strukturált dokumentálása, a kapcsolatok szemléletes ábrázolása szintén tanácsadói feladat. Sokat tehet a tanácsadó a munka eredményének a menedzsment felé történő szemléletes prezentálásában. Apropó prezentálás...
Hogyan indokold?
Az egyes megoldások gazdaságossági és szakmai indoklása egyaránt fontos. Tapasztalatunk szerint, az hogy egy tervből lesz-e megvalósítás legalább annyira gazdaságossági (erőforrás) kérdés, mint szakmai. A döntésre előkészített anyag és prezentáció ne hemzsegjen a szakmai kifejezésektől, legyen világos és a szakmai indokoltságon kívül gazdaságilag alátámasztott.
Segítsük a menedzsmentet a döntésben azzal is, hogy ismertetjük az implementáció lehetséges eredményeit, illetve elmaradásának veszélyeit. Itt nem csak a közvetlen biztonsági eredményekre gondolok, hiszen hozzáadott érték az is, ha pontosan körülhatároltak lesznek az üzleti folyamatok és kapcsolataik, ha a felelősségi kérdések dokumentáltak lesznek és erősödik a biztonsági tudatosság, nő a szervezet „érettségi" szintje.
A veszélyforrások és a velük járó kockázatok megismerése pedig növeli a menedzsment felelőség érzetét, hiszen a nem csökkentett kockázatokat fel kell vállalniuk.
Ne feledjük ezzel még csak a tervezés készült el. Ahhoz hogy a szervezet, az üzlet felkészült legyen a váratlan események kezelésére, mindezt meg kell valósítani, az eljárást meg kell ismerni, begyakorolni és időszakonként felülvizsgálni.
Mindebben segítségünkre lehet egy hatásos biztonsági menedzsment rendszer és persze ha van akkor sem dőlhetünk hátra...