1 / 15

Folyamatos BCP, katasztrofális DRP

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ó. Bevezetés. Az üzletmenet-folytonosság tervezése az egyik legalapvetőbb feladat az információbiztonsági irányítás rendszerben.

colton
Download Presentation

Folyamatos BCP, katasztrofális DRP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related