Докладване на инцидент по ЗКС: шаблони за 24 и 72 часа и комуникация с ОЕЦ

Сценарий 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. Разследването установява инцидент отпреди седмици

T0 е моментът, в който разследването установява, че е настъпил инцидент, а не моментът на самото събитие. Ако при разследване установите злоупотреба с акаунт отпреди 6 седмици, това не означава автоматично, че сте пропуснали 24-часовия срок. В този случай началният момент е установяването на инцидента. Документирайте откритието и го съобщете своевременно.

Шаблон 1

Ранно предупреждение за инцидент по чл. 22 от ЗКС

До: Оперативен експертен център, Държавна агенция „Електронно управление“ (incidents@e-gov.bg или официалния портал)

От: [Име на компанията], ЕИК [НОМЕР], [Адрес]

Дата и час на изпращане: [ДД.ММ.ГГГГ ЧЧ:ММ часа българско време]

Категория субект: [съществен / важен]

Сектор по приложение N от ЗКС: [например: енергетика / здравеопазване / банково дело / ИКТ услуги]

1. Първоначално описание

На [ДД.ММ.ГГГГ] в [ЧЧ:ММ] часа българско време установихме [кратко описание в 1-2 изречения, например: „признаци за неразрешен достъп до файлов сървър и криптиране на файлове“]. Към момента разследваме инцидента и ограничаваме последствията от него.

2. Преценка дали инцидентът е значим

[Изберете една: значим (с обосновка от 1 изречение, например: „поради потенциалното засягане на услуга, която обслужва над N клиенти/потребители“) / към момента не сме в състояние да преценим значимостта]

3. Подозрение за злонамерено действие

[Изберете една: да, с първоначални индикации за [тип, например: ransomware / неоторизиран достъп / DDoS] / към момента не можем да потвърдим или отхвърлим]

4. Възможно трансгранично или междусекторно въздействие

[Изберете една: не се установяват към момента / има индикации за засягане на партньори в [държава или сектор] - подробности ще бъдат предоставени в 72-часовия доклад]

5. Контактно лице

[Име, длъжност, имейл и мобилен телефон за денонощна връзка по време на инцидента]. Заместник: [същите данни].

6. Следващи стъпки

Ще предоставим подробен доклад по чл. 22 в рамките на 72 часа от узнаването за инцидента. Оставаме на разположение за въпроси и координация по време на разследването.

Подпис: [Име, длъжност на лицето, оторизирано да представлява компанията или CISO с делегирани пълномощия]

Шаблон 2

Подробен доклад за инцидент в 72 часа по чл. 22 от ЗКС

Раздел A. Идентификация на субекта и инцидента

• Юридическо лице, ЕИК, адрес, сектор по ЗКС, категория (съществен/важен)
• Уникален вътрешен номер на инцидента, който се използва и в следващата кореспонденция
• Дата и час на запознаване (T0) - повторен от ранното предупреждение
• Дата и час на изпращане на текущия доклад
• Лице за контакт, заместник и часове за връзка

Раздел B. Подробно описание на инцидента

• Хронология в точни часове: T0 - X (първа индикация), T0 (потвърждение), T0 + N часа (ключови стъпки)
• Засегнати активи: списък със системи, мрежи, бази данни, локации
• Засегнати услуги: кои бизнес услуги са били прекъснати или влошени
• Първоначална оценка на категорията: ransomware / неоторизиран достъп / DDoS / изтичане на данни / друго
• Първоначална оценка на тежестта по вътрешна скала и обосновка

Раздел C. Оценка на въздействието

• Брой засегнати потребители или клиенти (или диапазон с обосновка, ако точното число още не е известно)
• Продължителност на нарушаването на услугата (текуща и прогнозна)
• Финансово въздействие към момента (приблизително)
• Засегнати лични данни: вид, обем, дали ще се подава отделно уведомление до КЗЛД
• Засегнати трети страни: партньори, доставчици, клиенти, общност
• Трансгранично въздействие: други държави членки, в които може да има засягане

Раздел D. Първопричина (предварителна)

• Какво е установено към 72-рия час: начин на проникване, конкретна уязвимост или грешка
• Какво още се разследва: хипотези и необходими проверки
• Външни експерти, ангажирани с разследването (ако има)

Раздел E. Ограничаване на инцидента и възстановяване

• Незабавни мерки (изолация на засегнати системи, смяна на пароли, ротация на токени, активиране на резервни системи)
• Краткосрочни мерки: възстановяване от резервно копие, преинсталиране и инсталиране на актуализации за сигурност
• Текущ статус на възстановяването с проценти и прогноза за пълно възстановяване
• Комуникация към засегнатите страни (клиенти, партньори, общественост)

Раздел F. Сътрудничество с други органи

• КЗЛД: подадено ли е уведомление, кога, референтен номер (ако са засегнати лични данни)
• МВР / ГД БОП: подаден ли е сигнал за компютърно престъпление, кога, преписка
• Други надзорни органи: БНБ / КФН / КРС / ИАМО в зависимост от сектора
• Уведомяване на другия НИС2 регулатор, ако е приложимо за трансгранично въздействие

