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

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

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

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

1. вступ

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

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

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

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

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

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

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

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% без увімкненої багатофакторної автентифікації. Ця прогалина в безпеці дозволила зловмиснику отримати доступ, використовуючи лише вкрадені облікові дані.