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.

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:

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.

  • De Security Officer declareert het incident, wijst de initiële ernst toe en wijst de Incident Response Lead (IRL) aan.

  • Als de Security Officer niet beschikbaar is, mag elke beschikbare senior operator het incident declareren en overdragen zodra dat praktisch mogelijk is.

  • 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

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

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

  • Maak een incidentrecord met een zaaks-ID en werk de tijdlijn bij als acties worden ondernomen.

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

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

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

  • De Security Officer en de IRL keuren het terugkeren naar normale werkzaamheden goed.

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

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