(Documento Interno Oficial)
Protocolo de Respuesta a Incidentes (IRP)
Última actualización: 18 / 11 / 2025
1. Propósito
El objetivo de este Protocolo de Respuesta a Incidentes es establecer un proceso claro, ordenado y efectivo para identificar, analizar, contener y resolver cualquier incidente de seguridad relacionado con:
- Datos de pago
- Cuentas de usuarios
- Cuentas de comercios
- Operaciones de la plataforma
- Intentos de fraude
- Vulnerabilidades del sistema
Este protocolo está alineado con:
- PCI DSS (Payment Card Industry Data Security Standard)
- Requisitos de seguridad de Azul Dominicana
- Requisitos de seguridad de Stripe
- Buenas prácticas globales del sector financiero y tecnológico
2. Alcance
Este protocolo aplica a:
- Todo el equipo interno de Reddi
- Sistemas administrativos e internos
- Paneles de comercios y repartidores
- Flujos de pago procesados por Azul o Stripe
- Información de usuarios almacenada por Reddi (no sensible)
- Cualquier actividad sospechosa o maliciosa detectada en la plataforma
3. ¿Qué se considera un incidente de seguridad?
Un "incidente de seguridad” puede incluir, entre otros:
Accesos no autorizados
- Intento sospechoso de acceso al panel administrativo
- Robo de credenciales
- Intentos de acceso indebido por parte de comercios o terceros
Problemas relacionados con pagos
- Transacciones fraudulentas
- Múltiples fallos de pago consecutivos
- Actividad inusual con reembolsos o disputas
Comportamientos anómalos del sistema
- Uso indebido del API
- Actividad de bots
- Manipulación de datos
- Intentos de alterar pedidos o registros
Amenazas externas
- Phishing
- Ingeniería social
- Tarjetas reportadas como comprometidas
- Secuestro de cuenta de un comercio
4. Ciclo de Respuesta a Incidentes
El proceso de Reddi sigue 4 etapas principales, basadas en protocolos utilizados por Azul y Stripe.
Etapa 1 — Detección
El incidente puede detectarse mediante:
- Alertas automáticas de Azul o Stripe
- Registros del backend (logs)
- Notificaciones del sistema
- Informes de usuarios o comercios
- Comportamientos anormales detectados por el equipo
Responsable: Miembro designado del equipo de Reddi
Herramientas: Panel Reddi, panel de Azul, panel de Stripe, logs internos.
Etapa 2 — Contención
Acciones inmediatas para reducir el impacto:
- Suspender temporalmente la cuenta afectada (usuario/comercio)
- Congelar pedidos o transacciones relacionadas
- Forzar cambio de contraseña o cierre de sesión
- Bloquear IPs o sesiones sospechosas
- Desactivar temporalmente accesos administrativos si es necesario
Responsable: Miembro designado del equipo de Reddi
Etapa 3 — Investigación
Identificar:
- Qué ocurrió
- Cómo ocurrió
- Qué cuentas o sistemas fueron impactados
- Si está relacionado con pagos (Azul/Stripe)
- Evidencias necesarias
La investigación debe incluir:
- Logs detallados
- Historial de accesos
- Registros de transacciones
- Reportes de usuarios
- Alertas de Azul o Stripe
Responsable: Miembro designado del equipo de Reddi
Etapa 4 — Resolución
Acciones para cerrar el incidente:
- Restaurar servicios y accesos
- Revertir acciones no autorizadas
- Emitir reembolsos a través de Azul/Stripe cuando corresponda
- Actualizar reglas de seguridad (bloqueos, filtros, etc.)
- Reactivar cuentas suspendidas (si procede)
- Documentar el incidente y sus causas
Responsable: Miembro designado del equipo de Reddi
5. Notificaciones
Según la gravedad del incidente:
Notificaciones Internas
- El equipo responsable de seguridad y operaciones de Reddi
- Los miembros designados del equipo de Reddi involucrados en la gestión del incidente
Notificaciones Externas
Solo si es necesario:
- Usuarios afectados
- Comercios afectados
- Azul / Stripe (obligatorio si involucra pagos o fraude)
Cumplimiento legal en RD
En incidentes relacionados con pagos:
- Azul es quien reporta a Banco Popular o la Superintendencia de Bancos si aplica.
- Reddi coopera según el procedimiento de Azul.
6. Documentación del Incidente
Cada incidente debe registrarse con:
- Fecha y hora
- Descripción del incidente
- Sistemas afectados
- Acciones tomadas
- Evidencia recopilada
- Notificaciones realizadas
- Análisis de causa raíz
- Medidas preventivas implementadas
Documentos guardados por mínimo 12 meses.
7. Medidas de Prevención
Para evitar futuros incidentes, Reddi implementa:
- Acceso administrativo protegido con MFA (autenticación multifactor)
- Uso estricto de roles y permisos
- Revisión periódica de logs
- Actualizaciones continuas según requerimientos de Azul y Stripe
- HTTPS obligatorio
- No almacenamiento de datos sensibles
- Uso de tokenización para métodos de pago
- Respuesta inmediata a alertas antifraude
8. Matriz de Escalamiento
Incidente de Baja Severidad
- Errores menores en pagos
- Disputas no relacionadas a fraude
- Problemas de UI/UX
Responsables: Miembro designado del equipo de Reddi
Incidente de Severidad Media
- Inicio de actividad sospechosa
- Múltiples fallos de pago
- Comportamiento extraño en cuentas
Responsables: Miembro designado del equipo de Reddi
Incidente de Alta Severidad
- Compromiso de cuentas administrativas
- Secuestro de cuenta de comercio
- Fraude confirmado
- Manipulación de datos
Responsables: Miembro designado del equipo de Reddi
9. Cierre del Incidente
Un incidente se considera cerrado cuando:
- La amenaza ha sido eliminada
- Los sistemas están restaurados
- Los usuarios/comercios han sido notificados
- Se documentó la causa raíz
- Se implementaron mejoras de prevención
10. Revisión y Mejora Continua
Mensualmente, el equipo designado de Reddi revisa:
- Incidentes del mes
- Causas identificadas
- Ajustes de seguridad
- Procedimientos de soporte
- Reglas antifraude
Se realiza una revisión completa anual.