©2010 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice 1 Krasznay Csaba CISA, CISM, CISSP, CEH HP Magyarország IT biztonsági tanácsadó Folyamatos BCP, katasztrofális DRP Nehézségek a folytonossági tervezésben.Nehézségek a folytonossági tervezésben.

2 Footer Goes Here 2 Bevezetés –Az üzletmenet-folytonosság tervezése az egyik legalapvetőbb feladat az információbiztonsági irányítás rendszerben. –Jól működő BC folyamatokkal mégis ritkán találkozunk. –Az előadás célja bemutatni azokat a leggyakoribb hibákat, amik az íróasztalfióknak készült tervezési dokumentumokhoz vezetnek. –Forrás: Franklin Fletcher, Common Business Continuity Planning Mistakes, –És a saját keserű tapasztalat…

3 Footer Goes Here 3 A menedzsment támogatás hiánya –A BCP elkészítésének oka leggyakrabban valamilyen külső kényszer: Jogszabályi előírás Tulajdonosi kötelezettség Felügyeleti bírság… –A menedzsment szemében ezért megfelelő előkészítés nélkül ez is „csak egy papír, aminek meg kell lennie”. –A támogatás sokszor csak a termék leadásáig tart, a folyamatos fejlesztés már nem fontos –Az is előfordulhat, hogy a hosszúra nyúlt tervezés miatt a menedzsment támogatása megszűnik –Megoldás: be kell láttatni a felsővezetéssel, hogy a BCP/DRP elkészítése egyértelműen fontos üzleti célokat szolgál!

4 Footer Goes Here 4 Az „ezen is túl vagyunk” érzés –Az információbiztonság folyamat (ld. ISO PDCA modell) –Ennek a folyamatnak része a BC is, melyet szintén Tervezni kell Végre kell hajtani Ellenőrizni kell Javítani kell –Gyakori hiba, hogy az első leadás után a szervezet hátradől, mint aki jól végezte dolgát. –Pedig a dokumentumban írtak akár másnap is megváltozhatnak. –Eggyel enyhébb fokozat az, amikor az éves audit előtti héten „frissül” a terv. –Megoldás: A tervek folyamatos karbantartásának feladatát ki kell osztani, és megfelelő auditterv mentén folyamatosan ellenőrizni kell az abban foglaltak megfelelőségét.

5 Footer Goes Here 5 Kockázatelemzés –Különböző iskolák eltérően értelmezik a kockázatelemzés szerepét az üzletmenet-folytonosság tervezésében –Miért kell kockázatelemzés, ha van üzletihatás-elemzés (BIA)? –Ha van kockázatelemzés, akkor milyen valós kockázatokkal számoljunk? –Hidvégi Zoltán-féle álláspont: az RA és a BIA párhuzamosan végrehajtandó feladat, az egyik műszaki, a másik üzleti kockázatokra fókuszál, eredményük együttesen használható fel. –Krasznay Csaba-féle álláspont: az RA célja azon kockázatok felderítése, amikkel számolnunk kell, és amikre konkrét védelmi intézkedéseket tudunk tervezni, a BC célja pedig felkészülni a nem belátható eseményekre.

6 Footer Goes Here 6 A nem megfelelő BIA –Határozzuk meg az időkritikus üzleti funkciókat! A felmérés eredményeképp meg lehet ezeket határozni. Ezen funkciókat kell az MTD-n belül visszaállítani. Figyeljünk a függőségekre is! -> De biztosan jól mértük fel az üzleti funkciókat? –Határozzuk meg a maximálisan elfogadható kiesés (MTD) mértékét! - > Biztos, hogy egyetlen folyamat sem állhat egy percet sem? –Az MTD alapján állapítsunk meg prioritást a kritikus üzleti funkciók alapján! Minél kisebb az MTD, annál fontosabb a funkció, és annál drágább visszaállítani. -> Biztos, hogy minden üzleti funkció kritikus?

7 Footer Goes Here 7 Elavult leltárlista –A visszaállítási stratégiák kidolgozásánál meg kell határozni a visszaállításhoz szükséges eszközök körét. –Néha egy lemerült elemen múlik a visszaállítás sikere… –Megoldás: TMK a rendszeres auditok során.

8 Footer Goes Here 8 A tervek begyakorlásának hiánya –Minden terv pontosan annyit ér, amennyit végre tudnak hajtani belőle. –Valószínűleg a legtöbb BC folyamatot használó szervezetnél fejvesztett rohangálás lenne egy komolyabb leállás eredménye –Megoldás: Átnézés: a terv felelősei egy asztal körül átnézik a tervet. Chechklist: az egyes területek kapnak egy listát, amit végignéznek, és ellenőrzik annak tartalmát. Szimuláció: a felelősök egy forgatókönyv alapján próbálják a terv működőképességét. Párhuzamos tesztelés: a kritikus rendszereket üzembe is helyezik a tartalékhelyen. Teljes megszakításos tesztelés: teljesen leállnak az élesüzemmel.

