Respuesta del plan de incidencia para Weblate

Alcance y objetivos

Este IRP cubre incidencias impactando la confidencialidad, integridad, o disponibilidad de despliegue de Weblate‐operativo.

Nota

Este plan está diseñado específicamente para implementaciones operadas por Weblate s.r.o. Otras implementaciones deberán adaptar los pasos organizativos y específicos del proveedor a su propio entorno.

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.

Logística de comunicaciones

  • Comunicación interna:

    • El canal principal es Señal para la coordinación entre humanos.

    • Las alertas técnicas permanecen fuera de Signal para evitar ruido.

  • Comunicación Externa:

    • El correo-e se utiliza para llegar a los clientes.

    • Las listas de contacto de clientes se mantienen en varios lugares para garantizar el acceso durante interrupciones del servicio.

  • Divulgación pública:

Categorías y gravedad de incidentes

Activación de incidente

  • Declare un incidente cuando se confirme o se sospeche firmemente que un evento afectará la confidencialidad, la integridad o la disponibilidad del servicio más allá del ruido operativo rutinario.

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

  • Reclasifique el incidente si el alcance o el impacto cambian durante la investigación.

Categorías de incidentes

  • Categoría 1 – Acceso no autorizado

  • Categoría 2 – Violación de la integridad de los datos

  • Categoría 3 – Interrupción o degradación del servicio

  • Categoría 4 – Error de configuración o implementación

Niveles de severidad y SLA

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.

Seriedad

Definición

Confirmación de Objetivo

Acción Inicial Destino

Crítico

Totalmente obsoleto; Compromiso administrativo; Violación de datos activa; requiere contención inmediata.

< 30 minutos

< 4 horas

Alta

Falla de función principal; fuga de información PII de un solo usuario.

< 2 horas

12 horas

Medio

Degradación del rendimiento; incidencia de seguridad menor.

1 día hábil

3 días hábiles

Baja

Defectos de IU; incidencias de puesta en escena; errores no relacionados con la seguridad.

Mejor Esfuerzo

Mejor Esfuerzo

Ciclo de vida de la respuesta a incidentes

Preparación

  • Asegúrese de realizar copias de respaldo diarias regulares de la base de datos PostgreSQL y del directorio de datos utilizando la copia de respaldo integrada de Weblate con rotación, consulte Respaldar y trasladar Weblate.

  • Asegure que Weblate utilice un proxy inverso configurado apropiadamente (p.ej., NGINX) con HTTPS (TLS 1.2+).

  • Habilite 2FA para todas las cuentas de nivel administrativo.

  • Mantenga la instancia Weblate y sus dependencias (Python, Django, Celery, base de datos, etc) al día.

  • Integre con sistemas SIEM utilizando el protocolo GELF para auditar y reenvío de bitácora de aplicación.

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

Identificación

  • Sistema de monitor y bitácoras de aplicación (journalctl bitácoras de proxy inverso, aplicación Weblate y bitácoras de auditoría).

  • Analizar sucesos de acceso, ejecuciones de ganchos web, y fallos de push/pull.

  • Configure alertas (a través de Prometheus, Zabbix o SIEM) para múltiples fallas de inicio de sesión, reinicios inesperados o acciones irregulares de VCS.

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

Contención

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

  • Coordinar la respuesta humana en Señal y mantener las alertas técnicas en los sistemas de monitoreo existentes.

  • Para incidencias de Categoría 1 o 2, crea una Instantánea de Hetzner Cloud manual antes de tomar medidas disruptivas cuando está seguro de hacer eso.

    • Formato de nombre: IRP-[CaseID]-[YYYYMMDD]-Evidence.

    • Estas son independientes de los respaldos rotativos estándar y deben conservarse para su análisis.

  • Aísle el host o servicio afectado según sea necesario (p.e., mediante reglas de cortafuegos o aislamiento de servicio).

  • Inhabilita las integraciones externas (Git/webhooks) si son parte del vector de ataque.

  • Suspender inmediatamente las cuentas de usuario afectadas.

  • Revocar o rotar los aspectos administrativos afectados, el API, el VCS y credenciales de webhook según corresponda.

  • Conserve las pruebas pertinentes, incluidos los registros del sistema, los registros del proxy inverso, los registros de auditoría y de la aplicación Weblate, el estado de la configuración afectada y la lista de credenciales o integraciones afectadas.

Erradicación

  • Retira cualquier código o datos no autorizados.

  • Ruta conocida de vulnerabilidades modernizando Weblate o componentes del servidor.

  • Valide la integridad binaria y del repositorio utilizando sumas de comprobación SHA-256 o bitácoras de Git.

Recuperación

  • Restaure los servicios o datos afectados desde las últimas copias de seguridad de Weblate conocidas como correctas.

  • Reintroducir los servicios mediante un enfoque gradual.

  • Confirme que ha sido eliminada la causa raíz o que se ha implementado un control compensatorio antes de restablecer el tráfico normal.

  • Rote las credenciales afectadas y verifique la integridad del sistema, los repositorios y la configuración restaurados.

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

  • Supervise las bitácoras y el comportamiento del sistema de forma continua durante al menos 72 horas tras la recuperación.

Revisión posterior al incidente

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

  • Compilar una cronología completa del incidente y las acciones tomadas.

  • Realizar un análisis de causa raíz (RCA) y documentarlo dentro de 10 días hábiles.

  • Actualizar las normativas de seguridad y la documentación del IRP según los hallazgos.

  • Revisar la eficacia de los mecanismos de detección y contención.

  • Verifique si la escalada, las alertas y la comunicación externa siguieron el procedimiento previsto en Vulnerabilidad y tratamiento de incidente.

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