ISO 27001 дедалі частіше фігурує як обов'язкова вимога в тендерних умовах для постачальників оборонного програмного забезпечення по всій Європі. Те, що раніше було бажаним показником, перетворилося на базовий стандарт: постачальники без чинної сертифікації ISO 27001:2022 виключаються зі списків учасників ще до технічної оцінки. Розуміння того, що насправді вимагає стандарт — а не просто як виглядає сертифікат — є необхідним як для постачальників, що прагнуть сертифікації, так і для офіцерів закупівель, які оцінюють пропозиції.

У цій статті розглядається, що вимагає ISO 27001:2022 стосовно організацій з розробки програмного забезпечення, які суттєві зміни запровадила редакція 2022 року та що сертифікація практично означає для процесів розробки, складу команди та виконання проектів.

Що таке ISO 27001:2022 і що змінилося

ISO 27001 — міжнародний стандарт, що визначає вимоги до Системи управління інформаційною безпекою (СУІБ). На відміну від технічних стандартів безпеки, які наказують конкретні засоби контролю, ISO 27001 вимагає від організацій визначати ризики інформаційної безпеки, впроваджувати відповідні засоби контролю для управління цими ризиками та підтримувати цикл постійного вдосконалення.

Редакція 2022 року замінила ISO 27001:2013 та внесла суттєві зміни до Додатку A, що містить набір засобів контролю. У версії 2013 року було 114 засобів контролю в 14 доменах. Версія 2022 року реструктурувала їх до 93 засобів контролю у 4 темах: організаційні, кадрові, фізичні та технологічні засоби контролю. Крім того, було введено 11 нових засобів контролю, безпосередньо актуальних для організацій з розробки програмного забезпечення:

  • Аналіз загроз (5.7) — організації повинні збирати та аналізувати інформацію про загрози, що стосуються їхнього контексту
  • Інформаційна безпека при використанні хмарних послуг (5.23) — явні вимоги до управління використанням хмарних технологій
  • Готовність ІКТ до забезпечення безперервності бізнесу (5.30) — планування безперервності повинне враховувати залежності ІКТ
  • Веб-фільтрація (8.23) — засоби контролю доступу систем до інтернет-ресурсів
  • Безпечне кодування (8.28) — формальні вимоги до безпечних практик розробки
  • Маскування даних (8.11) — вимоги до маскування чутливих даних у непродуктивних середовищах

Для постачальників оборонного програмного забезпечення засіб контролю 8.28 (Безпечне кодування) є особливо значущим. Стандарт 2022 року тепер явно вимагає, щоб організації застосовували принципи безпечного кодування — тобто практики безпечної розробки повинні бути задокументовані, дотримані та перевірені аудиторами.

Ключові засоби контролю, актуальні для розробки ПЗ

ISO 27001 не наказує конкретних технологій або методологій розробки. Він вимагає структурованого підходу до виявлення та управління ризиками інформаційної безпеки протягом усього життєвого циклу розробки. На практиці це означає кілька категорій вимог, що впливають на роботу організацій.

Управління доступом (8.2–8.5). Стандарт вимагає управління доступом до систем, репозиторіїв коду та інфраструктури розгортання на основі принципу найменших привілеїв. Для оборонної розробки це означає, що розробники не повинні мати доступу до виробничого середовища, перевірка коду повинна контролювати злиття у захищені гілки, а привілейований доступ до систем розгортання — бути обмеженим у часі та журналюватися.

Криптографія (8.24). Організації повинні мати політику управління криптографічними засобами: які алгоритми схвалені, як управляються ключі та хто відповідає за криптографічні рішення. Для оборонного програмного забезпечення це зазвичай означає відповідність національним криптографічним стандартам.

Безпечний життєвий цикл розробки (8.25–8.31). Стандарт вимагає інтеграції безпеки у весь процес розробки: вимоги безпеки повинні визначатися на етапі проектування, тестування безпеки — проводитися перед випуском, а залежності — оцінюватися на вразливості. Це безпосередньо вимагає таких практик, як моделювання загроз, статичний аналіз, сканування вразливостей залежностей та тестування на проникнення.

