У пошуку часто набирають «ISO 27001 розробка програмного забезпечення» — і за цим запитом ховається не один пункт стандарту, а цілий кластер із десяти сусідніх. Центральний серед них — 8.25, безпечний життєвий цикл. Розберемо, чого він насправді очікує, що пишуть у відповідному документі, де в циклі ставлять контрольні ворота і на чому команди сипляться найчастіше. Загальний огляд усіх заходів — у матеріалі про контролі Додатка A.
Контроль 8.25: що він насправді вимагає
Формулювання в стандарті коротке: правила створення ПЗ і систем мають бути встановлені та застосовані. Усе. Жодної згаданої методології, жодного переліку інструментів.
Із цього випливають три речі, які варто зрозуміти одразу:
- Agile чи водоспад — байдуже. Стандарт не втручається в те, як ви організували роботу команди. Він цікавиться лише тим, чи є в цій роботі місце для захисту й чи справді воно використовується.
- Правила мають бути записані. «Ми й так усе робимо правильно» — не аргумент: на аудиті питають, де це зафіксовано і хто це підтвердив.
- Захист вбудований, а не прикручений. У редакції 2013 року цей пункт мав номер 14.2.1; у 2022-му його переписали й посилили очікування щодо тестування та інженерних принципів.
Логіка проста й економічна: помилка, знайдена на етапі задуму, коштує годину розмови. Та сама помилка після релізу коштує інциденту.
Не лише 8.25: ISO 27001 заходи для розробки програмного забезпечення
Восьма тема Додатка A містить цілий блок, присвячений створенню систем. Ось він повністю:
| Номер | Про що |
|---|---|
| 8.25 | Безпечний життєвий цикл — рамковий пункт, під яким лежать усі інші |
| 8.26 | Вимоги до захисту застосунку: що продукт має вміти ще до першого рядка коду |
| 8.27 | Принципи безпечної архітектури та інженерії |
| 8.28 | Безпечне кодування — цей пункт з'явився лише в редакції 2022 року |
| 8.29 | Перевірка захищеності під час створення й приймання продукту |
| 8.30 | Робота з підрядниками, які пишуть код замість вас |
| 8.31 | Розділення середовищ: розробка, тестування, промислова експлуатація |
| 8.32 | Керування змінами |
| 8.33 | Тестові дані |
| 8.34 | Захист систем під час аудиторських перевірок |
Поруч працюють ще три пункти з інших блоків: 8.4 — доступ до вихідного коду, 8.9 — керування конфігураціями, 5.8 — захист у проєктному управлінні.
Звідси практичний висновок: Заява про застосовність, у якій із цього блоку відзначено лише 8.25, а решту виключено «як незастосовне», — червоний прапорець. Якщо ви пишете код, застосовний майже весь блок.
ISO 27001: політика безпечної розробки — що в ній має бути
Головна плутанина: документ описує, що ви робите, а не як. Покроковий опис — це вже процеси й інструкції, вони живуть окремо й змінюються частіше.
Що зазвичай містить такий документ:
- Сфера дії — які продукти, команди й репозиторії він охоплює, а які ні.
- Ролі — хто затверджує вимоги до захисту, хто перевіряє код, хто дозволяє випуск.
- Середовища — правила розділення й доступу до кожного з них.
- Стандарти коду — які практики обов'язкові, які інструменти перевірки ввімкнені.
- Контрольні ворота — на яких етапах проєкт не рухається далі без перевірки.
- Підрядники — які умови мають бути в договорі, включно з правом перевірити роботу.
- Сторонні компоненти — робота з відкритим кодом, ліцензіями й залежностями.
- Код і секрети — де зберігаються, хто має доступ, як ротуються ключі.
Оптимальний обсяг — дві-чотири сторінки. Двадцятисторінковий документ, який ніхто не відкриває, гірший за коротку сторінку, яку команда справді виконує. Оформлюють його як частину процедур та інструкцій СУІБ, спираючись на загальну політику компанії.
Де в циклі стоять ворота
Аудитор не читає ваш код. Він дивиться, чи лишає процес сліди. Тому корисно одразу мислити парами «дія — доказ»:
| Етап | Що робимо | Що покаже аудитор |
|---|---|---|
| Задум | Формулюємо вимоги до захисту продукту (8.26) | Записи в беклозі, а не «домовилися на словах» |
| Проєктування | Моделюємо загрози, застосовуємо принципи (8.27) | Протокол огляду архітектури |
| Кодування | Тримаємо стандарти (8.28), робимо взаємний огляд | Історія рев'ю, налаштування аналізаторів коду |
| Перевірка | Скануємо, тестуємо на проникнення (8.29) | Звіти сканувань і висновок за результатами тестів |
| Випуск | Розділяємо середовища (8.31), узгоджуємо зміни (8.32) | Журнал випусків із підписами відповідальних |
| Супровід | Стежимо за залежностями й оновленнями | Реєстр вразливостей із датами усунення |
Якщо в якомусь рядку немає третьої колонки — ворота там лише намальовані.
Пастки, на яких сипляться команди
Ключі в репозиторії. Документ написано, а в історії комітів лежить пароль до бази. Тут одразу два пункти: доступ до коду (8.4) і керування конфігураціями (8.9). Секрети зберігають окремо, а історію чистять.
Промислові дані в тестовому середовищі. Про це є окремий пункт — 8.33. Реальні персональні відомості на стенді розробника — це витік, який просто ще не помітили. Знеособлення обов'язкове.
«У нас Agile, тому документів не буде». Стандарт не проти гнучких методів. Він проти відсутності правил. Визначення готовності (definition of done) із пунктом про перевірку захищеності — цілком годиться як доказ.
Підрядник написав — підрядник і винен. Ні. Відповідальність лишається вашою, а 8.30 прямо цього торкається: умови мають бути в договорі, разом із правом перевірити результат і доступом до звітів про перевірки.
Відкритий код без нагляду. Чужі бібліотеки — окрема поверхня атаки: і вразливості в залежностях, і ліцензійні зобов'язання. Реєстр компонентів тут перестав бути екзотикою.
Що дає ISO 27001 для розробки програмного забезпечення
Три речі, які помітні відразу:
- Передбачуваність. На питання «а хто це погоджував» з'являється відповідь, і вона не залежить від того, хто зараз у відпустці.
- Дешевші виправлення. Ворота на ранніх етапах ловлять те, що інакше довелося б переробляти після релізу.
- Готові відповіді замовникам. Анкети з питаннями про процес створення ПЗ заповнюються за годину, а не за тиждень.
І чесне застереження: сертифікат не робить код захищеним. Він робить процес керованим — а це різні речі. Технічні заходи довкола самих даних розібрано окремо: шифрування, копії, вразливості. Уся ця конструкція, своєю чергою, живе всередині системи управління.