Политики и документи по NIS2: какво трябва да има написано една българска фирма

Законът за киберсигурност (ЗКС) не казва „имайте политика за пароли“. Той изброява в чл. 22, ал. 2 дванадесет области, в които съществените и важните субекти трябва да имат подходящи и пропорционални мерки, и в чл. 21 задължава управителния орган да ги одобри и да следи за прилагането им. Проверяващият или одиторът на клиента ви ще преведе тези области в документи и доказателства. Тук правим превода предварително: кой документ покрива коя точка, кой го подписва и как да го поддържате жив, вместо да събира прах в папка.

Първият документ: решението на управителния орган

Преди политиките идва протоколът. По чл. 21, ал. 1 ЗКС управителните органи одобряват мерките за управление на риска и следят за прилагането им. Това се доказва с решение на управителния съвет, съвета на директорите или управителя (при ЕООД), в което е записано:

• кой е отговорен за киберсигурността във фирмата и пред кого се отчита;
• че мерките по чл. 22 ЗКС се одобряват в приложения списък, с бюджет и срокове;
• колко често ръководството получава отчет за състоянието и инцидентите;
• графикът на обученията по чл. 21, ал. 2 ЗКС за самите членове на управителния орган (на всеки две години) и за служителите (чл. 21, ал. 3 ЗКС).

Личната глоба за управител при нарушение на чл. 21 е от 500 до 5000 евро (чл. 29, ал. 4 ЗКС). Протоколът е документът, който показва, че ръководството е свършило своята част.

Дванадесетте области и документите зад тях

Редът следва чл. 22, ал. 2 ЗКС. Имената на документите са препоръка, важен е обхватът.

1. Политики за анализ на риска и сигурност на информационните системи

Политика за информационна сигурност (рамковият документ, две до четири страници, подписан от ръководството) и методика и регистър на рисковете: кои са активите, какви са заплахите, каква е оценката, кой носи риска, какво се прави по него. Регистърът се преглежда поне веднъж годишно и след всеки значителен инцидент. Без регистър на рисковете не можете да докажете пропорционалност, а чл. 22, ал. 1 ЗКС изисква мерките да съответстват на риска.

2. Действия при инцидент

План за реакция при инциденти с ясна дефиниция какво е значителен инцидент за вашата фирма, роли и телефони извън работно време, стъпки по ограничаване и възстановяване, и отделна процедура за докладване по чл. 23 ЗКС: ранно предупреждение до СЕРИКС до 24 часа от установяването, уведомление до 72 часа, междинен доклад по искане, окончателен доклад до един месец след уведомлението, плюс уведомяване на засегнатите получатели на услугата. Процедурата трябва да може да се изпълни в неделя в 3 часа сутринта от човека на смяна. Към нея върви дневник на инцидентите, в който се записват и малките, недокладвани случаи.

3. Непрекъснатост на дейността, бекъп и управление на кризи

План за непрекъснатост и възстановяване: кои процеси са критични, колко време можете да работите без тях, в какъв срок трябва да се възстановят данните и системите, кой взема решения в криза и как се комуникира с клиенти и органи. Политика за резервни копия с честота, местоположение (включително копие извън основната площадка и копие, което не може да се промени от атакуващ), срок на съхранение и, най-важното, протоколи от тестове за възстановяване. Бекъп, който не е възстановяван на тест, е предположение. Вижте и Архивиране и възстановяване след бедствие.

4. Сигурност на веригата за доставка

Политика за доставчици и регистър на доставчиците с оценка на критичността: кой има достъп до системите ви, кой държи ваши данни, кой може да спре дейността ви. Чл. 22, ал. 3 ЗКС изисква да вземете предвид уязвимостите и практиките за киберсигурност на всеки пряк доставчик, включително процедурите му за сигурно разработване. Това се доказва с анкета за оценка на доставчик и със стандартни договорни клаузи: уведомяване при инцидент в определен срок, MFA и обновления, право на одит, връщане или унищожаване на данните при прекратяване, подизпълнители само със съгласие. Клаузите са причината малки фирми извън обхвата да получават изисквания по NIS2 от клиентите си.

