План реагирования на инциденты для Weblate

Область применения и цели

Этот IRP охватывает инциденты, влияющие на конфиденциальность, целостность или доступность развёртываний, управляемых Weblate.

Примечание

Этот план специально разработан для развёртываний, управляемых Weblate s.r.o. Другим развёртываниям необходимо адаптировать шаги, специфичные для поставщика и организации, к своей собственной среде.

Роли и обязанности

  • Ведущий реагирования на инциденты (IRL): Координирует все фазы процесса реагирования.

  • Системный администратор: Выполняет меры по локализации и восстановлению.

  • Сотрудник по безопасности: Оценивает влияние на безопасность и регуляторные последствия.

  • Сотрудник по защите данных (DPO): Оценивает, были ли скомпрометированы персональные данные (PII), и управляет обязательными уведомлениями GDPR.

  • Ведущий по коммуникациям: Управляет уведомлениями для внутренних заинтересованных сторон и внешних сторон, если требуется.

Логистика связи

  • Внутренняя связь:

    • Основным каналом для координации между людьми является Signal.

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

  • Внешняя связь:

    • Электронная почта используется для связи с клиентами.

    • Списки контактов клиентов поддерживаются в нескольких местах, чтобы обеспечить доступ во время сбоев в обслуживании.

  • Публичное раскрытие:

Категории инцидентов и серьёзность

Активация инцидента

  • Объявите инцидент, когда событие подтверждено или есть сильное подозрение, что оно влияет на конфиденциальность, целостность или доступность службы сверх обычного операционного шума.

  • Сотрудник по безопасности объявляет инцидент, назначает начальную степень серьёзности и назначает Ведущего реагирования на инциденты (IRL).

  • Если сотрудник по безопасности недоступен, любой доступный старший оператор может объявить инцидент и передать ответственность, как только это станет возможным.

  • Переклассифицируйте инцидент, если в ходе расследования изменятся масштаб или воздействие.

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

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

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

  • Категория 3 – Сбой или деградация службы

  • Категория 4 – Ошибка конфигурации или развёртывания

Уровни серьёзности и соглашения об уровне обслуживания (SLA)

Уровень

Определение

Подтверждение цели

Начальное действие цели

Важно

Полный сбой; Компрометация администратора; Активная утечка данных; требует немедленной локализации.

< 30 минут

< 4 часов

Высокий

Сбой основной функции; Утечка PII одного пользователя.

< 2 часов

12 часов

Средний

Деградация производительности; Незначительная проблема безопасности.

1 рабочий день

3 рабочих дня

Низкий

Ошибки интерфейса; Проблемы промежуточной среды; Ошибки, не связанные с безопасностью.

По мере возможности

По мере возможности

Жизненный цикл реагирования на инциденты

Подготовка

  • Обеспечьте регулярное ежедневное резервное копирование базы данных PostgreSQL и каталога данных с помощью встроенной функции резервного копирования Weblate с ротацией, см. Резервное копирование и перенос Weblate.

  • Убедитесь, что Weblate использует правильно настроенный обратный прокси-сервер (например, NGINX) с HTTPS (TLS 1.2+).

  • Включите двухфакторную аутентификацию для всех учётных записей уровня администратора.

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

  • Интегрируйтесь с системами SIEM, используя протокол GELF для пересылки журналов аудита и приложений.

Идентификация

  • Отслеживайте системные журналы и журналы приложений (journalctl, журналы обратного прокси-сервера, журналы приложений и аудита Weblate).

  • Анализируйте события входа в систему, выполнение веб-обработчиков и сбои отправки/извлечения.

  • Настройте оповещение (через Prometheus, Zabbix или SIEM) о множественных сбоях входа в систему, неожиданных перезапусках или нерегулярных действиях СКВ.

Сдерживание

  • Создайте запись об инциденте с идентификатором дела и фиксируйте обновления временной шкалы по мере выполнения действий.

  • Координируйте реагирование людей в Signal и сохраните техническое оповещение в существующих системах мониторинга.

  • Для инцидентов категории 1 или 2 создайте Hetzner Cloud Snapshot вручную перед выполнением разрушительных действий, когда это безопасно.

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

    • Они отделены от стандартных ротационных резервных копий и должны храниться для анализа.

  • Изолируйте затронутый узел или службу по мере необходимости (например, с помощью правил брандмауэра или изоляции службы).

  • Отключите внешние интеграции (Git/веб-обработчики), если они являются частью вектора атаки.

  • Немедленно приостановите действие затронутых учётных записей пользователей.

  • Отзовите или смените затронутые учётные данные администратора, API, СКВ и веб-обработчиков, если применимо.

  • Сохраните соответствующие доказательства, включая системные журналы, журналы обратного прокси-сервера, журналы приложений и аудита Weblate, состояние затронутой конфигурации и список затронутых учётных данных или интеграций.

Искоренение

  • Удалите любой неавторизованный код или данные.

  • Устраните известные уязвимости путём обновления Weblate или компонентов сервера.

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

Восстановление

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

  • Оценка PII: Сотрудник по защите данных (DPO) определяет, требует ли утечка 72-часового уведомления GDPR.

  • Восстановите службы поэтапно.

  • Подтвердите, что основная причина устранена или установлен компенсирующий контроль, прежде чем восстанавливать нормальный трафик.

  • Смените затронутые учётные данные и проверьте целостность восстановленной системы, репозиториев и конфигурации.

  • Сотрудник по безопасности и Ведущий реагирования на инциденты (IRL) одобряют возврат к нормальной работе.

  • Непрерывно отслеживайте журналы и поведение системы в течение как минимум 72 часов после восстановления.

Анализ после инцидента

  • Временная шкала: Проведите совещание по рассмотрению в течение 5 рабочих дней после закрытия инцидента.

  • Составьте полную временную шкалу инцидента и принятые меры.

  • Выполните анализ основных причин (RCA) и задокументируйте его в течение 10 рабочих дней.

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

  • Оцените эффективность механизмов обнаружения и локализации.

  • Проверьте, соответствуют ли эскалация, оповещение и внешняя коммуникация Обработка уязвимостей и инцидентов.