Раздел G. План за следващи стъпки

• Срок за окончателен доклад (1 месец от T0 или по-кратък, ако анализът приключи по-рано)
• Допълнителни действия: независимо техническо разследване, преглед на сходни системи, обучение
• План за последваща комуникация и уведомяване при нови съществени обстоятелства

Прикачени документи: хронология във вид на таблица (Excel/PDF), технически индикатори (хешове, IP адреси, домейни - в STIX или CSV формат, ако е приложимо), оторизация на подписалия. Внимавайте за чувствителни данни - предоставяйте обезличени версии, ако не е изрично поискано конкретно лице.

Раздел H. Окончателна първопричина

С техническа точност. Конкретна уязвимост (CVE, ако е приложимо), конкретен компрометиран акаунт, конкретна неработеща контрола. Не общи изрази като „слаба сигурност“, а „на 12 март устройство Х получи фишинг имейл, потребителят X кликна, ние нямахме MFA на M365, акаунтът бе компрометиран, в следващите 4 часа бяха изтеглени Y файла“. Колкото по-конкретно, толкова по-добре.

Раздел I. Окончателно въздействие

Посочете окончателните данни: брой засегнати записи и потребители, продължителност на прекъсването и финансово отражение, включително загубени приходи и разходи за разследване и уведомяване. Отбележете колко лица са уведомени, как са реагирали и има ли искания за обезщетение или заведени искове.

Раздел J. План за коригиращи мерки

За всяка мярка посочете кой установен проблем отстранява, кой отговаря за нея, до кога трябва да е изпълнена и как ще бъде проверен резултатът. Например вместо „ще подобрим обучението“ запишете: „Обучение за разпознаване на фишинг за всички служители до 30 април, с минимален резултат от теста 80%; отговорник: CISO“.

Раздел K. Поуки за компанията

Опишете промените в политиките, процедурите и защитните мерки след инцидента. Посочете какво е докладвано на управителния съвет и какви решения е взел той, включително промени в бюджета, екипа или отговорностите.

1. Един говорител, един имейл, един телефон

Определете едно основно лице за връзка с ОЕЦ и негов заместник. Всички съобщения трябва да минават през тях, за да се избегнат противоречия и повторно изпращане на остаряла информация. Обикновено тази роля се поема от CISO или координатора на инцидента, докато техническият екип работи по разследването.

2. Само факти, ясно разграничени от хипотези

„Журналът показва влизане в 03:14 ч. от IP адрес X“ е факт. „Предполагаме, че причината е XYZ“ е хипотеза. Разграничавайте ги ясно: „Установени факти: …“ и „Хипотези, които проверяваме: …“. Когато представите предположение като факт и то се окаже невярно, подкопавате доверието в доклада.

3. Никаква вина към доставчик в първите 72 часа

Дори ако сте 80% сигурни, че причината е компрометиран доставчик, не го заявявайте в първите 72 часа. Подгответе тази позиция за окончателния доклад с категорични доказателства. Преждевременното прехвърляне на вина се възприема като опит да се измъкнете от собствената си отговорност и подсилва впечатлението за слаб надзор върху веригата на доставки (което е отделен инкриминируем пропуск по чл. 21). Ако не искате да водите това в таблици, NIS2 модулът на Venvera свързва всяко изискване с доказателствата за изпълнението му.

4. Прозрачност за това, което не знаете

Ако още не разполагате с информацията, кажете това ясно и посочете кога ще я предоставите. Например: „В момента проверяваме този въпрос и ще отговорим до 18:00 утре“. Не запълвайте липсите с предположения.

5. Писмено след всеки разговор

След разговор или среща с ОЕЦ изпратете кратко писмено обобщение: „Благодарим за разговора в 14:00 на ДД.ММ. Уточнихме следното: 1) ... 2) ... 3) ... Моля, потвърдете дали сме отразили правилно договореното“. Така намалявате риска от различни тълкувания впоследствие.

Грешка 1. Забавяте ранното предупреждение без обосновка

Изпращате го на 27-я час с обяснение „чакахме повече данни“. Това е най-честата причина за първоначална глоба. Срокът от 24 часа не е препоръка - той е законов. Ако наистина не сте могли в първите 24 часа, изпратете обяснението в 24-я час, не на 27-я. Ако не искате да водите това в таблици, NIS2 модулът на Venvera връзва всяко изискване с доказателството за него.

Грешка 2. Посочвате неверен начален момент (T0)

Ако уведомлението посочва узнаване в 14:00 ч., а записът на SOC показва потвърждение в 09:30 ч., несъответствието трябва да бъде изяснено. Поддържайте точна хронология, подкрепена с журнали и записи за действията.

Грешка 3. Пропускате съществена информация

