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

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

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

Примечание

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

Handling an incident

One team member handles the incident and names an available teammate as a backup. They coordinate investigation, containment, recovery, reporting, and user communication, asking other teammates or outside specialists for help when needed. The backup takes over when the handler is unavailable.

Use Incident reporting for reporting decisions, deadlines, and a private incident note. No separate management approval is needed to begin responding.

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

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

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

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

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

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

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

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

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

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

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

  • Whoever identifies the incident alerts teammates through Signal. An available teammate takes responsibility, records the initial severity, and names a backup.

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

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

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

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

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

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

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

These are operational response targets, not a statement of continuous staffing. Assess product-security reporting separately using Incident reporting; these targets do not extend reporting deadlines.

Уровень

Определение

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

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

Важно

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

< 30 минут

< 4 часов

Высокий

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

< 2 часов

12 часов

Средний

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

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

3 рабочих дня

Низкий

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

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

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

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

Подготовка

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

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

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

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

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

  • Complete the preparation checklist in Incident reporting and keep private contact and access details current.

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

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

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

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

  • Record awareness times and assess authority and user notifications using Incident reporting, without waiting for a complete investigation.

  • Assess whether a security incident caused accidental or unlawful destruction, loss, or alteration of personal data, or unauthorized disclosure or access, and follow Personal-data breach notifications. This includes availability or integrity breaches without disclosure, such as accidental deletion or ransomware destruction. Seek privacy advice where needed while continuing investigation and reporting preparation.

Personal-data breach notifications

The incident handler determines whether Weblate acts as controller or processor for the affected processing and records the assessment in the private incident note. Under GDPR Article 33:

  • As controller, notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the personal-data breach, unless the breach is unlikely to result in a risk to individuals“ rights and freedoms. Record the reason for a decision not to notify.

  • If notification takes longer than 72 hours, include the reasons for the delay. Where information cannot be supplied together, provide it in stages without undue further delay.

  • As processor, notify the controller without undue delay after becoming aware of a personal-data breach; do not wait for the controller’s 72-hour deadline.

The controller’s supervisory-authority notification must include the following information under Article 33(3):

  • The nature of the breach, including, where possible, the categories and approximate numbers of affected individuals and personal-data records.

  • The name and contact details of the person who can provide further information, such as the incident handler or a data protection officer if one is appointed.

  • The likely consequences of the breach.

  • Measures taken or proposed to address the breach, including measures to reduce its adverse effects where appropriate.

Identify information that is not yet available and provide it in follow-up notifications without undue further delay. Do not wait for exact counts before notifying the authority.

As controller, separately assess communication to affected individuals under GDPR Article 34. If the breach is likely to create a high risk to their rights and freedoms, inform them without undue delay unless an Article 34(3) exception applies. This applies even without active exploitation or a severe product-security incident. Notification to the supervisory authority does not replace this communication.

Explain the breach in clear language, giving a contact for further information, likely consequences, measures taken or proposed, and actions individuals can take. Record the assessment and any exception relied on: effective protection of the affected data, such as encryption making it unreadable to unauthorized people, or subsequent measures ensuring the high risk is no longer likely. If individual communication would involve disproportionate effort, use public communication or a similar measure that informs individuals equally effectively. See the EDPB data-breach guidance.

Record breach-awareness timestamps, recipients, and deadlines separately from CRA reporting. A CRA submission does not replace a GDPR notification, and the two reporting clocks may start at different times.

Сдерживание

  • Maintain the private incident note from Incident reporting, including timeline updates, reporting deadlines, and submission receipts.

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

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

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

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

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

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

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

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

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

Искоренение

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

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

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

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

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

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

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

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

  • The handler records the decision to return to normal operations, checking recovery with the backup or another teammate where practical.

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

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

  • Timeline: Hold a short team review within 5 business days of incident closure.

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

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

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

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

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

  • Check for outstanding reports, promised updates, and delayed disclosures before closing the incident note.