Отвъд таблиците за съпоставка

Организациите рядко работят само по една рамка за киберсигурност. Доставчик на SaaS може да се стреми към сертифициране по ISO 27001, да получава искания от клиенти за доклад по SOC 2 и да има задължения по ОРЗД за своите дейности по обработване. В зависимост от услугите, сектора, размера и националното транспониране може да се прилага и NIS2. Доставчик в отбранителния сектор е изправен пред различна комбинация от стандарти и договорни изисквания, но среща същия инженерен проблем: припокриващи се изисквания, поддържани като несвързана работа.

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

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

Две инициативи на NIST разглеждат различни части на този проблем: Националната програма за онлайн информативни препратки, известна като OLIR, и моделът за съпоставяне на контроли на OSCAL. Разбирането на ролите им помага на екипите да преминат от статични таблици за съпоставка към поддържаема инфраструктура за съответствие.

Започнете с разграничаване на изискванията, контролите и доказателствата

Много проекти за съпоставяне се провалят, защото поставят три различни обекта в една и съща колона на таблицата.

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

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

Тези обекти се нуждаят от отделни връзки:

• Съпоставките изискване към изискване идентифицират припокриването между документните източници.
• Съпоставките изискване към контрол описват как организацията изпълнява дадено очакване.
• Връзките контрол към система установяват къде функционира внедряването.
• Връзките с доказателства показват какво подкрепя дадено внедряване или заключение от оценка.

Публикуваната таблица за съпоставка обикновено помага за първата връзка. Тя не установява останалите три.

Това разграничение предотвратява и неуместни сравнения между различни видове увереност. ISO 27001 се отнася до система за управление на информационната сигурност с определен обхват. SOC 2 е доклад за атестация, а не сертифициране. ОРЗД налага задължения според дейностите по обработване и ролите на организацията. Сертификат или доклад не установява съответствие с регламента.

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

Какво допринася OLIR: знания за съпоставките с контекст

OLIR предоставя стандартизиран начин експертите в дадена област да описват връзките между елементи на референтни документи и поддържани фокусни документи на NIST. Фокусните документи могат да включват NIST Cybersecurity Framework, NIST SP 800-53 или NIST AI Risk Management Framework.

Една информативна препратка може да свързва отраслово изискване с подкатегория на NIST CSF 2.0. Тя е твърдение за връзката между тези елементи, а не доказателство, че организацията е внедрила който и да е от тях.

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

• Шаблони и конвенции за поддържаните фокусни документи
• Метаданни, идентифициращи съпоставените документи и подаващата организация
• Централизиран публичен каталог
• Статуси на чернова и окончателна публикация
• Процес на публично обсъждане
• Информация дали подателят е собственик на съпоставения документ, или е трета страна

NIST разграничава три стила на съпоставяне в OLIR: концептуални съпоставки, съпоставки на връзки по теория на множествата и съпоставки на подкрепящи връзки. Целите им са различни. Концептуалната съпоставка може да помогне на хората да се ориентират в свързани идеи, докато връзката по теория на множествата може да изрази по-конкретно твърдение за това как два елемента се припокриват.

За планирането на внедряването тази разлика има значение. „Тези елементи се отнасят до реагирането на инциденти“ е полезно за откриване, но недостатъчно, за да се реши дали един процес покрива условията за докладване, получателите или сроковете на друго изискване.

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

Резултатът от набавянето на материали от OLIR трябва да бъде регистър на източниците: използваната препратка, нейният статус, версиите на документите, авторът, датата на извличане и предвидената употреба. Съхранявайте оригинала наред с всяко нормализирано представяне, за да могат проверяващите да реконструират импорта.

Какво допринася OSCAL: изчислим модел на връзките

OSCAL, Open Security Controls Assessment Language, предоставя машинночетими модели за каталози с контроли, профили, планове за сигурност на системи, планове за оценка, резултати от оценка и свързана информация за съответствието. По-широката му цел е документацията за сигурност да бъде структурирана и обменима, вместо да зависи от оформлението на документите.

