Що таке вразливість в ISO 27001?

Огляд

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

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

Вразливості на практиці

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

Рівняння ризику: Ризик = Загроза × Вразливість × Цінність активу × Вплив

Контролі з Додатка A призначені для зменшення або усунення вразливостей, що ускладнює успіх загроз.

Категорії вразливостей

Технічні вразливості

Слабкості в технологічних системах та програмному забезпеченні:

• Неоновлене програмне забезпечення: Відомі вразливості в операційних системах, додатках або прошивках
• Неправильні конфігурації: Небезпечні налаштування (паролі за замовчуванням, відкриті порти, надмірні дозволи)
• Слабке шифрування: Застарілі криптографічні алгоритми або неналежне управління ключами
• Відсутність валідації вхідних даних: Код, вразливий до SQL-ін'єкцій, міжсайтового скриптингу
• Відсутність засобів захисту: Немає брандмауера, антивірусу або системи виявлення вторгнень

Приклад: Сервер електронної комерції з застарілим програмним забезпеченням, що має відому вразливість віддаленого виконання коду. Загроза: Зовнішній зловмисник. Контроль: Управління оновленнями (A.8.8).

Людські вразливості

Слабкості, пов'язані з людьми та їхньою поведінкою:

• Відсутність обізнаності з питань безпеки: Співробітники не знають про фішинг, соціальну інженерію або політику безпеки
• Недостатнє навчання: Персонал не вміє безпечно обробляти конфіденційні дані
• Неналежні практики роботи з паролями: Слабкі, повторно використані або спільні паролі
• Надмірні привілеї: Користувачі мають більше доступу, ніж потрібно для їхньої ролі
• Відсутність розподілу обов'язків: Одна людина контролює критичні процеси

Приклад: Співробітники без навчання з питань безпеки вразливі до фішингових атак. Загроза: Соціальна інженерія. Контроль: Навчання з питань безпеки (A.6.3).

Вразливості процесів

Слабкості в організаційних процедурах та робочих процесах:

• Відсутність управління змінами: Зміни в системах проводяться без перевірки або тестування
• Недостатній аудит доступу: Колишні співробітники все ще мають активні облікові записи
• Слабке реагування на інциденти: Немає плану виявлення та реагування на події безпеки
• Неналежне управління постачальниками: Сторонні компанії не оцінюються на ризики безпеки
• Відсутність процедур резервного копіювання: Немає надійного відновлення після втрати даних

Приклад: Відсутність процесу деактивації облікових записів при звільненні співробітників створює вразливість для несанкціонованого доступу. Загроза: Ображений колишній співробітник. Контроль: Управління життєвим циклом ідентифікації (A.5.18).

Фізичні вразливості

Слабкості у фізичній безпеці:

• Незахищені приміщення: Відсутність контролю доступу до серверних кімнат або офісів
• Недостатні екологічні контролі: Відсутність систем пожежогасіння, моніторингу температури
• Незахищене обладнання: Сервери, ноутбуки або носії резервних копій залишаються без нагляду
• Неналежне управління відвідувачами: Необмежений доступ для постачальників або гостей

Приклад: Серверна кімната, доступна всім співробітникам, вразлива до крадіжки або саботажу. Загроза: Зловмисний інсайдер. Контроль: Фізичний контроль доступу (A.7.2).

Методи оцінки вразливостей

ISO 27001:2022 вимагає ідентифікації вразливостей як частини оцінки ризиків (пункт 6.1.2). Поширені методи оцінки включають:

Автоматизоване сканування вразливостей

Використання інструментів для сканування систем на наявність відомих вразливостей (CVE), неправильних конфігурацій та відсутніх оновлень.

Інструменти: Nessus, Qualys, OpenVAS, сканери хмарних провайдерів (AWS Inspector, Azure Security Center).

Тестування на проникнення

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

Аудит коду

Ручний або автоматизований аналіз вихідного коду додатків для пошуку вразливостей.

Аудит конфігурацій

Перевірка налаштувань систем на відповідність базовим вимогам безпеки (CIS Benchmarks, рекомендації виробників щодо захисту).

Аналіз розривів

Порівняння поточних контролів з вимогами Додатка A для виявлення відсутніх або слабких контролів.

Життєвий цикл вразливостей

Управління вразливостями відбувається за безперервним циклом:

1. Виявлення: Пошук вразливостей за допомогою сканування, аудитів, розвідки загроз
2. Оцінка: Визначення ступеня серйозності на основі можливості експлуатації та потенційного впливу
3. Пріоритизація: Ранжування вразливостей за рівнем ризику (враховуючи оцінки CVSS, контекст загроз, критичність активу)
4. Усунення: Застосування оновлень, переналаштування систем, впровадження компенсуючих контролів
5. Перевірка: Підтвердження усунення вразливостей
6. Моніторинг: Безперервне відстеження нових вразливостей

Вразливість, загроза та ризик

Ці поняття взаємодіють під час оцінки ризиків:

• Вразливість: Слабкість, яку можна експлуатувати (наприклад, неоновлений веб-сервер)
• Загроза: Потенційна причина шкоди, яка використовує слабкість (наприклад, автоматизований бот, що сканує вразливі сервери)
• Ризик: Ймовірність та вплив експлуатації вразливості загрозою (наприклад, високий ризик витоку даних через атаку SQL-ін'єкції)

Вибір контролів: Впровадження управління вразливостями (A.8.8), безпечних конфігурацій (A.8.9) та засобів захисту веб-додатків для зниження ризику.

Поширені приклади вразливостей

Технологічна компанія

• Вразливість: Кінцеві точки API не мають обмеження кількості запитів
• Загроза: Атака підбору облікових даних
• Ризик: Перехоплення облікових записів та витік даних
• Контроль: Впровадження обмеження кількості запитів та моніторингу (A.8.16)

Медична організація

• Вразливість: Медичні пристрої в мережі з паролями за замовчуванням
• Загроза: Поширення програм-вимагачів через мережу
• Ризик: Порушення надання медичної допомоги та шифрування даних
• Контроль: Сегментація мережі (A.8.22), політика паролів (A.5.17)

Фінансові послуги

• Вразливість: Співробітники не обізнані з фішингом
• Загроза: Цілеспрямована фішингова кампанія
• Ризик: Шахрайство з переказом коштів або крадіжка облікових даних
• Контроль: Навчання з питань безпеки (A.6.3), фільтрація електронної пошти (A.8.7)

Вимоги до документації

Ваша документація з оцінки ризиків повинна включати:

• Виявлені вразливості для кожного активу
• Оцінку серйозності та можливості експлуатації
• Які загрози можуть використати кожну вразливість
• Вибрані контролі для усунення вразливостей
• Терміни усунення
• Залишкові вразливості, прийняті з обґрунтуванням

Пов'язані терміни

• Threat – Те, що експлуатує вразливості
• Risk Assessment – Процес виявлення вразливостей
• Asset – Те, що містить вразливості
• Control – Заходи, що зменшують вразливості