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

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

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

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

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

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

1. вступ

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

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

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

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

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

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

   Деталі попередження розкривають таку інформацію: Account : sysadmin_jsmith (системний адміністратор) Джерело IP : 185.220.101.45 (Східна Європа) Failed спроб : 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% без увімкненої багатофакторної автентифікації. Ця прогалина в безпеці дозволила зловмиснику отримати доступ, використовуючи лише вкрадені облікові дані.