Не споменавате, че същата група акаунти беше компрометирана преди 6 месеца и тогава не сте докладвали. Регулаторът ще го намери - чрез ваши служители, чрез доставчик, чрез данни от партньор. Когато го намери, добавя сериозно наказание за „предходен неотчетен пропуск“.

Грешка 4. Прехвърляте вината към доставчик в първите 72 часа

„Те ни вкараха ransomware.“ Дори ако е технически вярно, преждевременното заявяване отваря тема „как точно сте проверявали сигурността на този доставчик?“ - тема, от която не искате да започвате с дефанзивна позиция. Първо подгответе доказателствата.

Грешка 5. Окончателен доклад без конкретен план

„Ще подобрим обучението и ще въведем повече контроли.“ Това не е план. Регулаторът чете окончателен доклад като одиторски доклад - конкретни мерки, конкретни срокове, конкретни отговорници, конкретни критерии за успех. Без тях докладът сигнализира, че компанията не е разбрала какво се е случило.

Грешка 6. Не уведомявате КЗЛД, когато трябва

Ransomware с потенциално засягане на лични данни почти винаги изисква уведомление до КЗЛД в 72 часа. Често компании уведомяват само ОЕЦ, мислейки, че едното покрива другото. Не покрива - двата режима текат паралелно и са независими. Ако не уведомите КЗЛД, при последваща проверка ще получите второ, отделно наказателно постановление по GDPR.

Грешка 7. Без уведомяване на засегнатите получатели на услугата

Ако инцидентът „значително влияе“ върху услугата, чл. 22 ал. 4 от ЗКС задължава да информирате получателите на услугата и да им предложите мерки за защита. Това задължение се пропуска често. Регулаторът проверява не само дали сте уведомили него, но и дали сте уведомили клиентите си - често по индиректен начин (чрез жалби или след сигнал от потребител).

1. Кой точно има право да подпише ранното предупреждение?

По закон - лицето, оторизирано да представлява юридическото лице, или лице с делегирани от УС пълномощия. На практика това почти винаги е CISO или ИТ директорът с писмена делегация от изпълнителния директор, заведена в деловодството. Подгответе тази делегация СЕГА, не в нощта на инцидента. Тя е едно изречение: „Делегирам пълномощия на [Име, длъжност] да подписва уведомления по чл. 22 от ЗКС от името на компанията“ с дата, подпис и печат. Без такава делегация инцидентният имейл, подписан от ИТ директора, може да бъде отхвърлен формално, което резултира в закъснял доклад.

2. Кой е официалният канал за изпращане на доклада?

Към момента ОЕЦ приема уведомления чрез официалния портал на ДАЕУ и чрез служебен имейл (incidents@e-gov.bg или конкретен адрес на сектора, ако е оповестен). За субекти под надзора на секторни регулатори (БНБ, КФН, КРС, ИАМО) уведомлението може да тече и през съответния регулатор. Подгответе си списък в писмен вид с адресите и URL на портала, защото в нощта на инцидента няма да искате да търсите. Винаги запазвайте автоматично потвърждение за получаване и screenshot на изпратената форма.

3. Ако установим инцидента в петък вечерта, сроковете текат ли през почивните дни?

Да. Сроковете по чл. 22 се изчисляват в часове, а не в работни дни. Ако T0 е петък в 22:00, ранното предупреждение е до събота в 22:00, а 72-часовият доклад до понеделник в 22:00. Осигурете денонощна връзка и заместник на отговорника и проверете организацията чрез учение.

4. Трябва ли да докладваме „почти-инцидент“ или само потвърдени значими инциденти?

Чл. 22 от ЗКС изисква уведомяване за значими инциденти. „Почти-инциденти“ (near miss) не са задължителни за доклад, но е силно препоръчително да ги впишете във вътрешния регистър и да обсъждате между сектора при доброволни обмени. Това подкрепя кооперативната позиция на компанията. Внимавайте обаче: ако „почти-инцидентът“ е бил всъщност значим (например ransomware, който сте успели да блокирате преди шифроването), той вече е значим инцидент по дефиниция и трябва да бъде докладван. Когато сте на ръба - докладвайте.

5. Какви са ползите и рисковете при привличане на външни специалисти за разследването?

Външните специалисти могат да осигурят независим анализ и надеждно събиране на доказателства. Уточнете в договора обхвата, поверителността и начина на комуникация с регулатора. Професионалните екипи, включително Atlant Security, eSec и КонтролСофт, работят с такива договорни условия. Изберете партньора предварително, когато имате време да сравните предложенията.

6. Какво да правим, ако в средата на 72-часовия период установим, че инцидентът е по-голям, отколкото смятахме?

Уведомете ОЕЦ веднага за новите факти, без да чакате изтичането на 72 часа. Използвайте тема „Актуализация по инцидент [идентификатор]: разширяване на обхвата“ и опишете промяната в 2-3 абзаца. След това включете информацията в подробния доклад, който се подава в първоначалния срок.