5. Сигурност при придобиване, разработване и поддръжка, управление на уязвимости

Политика за управление на уязвимости и обновления: откъде научавате за уязвимости, в какъв срок се прилагат критичните и останалите корекции, какво става със системи, които не могат да се обновят (изолация, компенсиращи мерки, срок за подмяна), как се тества преди пускане. Ако разработвате софтуер, добавете стандарт за сигурна разработка и процес за приемане на уведомления за уязвимости отвън. Доказателства: отчети от сканиране, списък на изключенията с подпис.

6. Оценка на ефективността на мерките

Програма за вътрешни проверки и одити: какво се проверява, от кого, колко често, как се докладва на ръководството. Тук влизат годишният преглед на политиките, резултатите от тестове за проникване и фишинг симулации, и проследяването на констатациите до затваряне. Чл. 22, ал. 4 ЗКС изисква при установен пропуск да се предприемат коригиращи мерки, затова всеки одит трябва да завършва със списък от действия с отговорник и срок.

7. Основни киберхигиенни практики и обучение

Програма за обучение и осведоменост с три нива: управителен орган (на всеки две години по чл. 21, ал. 2 ЗКС), всички служители (при постъпване и периодично) и роли с повишен риск (администратори, финанси, обслужване на клиенти). Задължителни доказателства: присъствени списъци или записи от платформата, материалите, тестове, резултати от фишинг симулации. Обучение без документи не съществува за проверяващия. Вижте Обучение на служители.

8. Криптография и криптиране

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

9. Човешки ресурси, контрол на достъпа и управление на активи

Три документа: политика за контрол на достъпа (минимално необходими права, отделни администраторски акаунти, преглед на правата поне веднъж годишно, незабавно спиране при напускане), процедура за персонала (проверки при назначаване според ролята, споразумения за конфиденциалност, процес при постъпване и напускане със списък какво се дава и какво се връща) и регистър на активите: сървъри, работни станции, мобилни устройства, мрежово оборудване, облачни услуги, лицензи, данни, с отговорник за всеки запис. Регистърът на активите е основата на регистъра на рисковете и на управлението на уязвимостите, затова го правете първи.

10. Многофакторно удостоверяване и защитени комуникации

Стандарт за удостоверяване: за кои системи MFA е задължителна (всеки външен достъп, имейл, администраторски акаунти, облачни конзоли), какви методи се допускат, какво става с изключенията и в какъв срок се затварят. Към него: правила за защитени канали за гласова, видео и текстова комуникация и за спешна комуникация вътре във фирмата, когато е целесъобразно, както гласи чл. 22, ал. 2, т. 10 ЗКС.

11. Управление на измененията

Процедура за управление на промените: кои промени в системите подлежат на одобрение, кой одобрява, как се тества, как се връща назад при проблем, къде се записва. Доказателство: дневник на промените, съгласуван с регистъра на активите. Най-често липсващият документ при малки и средни фирми, и най-честата причина за инцидент „след ъпдейта“.

12. Специфични изисквания за критичните субекти

Ако фирмата е установена като критичен субект по Директива (ЕС) 2022/2557, чл. 22, ал. 2, т. 12 ЗКС добавя мерките и задълженията за докладване за тази категория. Те се оформят като допълнение към плана за реакция и към плана за непрекъснатост. За повечето фирми тази точка остава празна и това се записва изрично.

Кой подписва какво

Как да ги държите живи

• Версии и дати. Всеки документ има номер на версия, дата, автор и одобряващ. Старите версии се пазят. Проверяващият чете историята на промените като доказателство, че системата работи.
• Годишен преглед по календар. Един ден в годината за преглед на всички политики, регистъра на рисковете и регистъра на доставчиците, с протокол. Плюс извънреден преглед след значителен инцидент или след голяма промяна в системите.
• Папка с доказателства. За всяка политика има място, където се трупат доказателствата за прилагане: протоколи от тест на бекъп, отчети от сканиране, списъци от обучения, прегледи на достъпа, дневник на инцидентите. Политиката без тази папка е намерение.
• Един собственик на документ. Документ с „общ“ собственик няма собственик.
• Език, който хората разбират. Политиката за служителите е две страници на български, не превод на стандарт. Техническите стандарти са отделни документи за хората, които ги прилагат.

