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 een uitrol van Weblate.
Notitie
Het plan is specifiek ontworpen voor uitvoeringen van Weblate door Weblate s.r.o., maar kan soortgelijk op andere uitvoeringen worden toegepast.
Rollen en verantwoordelijkheden¶
Incident herstel leider (Incident Response Lead (IRL)): Coördineert alle fasen van het herstelproces.
Systeembeheerder: Voert maatregelen voor afzondering en herstel uit.
Beveiligings officier: Evalueert impact voor beveiliging en konsekwenties voor regelgeving.
Data Protection Officer (DPO): Evalueert of persoonlijke gegevens (PII) werden gecompromitteerd en beheert verplichte notificaties voor de GDPR.
Leider communicatie: beheert notificaties voor interne sleutelpersonen en, indien nodig, externe partijen.
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 er een beveiligingskwetsbaarheid wordt ontdekt, volg Kwetsbaarheid en incidentafhandeling.
Categorieën incidenten en ernst daarvan¶
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¶
Ernst |
Definitie |
Doelkennis |
Doel initiële actie |
|---|---|---|---|
Kritisch |
Totale uitval; beheer gecompromitteerd; actieve inbreuk op gegevens. |
< 30 minuten |
4 uur |
Hoog |
Uitval bron-mogelijkheid; lek persoonlijke gegevens van een enkele gebruiker. |
< 2 uur |
12 uur |
Gemiddeld |
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.
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.
Afzonderen¶
- Forensische voorbereidingen: Voor incidenten van Categorie 1 of 2, maak een handmatige Hetzner Cloud Snapshot voordat een vernietigende actie wordt uitgevoerd.
Indeling voor naam:
IRP-[CaseID]-[JJJJMMDD]-Evidence.Deze staan los van standaard roterende back-ups en moeten worden bewaard voor analyses.
Beperk tijdelijk de toegang (bijv. via regels voor firewall of isoleren van service).
Schakel externe integraties uit (Git/webhooks) als ze deel uitmaken van het aangevallen gebied.
Schors betrokken gebruikers onmiddellijk.
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.
Beoordeling Inbreuk persoonlijke gegevens: DPO bepaalt of de inbreuk een 72-uurs notificatie voor de GDPR vereist.
Introduceer de services opnieuw in een gefaseerde benadering.
Monitor logs en het systeemgedrag doorlopend gedurende ten minste 72 uur na het herstel.
Nakijken na het incident¶
Tijdlijn: Houd binnen 5 werkdagen na het sluiten van het incident een review-vergadering.
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.