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

Обсяг та цілі

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

  • Це стосується самостійно розміщених екземплярів Weblate, як локально, так і в хмарній інфраструктурі.

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

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

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

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

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

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

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

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

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

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

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

Підготовка

  • Забезпечте регулярне щоденне резервне копіювання бази даних PostgreSQL та каталогу даних.

  • Захистіть Weblate за допомогою зворотного проксі-сервера (наприклад, NGINX або Apache) та HTTPS (TLS 1.2+).

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

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

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

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

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

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

  • Налаштуйте сповіщення (наприклад, через Prometheus, Zabbix або SIEM) для: - Кілька невдалих спроб входу в систему - Неочікуваних перезапусків служб або піків використання пам’яті - Нерегулярних дій push/pull від системи контролю версій

Стримування

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

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

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

Викорінення

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

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

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

Відновлення

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

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

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

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

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

  • Виконайте аналіз першопричин (RCA).

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

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