Моделът за съпоставяне на контроли на OSCAL представя връзките между контроли и елементи на контроли от документни източници. Той поддържа машинночетими представяния в JSON, YAML или XML, включително връзки на по-фино ниво от цял контрол.

Речникът на връзките в модела включва equal-to, equivalent-to, subset-of, superset-of, intersects-with и no-relationship. Те не бива да се превръщат във взаимозаменяеми етикети за „горе-долу сходно“.

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

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

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

Машинночетимо не означава автоматично вярно. Валидирането спрямо схемата може да провери структурата и допустимите стойности. То не може да установи дали тълкуването на два изисквания от даден анализатор е обосновано.

OLIR и OSCAL решават различни проблеми

OLIR е програма, процес на публикуване, каталог и източник на твърдения за съпоставки. OSCAL осигурява техническо представяне за съхраняване, обмен и обработка на връзките.

Следователно една организация може да използва OLIR като един външен източник на съпоставки, а OSCAL като свое канонично вътрешно представяне. Други източници могат да включват съпоставки, предоставени от издатели, регулаторни анализи, изисквания на клиенти и вътрешно прегледани експертни съпоставки.

Обхватът на OSCAL е по-широк от ориентираната към NIST структура на подаване в OLIR. Подходящи каталози или профили могат да представят преки връзки, например IT-Grundschutz към ISO 27001, NIS2 към вътрешна библиотека с контроли или изискване на клиент към контрол на организацията. Такива връзки не е задължително да отговарят на условията за подаване в OLIR.

Практичната архитектура изглежда така:

External and internal mapping sources
                 ↓
Source preservation and import
                 ↓
Document, version, and identifier resolution
                 ↓
Normalized mapping collections
                 ↓
Technical validation and expert review
                 ↓
Controls, implementations, evidence, and assessments
                 ↓
Gap analysis and change-impact work

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

Изградете процеса на съпоставяне около изрични решения

Изяснете приложимостта, преди да сравнявате формулировки

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

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

По същия начин не добавяйте всяка категория на SOC 2 само защото съществува. Запишете предвидения обхват на ангажимента. При ISO 27001 запазете изискванията към системата за управление, третирането на риска и решенията в Декларацията за приложимост, вместо да свеждате стандарта до контролен списък по Приложение А.

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

Нормализирайте документите, без да губите структурата им

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

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

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

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

Генерирайте кандидати, след това преглеждайте твърденията

Генерирането на кандидати може да използва съществуващи съпоставки, обща терминология, цели за сигурност или анализ с помощта на ИИ. Резултатът му трябва да бъде опашка за преглед, а не одобрена колекция от съпоставки.

За всяко съществено твърдение проверяващите трябва да разгледат действителните елементи и да запишат:

• Вид и посока на връзката
• Основа за сравнението
• Допускания и ограничения на обхвата
• Общи очаквания и непокрити разлики
• Произход на източника и метод на съпоставяне
• Проверяващ, решение и дата на прегледа

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

Отхвърлянето на кандидат също е ценно. Запазването на документирано решение no-relationship помага бъдещи импорти или автоматични предложения да не представят многократно същото подвеждащо съвпадение.

Валидирайте както структурата, така и смисъла

Изпълнете технически проверки преди одобрение: неразрешени препратки, липсващи версии, невалидни стойности на връзки, дубликати и неочаквано обърната посока трябва да бъдат видими.

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

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

Тествайте импортите и експортите като инженерни компоненти

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

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

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

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

Създайте общи контроли, без да изравнявате рамките

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

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

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

Използвайте обща базова линия плюс изрични допълнения:

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

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

Използвайте повторно доказателствата чрез контекста на оценката

Централното хранилище намалява дублирането само ако проверяващите разбират какво доказва всеки артефакт.

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

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

Времето също променя повторната употреба. Ангажимент по SOC 2 Type II проверява функционирането през определен период, докато артефакт към конкретен момент обхваща по-тесен интервал. При проектирането на събирането разграничавайте честотата на контрола, периода на оценка и актуалността на артефакта. Скорошна екранна снимка не възстановява месеци липсващи записи за изпълнение.

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

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

