Докладване на инцидент по ЗКС за 24 и 72 часа: точният шаблон, кога стартира броячът и как да говорите с ОЕЦ
Alexander Sverdlov
Анализатор по сигурността
Най-важното накратко
- Броячът за 24 и 72 часа тръгва от осведомеността на субекта, не от момента на самата атака. Това е критично разграничение, което повечето компании пропускат и грешно стартират часовниците твърде късно или твърде рано
- Ранното предупреждение в първите 24 часа е кратко (3 до 5 параграфа) и съдържа фиксиран набор от факти. Не е финален разказ, не е признание, не е план за действие. Грешка е да го забавите, докато не знаете всичко
- Подробният доклад в 72 часа е структурен документ от 6 до 10 страници с конкретни раздели. Без подготвен шаблон в нощта на инцидента нямате време да го съставите от нула
- Тонът към ОЕЦ е фактологичен, спокоен и проследим. Емоционални формулировки, омаловажаване или прехвърляне на вина към доставчик са трите най-чести подсилващи фактори за наказателно постановление
- Окончателният доклад в рамките на 1 месец трябва да включва анализ на първопричината и план за корективни мерки със срокове. Това е документът, по който ще ви съдят след 12 месеца, не нощният имейл
- При засягане на лични данни тече паралелен брояч към КЗЛД, също 72 часа. Двата режима не се замествуват, дори формулярите да са почти еднакви
Беше четвъртък, 22:43. Главният ИТ специалист на средно голяма българска компания, която обслужва критична инфраструктура, ми се обади на личния телефон. „Имаме нещо. SOC-ът ни алармира за подозрителна активност в домейн контролера преди два часа. Сега имаме потвърждение, че злонамерен софтуер шифрира файлове. Колко време имаме до доклад до ОЕЦ?" Първият ми въпрос не беше технически. Беше: „В коя точно минута сте разбрали, че е реален инцидент?" Той замълча. „Около 21:30, мисля. Но не сме сигурни как точно да го определим."
Това е сцената, която ще играете и вие. И това е причината този материал да съществува. Защото в нощта на инцидента нямате време да четете чл. 22 от Закона за киберсигурност, не разбирате защо има два различни броячи (24 и 72 часа), нямате готов шаблон в правилния формат, не знаете на коя имейл точно да изпратите, и не помните дали трябва да уведомите и КЗЛД. Натискът върху ИТ е огромен, защото системите все още не са възстановени; натискът върху УС е огромен, защото никой не знае колко ще струва това.
Този материал е подготовката, която трябва да направите СЕГА, докато не сте под огън. Той ви дава готовия шаблон за 24-часовото ранно предупреждение, готовия шаблон за 72-часовия доклад, картата за решение „кога точно тръгва броячът", протокол за разговора с ОЕЦ и петнадесетте изречения, които никога не пишете в официален доклад до регулатора. Адресатът е ИТ ръководителят, CISO-функцията или координаторът на инциденти, който ще получи телефонното обаждане в 22:43.
Раздел 1
Кога точно тръгва броячът: четирите типови сценария
Първото и най-важно решение, което вземате в нощта на инцидента, не е техническо. То е документално: да определите точния момент, от който тече 24-часовият брояч за ранното предупреждение и 72-часовият брояч за подробния доклад. Този момент влиза в писмен вид в официалния протокол, той се верифицира впоследствие срещу лог-файлите, и той определя дали сте били в срок или не. Грешка в дефиницията на момента е грешка, която не можете да поправите със заден ред.
Законът използва формулировката „от момента, в който субектът се е запознал с инцидента". Това звучи просто. В практиката не е. Защото между първа алерт от EDR в 19:12, до потвърждение на SOC аналитика в 19:48, до телефонно обаждане към ИТ директора в 20:15, до решение „да, това е значим инцидент" в 21:30, имате четири възможни моменти. Различният избор води до различни срокове - и до различна позиция при евентуален спор с регулатора.
Ето как се решава в четирите типови сценария:
Сценарий 1. Алерт от EDR/SIEM, потвърден от SOC аналитик
T0 = моментът, в който SOC аналитикът е писал в тикета „confirmed true positive" или еквивалент. Не моментът на първата алерт - тогава тя още не е била „инцидент" в смисъла на закона. Не моментът, в който е била ескалирана до ИТ директора - тогава тя вече е била потвърдена. Документирайте часа от тикетинг системата, не от паметта.
Сценарий 2. Външно уведомление от партньор, доставчик или клиент
T0 = моментът на получаване на ясно уведомление за конкретен инцидент във вашата компания. Не моментът на следващото вътрешно потвърждение. Ако получите имейл от партньор в 09:14, че виждат подозрителен трафик от ваш IP към техните системи, и след вътрешен преглед потвърдите в 14:30, че сте компрометирани - T0 е 09:14, не 14:30. Регулаторът ще прочете партньорския имейл и ще го свери. Опит да измените T0 в по-късен момент е една от грешките с тежки последствия.
Сценарий 3. Самооткриване от вътрешен потребител (изнудване, фишинг, аномалия)
T0 = моментът, в който информацията достига функцията, която вътрешно е назначена като координатор на инциденти. Не моментът, в който редовият потребител е забелязал нещо. Ако служител в счетоводството получи изнудващ имейл в 11:00, но го препрати на ИТ helpdesk едва в 16:45, и helpdesk-ът ескалира до CISO в 17:20 - T0 е 17:20. Това обаче изисква да докажете, че имате реално работеща процедура, по която служителите трябва да докладват веднага. Ако служителят е „забравил", регулаторът ще приеме T0 = 11:00.
Сценарий 4. Постфактум откриване (forensic анализ показва инцидент отпреди седмици)
T0 = моментът, в който форензичният анализ е достигнал заключение, че инцидент е настъпил, не моментът на самото минало събитие. Ако сега правите DFIR и установите, че злоупотреба с акаунт е била извършена преди 6 седмици, не означава, че сте „пропуснали" 24 часа. Означава, че T0 е сегашният момент на установяване. Това е важно за honesty - не скривайте откритията, а ги обявявайте веднага. Регулаторът оценява прозрачността далеч по-силно от закъснението на самото подозрение.
Една практическа добавка: запишете T0 в три независими места веднага - тикетинг системата, имейл до CISO и УС, и физически бележник или Slack канал с timestamp. Това дава доказателство за добросъвестност, ако впоследствие регулаторът поиска да провери дали T0 е бил манипулиран по-късно.
Раздел 2
Шаблон за ранно предупреждение в 24 часа
Ранното предупреждение не е финалният доклад. То е сигнал на регулатора, че сте се запознали с инцидент и работите по него. То е целенасочено кратко, защото на ден първи няма как да знаете всички детайли. Опитите да напишете обстойно „всичко, което знаем" в първите 24 часа са грешка - те създават писмено доказателство с неточности, които впоследствие ще трябва да коригирате, и създават впечатление, че бързате с интерпретации.
Ето точният шаблон, който прилагаме за нашите клиенти. Адаптирайте го към вашия фирмен формат, но не разширявайте структурата отвъд тези раздели в първите 24 часа:
Шаблон 1
Ранно предупреждение за инцидент по чл. 22 от ЗКС
До: Оперативен експертен център, Държавна агенция „Електронно управление" (incidents@e-gov.bg или официалния портал)
От: [Име на компанията], ЕИК [НОМЕР], [Адрес]
Дата и час на изпращане: [ДД.ММ.ГГГГ ЧЧ:ММ часа българско време]
Категория субект: [съществен / важен]
Сектор по приложение N от ЗКС: [например: енергетика / здравеопазване / банково дело / ИКТ услуги]
1. Първоначално описание
На [ДД.ММ.ГГГГ] в [ЧЧ:ММ] часа българско време установихме [кратко описание в 1-2 изречения, например: „индикации за неоторизиран достъп до файлов сървър с криптиране на файлове"]. Към момента на изпращане работим по разследване и съдържане на инцидента.
2. Преценка дали инцидентът е значим
[Изберете една: значим (с обосновка от 1 изречение, например: „поради потенциалното засягане на услуга, която обслужва над N клиенти/потребители") / към момента не сме в състояние да преценим значимостта]
3. Подозрение за злонамерено действие
[Изберете една: да, с първоначални индикации за [тип, например: ransomware / неоторизиран достъп / DDoS] / към момента не можем да потвърдим или отхвърлим]
4. Възможно трансгранично или междусекторно въздействие
[Изберете една: не се установяват към момента / има индикации за засягане на партньори в [държава или сектор] - подробности ще бъдат предоставени в 72-часовия доклад]
5. Контактно лице
[Име, длъжност, имейл, мобилен телефон, наличност 24/7 за периода на инцидента]. Резервно контактно лице: [същото].
6. Следващи стъпки
Ще предоставим подробен доклад по чл. 22 в рамките на 72 часа от часа на запознаване. Готови сме за допълнителни запитвания и координация по време на разследването.
Подпис: [Име, длъжност на лицето, оторизирано да представлява компанията или CISO с делегирани пълномощия]
Забележете три неща в шаблона. Първо, той не съдържа предположения за първопричината - „смятаме, че е заради уязвимост в X" е изречение, което ще ви тегли назад впоследствие. Второ, той използва нюанс „към момента не сме в състояние да преценим" вместо „не знаем" - първото показва дисциплина, второто звучи небрежно. Трето, той приключва с обещание за подробен доклад в 72 часа - това задължение, веднъж записано, се изпълнява без забавяне.
Изпращайте имейла от служебен пощенски адрес на компанията, с копие до CISO и юриста. Запазете автоматичното потвърждение за получаване (delivery receipt). Ако изпращате през официален портал, направете screenshot на потвърждението с timestamp. Тези два документа са доказателство за спазен срок при евентуален спор.
Една често задавана дилема: трябва ли да изпратите ранното предупреждение, ако не сте сигурни, че инцидентът е „значим"? Препоръката ни е да изпратите. Грешката „изпратихме нещо, което не беше значим инцидент" се прощава лесно; грешката „не изпратихме нещо, което беше значим" - не. Закъснението с 6 часа над срока, защото сте чакали допълнителни данни, ще тежи повече от това, че сте уведомили рано за нещо, което се е оказало по-малко тежко.
Раздел 3
Шаблон за подробен доклад в 72 часа
Подробният доклад в 72 часа е същинският първи документ. Той вече има тегло - регулаторът ще го чете внимателно, ще го сравнява с впоследствие предоставения окончателен доклад, и ще тегли заключения от тона му. Адекватен подробен доклад е 6 до 10 страници; по-кратък изглежда неподготвен; по-дълъг означава, че сте включили предположения, които впоследствие ще се окажат грешни.
Ето структурата на шаблона:
Шаблон 2
Подробен доклад за инцидент в 72 часа по чл. 22 от ЗКС
Раздел A. Идентификация на субекта и инцидента
- Юридическо лице, ЕИК, адрес, сектор по ЗКС, категория (съществен/важен)
- Уникален вътрешен идентификатор на инцидента (за корелация с бъдеща кореспонденция)
- Дата и час на запознаване (T0) - повторен от ранното предупреждение
- Дата и час на изпращане на текущия доклад
- Лице за контакт, заместник, режим на наличност
Раздел B. Подробно описание на инцидента
- Хронология в точни часове: T0 - X (първа индикация), T0 (потвърждение), T0 + N часа (ключови стъпки)
- Засегнати активи: списък със системи, мрежи, бази данни, локации
- Засегнати услуги: кои бизнес услуги са били прекъснати или влошени
- Първоначална оценка на категорията: ransomware / неоторизиран достъп / DDoS / изтичане на данни / друго
- Първоначална оценка на тежестта по вътрешна скала и обосновка
Раздел C. Оценка на въздействието
- Брой засегнати потребители или клиенти (или диапазон с обосновка, ако точното число още не е известно)
- Продължителност на нарушаването на услугата (текуща и прогнозна)
- Финансово въздействие към момента (приблизително)
- Засегнати лични данни: вид, обем, дали ще се подава отделно уведомление до КЗЛД
- Засегнати трети страни: партньори, доставчици, клиенти, общност
- Трансгранично въздействие: други държави членки, в които може да има засягане
Раздел D. Първопричина (предварителна)
- Какво знаем към 72-я час: вектор на атака, конкретна уязвимост или грешка, ако е установена
- Какво още разследваме: списък с конкретни хипотези и какво е необходимо да се установят
- Външни експерти, ангажирани с разследването (ако има)
Раздел E. Мерки за сдържане и възстановяване
- Незабавни мерки (изолация на засегнати системи, смяна на пароли, ротация на токени, активиране на резервни системи)
- Краткосрочни мерки (възстановяване от бекъп, преинсталиране, прилагане на patch)
- Текущ статус на възстановяването с проценти и прогноза за пълно възстановяване
- Комуникация към засегнатите страни (клиенти, партньори, общественост)
Раздел F. Сътрудничество с други органи
- КЗЛД: подадено ли е уведомление, кога, референтен номер (ако са засегнати лични данни)
- МВР / ГД БОП: подаден ли е сигнал за компютърно престъпление, кога, преписка
- Други надзорни органи: БНБ / КФН / КРС / ИАМО в зависимост от сектора
- Тарга на другия НИС2 регулатор, ако е применимо за трансгранично въздействие
Раздел G. План за следващи стъпки
- Срок за окончателен доклад (1 месец от T0 или по-кратък, ако анализът приключи по-рано)
- Допълнителни ангажименти: външен форензичен анализ, преглед на сходни системи, обучение
- Контактен ритъм: предложение за междинно актуализиране на регулатора при значими развития
Прикачени документи: хронология във вид на таблица (Excel/PDF), технически индикатори (хешове, IP адреси, домейни - в STIX или CSV формат, ако е приложимо), оторизация на подписалия. Внимавайте за чувствителни данни - предоставяйте обезличени версии, ако не е изрично поискано конкретно лице.
Една забележка по раздел D (първопричина). В 72-я час почти никога нямате окончателно потвърждение коя точно е била първопричината. Затова шаблонът разделя „какво знаем" от „какво още разследваме". Не пишете „смятаме, че е фишинг", ако нямате потвърждение - вместо това пишете „един от разглежданите вектори е фишинг през компрометиран служебен акаунт; разследваме това чрез преглед на имейл логовете от последните 30 дни и интервюта със засегнатия персонал." Първото е спекулация; второто е дисциплина.
Раздел 4
Окончателен доклад в рамките на 1 месец
Окончателният доклад в рамките на 1 месец от T0 е документ, по който ще ви оценяват в продължение на години. Той е техническа аутопсия с управленски заключения. Регулаторът чете в него отговора на най-важния въпрос: научила ли е компанията нещо от инцидента или ще го повтори? Това е и документът, по който се взема решение за наказателно постановление или само препоръка.
Окончателният доклад надгражда 72-часовия с допълнителни раздели:
Раздел H. Окончателна първопричина
С техническа точност. Конкретна уязвимост (CVE, ако е приложимо), конкретен компрометиран акаунт, конкретна неработеща контрола. Не общи изрази като „слаба сигурност", а „на 12 март устройство Х получи фишинг имейл, потребителят X кликна, ние нямахме MFA на M365, акаунтът бе компрометиран, в следващите 4 часа бяха изтеглени Y файла". Колкото по-конкретно, толкова по-добре.
Раздел I. Окончателно въздействие
Реални числа, не диапазони. Колко записа, колко потребители, колко часа downtime, какво е финансовото отражение (загубени приходи, разходи за разследване, разходи за уведомяване). Колко от засегнатите са получили индивидуално уведомление, какъв отзив. Колко от тях са поискали обезщетение или са предявили иск.
Раздел J. План за корективни мерки
Конкретни мерки със срокове и отговорници. За всяка мярка: какво адресира от първопричината, кога ще бъде завършена, кой е отговорникът, как ще се потвърди ефективността. Без общи фрази „ще подобрим обучението" - вместо това „провеждаме задължителен фишинг тренинг за всички служители до 30 април с минимална оценка 80% за валидация на завършването, отговорник CISO". Този раздел е сърцето на окончателния доклад.
Раздел K. Поуки за компанията
Какво се промени в политиките, процедурите, контролите след инцидента. Какъв доклад е направен до УС и какво е решението му. Дали бюджетът за сигурност е увеличен и с колко. Дали има промени в персонала или организационната структура. Това е разделът, в който регулаторът вижда дали инцидентът е довел до култура на учене или само до затваряне на конкретната дупка.
Един съвет: ако очаквате, че разследването няма да приключи в рамките на 1 месец (типично за сложен ransomware с външни форензици), подайте „окончателен доклад със статус „текущо разследване" в срок, а не закъснял доклад. Регулаторът цени спазването на сроковете повече от пълнотата към фиксиран момент. Когато анализът завърши, подайте обновена версия с маркер „актуализация на окончателния доклад от ДД.ММ.ГГГГ".
Раздел 5
Как да говорите с ОЕЦ: тон, дисциплина, какво не правите
Регулаторът не е ваш противник. Това е първото нещо, което трябва да приемете - и това, което е най-трудно за хора в режим на криза. Оперативният експертен център към ДАЕУ е техническо звено, чиято роля е да координира кризата, да помогне на сектора, да види по-широка картина. Ако подходите с подозрение, защита, или с инстинкт да омаловажавате - вие саботирате собствената си позиция.
Има пет правила за разговор с ОЕЦ, които работят:
1. Един говорител, един имейл, един телефон
Назначете един основен и един резервен говорител с ОЕЦ. Всички съобщения от и към ОЕЦ минават през тях. Това избягва ситуация, в която различни членове на екипа казват различни неща или повторно изпращат предходна, вече остаряла информация. Говорителят обикновено е CISO или координаторът на инциденти; не е ИТ инженерът, който е „най-навлязъл в техническите детайли".
2. Само факти, ясно разграничени от хипотези
„Лог-файлът показва логин в 03:14 от IP X" е факт. „Смятаме, че е било XYZ" е хипотеза. Винаги разграничавайте двете явно: „Установяваме следните факти: ... . Разглеждаме следните хипотези: ... ". Хипотеза, представена като факт и впоследствие оборена, е трайно впечатление за несигурност или нечестност.
3. Никаква вина към доставчик в първите 72 часа
Дори ако сте 80% сигурни, че причината е компрометиран доставчик, не го заявявайте в първите 72 часа. Подгответе тази позиция за окончателния доклад с категорични доказателства. Преждевременното прехвърляне на вина се възприема като опит да се измъкнете от собствената си отговорност и подсилва впечатлението за слаб надзор върху веригата на доставки (което е отделен инкриминируем пропуск по чл. 21).
4. Прозрачност за това, което не знаете
„В момента не разполагаме с тази информация; ще ви върна отговор до 18:00 утре" е по-силно от опит да измислите или закъсняла обобщена справка. Регулаторът ще оцени фокусираността; ще запомни „не знаем" по-малко, отколкото бихте могли да си помислите.
5. Писмено след всеки разговор
Всеки телефонен разговор или среща с представители на ОЕЦ се потвърждава с кратък имейл към тях: „Благодарим за разговора в 14:00 на ДД.ММ. Кратко резюме на договореното: 1) ... 2) ... 3) ... . Молим, потвърдете дали резюмето отразява вашето разбиране." Това създава писмена следа, която ви защитава от впоследствие различни интерпретации.
Една допълнителна тактика: ако имате юрист или външен консултант с предишен опит с ОЕЦ, поканете го като „шепот в ухото". Той не говори от ваше име, но седи до говорителя по време на ключовите разговори и помага с тон, формулировки и стратегически решения. Това е една от най-ефективните инвестиции в нощта на инцидента - под 5000 лв за външна експертиза, която може да спести десетки хиляди в наказание.
Раздел 6
Седемте утежняващи грешки, които превръщат инцидента в наказание
Анализ на наказателните постановления по подобни режими в Германия, Естония и Финландия (където NIS2 проверките вече тече от една до две години) показва, че самият инцидент рядко е причина за тежко наказание. Тежките глоби идват от това как сте се държали ПОКОЛО инцидента. Ето седемте най-чести грешки, които превръщат „препоръка" в „наказателно постановление":
Грешка 1. Закъснявате ранното предупреждение без обосновка
Изпращате го на 27-я час с обяснение „чакахме повече данни". Това е най-честата причина за първоначална глоба. Срокът от 24 часа не е препоръка - той е законов. Ако наистина не сте могли в първите 24 часа, изпратете обяснението в 24-я час, не на 27-я.
Грешка 2. Манипулирате T0 (по-късно от истинския)
„Запознахме се на 14:00, а в тикета пише, че SOC аналитикът е потвърдил в 09:30." Регулаторите винаги искат лог-файлове и тикети. Несъответствие е сигнал за лоша вяра, което прехвърля случая от регулаторно нарушение към етично нарушение - значителна ескалация.
Грешка 3. Скривате информация, която впоследствие изплува
Не споменавате, че същата група акаунти беше компрометирана преди 6 месеца и тогава не сте докладвали. Регулаторът ще го намери - чрез ваши служители, чрез доставчик, чрез данни от партньор. Когато го намери, добавя сериозно наказание за „предходен неотчетен пропуск".
Грешка 4. Прехвърляте вината към доставчик в първите 72 часа
„Те ни вкараха ransomware." Дори ако е технически вярно, преждевременното заявяване отваря тема „как точно сте проверявали сигурността на този доставчик?" - тема, от която не искате да започвате с дефанзивна позиция. Първо подгответе доказателствата.
Грешка 5. Окончателен доклад без конкретен план
„Ще подобрим обучението и ще въведем повече контроли." Това не е план. Регулаторът чете окончателен доклад като одиторски доклад - конкретни мерки, конкретни срокове, конкретни отговорници, конкретни критерии за успех. Без тях докладът сигнализира, че компанията не е разбрала какво се е случило.
Грешка 6. Не уведомявате КЗЛД, когато трябва
Ransomware с потенциално засягане на лични данни почти винаги изисква уведомление до КЗЛД в 72 часа. Често компании уведомяват само ОЕЦ, мислейки, че едното покрива другото. Не покрива - двата режима тече паралелно и са независими. Ако не уведомите КЗЛД, при последваща проверка ще получите второ, отделно наказателно постановление по GDPR.
Грешка 7. Без уведомяване на засегнатите получатели на услугата
Ако инцидентът „значително влияе" върху услугата, чл. 22 ал. 4 от ЗКС задължава да информирате получателите на услугата и да им предложите мерки за защита. Това задължение се пропуска често. Регулаторът проверява не само дали сте уведомили него, но и дали сте уведомили клиентите си - често по индиректен начин (чрез жалби или след сигнал от потребител).
Последен поглед
Главният ИТ специалист, който ми се обади в 22:43, изпрати ранното предупреждение в 21:18 на следващия ден - близо до края на 24-часовия срок, но в него. Подробният доклад в 72 часа беше готов за 56 часа, защото имахме шаблона предварително. Окончателният доклад постъпи на 28-я ден с конкретен план за корективни мерки и решение на УС за допълнителен бюджет от 240 000 лв за централизирани логове и MFA на всички системи. ОЕЦ препоръча подобрения, без наказателно постановление.
Разликата между „препоръка" и „120 000 лв глоба" не беше в инцидента. Беше в дисциплината на докладването. Времето, когато това се подготвя, е сега, докато имате спокойствие - не в 22:43 в четвъртък вечерта.
Често задавани
Въпросите, които чуваме от ИТ ръководителите
1. Кой точно има право да подпише ранното предупреждение?
По закон - лицето, оторизирано да представлява юридическото лице, или лице с делегирани от УС пълномощия. На практика това почти винаги е CISO или ИТ директорът с писмена делегация от изпълнителния директор, заведена в деловодството. Подгответе тази делегация СЕГА, не в нощта на инцидента. Тя е едно изречение: „Делегирам пълномощия на [Име, длъжност] да подписва уведомления по чл. 22 от ЗКС от името на компанията" с дата, подпис и печат. Без такава делегация инцидентният имейл, подписан от ИТ директора, може да бъде отхвърлен формално, което резулира в закъснял доклад.
2. Какво е официалният канал за изпращане на доклада?
Към момента ОЕЦ приема уведомления чрез официалния портал на ДАЕУ и чрез служебен имейл (incidents@e-gov.bg или конкретен адрес на сектора, ако е оповестен). За субекти под надзора на секторни регулатори (БНБ, КФН, КРС, ИАМО) уведомлението може да тече и през съответния регулатор. Подгответе си списък в писмен вид с адресите и URL на портала, защото в нощта на инцидента няма да искате да търсите. Винаги запазвайте автоматично потвърждение за получаване и screenshot на изпратената форма.
3. Какво ако установим инцидента в петък вечерта - тече ли броячът през уикенда?
Да. Сроковете в чл. 22 са в часове, не в работни дни. Това е една от причините инцидентната политика да предвижда наличност 24/7 за периода на инцидента и резервен говорител. Ако T0 е петък 22:00, ранното предупреждение е до събота 22:00, а 72-часовият доклад е до понеделник 22:00. Никаква отстъпка за уикенда. Подгответе своя екип ясно за това - включете го в задължителния тренинг при tabletop упражнения.
4. Трябва ли да докладваме „почти-инцидент" или само потвърдени значими инциденти?
Чл. 22 от ЗКС изисква уведомяване за значими инциденти. „Почти-инциденти" (near miss) не са задължителни за доклад, но е силно препоръчително да ги впишете във вътрешния регистър и да обсъждате между сектора при доброволни обмени. Това подкрепя кооперативната позиция на компанията. Внимавайте обаче: ако „почти-инцидентът" е бил всъщност значим (например ransomware, който сте успели да блокирате преди шифроването), той вече е значим инцидент по дефиниция и трябва да бъде докладван. Когато сте на ръба - докладвайте.
5. Какъв е рискът, ако ангажираме външни форензици - те знаят повече, отколкото бихме искали ние да знаем
Външни форензици са почти винаги нетен плюс. Те дават независимо мнение, дисциплина в доказателствата и кредит при регулатора - не обратното. Ключът е в договора: ясно дефиниран обхват, конфиденциалност, без задължения да докладват директно на регулатора без вашето знание. На практика всички професионални форензици в България (Atlant Security, eSec, КонтролСофт и подобни) работят с тази дисциплина. Изборът на форензичен партньор се прави СЕГА, преди инцидента - не в 23:00 в нощта, когато опции са малко.
6. Какво да правим, ако в средата на 72-часовия период установим, че инцидентът е по-голям, отколкото смятахме?
Изпратете междинно актуализиране до ОЕЦ незабавно, без да чакате формалния 72-часов срок. Темата на имейла: „Актуализация по инцидент [идентификатор] - значимо разширяване на обхвата". 2-3 параграфа с новите факти. След това продължавате към подробния доклад в 72-часовия срок с пълна структура. Това поведение е смекчаващ фактор - регулаторът ви оценява за проактивната комуникация. Опитът да „запазите за подробния доклад" е грешка - изненадите никога не са добра комуникация с регулатор.
Готови шаблони и 24/7 реакция при инцидент
Нашата услуга „Реакция при инциденти 24/7" включва: предварително адаптиран към вашата компания пакет от шаблоните (24-часов, 72-часов, окончателен), tabletop упражнение в рамките на 2 седмици след старта, спешен телефон с гарантирана реакция до 30 минути, координация с ОЕЦ и КЗЛД от наш специалист по време на реален инцидент.
Заявете услугата за реакция при инцидентиПърва 30-минутна консултация без задължение. Алтернативно - вижте готовност по ЗКС за пълна подготовка преди първата проверка.
Александър Свердлов
Основател на Atlant Security. Автор на 2 книги за информационна сигурност, лектор по киберсигурност на най-големите конференции по киберсигурност в Азия и панелист на конференция на ООН. Бивш член на екипа за консултации по сигурността на Microsoft, външен консултант по киберсигурност в Емиратската корпорация за ядрена енергия.