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.

Los roles y responsabilidades

  • Respuesta de Cabecera de Incidente (IRL): coordina todas las fases del proceso de respuesta.

  • Administrador del sistema: Ejecuta medidas de contención y recuperación.

  • Oficial de seguridad: evalúa el impacto en la seguridad y las consecuencias regulatorias.

  • Oficial de Protección de Datos (OPD): evalúa si los datos personales (PII) se vieron comprometidos y gestiona las notificaciones obligatorias del RGPD.

  • Responsable de comunicaciones: Gestiona las notificaciones a las partes interesadas internas y externas si es necesario.

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.

  • El Oficial de Seguridad declara el incidente, asigna la gravedad inicial y designa al Jefe de Respuesta a Incidentes (JRI).

  • Si el responsable de seguridad no está disponible, cualquier operador de mayor rango disponible podrá declarar el incidente y ceder la responsabilidad lo antes posible.

  • 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

Gravedad

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.

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.

Contención

  • Cree un registro de incidente con un ID de caso y registre las actualizaciones de la cronología a medida que se tomen acciones.

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

  • Evaluación de PII: El DPO determina si la violación requiere una notificación GDPR de 72 horas.

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

  • El responsable de seguridad e IRL aprueba reanudación de las operaciones normales.

  • 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

  • Cronograma: Realizar una reunión de revisión dentro de los 5 días hábiles posteriores al cierre del incidente.

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