Всяка сериозна рамка за киберсигурност започва с един и същ документ: писмена политика за сигурност на информацията (ISSP), одобрена от ръководството. NIS2 я поставя на първо място сред мерките за управление на риска по член 21, а ISO/IEC 27001 я превръща в изискване по клауза 5.2. Security Policy Express води европейското МСП през насочен онлайн семинар и генерира структурирана първа версия от свое име: работен проект за вашите консултанти, а не правен съвет.
Отговорът за една минута, за управител, който не е ИТ специалист.
Политиката за сигурност на информацията (често съкращавана ISSP, а на френски PSSI) е документът, в който ръководството декларира в писмена форма как дружеството защитава своята информация и ИТ системи, кой за какво отговаря и кои правила всеки трябва да спазва. В началото е кратка (декларация за политиката, подписана от ръководството), а отдолу е по-подробна (правила по отделни теми и оперативни процедури). Тя не е техническо ръководство: това е управленско решение, записано на хартия, към което може да се препраща останалата част от работата по сигурността.
ISO/IEC 27001 възлага политиката на „най-високото ръководство“, а NIS2 член 20 изисква от управителните органи на обхванатите субекти да одобряват мерките за управление на риска в киберсигурността и да упражняват надзор върху тяхното изпълнение. Вашият ИТ доставчик може да помогне за изготвянето ѝ; собственик може да бъде само ръководството.
Източници: Директива (ЕС) 2022/2555, чл. 20 · ISO/IEC 27001:2022, клауза 5Добрата практика различава три нива. Политиката определя принципите и отговорностите. Политиките по теми (контрол на достъпа, резервно копиране, криптография, доставчици...) ги превеждат по области. Процедурите описват кой какво прави, стъпка по стъпка, когато нещо се случи. Контрол 5.1 от ISO/IEC 27001 изрично споменава както политиката, така и политиките по теми.
Източник: ISO/IEC 27001:2022, Приложение A, контрол 5.1Никой европейски текст не налага един единствен образец. NIS2 член 21(1) изисква мерки, които са „подходящи и пропорционални“, като се отчитат експозицията на субекта към рискове, размерът му, както и вероятността и тежестта на инцидентите. Производител с 40 служители и болница няма да напишат една и съща политика и не трябва да го правят.
Източник: Директива (ЕС) 2022/2555, чл. 21(1)Политика, написана веднъж и прибрана в папка, не защитава нищо. Рамките очакват тя да бъде съобщена на персонала, потвърдена от него и преразглеждана на планирани интервали и след значителни промени. Затова вашата политика трябва да включва от самото начало собствен цикъл на преглед, собственик и история на версиите.
Източник: ISO/IEC 27001:2022, клауза 5.2 и контрол 5.1Повечето малки и средни дружества вече прилагат някои правила за сигурност. Обикновено липсва писмената, одобрена и последователна версия, която регулатор, одитор, застраховател или голям клиент действително може да прочете.
NIS2 разширява европейските правила за киберсигурност към много средни предприятия в сектори като производство, храни, управление на отпадъци, транспорт или цифрови услуги. За обхванатите субекти „политиките за анализ на риска и за сигурност на информационните системи“ са първата мярка, изброена в член 21(2).
NIS2 член 21(2), буква г) изисква обхванатите субекти да управляват сигурността на веригата на доставките, включително аспектите на сигурността в отношенията с преките доставчици. Дори да сте извън обхвата, по-големите ви клиенти може да поискат да видят писмена политика за сигурност в своите въпросници за доставчици.
Писането на политика означава отговор на много въпроси наведнъж: кои са критичните ни активи, кой решава, какво правим при атака с ransomware, колко време пазим резервните копия? Без структура упражнението обикновено се отлага, тримесечие след тримесечие.
Изтеглените шаблони често описват организация със служител по сигурността, център за оперативна сигурност и отделен бюджет. Документ, който не отговаря на реалността, е по-лош от никакъв: няма да се прилага, а одиторът ще забележи разликата между хартията и практиката.
Един и същ документ отговаря едновременно на няколко текста. Ето какво казва всеки от тях, с връзка към официалния източник. Всяка препратка води към официалния източник; националните транспонирания може да добавят подробности.
Съществените и важните субекти трябва да прилагат „подходящи и пропорционални технически, оперативни и организационни мерки“ за управление на рисковете за киберсигурността, на основата на подход, обхващащ всички опасности. Списъкът в член 21(2) започва с „а) политики за анализ на риска и за сигурност на информационните системи“. Член 20 добавя, че управителните органи одобряват тези мерки, упражняват надзор върху изпълнението им и преминават обучение.
Клауза 5.2 изисква най-високото ръководство да установи политика за сигурност на информацията, която е подходяща за целта на организацията, осигурява рамка за целите в областта на сигурността и включва ангажименти за изпълнение на приложимите изисквания и за постоянно подобряване. Тя трябва да бъде документирана, съобщена вътрешно и предоставена на заинтересованите страни, когато е уместно. Контрол 5.1 от Приложение A разширява това до политики по теми, одобрени, публикувани, потвърдени и преразглеждани.
Член 24(2) посочва, че когато е пропорционално на дейностите по обработване, мерките на администратора включват „прилагането на подходящи политики за защита на данните“. Член 32 изисква подходящи технически и организационни мерки за осигуряване на ниво на сигурност, съответстващо на риска. Политиката за сигурност е естественото място за документиране на тези мерки.
За някои цифрови субекти (например доставчици на облачни изчисления, центрове за данни и управлявани ИТ услуги) Комисията прие подробни технически и методологически изисквания. Приложението му започва с „политика за сигурността на мрежовите и информационните системи“ и описва как тя се одобрява, документира и преразглежда. Дори дружеството ви да не е от тези видове субекти, приложението е полезна публична справка за структуриране на политиката.
За финансовите субекти DORA изисква да разработят и документират политика за сигурност на информацията, определяща правилата за защита на наличността, автентичността, целостта и поверителността на данните, информационните активи и ИКТ активите. Ако сте ИКТ доставчик на банка или застраховател, очаквайте клиентът ви да попита как вашата собствена политика се съотнася с тях.
Националните агенции за киберсигурност публикуват безплатни насоки, върху които може да се изгради политиката. Във Франция ръководството на ANSSI за ИТ хигиена определя 42 основни мерки за лицата, отговорни за сигурността на информационната система на една организация. ENISA, Агенцията на ЕС за киберсигурност, публикува насоки в подкрепа на прилагането на NIS2 в целия Съюз.
Член 21(2) от NIS2 изброява десет минимални мерки. Точка (a) е самата политика, но добре изградената политика е и мястото, където другите девет намират своя собственик, правило и процедура. Така структурираме генерирания документ.
Декларацията за политиката, обхватът, ролите и методът, с който определяте и оценявате рисковете. Това е гръбнакът на документа.
Процедура за управление на инциденти: откриване, квалификация, ескалация, локализиране, уведомяване и извлечени поуки.
Управление на резервните копия, възстановяване след бедствие и управление на кризи, както го формулира директивата: кой решава, кое се възстановява първо, колко често се тестват резервните копия.
Правила за избор, договаряне и наблюдение на ИТ доставчици и доставчици на услуги, включително клаузите за сигурност, които очаквате от тях.
Как се избират и конфигурират нови системи, как се прилагат актуализации и как се обработват и оповестяват уязвимостите.
Политики и процедури за проверка, че мерките работят: показатели, вътрешни прегледи, учения и преглед от ръководството.
Ежедневните правила (пароли, актуализации, осведоменост относно фишинг) и план за обучение, включително за ръководството, както изисква член 20(2) за управителните органи.
Кога данните трябва да бъдат шифровани (лаптопи, резервни копия, предавания), кои протоколи са приемливи и кой управлява ключовете.
Постъпващи, преминаващи на друга длъжност и напускащи служители; кой получава кой достъп и кой го одобрява; инвентар на активите с техните собственици.
Къде се изисква многофакторно или непрекъснато удостоверяване и как се защитават гласовите, видео-, текстовите и аварийните комуникации.
Референциите към ISO/IEC 27001 са ориентировъчни съответствия, изготвени от нас, за да ви помогнат да се ориентирате, а не официално съответствие, публикувано от ISO или Европейската комисия. Източник за десетте мерки: Директива (ЕС) 2022/2555, чл. 21(2).
Генерираният документ следва структура, която одитор, застраховател или клиент ще разпознае. Всяка глава се попълва от отговорите, които давате в семинара, така че да описва вашето дружество, а не фиктивно такова.
Ангажиментът на ръководството, в няколко параграфа, подписан и датиран.
Кой решава, кой изпълнява, кой проверява, включително когато ИТ е външно възложен.
Прост, повторяем начин за идентифициране, оценка и третиране на рисковете.
Знаете какво защитавате, преди да решите как.
Кой до какво има достъп и как това се доказва.
Техническата основа, описана на ясен език.
Къде се изисква шифроване и как се управлява.
Сигурност в отношенията ви с ИТ доставчици и облачни услуги.
Човешкият фактор, от наемането до напускането.
Помещения, сървърни зали и оборудване извън офиса.
Принципите, подробно описани в процедурите по-долу.
Как политиката остава жива и вярна.
Политиката казва какво трябва да се случи; процедурата казва кой го прави, в какъв ред и с какъв запис. Тези четири са тези, които клиентите и одиторите най-често искат да видят, и тези, които са най-важни в деня, когато нещо се обърка.
От първия сигнал до заключителния доклад: как служителите докладват подозрително събитие, кой го квалифицира, кой изолира засегнатите системи, кой се свързва с ИТ доставчика, застрахователя и органите, и как се запазват доказателствата.
Как се заявява, одобрява, създава, променя и премахва акаунт. Процедурата обхваща постъпване, смяна на длъжност и напускане, администраторски акаунти, споделени и служебни акаунти, и периодичния преглед, при който ръководител потвърждава, че всеки човек все още се нуждае от достъпа, който има.
Как се описва, оценява по риск, одобрява, тества, извършва и при необходимост отменя промяна в производствена система (ново приложение, правило на защитната стена, голяма актуализация). В малко дружество може да е леко: достатъчни са кратък формуляр и регистър, при условие че съществуват и се използват.
Какво се архивира, колко често, къде, за колко време и преди всичко как се тества възстановяването. Процедурата свързва резервните копия с целите за възстановяване за всяка критична дейност и описва организацията при криза: кой решава, кой комуникира, кои системи се рестартират първи.
Политиката е написана за ръководството и ИТ. Политиката за допустима употреба (AUP) е написана за всички останали: краткият и четлив набор от правила, които всеки служител, временен работник или изпълнител приема, преди да използва ИТ на дружеството.
Използване на акаунти и пароли, електронна поща и съобщения, достъп до интернет, допустима ли е или не лична употреба, мобилни устройства и работа от разстояние, преносими носители, облачни услуги и инструменти с генеративен ИИ, поверителност, докладване на инциденти, както и какво може да наблюдава дружеството и защо.
Контрол 5.10 от ISO/IEC 27001 изисква правилата за допустима употреба на информацията и другите свързани активи да бъдат установени, документирани и приложени. Държането им в отделно приложение ги прави по-лесни за четене, подписване, актуализиране и прилагане към трудовите документи.
Когато AUP споменава регистриране или наблюдение на дейността на служителите, важи законодателството за защита на данните: служителите трябва да бъдат информирани (ОРЗД чл. 13), а държавите членки могат да приемат по-специфични правила за трудовия контекст (ОРЗД чл. 88). Органи за защита на данните, като CNIL, публикуват насоки за това какво е допустимо.
Превръщането на AUP в задължителен за служителите може да изисква национални формалности. Във Франция, например (да се потвърди с вашия консултант спрямо Кодекса на труда), правила от този вид обикновено се прилагат като приложение към правилника за вътрешния ред (règlement intérieur), който следва процедура, определена от Кодекса на труда, включително консултация с представителите на служителите. Проверете правилата за вашата страна с вашия консултант.
Източници: ISO/IEC 27001:2022, A.5.10 · Регламент (ЕС) 2016/679, чл. 13, 88 · CNIL · Légifrance, Кодекс на труда на Франция, чл. L1321-4 и L1321-5.
Политиката описва дружество, което се променя: нови служители, нов софтуер, нови доставчици, нови заплахи. Рамките, които цитираме, обикновено очакват тя да се актуализира. Генерираният документ включва собствен календар за преглед, собственик и таблица на версиите.
Първата версия се одобрява от ръководството, датира се и се версира. Според NIS2 член 20(1) управителните органи на обхванатите субекти одобряват мерките за управление на риска в киберсигурността; според клауза 5.2 от ISO/IEC 27001 най-високото ръководство установява политиката.
Политиката се публикува вътрешно; политиката за допустима употреба се потвърждава от всеки потребител. ISO/IEC 27001 контрол 5.1 очаква политиките да бъдат съобщени на съответния персонал и заинтересовани страни и да бъдат потвърдени от тях.
ISO/IEC 27001 контрол 5.1 изисква преглед на планирани интервали и при настъпване на значителни промени. Годишният преглед е разумна стойност по подразбиране за МСП; Регламент за прилагане (ЕС) 2024/2690 също определя рамката за преглед на политиката за видовете цифрови субекти, които обхваща.
Сериозен инцидент, сливане, нов обект, преход към облака или нова регулация са все причини да се отвори отново документът, без да се чака годишнината. Извлечените поуки от инцидентите влизат в следващата версия.
Таблица на версиите, регистър на одобренията, списък на промените, потвърждения. В деня, в който одитор, застраховател или клиент поиска, тази история е това, което показва, че политиката се прилага, а не само е написана. ISO/IEC 27001 клауза 7.5 урежда тази документирана информация.
Security Policy Express е замислен като инструмент за самообслужване. Вие контролирате съдържанието; инструментът предоставя структурата, въпросите и препратките.
Кратък тест пита за вашия сектор, размер, дейности и клиенти и ви казва дали NIS2 вероятно се прилага към вас, кои други текстове може да са уместни и кои части от политиката са най-важни във вашата ситуация. Той ви насочва към официалните инструменти на вашия национален орган за окончателен отговор.
Отговаряте със собствени думи на поредица от насочващи въпроси, глава по глава: за вашата организация, критичните ви дейности, ИТ доставчика ви, резервните копия, как се справяте с напускания, какво бихте направили при ransomware. Всеки въпрос обяснява защо се задава и към кой член или контрол се отнася. Можете да спрете и да продължите по всяко време.
Инструментът генерира политиката, четирите процедури и приложението за допустима употреба от името на вашето дружество, въз основа на вашите отговори. Когато даден отговор липсва, документът го казва изрично, вместо да запълни празнотата с общ текст. Резултатът е работен проект, който трябва да бъде прегледан и валидиран от вашите собствени консултанти (адвокат, ИТ доставчик, служител по защита на данните) преди одобрение от ръководството.
Ако искате помощ, за да обсъдите критично отговорите си, да адаптирате документа към конкретен контекст или да се подготвите за одит, можете да поискате подкрепа от партньорски консултант. Тази стъпка е незадължителна: пътят на самообслужване е завършен и без нея.
Важно: генерираният документ е работна основа. Той не представлява правен съвет и сам по себе си не прави дружеството ви съответстващо на NIS2, ISO/IEC 27001, ОРЗД или на който и да е национален закон. Съответствието зависи от това, което действително прилагате, и остава ваша отговорност.
Три градивни елемента, генерирани заедно от един и същ семинар. Наличността и условията ще бъдат обявени при старта.
Основният документ, подписан от ръководството.
Това, което прави политиката работеща.
За да се ориентирате в текстовете.
Две положения не трябва да се смесват: правно задължение за дружествата в обхвата на NIS2 (или DORA) и силно препоръчана добра практика за всички останали.
NIS2 се прилага по принцип към публични или частни субекти от вид, посочен в приложения I или II, които са средни предприятия или надхвърлят горните прагове за средни предприятия, съгласно Препоръка 2003/361/ЕО на Комисията (чл. 2(1)). Някои видове субекти са обхванати независимо от размера (чл. 2(2)). Субектите след това се класифицират като „съществени“ или „важни“ (чл. 3), което влияе върху надзора и санкциите, но и двата вида трябва да прилагат член 21.
Приложение I (сектори с висока критичност): енергетика, транспорт, банков сектор, инфраструктури на финансовите пазари, здравеопазване, питейна вода, отпадъчни води, цифрова инфраструктура, управление на ИКТ услуги (от бизнес към бизнес), публична администрация и космос. Приложение II (други критични сектори): пощенски и куриерски услуги, управление на отпадъци, химикали, храни, производство (включително медицински изделия, електроника, електрическо оборудване, машини и превозни средства), цифрови доставчици и научни изследвания.
NIS2 е директива: държавите членки трябваше да я транспонират до 17 октомври 2024 г. и да прилагат мерките от 18 октомври 2024 г. (чл. 41). Статусът и подробностите на транспонирането се различават от държава в държава, а националното право може да уточни съдържанието на мерките. Винаги проверявайте закона и официалните инструменти за допустимост на вашата страна.
Извън тези обхвати никакъв общ европейски закон не изисква от МСП да приеме документ, наречен „политика за сигурност на информацията“. Но ОРЗД се прилага към почти всяко дружество, клиентите все по-често питат доставчиците за сигурността, а писмената политика е първата стъпка на всяка призната рамка. Това е избор на предпазливост, а не правна санкция.
Източници: Директива (ЕС) 2022/2555, чл. 2, 3, 41 и приложения I и II · Препоръка 2003/361/ЕО на Комисията · Европейската комисия, страница за Директивата NIS2 · Франция: ANSSI, страница NIS 2 (MesServicesCyber).
Всяко нормативно или стандартизационно твърдение по-горе се отнася към един от тези източници. Връзките водят към официалния издател.
Тази страница се предоставя за информация. Тя не представлява правен съвет. Текстовете се цитират във версията, публикувана в EUR-Lex; националните транспонирания и насоките на органите може да добавят изисквания.
Онлайн семинарът за самообслужване е в подготовка. Въпроси междувременно: contact@syaga.eu.