Incident herstelplan (Incident response plan (IRP)) voor Weblate

Bereik en doelen

Dit IRP behandelt incidenten die impact hebben op de vertrouwelijkheid, integriteit of beschikbaarheid van door Weblate uitgevoerde uitrollen.

Notitie

Dit plan is specifiek ontworpen voor uitrollen die worden uitgevoerd door Weblate s.r.o. Andere soorten uitrollen moeten provider-specifieke en stappen binnen de organisatie aanpassen aan hun eigen omgeving.

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.

Logistiek voor communicatie

• Interne communicatie:

  • Primaire kanaal is Signal voor coördinatie van mens naar mens.

  • Technische alarmeringen blijven buiten Signal, teneinde ruis te voorkomen.

• Externe communicatie:

  • E-mail wordt gebruikt om klanten te bereiken.

  • Contactlijsten voor klanten worden op verschillende locaties onderhouden om toegang te kunnen verzekeren tijdens uitval van de services.

• Openbare informatie:

  • Als een incident een kwetsbaarheid van het product Weblate bevat, volg het proces voor het rapporteren van een kwetsbaarheid in het product en Beleid voor openbaar maken kwetsbaarheden in Kwetsbaarheid en incidentafhandeling.

Categorieën incidenten en ernst daarvan

Incident activeren

• Declareer een incident wanneer een gebeurtenis is bevestigd of sterk wordt verdacht om de vertrouwelijkheid, integriteit of beschikbaarheid van de service te beïnvloeden tot boven routinematige operationele ruis.

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

• Herclassificeer het incident als het bereik of de impact wijzigt tijdens het onderzoek.

Categorieën incidenten

• Categorie 1 – Niet geauthoriseerde toegang

• Categorie 2 – Overtreding integriteit gegevens

• Categorie 3 – Uitval service of degradatie

• Categorie 4 – Foutieve configuratie of fout bij uitrol

Niveaus voor de ernst en SLA’s

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.

Ernst	Definitie	Doelkennis	Doel initiële actie
Kritisch	Totale uitval; beheer gecompromitteerd; actieve inbreuk op gegevens, vereist direct insluiten.	< 30 minuten	< 4 uur
Hoog	Uitval bron-mogelijkheid; lek persoonlijke gegevens van een enkele gebruiker.	< 2 uur	12 uur
Medium	Vermindering van uitvoering; kleiner beveiligingsprobleem.	1 werkdag	3 werkdagen
Laag	Problemen in gebruikersinterface; problemen met weergeven; fouten zonder beveiligingsrisico.	Beste inspanningen	Beste inspanningen

Levenscyclus incident herstel

Voorbereiding

• Zorg voor regelmatige dagelijkse back-ups van de PostgreSQL database en de map met gegevens door middel van Weblate’s ingebouwde back-upfunctie met rotatie, zie Weblate back-uppen en verplaatsen.

• Zorg ervoor dat Weblate een juist geconfigureerde omgekeerde proxy gebruikt (bijv. NGINX met HTTPS (TLS 1.2+).

• Schakel 2FA in voor alle accounts op niveau van systeembeheerders.

• Houd de Weblate instantie en zijn afhankelijkheden (Python, Django, Celery, database, etc.) up-to-date.

• Integreer met SIEM-systemen met het protocol GELF voor het auditten en doorsturen van logs van de toepassing.

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

Identificatie

• Monitor systeem en toepassingslogs (journalctl, logs van de omgekeerde proxy, logs van de toepassing Weblate en de audit).

• Analyseer gebeurtenissen voor inloggen, het uitvoeren van webhooks en falen van push/pull.

• Configureer alarmering (via Prometheus, Zabbix of SIEM) voor: meermaals mislukt inloggen, onverwacht opnieuw starten, of onregelmatige VCS-acties.

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

Afzonderen

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

• Coördineer menselijke antwoorden in Signal en houdt technische meldingen in de bestaande monitorsystemen.

• Voor incidenten van Categorie 1 of 2, maak een handmatige Hetzner Cloud Snapshot voordat een vernietigende actie wordt uitgevoerd, als dat veilig is om te doen.

  • Indeling voor naam: IRP-[CaseID]-[JJJJMMDD]-Evidence.

  • Deze staan los van standaard roterende back-ups en moeten worden bewaard voor analyses.

• Isoleer de getroffen host of service indien zoals nodig (bijvoorbeeld met regels voor de firewall of isoleren van de service).

• Schakel externe integraties uit (Git/webhooks) als ze deel uitmaken van het aangevallen gebied.

• Schors betrokken gebruikers onmiddellijk.

• Verwijder of roteer beïnvloede wachtwoordgegevens voor beheer, API, VCS en webhook indien nodig.

• Behoud relevant bewijs, inclusief systeemlogs, logs voor omgekeerde proxy, logs voor de toepassing Weblate en auditlogs, de beïnvloede staat van de configuratie en de lijst met getroffen wachtwoorden of integraties.

Uitroeien

• Verwijder alle niet geautoriseerde code of gegevens.

• Herstel bekende kwetsbaarheden door Weblate of serveronderdelen te upgraden.

• Valideer binaire en integriteit van de opslagruimte met SHA-256 controlesommen of Git-logs.

Herstel

• Herstel de getroffen services of gegevens vanuit de laatst bekende goede back-ups van Weblate.

• Introduceer de services opnieuw in een gefaseerde benadering.

• Bevestig dat de bron van het probleem is verwijderd of dat compenserend beheer is ingesteld, voordat het normale verkeer wordt hervat.

• Roteer beïnvloede wachtwoordgegevens en verifieer integriteit van het herstelde systeem, opslagruimten en configuratie.

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

• Monitor logs en het systeemgedrag doorlopend gedurende ten minste 72 uur na het herstel.

Nakijken na het incident

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

• Stel een volledige tijdlijn voor het incident en de genomen acties samen.

• Voer een Root Cause Analysis (RCA) uit en documenteer het binnen 10 werkdagen.

• Werk beveiligingsbeleid en documentatie voor IRP bij, gebaseerd op de opgedane bevindingen.

• Kijk de effectiviteit van de mechanismen voor detectie en afzondering na.

• Verifieer of escalatie, meldingen en externe communicatie Kwetsbaarheid en incidentafhandeling volgde zoals werd verwacht.

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