От архитектурен проект до одитна готовност: управление на изискванията за сигурност на приложенията за ISO 27001, DORA и NIS2

Напрежението преди одита беше осезаемо. За Мария, CISO на средно голяма fintech компания, предстоящата оценка за съответствие с DORA изглеждаше не толкова като преглед, колкото като момент на равносметка. Екипът ѝ беше силен, ИТ инфраструктурата — укрепена, но една натрапчива уязвимост не ѝ даваше покой: разрастващият се и хаотичен свят на техните приложения.

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

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

Този сценарий не е изключение. Той показва критичния пропуск, пред който са изправени много CISO и ръководители по съответствие: превръщането на намерението „ние осигуряваме сигурност“ в ясни, проверими изисквания за сигурност на приложенията, съгласувани с основни стандарти като ISO/IEC 27001:2022 и ключови регулации като NIS2, DORA и GDPR.

Високата цена на неяснотата: какво всъщност очаква съответствието

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

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

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

В съвременните стандарти очакването е последователно: сигурността трябва да бъде дефинирана като изисквания, в ранна фаза и обвързана с риска и закона. Насоките на ISO/IEC 27002:2022 за контрол 8.26, Application security requirements, очакват организациите систематично да определят, документират и одобряват изискванията за сигурност въз основа на формална оценка на риска и регулаторни изисквания.

Този единствен принцип е ключов за широк набор от задължения за съответствие. Картографирането на Clarysec между различни рамки за съответствие в Zenith Controls: The Cross-Compliance Guide Zenith Controls показва как тази концепция присъства навсякъде:

• GDPR Articles 25 and 32 очакват „защита на данните още при проектиране“ и „сигурност на обработването“.
• NIS2 Article 21(2)(d)-(e) акцентира върху сигурната разработка и сигурността на веригата на доставки.
• DORA Articles 6(4), 8, 10, and 11 изискват управление на ИКТ риска и сигурност още при проектиране за финансовите субекти.
• NIST SP 800-53 Rev.5 в контролите SA-4 и SA-15 изисква дефинирани изисквания за сигурност на системите и практики за сигурна разработка.
• COBIT 2019 в процесите BAI03 и DSS05 изисква изискванията, свързани със сигурността, да бъдат съгласувани с бизнеса и съответствието преди изграждането на решение.

Целта е да се дефинира, по думите на Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, „какво означава сигурност за вашите приложения, преди да бъде написан и един ред код.“

Защо традиционните подходи се провалят: контролни списъци, късно тестване и театър на сигурността

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

Често срещаните модели на провал включват:

1. Общи контролни списъци: екипите използват повторно едностраничен „контролен списък за сигурно програмиране“ за всеки проект. Той не е обвързан със специфичните рискове на приложението, чувствителността на данните или регулаторния контекст. Когато одитор попита как списъкът се съотнася към GDPR Article 25, няма ясен отговор.
2. Сигурността като късна контролна точка: изискванията за сигурност не са вградени в дизайна или в потребителските истории. Те се появяват накрая като заявка за тестове за проникване. Zenith Blueprint предупреждава, че „разчитането на контролен списък за сигурност в края на проекта не работи; тези изисквания трябва да оформят архитектурата, да влияят върху избора на библиотеки и да насочват приоритизацията на функционалностите още от първия ден.“
3. Липса на проследимост от изискване до тест: може да съществува изискване за „шифроване на данни при пренос“, но да няма свързан тестов сценарий, който проверява налагането на TLS версия, валидността на сертификата и силата на шифрите. Zenith Blueprint изисква очакванията да бъдат измерими и проверими, като тестовете за сигурност са директно съпоставени със съответните изисквания.
4. Ад хок обработване на код от трети страни: съвременните приложения често са „сглобени от вътрешен код, библиотеки от трети страни, приложни програмни интерфейси (API) и облачно-нативни услуги“, както е посочено в Zenith Blueprint. Без изрични изисквания към доставчиците и компонентите с отворен код рискът по веригата на доставки остава мащабна, неконтролирана сляпа зона.

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

Изграждане на основата: от политика към практика

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

Нашата Application Security Requirements Policy Политика за изискванията за сигурност на приложенията установява задължителни основни правила. Например клауза 5.2 в раздел „Изисквания за управление“ постановява:

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

Тази проста директива предотвратява манталитета „първо изграждаме, после защитаваме“. Политиката също така възлага ясна отчетност. Клауза 4.3.1 в раздел „Роли и отговорности“ посочва, че разработчиците са длъжни да:

Внедряват приложенията в съответствие с дефинираните изисквания и стандарти за сигурност.