Типични грешки

• Копиран шаблон. Политика, в която пише „информационен офицер“ и се споменават системи, които фирмата няма. Проверяващият го вижда на втора страница и оттам нататък не вярва на нищо.
• Няма доказателства. Политиката за бекъп е перфектна, но никой не може да покаже протокол от възстановяване. Политиката за достъп изисква годишен преглед, а преглед не е правен.
• Обучението не е документирано. „Говорихме им на общото събрание“ не е обучение по чл. 21 ЗКС.
• Процедурата по чл. 23 ЗКС е само на хартия. Никой не знае образеца, кой е СЕРИКС за сектора и кой звъни в 24-часовия срок, ако отговорникът е в отпуск.
• Доставчиците не са в системата. Външната ИТ фирма има администраторски достъп до всичко, а в договора няма ред за сигурност.
• Документи за одита, а не за фирмата. Ако екипът не ги ползва, те не управляват риск. Правилото е просто: ако никой не е отварял документа от година, или е излишен, или не се спазва.

Как ги чете проверяващият или клиентът

Редът е почти винаги един и същ. Първо решението на ръководството и политиката за сигурност: има ли собственик и отговорност. После регистърът на активите и регистърът на рисковете: знае ли фирмата какво защитава. След това плана за инциденти и доказателствата, че процедурата по чл. 23 ЗКС е изпробвана. После бекъпът и протоколите от възстановяване. Чак след това политиките за достъп, MFA, уязвимости и доставчици, вече с конкретни въпроси: „покажете ми прегледа на достъпа от тази година“, „покажете ми кой има външен достъп без MFA“, „покажете ми договора с ИТ доставчика“. При одит от голям клиент редът е същият, но с акцент върху точка 4 и върху доказателствата за обучение. Подредете папката в този ред и половината работа на проверката е свършена.

Пълното ръководство по NIS2 е в NIS2 Директива: пълно ръководство за български бизнес. Ако не сте сигурни дали попадате в обхвата, започнете от Оценка на готовността за NIS2. За написването и внедряването на пакета от документи, съобразен с реалните ви системи, вижте Съответствие и регулации, а за частта с инцидентите, Реакция при инциденти.

Често задавани въпроси

Колко документа са нужни минимум?

Законът не брои документи, а области. За средна фирма практичният минимум е решение на управителния орган, политика за информационна сигурност, регистър на активите, регистър на рисковете, план за инциденти с процедурата по чл. 23 ЗКС, план за непрекъснатост и бекъп, политика за достъп и MFA, политика за доставчици с договорни клаузи, политика за уязвимости и промени, програма за обучение. Останалите области могат да са раздели в тези документи.

Може ли ISO 27001 да замести всичко това?

Система по ISO/IEC 27001 покрива голяма част от областите по чл. 22 ЗКС и дава готовата структура с версии, одити и доказателства. Сертификатът обаче не замества специфичните задължения по ЗКС: процедурата за докладване до СЕРИКС в сроковете по чл. 23, обучението на управителния орган по чл. 21 и данните в регистъра по чл. 6. Ако имате ISO 27001, добавете тези три неща и съпоставителна таблица към 12-те точки.

Ние сме малка фирма извън обхвата, но клиент ни иска „политики по NIS2“. Кои?

Обикновено клиентът изпълнява своята точка 4 (чл. 22, ал. 2, т. 4 ЗКС) и иска да види, че сте управляем риск: политика за сигурност, MFA на външния достъп, бекъп с тест, план за инциденти с ангажимент да го уведомите в срок, обучение на хората, които работят по неговите системи. Пакет от пет документа с доказателства е достатъчен за повечето такива искания.

Колко често трябва да се преглеждат?

Законът не задава честота за самите документи, но изисква мерките да съответстват на риска и да се оценява ефективността им (чл. 22, ал. 1 и ал. 2, т. 6 ЗКС). Годишен преглед с протокол плюс извънреден преглед след значителен инцидент или голяма промяна е практиката, която проверяващите приемат без въпроси.