План реагування на інциденти для Weblate

Обсяг та цілі

Цей IRP охоплює інциденти, що впливають на конфіденційність, цілісність або доступність розгортання Weblate.

Примітка

Цей план спеціально розроблений для розгортання Weblate компанією Weblate s.r.o., але його можна аналогічно застосувати до інших розгортань.

Ролі та обов’язки

  • Керівник реагування на інциденти (IRL): Координує всі етапи процесу реагування.

  • Системний адміністратор: Виконує заходи щодо стримування та відновлення.

  • Співробітник служби безпеки: Оцінює вплив на безпеку та нормативні наслідки.

  • Спеціаліст із захисту даних (DPO): оцінює, чи було порушено безпеку персональних даних (PII), та управляє обов’язковими повідомленнями відповідно до GDPR.

  • Керівник відділу комунікацій: Здійснює сповіщення внутрішніх зацікавлених сторін та зовнішніх сторін, якщо це необхідно.

Логістика комунікацій

  • Внутрішня комунікація:

    • Основним каналом для координації між людьми є Signal.

    • Технічні сповіщення залишаються поза межами Signal, щоб уникнути шуму.

  • Зовнішня комунікація:

    • Електронна пошта використовується для зв’язку з клієнтами.

    • Списки контактів клієнтів зберігаються в декількох місцях, щоб забезпечити доступ до них під час перебоїв у наданні послуг.

  • Публічне розкриття інформації:

Категорії інцидентів та їх серйозність

Категорії інцидентів

  • Категорія 1 – Несанкціонований доступ

  • Категорія 2 – Порушення цілісності даних

  • Категорія 3 – Збій або погіршення якості обслуговування

  • Категорія 4 – Неправильна конфігурація або помилка розгортання

Рівні серйозності та SLA

Серйозність

Визначення

Підтвердження цілі

Ціль Початкова дія

Критичний

Повна відмова; компрометація адміністратора; активне порушення безпеки даних.

< 30 Хвилин

4 Годин

Викокий

Відмова основної функції; витік персональних даних одного користувача.

< 2 Години

12 Години

Середній

Погіршення продуктивності; Незначна проблема безпеки.

1 Робочий день

3 Робочі дні

Низький

Помилки інтерфейсу користувача; Проблеми зі стадією; Помилки, не пов’язані з безпекою.

Найкращі зусилля

Найкращі зусилля

Життєвий цикл реагування на інциденти

Підготовка

  • Забезпечте регулярне щоденне резервне копіювання бази даних PostgreSQL та каталогу даних за допомогою вбудованої функції резервного копіювання Weblate з ротацією, див. Резервне копіювання і пересування Weblate.

  • Переконайтеся, що Weblate використовує правильно налаштований зворотний проксі-сервер (наприклад, NGINX) з HTTPS (TLS 1.2+).

  • Увімкніть 2FA для всіх облікових записів рівня адміністратора.

  • Підтримуйте екземпляр Weblate та його залежності (Python, Django, Celery, базу даних тощо) в актуальному стані.

  • Інтеграція з SIEM-системами за допомогою протоколу GELF для аудиту та пересилання журналів додатків.

Ідентифікація

  • Моніторинг системних та програмних журналів (journalctl, журналів зворотного проксі-серверу, журналів програм та аудиту Weblate).

  • Аналізуйте події входу, виконання вебхуків та збої push/pull.

  • Налаштуйте сповіщення (через Prometheus, Zabbix або SIEM) про кілька невдалих спроб входу, несподівані перезапуски або нерегулярні дії VCS.

Стримування

  • Збереження для судово-медичної експертизи: для інцидентів категорії 1 або 2 створіть ручний знімок Hetzner Cloud перед тим, як вживати заходів, що можуть спричинити перебої в роботі.

    • Форма імені: IRP-[CaseID]-[YYYYMMDD]-Evidence.

    • Вони відрізняються від стандартних обертових резервних копій і повинні зберігатися для аналізу.

  • Тимчасово обмежте доступ (наприклад, за допомогою правил брандмауера або ізоляції служб).

  • Вимкніть зовнішні інтеграції (Git/вебхуки), якщо вони є частиною вектора атаки.

  • Негайно призупиніть дію облікових записів користувачів, яких це стосується.

Викорінення

  • Видаліть будь-який неавторизований код або дані.

  • Виправте відомі вразливості, оновивши Weblate або серверні компоненти.

  • Перевірте цілісність бінарного файлу та репозиторію за допомогою контрольних сум SHA-256 або журналів Git.

Відновлення

  • Відновіть уражені служби або дані з останніх відомих надійних резервних копій Weblate.

  • Оцінка PII: DPO визначає, чи вимагає порушення 72-годинного повідомлення відповідно до GDPR.

  • Відновлювати послуги поетапно.

  • Безперервно контролюйте журнали та поведінку системи протягом щонайменше 72 годин після відновлення.

Огляд після інциденту

  • Термін: Провести нараду з підбиттям підсумків протягом 5 робочих днів після закриття інциденту.

  • Складіть повний хронологічний опис інциденту та вжитих заходів.

  • Проведіть аналіз першопричин (RCA) та задокументуйте його протягом 10 робочих днів.

  • Оновити політику безпеки та документацію IRP на основі отриманих результатів.

  • Перевірте ефективність механізмів виявлення та стримування.