Folyamatos BCP, katasztrofális DRP

©2010 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice

1

Krasznay CsabaCISA, CISM, CISSP, CEHHP MagyarországIT biztonsági tanácsadó

Folyamatos BCP, Folyamatos BCP, katasztrofális DRPkatasztrofális DRPNehézségek a folytonossági tervezésben.Nehézségek a folytonossági tervezésben.

2 Footer Goes Here2

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 Footer Goes Here3

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 Here4

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 Footer Goes Here5

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 Here6

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 Here7

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 Here8

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 Here9

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, 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 Here10

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 Here11

A terv hatóköre

12 Footer Goes Here12

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.

13 Footer Goes Here13

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 Here14

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!

E-mail: [email protected]: www.krasznay.hu