Incident Response, Business Continuity и Disaster Recovery често се използват като взаимозаменяеми понятия.
На практика обаче те решават три различни проблема:
Incident Response – как реагираме на инцидента.
Business Continuity – как продължаваме да работим по време на прекъсването.
Disaster Recovery – как възстановяваме системите и данните.
Една организация може да има добра процедура за реакция при инциденти, но все пак да не може да продължи работа, ако критична система спре. Или да има backup, но да няма ясен план как и в какъв ред да възстанови инфраструктурата.
Затова трите процеса трябва да работят заедно.
Incident Response – как реагираме на инцидента
Incident Response Plan описва какво трябва да се случи, когато организацията установи инцидент по информационна сигурност.
Например:
- компрометиран Microsoft 365 акаунт;
- ransomware;
- phishing атака;
- изтичане на данни;
- загубено устройство;
- неоторизиран достъп;
- malware на служебен компютър.
Основната цел е инцидентът да бъде открит, ограничен и разследван възможно най-бързо.
Добрата процедура трябва да отговаря на въпроси като:
Кой получава сигнала?
Кой взема решение за блокиране на акаунт или устройство?
Кой извършва техническото разследване?
Кой уведомява ръководството?
Има ли засегнати лични данни?
Трябва ли да бъдат уведомени клиенти, партньори или регулатор?
Incident Response се фокусира върху самото събитие.
Неговата задача е да спре разпространението на проблема и да ограничи последствията.
Business Continuity – как бизнесът продължава да работи
Business Continuity Plan има различна цел.
Той приема, че определена система, офис, доставчик или услуга може да стане временно недостъпна и задава въпроса:
Как продължаваме работа, докато проблемът бъде отстранен?
Например счетоводната система е недостъпна за един ден.
Business Continuity Plan не се интересува толкова защо системата е спряла. По-важното е как компанията ще работи междувременно.
Може да има временна процедура:
- плащанията да бъдат одобрявани по алтернативен процес;
- критични заявки да се записват в предварително определен файл;
- клиентите да бъдат обслужвани чрез резервен канал;
- определени дейности временно да се извършват ръчно;
- служителите да работят от друга локация.
Business Continuity е преди всичко бизнес процес, а не само IT документ.
Затова при изготвянето му трябва да участват и ръководителите на критичните функции.
Disaster Recovery – как възстановяваме IT средата
Disaster Recovery Plan е най-техническият от трите.
Той описва как организацията ще възстанови системите и данните след сериозно прекъсване.
Например:
- повреда на сървър;
- ransomware;
- загуба на виртуална машина;
- проблем в data centre;
- критична повреда на storage;
- изтриване или криптиране на данни;
- сериозен проблем с cloud инфраструктура.
Тук вече трябва да е ясно:
Какво възстановяваме първо?
Къде се намират backup копията?
Кой има достъп до тях?
Как се стартира възстановяването?
Как проверяваме дали данните са коректни?
Колко време можем да бъдем без системата?
Колко данни можем да си позволим да загубим?
Точно тук се използват понятия като RTO и RPO.
RTO – Recovery Time Objective
Колко време може да бъде недостъпна дадена система.
RPO – Recovery Point Objective
Колко загуба на данни е приемлива.
Ако backup се прави веднъж дневно, например, при сериозен инцидент може да се загубят до 24 часа информация.
Един инцидент, три различни плана
Най-лесно разликата се вижда с пример.
Представете си, че компанията е засегната от ransomware.
Incident Response
IT екипът:
- изолира заразените устройства;
- блокира компрометирани акаунти;
- проверява логове;
- търси първоначалния вектор на атаката;
- определя кои системи са засегнати;
- проверява дали има изтичане на данни.
Целта е атаката да бъде овладяна.
Business Continuity
Междувременно компанията трябва да продължи да работи.
Тя активира резервни процеси:
- определя кои дейности могат да продължат;
- уведомява ключови клиенти;
- премества комуникацията към алтернативен канал;
- определя временни процедури;
- приоритизира най-важните бизнес функции.
Целта е бизнесът да не спре напълно.
Disaster Recovery
След като средата е обезопасена, започва възстановяването.
IT екипът:
- възстановява критичните сървъри;
- връща данни от backup;
- проверява целостта им;
- възстановява приложенията;
- тества системите;
- постепенно връща потребителите към нормална работа.
Целта е IT средата да бъде възстановена безопасно.
Трите процеса могат да текат едновременно, но отговарят на различни въпроси.
Трябва ли да имаме три отделни документа?
Не винаги.
При голяма организация е напълно логично да има отделни:
Incident Response Plan
Business Continuity Plan
Disaster Recovery Plan
За компания с 10–50 служители обаче документите могат да бъдат по-кратки и взаимно свързани.
По-важно е да няма противоречия между тях.
Например няма смисъл Business Continuity Plan да казва, че критична система трябва да бъде възстановена до два часа, ако Disaster Recovery Plan показва, че реалното възстановяване от backup отнема осем часа.
Backup не е Disaster Recovery Plan
Това е едно от най-честите обърквания.
Компанията може да има отличен backup и все пак да няма работещ Disaster Recovery Plan.
Backup отговаря на въпроса:
„Имаме ли копие на данните?“
Disaster Recovery трябва да отговори и на:
Как ги възстановяваме?
Къде?
В какъв ред?
Кой го прави?
Колко време отнема?
Проверявали ли сме дали процедурата действително работи?
Затова backup без периодичен restore test не дава достатъчна увереност, че компанията може да се възстанови при реален инцидент.
Най-честият проблем: документ има, но никой не го е тествал
Плановете често се създават за одит, клиентско изискване или сертификация и след това остават в папка.
Това е риск.
Една процедура може да изглежда напълно логична на хартия, но при тест да се окаже, че:
- телефонният номер на отговорното лице е стар;
- служителят, който трябва да има достъп до backup, няма необходимите права;
- резервният акаунт не работи;
- backup копието е повредено;
- критичен доставчик липсва от плана;
- реалното време за възстановяване е много по-дълго от очакваното.
Затова плановете трябва периодично да се преглеждат и тестват.
Какво е минимално необходимо за малка и средна компания?
Не е нужен стотици страници документация.
За повечето организации е достатъчно ясно да бъдат определени:
- критичните системи и процеси;
- отговорните лица;
- начинът за ескалация;
- контактите на ключови доставчици;
- алтернативните начини за работа;
- backup и restore процедурите;
- редът за възстановяване;
- комуникацията при инцидент;
- RTO и RPO за критичните системи;
- периодичните тестове.
Най-важното е хората, които трябва да използват плановете, реално да знаят, че съществуват и какво се очаква от тях.
Кратко обобщение
Разликата може да се сведе до три въпроса:
Incident Response:
Как спираме и разследваме инцидента?
Business Continuity:
Как продължаваме работа, докато той бъде решен?
Disaster Recovery:
Как възстановяваме системите и данните?
Добрата устойчивост на една организация изисква и трите.
Не е достатъчно само да предотвратяваме инциденти. Трябва да сме подготвени и за момента, в който въпреки всички мерки нещо действително се обърка.