Управління інцидентами (5.24–5.28). Організації повинні мати задокументовані процедури для виявлення, звітування та реагування на інциденти безпеки. Для середовищ розробки це означає моніторинг аномального доступу до репозиторіїв коду та несанкціонованих змін у конфігураціях розгортання.

Примітка для закупівель: При оцінці сертифікатів ISO 27001 завжди перевіряйте межі сертифікації. Сертифікат, що охоплює лише «головний офіс» або «адміністративні функції», не дає жодних гарантій щодо середовища розробки, де фактично пишеться код. Межі повинні явно включати діяльність з розробки програмного забезпечення та підтримуючу інфраструктуру.

Що реально змінюється у процесах розробки

Організації, що вперше проходять сертифікацію ISO 27001, як правило, виявляють, що вплив стандарту на їхні процеси розробки є більш суттєвим, ніж очікувалося. Такі зміни є стійкими та систематично недооцінюються.

Оцінка ризиків стає задокументованим артефактом. ISO 27001 вимагає, щоб ризики інформаційної безпеки були виявлені, оцінені та відстежені. Для розробки програмного забезпечення це означає ведення реєстру ризиків, що охоплює ризики середовища розробки, ризики ланцюга поставок та операційні ризики. Реєстр ризиків — це не одноразовий документ; він повинен переглядатися та оновлюватися через визначені інтервали.

Контрольні точки SDLC стають обов'язковими. Вимоги безпеки повинні фіксуватися на початку кожного циклу розробки, а тестування безпеки — проводитися перед випуском. Аудитори вимагатимуть результати тестування безпеки, а не лише запевнення про проведене тестування.

Управління постачальниками та залежностями вимагає формального підходу. Стандарт вимагає, щоб вимоги інформаційної безпеки були доведені до постачальників та щоб відносини з ними відстежувалися. Для розробки ПЗ це охоплює бібліотеки з відкритим вихідним кодом та компоненти третіх сторін.

Вимоги до безпеки персоналу впливають на найм та адаптацію. ISO 27001 вимагає перевірки осіб, чиї ролі передбачають доступ до чутливих інформаційних активів. Для постачальників оборонного програмного забезпечення це може потребувати відповідності національним вимогам безпеки.

Фізична безпека середовищ розробки повинна бути формально врегульована. Дистанційні та гібридні середовища розробки вводять виклики фізичної безпеки, які стандарт вимагає від організацій врегулювати — включаючи політики щодо роботи з чутливим кодом у публічних місцях та вимоги до шифрування пристроїв.

Чому офіцери закупівель вимагають ISO 27001

З погляду офіцера оборонних закупівель, сертифікація ISO 27001 виконує кілька функцій, що виходять за межі самих засобів контролю безпеки.

По-перше, вона забезпечує незалежну верифікацію. Сертифікат видається акредитованим органом третьої сторони після аудиту СУІБ організації. На відміну від самооціночних фреймворків відповідності, ISO 27001 вимагає, щоб кваліфікований аудитор вивчив докази впровадження засобів контролю. Наглядові аудити проводяться щороку; повторні сертифікаційні — кожні три роки.

По-друге, вона створює підзвітність. Сертифікація ISO 27001 вимагає, щоб вище керівництво було явно зобов'язане щодо СУІБ. Це означає, що організація не може правдоподібно стверджувати, що збої безпеки були ізольованими інцидентами, не пов'язаними з керівництвом.

По-третє, вона спрощує комплексну перевірку. Замість проведення детальної оцінки безпеки кожного потенційного постачальника, фреймворки закупівель, що вимагають ISO 27001, можуть використовувати сертифікат як базовий фільтр. Постачальники також повинні знати, що деякі оборонні фреймворки закупівель тепер явно вказують ISO 27001:2022, а сертифікати, що посилаються на стандарт 2013 року, після жовтня 2025 року вважаються недійсними.