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

Обсяг та цілі

This IRP covers incidents impacting the confidentiality, integrity, or availability of Weblate-operated deployments.

Примітка

This plan is specifically designed for deployments operated by Weblate s.r.o. Other deployments need to adapt provider-specific and organizational steps to their own environment.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Incident activation

  • Declare an incident when an event is confirmed or strongly suspected to affect the confidentiality, integrity, or availability of the service beyond routine operational noise.

  • The Security Officer declares the incident, assigns the initial severity, and appoints the Incident Response Lead (IRL).

  • If the Security Officer is unavailable, any available senior operator may declare the incident and hand over ownership as soon as practical.

  • Reclassify the incident if the scope or impact changes during investigation.

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

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

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

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

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

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

Серйозність

Визначення

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

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

Критичний

Total outage; Admin compromise; Active data breach; requires immediate containment.

< 30 Хвилин

< 4 Hours

Викокий

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

< 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.

Стримування

  • Create an incident record with a case ID and record timeline updates as actions are taken.

  • Coordinate human response in Signal and keep technical alerting in the existing monitoring systems.

  • For Category 1 or 2 incidents, create a manual Hetzner Cloud Snapshot before taking disruptive action when it is safe to do so.

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

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

  • Isolate the affected host or service as needed (for example by firewall rules or service isolation).

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

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

  • Revoke or rotate affected administrative, API, VCS, and webhook credentials as applicable.

  • Preserve relevant evidence, including system logs, reverse proxy logs, Weblate application and audit logs, affected configuration state, and the list of impacted credentials or integrations.

Викорінення

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

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

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

Відновлення

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

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

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

  • Confirm the root cause has been removed or a compensating control is in place before restoring normal traffic.

  • Rotate affected credentials and verify integrity of the restored system, repositories, and configuration.

  • The Security Officer and IRL approve returning to normal operations.

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

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

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

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

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

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

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

  • Verify whether escalation, alerting, and external communication followed Вразливість та обробка інцидентів as expected.