NIS2 и ISO 27001: използвайте повторно контролите, проучете пропуските

Програма по ISO 27001 може да осигури силна оперативна структура за NIS2: оценка на риска, отговорни собственици, контроли, доказателства и подобрение. Следващата стъпка е оценка, изискване по изискване, на това какво реално обхваща тази структура.

За техническия директор полезният въпрос не е дали рамките се припокриват. Въпросът е дали внедреният контрол защитава съответната услуга, изпълнява приложимото задължение и създава доказателства, които подкрепят това заключение. Използвайте повторно внедряването, когато тези условия са налице; запазвайте правните и оперативните разлики, когато не са.

Разберете какво установява всяка рамка

ISO/IEC 27001 определя изискванията към система за управление на информационната сигурност (ISMS) с определен обхват. Клаузи 4–10 уреждат нейната управленска структура, включително третирането на риска, оценката на резултатността и подобрението. Приложение А съдържа 93 референтни контрола в организационната, свързаната с хората, физическата и технологичната категория. Приложимостта на контролите се основава на риска и не е изискване всеки контрол да се внедрява по еднакъв начин. ISO 27002 предоставя насоки за внедряване.

NIS2 е директива на ЕС, която се прилага чрез националното право. Приложимостта зависи от сектора, размера, услугата и конкретни правила за включване. Приложение I и Приложение II посочват съответните сектори, но само секторът не определя дали една организация е съществен или важен субект. Някои субекти са обхванати независимо от размера си.

Практическите разлики са:

Сертифицирането се извършва от независими сертифициращи органи, а не от ISO. То не установява съответствие с NIS2, а NIS2 по принцип не изисква сертифициране по ISO 27001. Правоприлагането може да включва надзорни мерки и санкции; сертифицирането по ISO има различна цел по отношение на увереността.

Започнете със съпоставяне на границите

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

Създайте сравнение на обхвата, което записва:

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

Разграничавайте пропуска в обхвата от пропуска в контролите. Продукционна среда извън ISMS може вече да има добри контроли на достъпа, но тези контроли все пак се нуждаят от собственост, оценка и доказателства в рамките на работата по NIS2.

Проверете секторното законодателство, преди да дублирате задължения. Член 4 урежда връзката със секторните правни актове на ЕС. При финансовите субекти връзката с DORA изисква анализ според ролята. За дейности в Германия се консултирайте с информацията на BSI за NIS2, вместо да приемате, че съществуващите задължения по KRITIS и задълженията по NIS2 са идентични.

Съпоставяйте внедрените контроли, а не съвпадащите етикети

Член 21 изисква подходящи и пропорционални технически, оперативни и организационни мерки. Десетте му минимални области на мерки дават отправна точка за съпоставяне, но сходната формулировка е полезна следа, а не доказателство за равностойност.

Използвайте следното като подсказки за преглед, а не като автоматични декларации за покритие:

Декларацията за приложимост записва необходимите контроли и обосновката за включването или изключването им. Тя не е взаимозаменяема с плана за третиране на риска, констатациите от вътрешния одит или записите от прегледа от ръководството. Използвайте тези артефакти заедно, за да обясните както дизайна, така и функционирането.

Политиката установява очаквания. Експорт на конфигурация може да покаже внедряването. Резултатите от прегледи на достъпа, заявките за отстраняване и записите от тестове могат да покажат функционирането. Използвайте повторно доказателствата само когато системата, периодът и целта на оценката съвпадат.

Избягвайте фиксирани проценти на припокриване. Покритието зависи от внедряването и правния обхват; универсално число не може да установи готовност.

Изградете път за докладване на инциденти, който може да работи под натиск

План за реагиране, съобразен с ISO, може да подкрепя откриването, ограничаването, разследването и възстановяването, без да определя регулаторното уведомяване. Член 23 от NIS2 добавя задължения за докладване на значителни инциденти.

Етапите на докладване по директивата по принцип включват:

• Ранно предупреждение без ненужно забавяне и в рамките на 24 часа от узнаването за значителен инцидент.
• Уведомление за инцидента без ненужно забавяне и в рамките на 72 часа, което актуализира ранното предупреждение и съдържа първоначална оценка.
• Окончателен доклад по правило в срок от един месец след подаването на уведомлението за инцидента. При продължаващ инцидент към този момент се изисква доклад за напредъка, а окончателният доклад се подава в срок от един месец след приключване на обработката на инцидента.

Междинен доклад също трябва да бъде предоставен, ако CSIRT или компетентният орган поиска това.

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

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

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

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

Направете управлението и устойчивостта доказуеми

Член 20 изисква управителните органи да одобряват мерките за управление на риска в областта на киберсигурността и да упражняват надзор върху изпълнението им. Той урежда и обучението на членовете на управителните органи. Съществуващият преглед от ръководството е полезно доказателство, но проверете дали той изрично записва съответните одобрения, надзора, решенията и последващите действия.

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

Непрекъснатостта изисква също толкова конкретно третиране. Член 21 включва резервните копия, възстановяването след бедствия и управлението на кризи; той не налага универсално изискване за сертифициране по ISO 22301. Определете необходимата дълбочина според услугата, рисковете и приложимите правила.

Тествайте възстановяването на данни и услуги, а не само завършването на задачите за архивиране. Включете зависимости като услугите за идентичности, DNS, поддръжката от доставчици, привилегированите идентификационни данни и комуникациите, когато обичайната среда е недостъпна. Записвайте постигнатите резултати от възстановяването и нерешените пречки спрямо договорените цели.

Поддържайте видим регистър на разликите

За всяко изискване записвайте неговия източник и версия, съпоставените контроли, обхвата, препратките към доказателства, проверяващия и обосновката за повторна употреба. Разграничавайте подкрепеното покритие, частичното покритие, липсващото внедряване, липсващите доказателства и обоснованото решение за неприложимост. Липсата на документ не винаги означава липса на контрол, но изисква проучване.

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

Честите грешки включват съпоставяне само на Приложение А при пренебрегване на изискванията за управление, приемане на сертификат на доставчик без проверка на обхвата му, третиране на доказателствата от миналата година като актуални и закриване на задача, когато политиката е публикувана, но процесът остава нетестван. Регистрацията или сертифицирането никога не бива да се третират като доказателство за оперативно внедряване.

Практически пример: разширяване на съществуваща ISMS

Илюстративни допускания: доставчик на управлявани услуги има сертифицирана по ISO 27001 ISMS, която обхваща основния му оперативен екип. Оценката на приложимостта заключава, че услуга, предоставяна чрез допълнително юридическо лице, попада под NIS2. Това лице използва същата платформа за идентичности и същия екип за инциденти, но отделни договорености за възстановяване.

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

След това собственикът на процеса за инциденти запазва установената процедура за реагиране и добавя оценка на значителните инциденти и път за уведомяване на органа. Настолно упражнение симулира прекъсване при доставчик с несигурно въздействие върху клиентите. Участниците записват кога са узнали съответните факти, кой е решил относно значимостта и как би било подадено ранно предупреждение.

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

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

Превърнете оценката в поддържана работа

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

Започнете с една регулирана услуга. Включете нейния обхват, третирането на риска, Декларацията за приложимост, ръководството за инциденти и скорошните доказателства от тестове в съвместен технически преглед и преглед на съответствието. Изгответе прегледан регистър на разликите, след което използвайте обичайните цикли за преглед на ISMS, за да го поддържате при промяна на услугите, доставчиците и изискванията.