Реагування на інциденти безпеки

Що таке Реагування на інциденти безпеки?

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

Що ви дізнаєтесь у Реагування на інциденти безпеки

• Проводьте первинний розбір інциденту безпеки, щоб визначити, чи був доступ до персональних даних, чи їх викрадено або скомпрометовано
• Розпізнавайте, коли починається 72-годинний відлік за статтею 33 і чому він не чекає завершення розслідування
• Оцінюйте, чи ймовірно порушення призведе до ризику або до високого ризику для людей, чиї дані викрадено
• Негайно передавайте підтверджене порушення команді реагування на інциденти та DPO
• Документуйте хронологію інциденту та вжиті дії реагування, як того вимагає стаття 33(5)

Реагування на інциденти безпеки — Кроки навчання

1. Вступ

   Це навчання покаже, як реагувати на інциденти відповідно до вимог GDPR: оцінювати події безпеки, визначати вимоги до повідомлення про порушення та запускати потрібні процедури, коли під загрозою можуть бути персональні дані.

2. Початок зміни

   Аліса починає ранкову зміну в центрі моніторингу безпеки (SOC). На панелі звичайний рівень активності: кілька рутинних сповіщень, які нічна зміна вже розібрала. SecureNet Financial обробляє платежі для сотень корпоративних клієнтів. SOC цілодобово стежить за несанкціонованим доступом, викраденням даних, порушеннями політик та іншими подіями безпеки.

3. Сповіщення високої серйозності

   Раптом на панелі з'являється сповіщення високої серйозності. Система SIEM виявила незвичні спроби входу: кілька невдалих автентифікацій, а за ними — успішний вхід із закордонної IP-адреси. Сповіщення вказує, що обліковий запис належить системному адміністраторові з розширеними привілеями. Це може бути атака перебором паролів, яка призвела до компрометації облікових даних.

4. Аналіз сповіщення про вхід

   Подробиці сповіщення тривожні: Обліковий запис : sysadmin_jsmith (системний адміністратор) IP-адреса джерела : 185.220.101.45 (Східна Європа) Невдалі спроби : 47 за 3 години Успішний вхід : 06:47 за місцевим часом Тривалість сеансу : 1 година 37 хвилин (сеанс досі триває) Справжній власник облікового запису Джон Сміт зараз у відпустці в Іспанії, а вхід виконано зовсім з іншої країни.

5. Друге сповіщення

   Під час перегляду сповіщення про вхід з'являється друге — середньої серйозності. Система запобігання втраті даних (DLP) позначила запит на великий експорт даних. Хтось скористався скомпрометованим обліковим записом системного адміністратора, щоб експортувати записи клієнтів із продакшн-бази даних. Експорт завершився раніше, ніж автоматичні системи встигли його заблокувати.

6. Масштаби витоку

   Сповіщення про експорт показує, наскільки великою може бути шкода: Експортовано записів : 50 000 записів клієнтів Типи даних : повні імена, адреси електронної пошти, номери телефонів, номери фінансових рахунків, історія транзакцій Куди експортовано : зовнішній FTP-сервер (IP: 185.220.101.89) Час експорту : 07:15 за місцевим часом Це вже не просто подія безпеки, а викрадення даних: персональні дані потрапили на зовнішній сервер, який контролюють невідомі особи.

7. Підтвердження сповіщень

   Аліса має підтвердити обидва сповіщення, щоб показати: їх зараз розслідують. Так у журналі аудиту з'являється запис про те, коли в SOC стало відомо про потенційне порушення. За GDPR вважається, що організації стало відомо про порушення, коли SOC виявляє інцидент із персональними даними, а не коли розслідування завершується.

8. Підтвердження сповіщення про експорт даних

   Несанкціонований доступ позначено як підтверджений. Тепер Аліса має підтвердити й сповіщення про експорт даних. Коли підтверджено обидва сповіщення, є чітка відмітка часу, з якого компанії SecureNet Financial стало відомо про потенційне порушення, що стосується персональних даних.

9. Перевірка стану дотримання вимог

   Перш ніж передати інцидент далі, Аліса відкриває панель дотримання вимог, щоб зрозуміти, який зараз загальний рівень захищеності організації. Це допоможе з'ясувати, які засоби захисту могли дати збій. Якщо знати наявні прогалини в дотриманні вимог, легше пояснити, як стався витік і з чого почати зменшення ризику.

10. Виявлення вразливості

    Панель дотримання вимог показує критичну проблему: Керування згодами : відповідає вимогам Час відповіді на запити DSAR : відповідає вимогам Шифрування даних : відповідає вимогам Примусове застосування MFA : попередження — у 23% облікових записів адміністраторів немає MFA Зберігання даних : відповідає вимогам Скомпрометований обліковий запис системного адміністратора був одним із тих 23%, у яких не ввімкнено багатофакторну автентифікацію (MFA). Через цю прогалину зловмисникові вистачило викрадених облікових даних, щоб отримати доступ.