Folyamatos BCP katasztroflis DRP Nehzsgek a folytonossgi tervezsben

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

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, http: //www. giac. org/resources/whitepaper/planning/317. php – És a saját keserű tapasztalat… 2 Footer Goes Here

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! 3 Footer Goes Here

Az „ezen is túl vagyunk” érzés – Az információbiztonság folyamat (ld. ISO 27001 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. 4 Footer Goes Here

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. 5 Footer Goes Here

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? 6 Footer Goes Here

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. 7 Footer Goes Here

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: 8 • Á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. Footer Goes Here

A terv hatóköre – A NIST SP 800 -34 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, 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. 9 Footer Goes Here

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, 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. 10 Footer Goes Here

A terv hatóköre 11 Footer Goes Here

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; • Alkalmazás visszaállítási csapatok; • Kárfelmérési csapat; • Telekommunikációs csapat; • Operációs rendszer • Tesztelési csapat adminisztrátor; • Szállítási és költöztetési csapat; • Szerver visszaállítási csapat; • LAN/WAN visszaállítási csapat; • Sajtókapcsolatok; • Adatbázis visszaállítási csapat; • Jogi csapat; • Hálózati műveletek visszaálíltási • Biztonsági felelősök; • Beszerzési csapat; 12 Footer Goes Here

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. 13 Footer Goes Here

IT biztonság – A nem rendszerű 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! 14 Footer Goes Here

Köszönöm a figyelmet! E-mail: csaba. krasznay@hp. com Web: www. krasznay. hu 15 Footer Goes Here