Plan de Respuesta a Incidentes

Vigencia: 2 de junio de 2026

Este Plan de Respuesta a Incidentes («Plan») define cómo STANDOUT Inc. («nosotros») detecta los incidentes de seguridad, las interrupciones del servicio y las brechas de datos que afectan al servicio VATES («Servicio»), responde a ellos, se recupera de ellos y aprende de ellos. El Plan hace referencia a NIST SP 800-61 Rev.2 e ISO/IEC 27035, y se basa en el principio de diseño de que los instrumentos de monitorización automatizados sirven como primera línea de detección.

1. Propósito y alcance

Los objetivos de este Plan son:

• Detectar de manera oportuna los eventos que puedan afectar a la disponibilidad, la confidencialidad o la integridad del Servicio.
• Definir procedimientos de contención y recuperación que minimicen el impacto.
• Cumplir las obligaciones de notificación a los Clientes afectados y a las autoridades reguladoras.
• Permitir la mejora continua de la calidad operativa mediante un análisis posincidente estructurado.

Este Plan se aplica al entorno de producción del Servicio (EC2, Cloudflare y los proveedores SaaS asociados), a la ruta de comunicación desde el Servicio hacia los proveedores de IA de nivel superior, y a todo el almacenamiento que contiene datos de Clientes.

2. Definición de incidente y clasificación de gravedad

2.1 Definición de incidente

A los efectos de este Plan, un incidente es cualquier evento que coincida con uno o más de los siguientes:

• Sospecha de acceso no autorizado, compromiso de credenciales o intrusión en el sistema.
• Divulgación, alteración o pérdida no autorizadas de datos de Clientes, incluidos datos personales.
• Interrupción o degradación significativa del rendimiento que afecte a la funcionalidad principal del Servicio.
• Amenazas de seguridad, incluidas infecciones por malware, ransomware o ataques a la cadena de suministro.
• Error operativo, configuración errónea o defecto de software con impacto a gran escala.

2.2 Clasificación de gravedad

Cada incidente se clasifica en el momento de la detección en uno de los siguientes niveles de gravedad:

• P1 (Crítico): Interrupción total del Servicio, o brecha de datos confirmada que afecte a datos personales. Requiere respuesta inmediata.
• P2 (Alto): Deterioro significativo de la funcionalidad principal, indisponibilidad para Clientes específicos o anomalías de autenticación. Respuesta inicial requerida en el plazo de una hora.
• P3 (Medio): Deterioro funcional parcial o degradación del rendimiento con soluciones alternativas disponibles. Es aceptable la respuesta dentro del horario laboral.
• P4 (Bajo): Eventos con impacto limitado en los usuarios, desviación menor de la integridad de los registros o redundancia reducida de los instrumentos de monitorización. Se abordan en el siguiente ciclo de revisión programado.

3. Estructura de respuesta

3.1 Parte responsable

La parte responsable de este Plan es Takuya Aoki, Managing Director de STANDOUT Inc. y jefe de desarrollo de VATES. Toda la autoridad de decisión y de notificación externa durante un incidente se consolida en la parte responsable.

3.2 Instrumentos de detección automatizados

El Servicio opera una postura de monitorización continua totalmente automatizada compuesta por los siguientes instrumentos. Funcionan con independencia de la parte responsable y activan una notificación inmediata cuando se cumplen las condiciones de umbral.

• Cloudflare Health Check: Sondea el origen de producción desde múltiples puntos geográficos a intervalos de 60 segundos.
• HetrixTools: Monitoriza los endpoints de producción desde múltiples puntos globales a través de una ruta independiente de Cloudflare.
• Sentry: Captura las excepciones de la aplicación en tiempo real y notifica a la parte responsable.
• Cloudflare WAF (Managed Rules + OWASP Core Ruleset): Bloquea los patrones de ataque conocidos en modo Block.
• Cloudflare DDoS Protection: Mitiga de forma continua y automática los ataques DDoS en la capa de red, la capa SSL/TLS y la capa HTTP.
• Batch de detección de anomalías (systemd timer): Escanea los registros de auditoría cada cinco minutos y detecta tres categorías: tasa de solicitudes alta, tasa de denegaciones de autorización alta e intentos de fuerza bruta.
• Rate Limiting: Limitación de tasa de solicitudes por tenant en los endpoints de uso y limitación de tasa basada en IP en los endpoints de autenticación, rechazando automáticamente el tráfico excesivo.
• Alertas de seguridad configurables: Los Clientes pueden elegir qué eventos operativos (saldo bajo, inicio de sesión desde una nueva ubicación, acceso bloqueado, fallos de inicio de sesión repetidos) activan notificaciones por correo electrónico, con umbrales de sensibilidad por evento.
• Infraestructura de registro de auditoría: Registra cada llamada a la API en un registro de auditoría con cadena de hashes y evidencia de manipulación (SHA-256, secuencia por tenant) y consolida las entradas para su verificación independiente.
• Panel de estado (9 indicadores de salud): Visualiza en una sola pantalla la auditoría, las anomalías, el GeoIP, las copias de seguridad, el batch de eliminación, la cobertura del catálogo, la desviación de conciliación, el killswitch y la salud del servicio.
• Copia de seguridad automatizada: Cifra instantáneas de SQLite con GPG AES-256 y retiene 30 generaciones diarias.