9 Footer Goes Here 9 A terv hatóköre –A NIST SP szerint egy jó üzletmenet-folytonossági dokumentáció az alábbi terveket és dokumentumokat tartalmazza: Üzletmenet-folytonossági terv (Business Continuity Plan – BCP): annak leírása, hogy hogyan lehet egy üzleti funkciót fenntartani annak megzavarása alatt és után. Ez a leírás minden kulcsfunkcióra elkészül, azokat egyesével tárgyalva. Helyreállítási Terv (Business Resumption Plan – BRP): leírja, hogy egy üzleti folyamatot hogyan kell visszaállítani egy nem kívánt esemény után. Szemben a BCP-vel, nem mondja meg, hogy a vészhelyzet alatt hogyan biztosítsuk a folytonosságot. Általában a BCP része. Működés folytatásának terve (Continuity of Operations Plan – COOP): feladata annak a definiálása, hogy a szervezeti működést hogyan lehet visszaállítani egy nem kívánt esemény után. A BCP-től függetlenül készül. Mivel elsősorban a cég menedzsment funkcióinak visszaállítását tartalmazza, nem IT megközelítésű. A támogatás folyamatossági terve (Continuity of Support Plan): az üzleti folyamatokat támogató rendszerek folyamatos üzemelésére vonatkozó terv.

10 Footer Goes Here 10 A terv hatóköre Krízis kommunikációs terv (Crisis Communication Plan): a katasztrófa esetén szükséges belső és külső kommunikációs stratégiát leíró dokumentum. A BCP egyik melléklete. A legfontosabb része, hogy megnevezi azt a kizárólagos személyt, aki ilyenkor megszólalhat a nyilvánosság előtt. Informatikai incidenskezelési terv (Cyber Incident Response Plan): azokat a lépéseket tartalmazza, melyeket egy informatikai támadás során kell a szervezetnek megtennie. A BCP melléklete. Katasztrófa helyreállítási terv (DRP): akkor alkalmazzák, ha a szervezetet valóban katasztrofális esemény éri. Lényegében leírja, hogy hogyan lehet a teljes IT-t egy alternatív helyen újjáépíteni és üzemeltetni. A BCP része. Létesítményekre vonatkozó vészhelyzeti terv (Occupant Emergency Plan – OEP): a létesítményeket fenyegető veszélyek bekövetkezése esetén szükséges lépések leírása. Tartalmazza pl. a tűzeset vagy valamilyen bűncselekmény miatt életbelépő cselekményeket. A BCP-be beleírható, de attól elválasztva hajtják végre.

11 Footer Goes Here 11 A terv hatóköre

12 Footer Goes Here 12 Felelősségi hierarchia –A BCP életbelépése „hadi helyzet” egy szervezetnél, ami különösen indokolttá teszi a gyors döntések meghozatalát. –Ehhez már tervezés szintjén ki kell jelölni a szerepköröket. –Ennek hiányában csak a kapkodást és a fejetlenséget érjük el. Menedzsment csapat; Kárfelmérési csapat; Operációs rendszer adminisztrátor; Szerver visszaállítási csapat; LAN/WAN visszaállítási csapat; Adatbázis visszaállítási csapat; Hálózati műveletek visszaálíltási csapat; Alkalmazás visszaállítási csapatok; Telekommunikációs csapat; Tesztelési csapat Szállítási és költöztetési csapat; Sajtókapcsolatok; Jogi csapat; Biztonsági felelősök; Beszerzési csapat.

13 Footer Goes Here 13 Kommunikáció –A BC életbelépését mind a szervezet, mind a külvilág felé kommunikálni kell. –Belső kommunikációval kell elérni a dolgozókat, a partnereket, a beszállítókat. –Meg kell oldani az alternatív kommunikációt is esetleges természeti katasztrófák esetén –A külső kommunikációval kell megelőzni az esetleges pletykákat, kiszivárogtatásokat, amik sokkal nagyobb kárt okozhatnak, mint maga a kiesés. –Megoldás: krízis kommunikációs tervet kell készíteni, amiben meg kell nevezni a kommunikációért felelős személyeket.

14 Footer Goes Here 14 IT biztonság –A nem rendszerszerű működés komoly veszélyt jelent az információbiztonságra vonatkozóan. –Gondoljunk csak arra, hogy vészhelyzet esetén a tűzoltóknak, tűzszerészeknek olyan helyekre is bejárásuk van, ahova egyébként ember nem teheti be a lábát – felügyelet nélkül! –A BC folyamatok életbelépésére az IT biztonsági csapatnak külön fel kell készülni, külön kockázatként kell vele számolni!

15 Footer Goes Here Köszönöm a figyelmet! Web: