Криптографски изключения по ISO 27001: ръководство за доказателства и CER

Одитният разговор, от който Дейвид се страхуваше най-много, дойде три седмици по-рано от очакваното. InnovatePay току-що беше придобила по-малка фирма, QuickAcquire. Сделката беше стратегически успех, но дълбоко в технологичния стек имаше наследен модул за пренос на данни, който използваше криптографска библиотека, несъответстваща на одобрените стандарти на InnovatePay. Подмяната ѝ беше шестмесечен проект. Външният одитор щеше да дойде следващата седмица.

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

В този момент намерението няма значение; контролът има. Без документиран процес за изключения, приемане на риска от ръководството, компенсиращи контроли, логове за управление на ключове и времево ограничен план за отстраняване, одиторът вероятно ще третира проблема като неефективен контрол или слабо управление на СУИС. Това практическо ръководство показва как да превърнете този момент в демонстрация на зрелост, като използвате инструментариума и политиките на Clarysec, контрол A.8.24 „Използване на криптография“ от ISO/IEC 27001:2022 и перспектива за съответствие в няколко регулаторни режима, обхващаща NIS2, DORA, GDPR, NIST и COBIT 2019.

Защо криптографските изключения са неизбежни и как ги оценяват одиторите

Криптографските изключения възникват по предвидими причини. В ангажиментите на Clarysec виждаме повтарящи се модели:

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

Одиторите по ISO/IEC 27001:2022 не изискват съвършенство, а управляемост на контрола. Те оценяват дали криптирането е подходящо и последователно, дали управлението на ключове е контролирано и логвано и дали активно идентифицирате и управлявате остарели алгоритми във вашата среда. Първата стъпка е да приведете начина, по който управлявате изключенията, в съответствие с очакванията на одиторите.

Закответе изключението в политиката и управлението на риска

Зрялата СУИС третира изключенията като решения за третиране на риска, а не като технически дълг. Формалният механизъм е заявка за криптографско изключение (CER), а клаузата в политиката, която я изисква, е разграничителната линия между управлявано изключение и одитна констатация.

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

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

Изградете CER като контролен запис, готов за одит

Коментарите в билети не са записи за изключения. CER трябва да бъде структурирана, управлявана по версии и подходяща за извадково тестване като всеки друг контрол. Независимо дали е внедрена в GRC платформа или в контролиран шаблон, силната CER включва:

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

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

Минималният жизнеспособен пакет от доказателства за криптографско изключение

Одиторите очакват повече от техническа моментна снимка. При изключенията те търсят доказателства за управление и оперативно изпълнение. Практичният пакет от доказателства включва:

1. Попълнена CER с одобрения и срок на валидност.
2. Свързаната оценка на риска и решението за третиране.
3. Процедури за управление на ключове за засегнатата система, с логове за генериране, разпространение, ротация, достъп и унищожаване на ключове.
4. Записи за промени в криптографските настройки и тестови доказателства, показващи, че промените са проверени или ограниченията са потвърдени.
5. Доказателства от мониторинг и откриване за компенсиращите контроли, включително SIEM правила и тестове на предупреждения.
6. Записи от комуникации, които показват, че засегнатият персонал е информиран и обучен относно отклонението и очакванията за мониторинг.
7. Времево ограничен план за изход с ключови етапи, дати, бюджет, когато е приложимо, и собственици.
8. История на прегледите на политиката, която доказва поддържане на криптографската базова линия и управление на жизнения цикъл на алгоритмите.

Тези видове доказателства се съгласуват с указанията на ISO/IEC 27002:2022 относно криптографията и контрола на промените.

Използвайте Zenith Blueprint за събиране и представяне на доказателства

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

• Интервюирайте собственика на системата и ръководителя по сигурността. Защо изключението е необходимо, какво се е променило след последния преглед и каква е следващата стъпка в плана за изход.
• Прегледайте CER, записа за риска, клаузата от политиката и ограниченията от доставчик или партньор. Потвърдете датите на изтичане и преглед.
• Наблюдавайте техническото състояние — точната конфигурация и мястото, където изключението се прилага, и вижте къде са внедрени компенсиращите контроли.
• Извадково тествайте няколко изключения, обичайно от три до пет, за да докажете последователност на структурата, одобренията, прегледите, логването и управлението на сроковете на изтичане.

Практически пример: как наследено TLS изключение да стане защитимо при одит

Сценарий: Критична за приходите B2B интеграция изисква по-стар TLS шифров пакет, защото крайната точка на партньора не може да договори одобрените от вас настройки. Прекъсването на връзката не е приемлив вариант.

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

1. Създайте CER и я свържете с риска. Задайте 90-дневен срок на валидност с прегледи на всеки 30 дни, приложете кореспонденцията с партньора и свържете със запис в регистъра на риска, притежаван от бизнеса.
2. Изберете компенсиращи контроли, които генерират доказателства. Ограничете изходните IP адреси до диапазоните на партньора чрез записи за промени в защитната стена. Наложете взаимна TLS автентикация, ако е възможно, и съхранявайте записите за издаване на сертификати. Увеличете мониторинга за аномалии при TLS договаряне и съхранявайте дефинициите на SIEM правилата и тестовете на предупреждения.
3. Докажете дисциплина при управление на ключове. Покажете логове за достъп до KMS, RBAC назначения, записи за авариен достъп и протоколи от периодични прегледи на правата за достъп. За по-малки програми базовото изискване е изрично посочено в Политика за криптографски контроли за МСП: Всеки достъп до криптографски ключове трябва да бъде регистриран в лог и съхраняван за одитен преглед, с редовни прегледи на правата за достъп.
4. Пакетирайте изключението. Съберете в една папка с доказателства или PDF CER, записа за риска, моментна снимка на конфигурацията на шлюза, билети за промени в защитната стена, KMS логове, SIEM правило и извадки от събития, тестови записи и комуникации към оперативните екипи.

Криптографска гъвкавост: доказване, че изключенията са временно заложени по замисъл

ISO/IEC 27002:2022 насърчава криптографската гъвкавост — способността да се актуализират алгоритми и пакети, без да се изграждат наново цели системи. Одиторите търсят доказателства за гъвкавост, а не обещания:

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

Управлението на изключенията среща форензиката

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

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

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

В регулирани среди или среди с множество рамки едно и също изключение ще бъде разглеждано през различни перспективи. Използвайте ръководството Zenith Controls, за да запазите пакета от доказателства последователен.

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

Дори в рамките на един одит стиловете се различават. Подгответе се за всеки стил и управлявайте разказа:

• Одиторът по ISO/IEC 27001:2022 ще попита къде е политиката за криптография, къде е дефиниран процесът за изключения, колко често се преглеждат изключенията и ще поиска извадково тестване. Започнете с вашите CER и контролиран регистър.
• Одиторът, ориентиран към NIST, ще търси базови линии за шифрови пакети, защити срещу понижаване на алгоритми, процедури за генериране и унищожаване на ключове и логове с предупреждения. Донесете KMS логове, SIEM правила и тестове за валидиране.
• Одиторът по COBIT или ISACA ще се фокусира върху това кой притежава риска, кой го е приел, какъв е цикълът на преглед и кои показатели показват намаляване на изключенията. Донесете протоколи от ръководния комитет и отчети за продължителността на изключенията.
• Проверяващият с регулаторна перспектива ще попита как изключението влияе върху наличността и целостта на критичните услуги и дали рискът от експониране на лични данни се е увеличил. Предоставете артефакти за планиране на устойчивостта и строг график за отстраняване.

Чести пропуски, които създават несъответствия

• Изключения без дати на изтичане, тълкувани като неуправляван риск.
• Липса на приемане на риска от ръководството, когато инженер е дал одобрение в билет без отчетна собственост.
• Компенсиращи контроли, описани, но неподкрепени с доказателства, например твърдения за мониторинг без SIEM правила.
• Липсващи или недостъпни логове за управление на ключове.
• Политиката казва едно, а практиката показва друго, например CER се изискват, но не се използват.

Контролен списък за деня на одита за криптографски изключения

• Актуален регистър изброява всички криптографски изключения с CER идентификатори, собственици, одобрения, дати на преглед и срокове на валидност.
• Всяко изключение е свързано със запис за риска и документирано решение за третиране.
• Най-малко два компенсиращи контрола за всяко изключение, с надеждни доказателства.
• Достъпът до ключове се логва, логовете се съхраняват и се извършват прегледи на правата за достъп.
• Налична е история на прегледите на криптографската политика, с промени под управление на версиите.
• Можете да извадково тествате три или повече изключения и да представите последователен разказ.
• Пътна карта показва намаляване на изключенията във времето.

Ограничения от доставчици и партньори

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

Следващи стъпки: изградете програмата си за изключения в един спринт

1. Инвентаризирайте всички криптографски изключения, включително скритите в периферни услуги.
2. Създайте или актуализирайте CER за всяко изключение с одобрения, срок на валидност и планове за изход.
3. Свържете всяка CER със запис в регистъра на риска с отчетно отговорен собственик.
4. Създайте стандартен шаблон за пакет от доказателства за изключения и упражнете извадково тестване за одит.
5. Валидирайте готовността за съответствие в няколко регулаторни режима с ръководството Zenith Controls.

Превърнете тревогата от криптографските изключения в увереност при одит. Запазете работна сесия с Clarysec. В рамките на един ангажимент внедряваме работен поток за CER, регистър на изключенията и структура на пакет от доказателства, готова за одитор. Резултатът е по-бързи одити, по-малко повторни констатации и криптографски изключения, които демонстрират управление вместо импровизация.