3.3 Delegación de la respuesta de primera línea a la automatización

Las etapas de detección y triaje las llevan a cabo los instrumentos automatizados descritos arriba como primera línea. La parte responsable interviene solo al recibir notificaciones de superación de umbrales. Este diseño garantiza que la cobertura de detección 24/7 quede físicamente establecida sin depender de la ubicación o la disponibilidad de la parte responsable.

4. Proceso de respuesta

4.1 Detección

Cuando uno o más de los instrumentos automatizados descritos en la Sección 3.2 detectan una anomalía, la parte responsable es notificada inmediatamente mediante Sentry, correo electrónico y alertas del panel. Los informes de los Clientes se reciben en [email protected] y se convierten en tickets dentro del mismo flujo.

4.2 Triaje

Al recibir una notificación, la parte responsable confirma la gravedad examinando:

• El alcance del impacto (todos los Clientes / un Cliente específico / una Instancia individual).
• Si están afectados datos personales, credenciales de autenticación o información de facturación.
• La implicación de factores externos (interrupciones de los proveedores de IA de nivel superior, interrupciones de Cloudflare, interrupciones de AWS).
• La correlación con patrones de ataque conocidos (registros del WAF, resultados de la detección de anomalías, alertas de GeoIP).

4.3 Contención

Según la gravedad, se aplican una o más de las siguientes medidas de contención:

• Suspensión de las Instancias afectadas mediante la máquina de estados para su aislamiento inmediato.
• Adición de las direcciones IP de origen a una lista de denegación (por Cliente o global).
• Revocación masiva de sesiones por JWT jti.
• Activación del killswitch (detención total del tráfico, medida de último recurso).
• Activación del «Under Attack Mode» de Cloudflare contra ataques L7.

4.4 Recuperación

Tras la contención, se eliminan las causas raíz y se realiza lo siguiente:

• Restauración desde copia de seguridad según sea necesario (procedimientos documentados en docs/RESTORE.md).
• Rotación de las credenciales afectadas (claves de API, secretos JWT, claves de cifrado de copias de seguridad, etc.).
• Aplicación de parches, correcciones de configuración y correcciones de código en producción.
• Verificación en los entornos de staging y producción.
• Observación continuada durante al menos 24 horas mediante los instrumentos de monitorización.

4.5 Posincidente

Una vez confirmada la recuperación, la parte responsable:

• Documenta la cronología, la causa raíz, el alcance del impacto y las acciones de respuesta.
• Identifica medidas preventivas y las incorpora a la hoja de ruta de implementación.
• Cuando corresponda, notifica a los Clientes afectados y a las autoridades reguladoras (ver Sección 5).
• Retroalimenta las mejoras a este Plan y a los documentos operativos relacionados.

5. Notificación a Clientes y autoridades

5.1 Notificación de brechas de datos personales

Si se confirma la adquisición, la pérdida o la divulgación no autorizadas de datos personales, proporcionamos notificación de acuerdo con:

• Reglamento General de Protección de Datos de la UE (GDPR) Article 33: Notificación a la autoridad de control dentro de las 72 horas siguientes a tener conocimiento.
• GDPR Article 34: Cuando se identifique un riesgo alto, notificación a los interesados afectados sin dilación indebida.
• Ley de Protección de la Información Personal (Japón): Informe a la Comisión de Protección de la Información Personal y notificación a los interesados, de acuerdo con las órdenes ministeriales y reglas aplicables.
• Otras jurisdicciones aplicables: Las notificaciones exigidas por las leyes de protección de datos nacionales o regionales aplicables.

5.2 Notificación de interrupciones del servicio

Para las interrupciones del servicio clasificadas como P1 o P2, notificamos a los Clientes afectados sin dilación indebida, incluyendo el plazo de recuperación previsto y cualquier mitigación provisional. Los canales de notificación son [email protected] y la consola de administración del Servicio.

5.3 Método de notificación

Las notificaciones se entregan principalmente por correo electrónico a la dirección registrada del Cliente, complementadas según sea necesario con banners dentro de la consola de administración.

6. Post-Mortem y ciclo de aprendizaje

Tras un incidente P1 o P2, la parte responsable realiza un Post-Mortem y documenta los siguientes elementos. El documento se conserva internamente y se divulga a los Clientes y a los auditores previa solicitud.

• La cronología de los eventos desde la detección hasta la recuperación.
• El análisis de la causa raíz (factores técnicos y operativos).
• El alcance cuantificado del impacto.
• La evaluación del proceso de respuesta.
• Las medidas preventivas y los plazos objetivo.

Los Post-Mortem se realizan como Blameless Post-Mortems, centrados en la mejora estructural y no en la responsabilidad individual.

7. Mantenimiento y revisión del Plan

7.1 Revisión periódica

Este Plan se revisa al menos una vez al año, así como después de cualquier incidente significativo, ante cambios sustanciales en la arquitectura del Servicio y ante modificaciones de las leyes y regulaciones aplicables.

7.2 Historial de revisiones

El historial de revisiones de este Plan se mantiene internamente y se divulga a los Clientes y a los auditores previa solicitud.

8. Contacto

Para informar de un incidente o plantear consultas sobre este Plan:

STANDOUT Inc.
Email: [email protected]

Última actualización: 2 de junio de 2026