Організація впроваджує ISO 27001 — і тут у розмові виринають ще три назви. Логічне питання: навіщо вони, якщо система вже будується за ISO 27001? Коротка відповідь: жодна з них не конкурує з ISO 27001, бо кожна працює на своєму поверсі — стратегія ризиків, люди, код. Плутанина виникає лише тоді, коли всі чотири назви ставлять в один ряд, ніби вони рівнозначні.
Установа, а не один документ
National Institute of Standards and Technology — Національний інститут стандартів і технологій США. Головний нюанс, з якого й починається плутанина: NIST — це не назва конкретного документа, а назва установи. Інститут випускає сотні публікацій, серед яких є ціла серія SP 800, присвячена кібербезпеці. Найчастіше згадують такі:
- SP 800-53 — великий каталог заходів захисту для інформаційних систем;
- SP 800-171 — вимоги до захисту чутливої несекретної інформації в недержавних організаціях, передусім у підрядників уряду США;
- SP 800-61 — настанова з реагування на кіберінциденти; чинною є редакція Rev. 3, а попередню Rev. 2 відкликано у 2025 році;
- SP 800-181 — Workforce Framework for Cybersecurity, більш відомий як NICE.
Звідси практичний висновок: коли в тендері чи в переписці бачите формулювання «стандарт NIST», одразу уточнюйте, про яку саме публікацію йдеться. Без номера документа ця фраза лишається порожньою.
CSF: спільна мова кіберризиків
Найвідоміший продукт інституту — Cybersecurity Framework. У чинній версії 2.0 його побудовано навколо шести функцій:
- Govern (керувати) — управління, ролі, стратегія кіберризиків; функція з'явилася саме у версії 2.0;
- Identify (ідентифікувати) — розуміти власні активи та ризики;
- Protect (захищати) — впроваджувати заходи;
- Detect (виявляти) — помічати атаки;
- Respond (реагувати) — діяти під час інциденту;
- Recover (відновлювати) — повертатися до нормальної роботи.
Але функції — лише верхній шар. Робочим цей каркас роблять ще два елементи, про які згадують значно рідше.
Рівні впровадження (Tiers). Чотири щаблі зрілості: від часткового, коли на події реагують за фактом, до адаптивного, коли безпека вбудована в рішення бізнесу. Рівень — не оцінка «добре чи погано», а орієнтир: наскільки складна практика виправдана для вашого профілю ризиків.
Профілі. Ви описуєте поточний стан і цільовий. Різниця між ними й формує план робіт із бюджетом і пріоритетами — мовою, зрозумілою керівництву без технічних деталей.
Ключове обмеження: за цим фреймворком не сертифікують. Немає ані акредитованих органів, ані документа, який можна показати замовнику. Ідеться про інструмент самооцінки та внутрішньої комунікації, а не про формальне підтвердження відповідності.
Версія 2.0 змінила ще одну важливу річ: якщо перша редакція писалася насамперед під критичну інфраструктуру, то тепер каркас адресований організаціям будь-якого розміру та галузі. Інститут супроводжує його короткими стартовими посібниками — зокрема окремим для малого бізнесу, якому повноцінна програма управління ризиками зазвичай завелика.
Плутанина в назвах: як шукають і що мають на увазі
Абревіатури пишуть у різному порядку, тому в пошуку вони виглядають як різні речі. Насправді за ними стоїть кілька конкретних документів:
| Як пишуть | Що мають на увазі насправді |
|---|---|
| стандарт NIST | Конкретна публікація інституту — найчастіше саме фреймворк кібербезпеки |
| CSF NIST, NIST CSF | Один і той самий каркас, чинна версія 2.0 |
| NIST NICE, NICE NIST, NICE NIST Framework | Кадровий каркас, публікація SP 800-181 |
| OWASP Framework | Не один документ, а набір матеріалів спільноти: Top 10, ASVS, WSTG, SAMM |
Порядок слів у запиті нічого не змінює. Змінює суть лише те, який документ ви зрештою відкриваєте.
Фреймворк про людей, а не про технології
Публікація SP 800-181 відповідає не на питання «що робити», а на питання «хто це робитиме». Її будівельні блоки:
- завдання, знання й навички (Task, Knowledge, Skill) — атоми, з яких складають усе інше;
- робочі ролі (Work Roles) та їхні категорії — від аналітика центру моніторингу до керівника напряму;
- сфери компетентності (Competency Areas) — групи знань і навичок під конкретний домен роботи.
Практична користь очевидна: посадові описи перестають бути переписаними вакансіями конкурентів, план навчання прив'язується до реальних завдань, а кадрові прогалини стає видно ще до того, як звільниться ключовий інженер. Найгостріше проблема проявляється при комплектуванні SOC, де ролі аналітика першої лінії, мисливця за загрозами й інженера з розслідувань часто звалюють на одну людину.
Корисна деталь для українських компаній: існує офіційний український переклад цього каркаса, підготовлений за підтримки Посольства США. Тобто формулювання ролей і завдань не доведеться перекладати самотужки.
OWASP: рівень коду й застосунків
Open Worldwide Application Security Project — некомерційна спільнота, яка створює відкриті матеріали з безпеки застосунків. Раніше другу літеру абревіатури розшифровували як Web, тепер — як Worldwide. Найвідоміший продукт спільноти — Top 10, перелік найкритичніших ризиків вебзастосунків.
Тут ховається типова помилка. Top 10 — документ про поінформованість, а не контрольний список для перевірки відповідності. Пройти по ньому й поставити десять галочок не вийде: частину категорій, як-от небезпечне проєктування, узагалі неможливо перевірити тестом. У чинній редакції 2025 року першу позицію знову посідає порушений контроль доступу, друга — помилки конфігурації, а серед новацій — окрема категорія збоїв у ланцюгу постачання програмного забезпечення.
Для перевірок спільнота дає інші матеріали:
- ASVS — перевірні вимоги до застосунку, згруповані за рівнями довіри; їх зручно виносити в договір із підрядником;
- WSTG — методика тестування, на яку спираються під час пентесту сайту;
- SAMM — модель зрілості процесів безпечної розробки;
- Cheat Sheets — короткі довідки для розробників із конкретними прикладами коду.
Хто за що відповідає
| Що | Поверх | Що дає | Сертифікація |
|---|---|---|---|
| ISO 27001 | Управління | Система управління інформаційною безпекою, визнана партнерами й аудиторами | Так |
| CSF | Стратегія й ризики | Оцінка зрілості, профілі, мова розмови з керівництвом | Ні |
| NICE | Люди | Ролі, завдання, навички, план навчання | Ні |
| OWASP | Код і застосунки | Практичні вимоги до розробки та перевірок | Ні |
Як поєднати їх і не роздути бюрократію
Типова помилка — «впроваджуємо все одразу»: чотири паралельні реєстри, чотири набори звітів і нульовий результат. Робоча схема інша:
- Один основний каркас. Якщо потрібен документ для партнерів, тендерів чи інвестора — ISO 27001 і побудована за ним СУІБ.
- Решта — як джерела, а не як паралельні системи. Заходи з Додатка А лишаються основою, а публікації інституту дають деталізацію там, де формулювання вимог надто загальні.
- Зіставлення замість подвійної роботи. Інститут публікує таблиці відповідності між власними функціями, вимогами ISO 27001 і робочими ролями, тож одну й ту саму роботу не доводиться виконувати двічі.
Прив'язка до реальних приводів проста:
- керівникові потрібна оцінка зрілості й мова для розмови про бюджет — беріть функції, рівні та профілі;
- службі безпеки бракує людей під уже описані заходи — беріть ролі, завдання й навички;
- розробникам потрібні перевірні вимоги до коду — беріть матеріали спільноти та аналіз вразливостей;
- аналітикам потрібні дані про свіжі атаки — це вже інший шар, обмін індикаторами через платформи на кшталт MISP.
Жоден із цих інструментів не замінює інший — тим паче впроваджену систему управління.