Vorfallsreaktionsplan für Weblate

Umfang und Ziele

Dieser Vorfallsreaktionsplan deckt Vorfälle ab, welche die Vertraulichkeit, Integrität oder Verfügbarkeit von mit Weblate betriebenen Bereitstellungen beeinträchtigen.

Bemerkung

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.

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.

Kommunikationsvorgehen

• Interne Kommunikation:

  • Hauptkanal ist Signal für die Koordinierung von Mensch zu Mensch.

  • Technische Warnungen bleiben außerhalb von Signal, um Rauschen zu vermeiden.

• Externe Kommunikation:

  • E-Mail wird verwendet, um Kunden zu erreichen.

  • Kundenkontaktlisten werden an mehreren Orten geführt, um den Zugriff bei Ausfällen des Dienstes zu gewährleisten.

• Öffentliche Bekanntmachung:

  • If an incident includes a Weblate product vulnerability, follow the product vulnerability reporting process and Richtlinie zur Offenlegung von Schwachstellen in Schwachstellen und Umgang mit Vorfällen.

Vorfallskategorien und Schweregrad

Auslösung eines Vorfalls

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

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

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

Kategorien von Vorfällen

• Kategorie 1 – Unbefugter Zugriff

• Kategorie 2 – Verstoß gegen die Datenintegrität

• Kategorie 3 – Dienstausfall oder -verschlechterung

• Kategorie 4 – Fehlkonfiguration oder Bereitstellungsfehler

Schweregrade und Service-Level-Vereinbarungen

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.

Gewichtung	Definition	Zielvorgabe für Bestätigung	Zielvorgabe für erste Maßnahme
Kritisch	Totalausfall; Kompromittierung der Administratoren; Aktive Datenpanne; sofortige Eindämmung erforderlich.	< 30 Minuten	< 4 Stunden
Hoch	Ausfall einer Kernfunktion; Offenlegung personenbezogener Daten eines einzelnen Benutzers.	< 2 Stunden	12 Stunden
Mittel	Leistungsverschlechterung; Geringfügiges Sicherheitsproblem.	1 Arbeitstag	3 Arbeitstage
Niedrig	UI-Fehler; Staging-Probleme; Nicht sicherheitsrelevante Fehler.	Bestmögliches Ergebnis	Bestmögliches Ergebnis

Lebenszyklus der Vorfallsreaktion

Vorbereitung

• Sorgen Sie für regelmäßige tägliche Sicherungen der PostgreSQL-Datenbank und des Datenverzeichnisses mit der in Weblate integrierten Sicherung mit Rotation, siehe Weblate sichern und verschieben.

• Stellen Sie sicher, dass Weblate einen korrekt konfigurierten Reverse-Proxy (z. B. NGINX) mit HTTPS (TLS 1.2+) verwendet.

• Aktivieren Sie 2FA für alle Konten auf Administratorebene.

• Halten Sie die Weblate-Instanz und ihre Abhängigkeiten (Python, Django, Celery, Datenbank usw.) auf dem neuesten Stand.

• Integrieren Sie SIEM-Systeme mithilfe des GELF-Protokolls für die Weiterleitung von Audit- und Anwendungsprotokollen.

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

Identifizierung

• Überwachen Sie System- und Anwendungsprotokolle (journalctl, Reverse-Proxy-Protokolle, Weblate-Anwendungs- und Auditprotokolle).

• Analysieren Sie Ereignisse bei der Anmeldung, Webhook-Ausführungen und Push-/Pull-Fehler.

• Konfigurieren Sie Warnmeldungen (über Prometheus, Zabbix oder SIEM) bei mehrfachen Anmeldefehlern, unerwarteten Neustarts oder unregelmäßigen VCS-Aktionen.

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

Eindämmung

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

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

• Bei Vorfällen der Kategorie 1 oder 2 sollten Sie einen manuellen Hetzner Cloud Snapshot erstellen, bevor Sie störende Maßnahmen ergreifen, wenn es sicher ist, dies zu tun.

  • Namensformat: IRP-[CaseID]-[YYYYMMDD]-Evidence.

  • Diese unterscheiden sich von den standardmäßigen rotierenden Sicherungen und müssen für Analysezwecke aufbewahrt werden.

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

• Deaktivieren Sie externe Integrationen (Git/Webhooks), wenn diese Teil des Angriffsvektors sind.

• Sperren Sie betroffene Benutzerkonten sofort.

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

Eliminierung

• Entfernen Sie alle nicht autorisierten Codes oder Daten.

• Schließen Sie bekannte Sicherheitslücken, indem Sie Weblate oder Serverkomponenten aktualisieren.

• Validieren Sie die Integrität von Binärdateien und Repositorys anhand von SHA-256-Prüfsummen oder Git-Protokollen.

Wiederherstellung

• Stellen Sie betroffene Dienste oder Daten aus den letzten als funktionierend bekannten Weblate-Sicherungen wieder her.

• Führen Sie die Dienste schrittweise wieder ein.

• 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 handler records the decision to return to normal operations, checking recovery with the backup or another teammate where practical.

• Überwachen Sie die Protokolle und das Systemverhalten kontinuierlich für mindestens 72 Stunden nach der Wiederherstellung.

Überprüfung nach Vorfall

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

• Erstellen Sie einen vollständigen Zeitplan für den Vorfall und die ergriffenen Maßnahmen.

• Führen Sie eine Fehler-Ursachen-Analyse durch und dokumentieren Sie diese innerhalb von 10 Arbeitstagen.

• Aktualisieren Sie die Dokumentation zu den Sicherheitsrichtlinien und zum Vorfallsreaktionsplan auf Grundlage der Ergebnisse.

• Überprüfen Sie die Wirksamkeit der Erkennungs- und Eindämmungsmechanismen.

• Verify whether escalation, alerting, and external communication followed Schwachstellen und Umgang mit Vorfällen as expected.

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