Plano de resposta de incidente para o Weblate

Escopo and objetivos

Este IRP cobre incidentes que impactam a confidencialidade, integridade, ou disponibilidade de implementações operadas pelo Weblate.

Nota

Este plano é especificamente desenhado para implementações operadas pelo Weblate s.r.o. Outras implementações precisam de adaptar passos específicos ao fornecedor e à organização para o seu próprio ambiente.

Funções e responsabilidades

  • Responsável pela Resposta a Incidentes (IRL): Coordena todas as fases do processo de resposta.

  • Administrador de Sistema: Executa medidas de contenção e recuperação.

  • Agente de Segurança: Avalia o impacto e consequências regulamentares.

  • Agente de Proteção de Dados (DPO): Avalia se dados pessoas (PII) foi comprometida e gere notificações GDPR obrigatórias.

  • Responsável pelas comunicações: Gere as notificações destinadas às partes interessadas internas e a entidades externas, caso seja necessário.

Logísticas de comunicação

  • Comunicação Interna:

    • O canal primário é Signal para coordenação entre humanos.

    • Technical alerts remain outside of Signal to avoid noise.

  • Comunicação Externa:

    • E-mail is used to reach customers.

    • Customer contact lists are maintained in several locations to ensure access during service outages.

  • Divulgação Pública:

Incident categories and severity

Incident activation

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

  • The Security Officer declares the incident, assigns the initial severity, and appoints the Incident Response Lead (IRL).

  • If the Security Officer is unavailable, any available senior operator may declare the incident and hand over ownership as soon as practical.

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

Categorias de incidente

  • Category 1 – Unauthorized Access

  • Category 2 – Data Integrity Violation

  • Category 3 – Service Outage or Degradation

  • Category 4 – Misconfiguration or Deployment Error

Severity levels and SLAs

Gravidade

Definição

Confirmação de Alvo

Target Initial Action

Crítico

Total outage; Admin compromise; Active data breach; requires immediate containment.

< 30 minutos

< 4 horas

Alta

Core feature failure; PII leak of single user.

< 2 horas

12 horas

Média

Performance degradation; Minor security issue.

1 Business Day

3 Business Days

Baixa

UI bugs; Staging issues; Non-security errors.

Melhor Esforço

Melhor Esforço

Ciclo de vida de resposta a incidentes

Preparação

  • Ensure regular daily backups of the PostgreSQL database and the data directory using Weblate’s built-in backup with rotation, see Efetuar cópias de segurança e mover o Weblate.

  • Ensure Weblate uses a properly configured reverse proxy (e.g., NGINX) with HTTPS (TLS 1.2+).

  • Enable 2FA for all admin-level accounts.

  • Keep the Weblate instance and its dependencies (Python, Django, Celery, database, etc.) up to date.

  • Integrate with SIEM systems using the GELF protocol for audit and application log forwarding.

Identificação

  • Monitor system and application logs (journalctl, reverse proxy logs, Weblate application and audit logs).

  • Analyze login events, webhook executions, and push/pull failures.

  • Configure alerting (via Prometheus, Zabbix, or SIEM) for multiple login failures, unexpected restarts, or irregular VCS actions.

Contenção

  • Create an incident record with a case ID and record timeline updates as actions are taken.

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

  • For Category 1 or 2 incidents, create a manual Hetzner Cloud Snapshot before taking disruptive action when it is safe to do so.

    • Name format: IRP-[CaseID]-[YYYYMMDD]-Evidence.

    • These are separate from standard rotating backups and must be preserved for analysis.

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

  • Disable external integrations (Git/webhooks) if they are part of the attack vector.

  • Suspend affected user accounts immediately.

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

Erradicação

  • Remove any unauthorized code or data.

  • Patch known vulnerabilities by upgrading Weblate or server components.

  • Validate binary and repository integrity using SHA-256 checksums or Git logs.

Recuperação

  • Restore affected services or data from the latest known-good Weblate backups.

  • PII Assessment: DPO determines if the breach requires a 72-hour GDPR notification.

  • Reintroduce services in a phased approach.

  • 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 Security Officer and IRL approve returning to normal operations.

  • Monitor logs and system behavior continuously for at least 72 hours post-recovery.

Post-incident review

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

  • Compile a full incident timeline and actions taken.

  • Perform Root Cause Analysis (RCA) and document it within 10 business days.

  • Update security policies and IRP documentation based on findings.

  • Review the effectiveness of detection and containment mechanisms.

  • Verify whether escalation, alerting, and external communication followed Tratamento de vulnerabilidades e incidentes as expected.