Така отговорността за сигурността се измества от отделен, често възприеман като опонентен, екип по сигурност към самите създатели на софтуера. Освен това политиката свързва различните домейни на сигурността. Клауза 10.2 посочва интеграцията ѝ с други ключови контроли:

P4 – Access Control Policy. Дефинира стандартите за управление на идентичността и сесиите, които трябва да се прилагат от всички приложения, включително силна автентикация, минимално необходим достъп и изисквания за преглед на достъпа.

За по-малки организации адаптирана политика като нашата Application Security Requirements Policy - sme Application Security Requirements Policy-sme гарантира, че тези принципи могат да бъдат мащабирани. Тя отчита, че макар рисковете да са сходни, внедряването трябва да бъде прагматично. И двете версии в крайна сметка целят един и същ резултат: сигурността на приложенията да бъде напълно интегрирана в ISMS и готова за одит.

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

Политиката задава „какво“ и „защо“, но разработчиците и ръководителите на проекти се нуждаят от „как“. Структурираното ръководство за внедряване е незаменимо за превръщането на контроли от високо ниво в изпълними стъпки. Стъпка 21 от Zenith Blueprint, фокусирана върху контрол 8.26 от ISO/IEC 27002:2022, предоставя ясна методология в шест стъпки.

Нека преминем през този процес, използвайки платежния портал на Мария като пример.

Стъпка 1: започнете от риска и регулаторния контекст

Като използвате резултатите от оценка на риска, съгласувани с ISO/IEC 27005:2024 (третиране на риска), първо идентифицирате контекста:

• Приложение: портал за клиентско самообслужване за плащания.
• Данни: лична идентифицираща информация (PII), удостоверителни данни, платежни токени.
• Юрисдикции: ЕС, финансови услуги, хостван в облак.
• Регулации: GDPR, DORA, PCI DSS.

Въз основа на насоките за контрол 8.26 в Zenith Controls и свързаните с него ISO стандарти (27034-1, 27017, 27701), началните категории изисквания трябва да включват идентификация и автентикация, оторизация, класификация на данни, валидиране на входни данни, журналиране и защита на данните при пренос и в покой.

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

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

Минималните раздели трябва да включват:

• име на приложението, собственик и критичност;
• категории данни и нива на чувствителност;
• приложими регулаторни и договорни задължения (GDPR, DORA и др.);
• входни данни за ландшафта на заплахите (изведени от контрол 5.7 разузнаване за заплахи);
• конкретни изисквания за сигурност по категории (автентикация, журналиране и др.);
• връзки към потребителски истории и критерии за приемане;
• връзки към тестови сценарии (функционални, за сигурност, за проникване);
• изисквания към доставчици и компоненти от трети страни.

Стъпка 3: вградете изискванията в Agile артефакти

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

• Оригинална потребителска история: „Като нов потребител мога да създам акаунт.“
• Сигурна потребителска история: „Като нов клиент искам да създам сигурен акаунт, така че платежната ми информация да бъде защитена.“
• Критерии за приемане (с вградена сигурност):
  • Системата трябва да налага политика за силни пароли в съответствие с P4 – Access Control Policy.
  • Системата трябва да изисква потвърждение на имейл чрез еднократна връзка преди активиране на акаунта.
  • Формулярът за създаване на акаунт трябва да бъде защитен с CAPTCHA, за да се предотвратят ботнет атаки.
  • Всички опити за регистрация трябва да бъдат журнализирани с IP адрес на източника и отпечатък на устройството.
  • Всички данни, подадени чрез формуляра, трябва да бъдат санитизирани, за да се предотврати междусайтов скриптинг (XSS).

Това не са отделни задачи по сигурността; те са неразделна част от дефиницията за „готово“ на функционалността.

Стъпка 4: свържете изискванията с тестването на сигурността

Използвайки контрол 8.29 Security testing от Zenith Controls, гарантирате, че всяко изискване има свързан тестов сценарий. Това затваря цикъла и предоставя одитируеми доказателства за ефективност на контролите.

• Изискване: шифроване при пренос с TLS 1.3. → Тест: автоматизирано сканиране за проверка на налагането на TLS, валидността на сертификата и одобрените набори от шифри.
• Изискване: валидиране на входни данни за предотвратяване на SQL инжекция. → Тест: автоматизирано SAST/DAST сканиране и ръчен fuzzing по време на QA.
• Изискване: 15-минутен таймаут на неактивна сесия. → Тест: автоматизирани и ръчни тестове за потвърждаване на инвалидиране на сесията от страна на сървъра след 15 минути неактивност.

Стъпка 5: разширете изискванията към веригата на доставки

