План реагування на інциденти для 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, щоб уникнути шуму.

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

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

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

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

  • If an incident includes a Weblate product vulnerability, follow the product vulnerability reporting process and Політика розкриття інформації про вразливості in Вразливість та обробка інцидентів.

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

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

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

• 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 Години
Викокий	Відмова основної функції; витік персональних даних одного користувача.	< 2 Години	12 Години
Середній	Погіршення продуктивності; Незначна проблема безпеки.	1 Робочий день	3 Робочі дні
Низький	Помилки інтерфейсу користувача; Проблеми зі стадією; Помилки, не пов’язані з безпекою.	Найкращі зусилля	Найкращі зусилля

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

Підготовка

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

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

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

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

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

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

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

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

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

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

• 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, систем контролю версій (VCS) та веб-хуків.

• Збережіть відповідні докази, зокрема системні журнали, журнали зворотного проксі-сервера, журнали роботи додатка 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.