Folyamatos BCP, katasztrofális DRP

1. 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ó

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

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. 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.

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. 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. 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. 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. 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 ContinuityPlan – 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 ResumptionPlan – 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 OperationsPlan – 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 SupportPlan): az üzleti folyamatokat támogató rendszerek folyamatos üzemelésére vonatkozó terv.

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. A terv hatóköre

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. 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. 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. Köszönöm a figyelmet!E-mail: csaba.krasznay@hp.comWeb: www.krasznay.hu