Тъй като ISO контрол 8.26 е свързан със сигурността на доставчиците (5.19, 5.20) и външната разработка (8.30) в Zenith Controls, процесът ви трябва да отчита кода от трети страни. За МСП, които силно разчитат на външни библиотеки, клаузата от Application Security Requirements Policy - sme е критична:

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

Това просто и прагматично изискване налага мислене, свързано със списък на софтуерните компоненти (SBOM), което е ключово очакване по регулации като NIS2. За основни доставчици същите изисквания за сигурност на приложенията трябва да бъдат включени в договорите, с препратка към ISO/IEC 27036-1 (сигурност на ИКТ веригата на доставки).

Стъпка 6: въведете периодична повторна оценка

С развитието на приложенията се променят и рисковете им. Насоките на Zenith Blueprint относно периодичната повторна оценка са от ключово значение. Когато интегрирате нов API или преминете към друга облачна услуга, рисковият контекст се променя. Това трябва да задейства преглед на съществуващите изисквания за сигурност, за да се гарантира, че те остават адекватни. Това е в съответствие с ISO/IEC 27005:2024 (текущо третиране на риска) и превръща сигурността на приложенията в непрекъсната практика, а не в еднократен проект.

Разграждане на екосистемата от контроли

ISO контрол никога не съществува във вакуум. Ефективната сигурност разчита на взаимосвързана мрежа от мерки. Истинската сила на контрол 8.26 се разкрива, когато разберете връзката му с други контроли — перспектива, подробно разгледана в Zenith Controls.

Контрол 8.26 е класифициран като превантивен контрол, но действа като централен възел за целия процес на сигурна разработка, като се свързва с:

• 8.25 - Secure development life cycle: това е общата рамка. Контрол 8.26 предоставя конкретното какво (изискванията), което трябва да бъде интегрирано в как (процеса SDLC).
• 8.27 - Secure system architecture and engineering principles: изискванията насочват архитектурните решения и гарантират, че сигурността е заложена в основата.
• 8.28 - Secure coding: след като изискванията са дефинирани (напр. „предотвратяване на SQL инжекция“), стандартите за сигурно програмиране предоставят на разработчиците техниките за изпълнение на това изискване.
• 8.29 - Security testing in development and acceptance: този контрол валидира, че изискванията, дефинирани в 8.26, са внедрени правилно.
• 5.34 - Privacy and protection of PII: когато приложение обработва лични данни, изискванията от 8.26 трябва да включват принципите на privacy by design.
• 5.19 & 5.20 - Information security in supplier relationships: за придобити или възложени на външен изпълнител приложения контрол 8.26 определя, че вашите изисквания за сигурност трябва да се разпростират към веригата на доставки.

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

През погледа на одитора: подготовка за проверка

Одиторите мислят в категории доказателства. За да се подготвите, трябва да разбирате различните гледни точки, които един одитор може да приложи. Разделът за методология на одита в Zenith Controls предвижда тези различни подходи.

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

Компасът за съответствие между рамки: един процес, много рамки

За компания като тази на Мария съответствието с DORA, GDPR и NIS2 е задължително. Ръчното картографиране на контроли е рецепта за дублиране на усилия и пропуски в съответствието. Централизираният подход към съответствието между рамки носи значителна стойност. Дефинирането на изисквания за сигурност на приложенията е практическото внедряване на принципа „сигурност още при проектиране“, който стои в основата на всички тези съвременни регулации.

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

От хаос към контрол: вашият път напред

Историята на Мария има положителен завършек. Тя използва инцидента с платежния портал като катализатор за промяна. Въоръжена с ясна политическа рамка от Clarysec и практическо ръководство за внедряване, тя събра екипите по разработка, сигурност и продукт. Те използваха методологията на Zenith Blueprint, за да дефинират ретроспективно изискванията за портала, като приоритизираха отстраняването въз основа на риска.

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

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

1. Установете управление: внедрете формална политика за дефиниране на изисквания за сигурност на приложенията. Нашите шаблони, като Application Security Requirements Policy, предоставят начална точка, готова за одит.
2. Приемете практическа рамка: използвайте Zenith Blueprint, за да интегрирате изискванията за сигурност директно във вашия жизнен цикъл на разработката, като ги направите изпълними, проверими и проследими.
3. Разберете пълния контекст: използвайте Zenith Controls, за да видите как този критичен контрол се свързва с по-широката екосистема на сигурността и как се картографира към DORA, NIS2, GDPR и други рамки.
4. Мащабирайте към портфолиото си: след като подходът сработи за едно приложение, мащабирайте го в цялото портфолио, като интегрирате шаблона за изисквания за сигурност в стандартните контролни списъци за начална фаза на проекта, Agile шаблони и процеси по снабдяване.

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