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

Coordinate security and privacy teams during a live breach.

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

Реагування на інциденти безпеки за GDPR вимагає від організацій визначити, чи пов'язаний інцидент безпеки з персональними даними, і якщо так, дотриматися конкретних процедур оцінки та повідомлення в стислі регуляторні строки. Не кожен інцидент безпеки є витоком даних, але кожен витік даних починається як інцидент безпеки. Швидке та точне визначення цього — основна навичка, яку розвиває ця вправа. Ви опиняєтесь на чолі активного інциденту безпеки, де Ваш мережевий моніторинг виявляє підозрілі патерни ексфільтрації даних. Ви повинні координувати дії між IT-безпекою, яка хоче стримати та розслідувати загрозу, та командою конфіденційності, яка повинна оцінити наслідки для персональних даних та управляти регуляторними зобов'язаннями. Ці два пріоритети іноді суперечать один одному: форензичне розслідування може вимагати збереження скомпрометованих систем онлайн для збору доказів, тоді як захист даних вимагає негайного стримування. Вправа проведе Вас через побудову крос-функціонального робочого процесу реагування на інциденти, що задовольняє обидві цілі. Ви практикуватимете дерево рішень класифікації: визначення серйозності інциденту, встановлення, чи був доступ до персональних даних або їх ексфільтрація, оцінка кількості постраждалих осіб та оцінка ризику для їхніх прав. Якщо інцидент кваліфікується як витік персональних даних, Ви повинні активувати процес повідомлення за статтею 33, поки розслідування ще триватиме, що означає звітування наглядовому органу з неповною інформацією та зобов'язання щодо поетапних оновлень. Відповідно до звіту IBM Cost of a Data Breach 2024, організації з перевіреними планами реагування на інциденти зменшують середню вартість витоку на 2,66 мільйона доларів США порівняно з тими, хто їх не має.

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

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

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