Резултатът е план за доказателствата за всеки общ контрол: какво се събира, кога, откъде, от кого и на кои въпроси от оценката може да отговори.

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

Практически пример: един процес за инциденти, няколко решения за докладване

Да разгледаме илюстративна SaaS организация с 45 служители. Да приемем, че продукционната ѝ услуга е в обхвата на ISMS по ISO 27001, че тя се подготвя за ангажимент по SOC 2 Security и че обработва лични данни както като администратор, така и като обработващ в различни дейности. Да приемем също, че оценка на приложимостта е установила задължения по NIS2 съгласно съответното национално транспониране.

Това са допускания за сценария, а не твърдения за типичната численост на персонала, правната приложимост или усилията по проекта.

Организацията импортира кандидати за съпоставки в областта на управлението на инциденти и определя общ контрол IR-01: докладваните събития, свързани със сигурността, се оценяват първоначално, получават собственик на инцидента, разследват се, ограничават се и се документират до закриването им.

Този контрол е полезен в цялата програма, но прегледът на съпоставките идентифицира няколко отделни елемента:

Затова екипът съпоставя конкретни елементи на процеса за инциденти, вместо да твърди, че IR-01 изцяло изпълнява всяко свързано задължение.

При нарушения на сигурността на личните данни член 33 от ОРЗД разграничава ролите. Обработващият уведомява администратора без ненужно забавяне. Администраторът преценява уведомяването на надзорния орган без ненужно забавяне и, когато това е осъществимо, не по-късно от 72 часа след като е разбрал за нарушението, освен ако не съществува вероятност нарушението да породи риск за правата и свободите на физическите лица. Високият риск може да изисква съобщаване на засегнатите лица съгласно член 34, при спазване на изключенията в него.

При значителни инциденти съгласно член 23 от NIS2 структурата на докладване в ЕС включва ранно предупреждение в рамките на 24 часа, уведомление в рамките на 72 часа и по правило окончателен доклад в срок от един месец след уведомлението. Организацията проверява приложимите национални и секторни правила, вместо да третира това обобщение като своя пълна процедура за докладване.

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

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

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

Направете оценката на въздействието от промени основен процес

Библиотеката със съпоставки става ненадеждна, ако записва само имената на рамките, използвани при първоначалната настройка.

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

Практичната последователност за актуализация е:

1. Запазете предишното издание и одобрения набор от съпоставки.
2. Импортирайте новото издание с отделни идентификатори и метаданни за версията.
3. Идентифицирайте променените елементи и засегнатите връзки.
4. Маркирайте засегнатите решения за възприемане за преглед.
5. Преоценете контролите, плановете за доказателства и допълненията, специфични за рамките.
6. Одобрете преработените решения и запазете историята на заменените.

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

Производните съпоставки изискват особено внимание. OLIR може да създава производни съпоставки на връзки, като сравнява как два референтни документа се отнасят към общ фокусен документ. NIST ги описва като неавторитетни отправни точки, а не като проверени преки съпоставки. Ако A е свързано с C и B е свързано с C, това не установява, че A и B са равностойни.

Използвайте производните връзки за приоритизиране на проучването. Не разпространявайте заключения за съответствие през граф само защото съществува път.

Пилотирайте слоя от съпоставки, преди да мигрирате всичко

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

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

• Регистър на приложимостта и обхвата
• Версионирани изходни документи или разрешени препратки към източници
• Прегледани твърдения за съпоставки с произход и обосновка
• Общи контроли със собственици и оперативни процедури
• Допълнения, специфични за рамките, и задачи за нерешени пропуски
• Планове за доказателствата и примерни решения от оценки
• Тествана процедура за актуализация

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

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

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

За конкретна двойка рамки вижте NIS2 и ISO 27001.

Въпроси, които имат значение преди внедряването

Можем ли да запазим таблиците по време на пилотния проект?

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

Трябва ли ИИ да одобрява съпоставки с висока увереност?

Не. Увереността в генерирано предложение не е отговорно решение от преглед. Използвайте ИИ, за да откроявате кандидати и разлики, след което изисквайте човешко одобрение за съществените заключения относно съпоставките и доказателствата.

Какво да направим след това?

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