Gestión Integral de la Seguridad de la Información

00Presentación de la organización

NexoPay S.A. es una fintech argentina fundada en 2019, con sede en CABA. Su negocio central es una billetera digital y un servicio de procesamiento de pagos para comercios e-commerce.

Esta organización fue elegida porque combina los tres marcos normativos más relevantes para la cátedra (ISO 27001, PCI DSS, GDPR/Ley 25.326) y porque su modelo de negocio depende críticamente de la confianza y la disponibilidad — ambos golpeados de frente por el incidente de la Etapa 2.

1.1Gobierno y estrategia

1.2Roles y responsabilidades

La seguridad en NexoPay se organiza siguiendo el principio de segregación de funciones: decidir ≠ ejecutar ≠ controlar. Ninguna persona o área tiene control completo de un proceso crítico.

Segregación de funciones — ejemplos concretos

1. ABM de usuarios: IT puede crear/modificar/borrar usuarios, pero las políticas de acceso las define Seguridad y el uso de los accesos lo revisa Auditoría.
2. Aprobación de pagos: quien carga una transferencia no puede aprobarla ni ejecutarla (regla de doble control, propia de fintech).
3. Cuentas administrativas: IT administra servidores, pero las cuentas privilegiadas se gestionan con un PAM (Privileged Access Management) cuya auditoría la revisa Seguridad, no el propio IT.
4. Respuesta a incidentes: el SOC detecta, el CSIRT contiene, pero el post-mortem lo revisa Auditoría para que no haya autoevaluación.

Principio RBAC (Role-Based Access Control): los accesos se asignan por rol, no por persona. Esto simplifica la gestión (alta/baja/rotación) y reduce el riesgo de privilegios huérfanos. Cada rol tiene el mínimo privilegio necesario (least privilege).

1.3Gestión de riesgos

1.3.1 Metodología

NexoPay aplica una metodología cuali-cuantitativa basada en ISO/IEC 27005, operada con la plantilla "TEMPLATE RIESGOS v2". El proceso tiene cuatro pasos:

1. Identificación de activos críticos → ya hecho en 1.1 (ACT-001 a ACT-008).
2. Identificación de amenazas y vulnerabilidades por activo.
3. Evaluación del riesgo inherente = Probabilidad × Impacto.
4. Evaluación de controles y cálculo del riesgo residual.

1.3.2 Escalas de medición

1.3.3 Fórmulas del análisis

1.3.4 Matriz de riesgos de NexoPay

Lectura ejecutiva: antes de controles hay 4 riesgos CRÍTICOS y 3 ALTOS. Después de controles queda 0 CRÍTICOS residuales, 2 ALTOS residuales (RSK-001 y RSK-002), que son los que más atención reciben. RSK-002 (compromiso de cuenta admin) es el riesgo que se materializa en la Etapa 2.

1.3.5 Mapa de calor y visualización

El mapa de calor es una matriz 5×5 (Probabilidad en filas × Impacto en columnas). Cada celda cuenta cuántos riesgos caen ahí. Hacé clic en una fila de la tabla de riesgos para resaltar su celda en el mapa; pasá el mouse por una celda para ver qué riesgos contiene.

Mapas de calor 5×5 — Inherente vs Residual

1.4Controles de seguridad establecidos

Los controles se alinean con los riesgos definidos y cubren accesos, monitoreo, protección de la información y continuidad.

1.5Políticas y procesos

Las políticas definen el "qué" (lineamientos); los procedimientos definen el "cómo" (ejecución).

Políticas principales vigentes

1. Política de control de accesos
2. Política de gestión de identidades y usuarios
3. Política de uso aceptable de los recursos tecnológicos
4. Política de protección de datos personales
5. Política de clasificación de la información
6. Política de seguridad de la información
7. Política de backups y recuperación
8. Política de gestión de incidentes de seguridad — detallada abajo (relacionada con la Etapa 2)

1.6Métricas

Se eligieron 3 métricas coherentes con el incidente de la Etapa 2 (compromiso por phishing + MFA). La cátedra distingue:

• KPI (Key Performance Indicator): mide desempeño — "¿qué tan bien lo estoy haciendo?" — más alto = mejor.
• KRI (Key Risk Indicator): mide exposición — "¿qué tan cerca estoy de un problema?" — más alto = peor.

Por qué estas tres: el incidente de la Etapa 2 empieza con un phishing exitoso contra un empleado sin MFA resistente. MTTD mide si lo detectamos rápido; %MFA mide la cobertura del control que debió frenarlo; la tasa de éxito de phishing mide la exposición humana que lo habilitó.

2.1Definición del incidente

Por qué este escenario: materializa justamente el riesgo residual ALTO RSK-002 (compromiso de cuenta admin/vía MFA débil) y el RSK-003 (phishing), que la Etapa 1 dejó como los dos residuales más altos. Conecta con control C-02 (MFA) y con la política de incidentes — cerrando el círculo pedagógico.

2.2Análisis del incidente

2.2.1 Origen del incidente

• Origen: externo (atacante no perteneciente a la organización).
• Vector de entrada: spear phishing dirigido al empleado de Finanzas. Email suplantando al área de RRHH con asunto "Actualización de datos bancarios — acción requerida", con un enlace a un portal de credentials harvesting idéntico al login de VPN de NexoPay.

Vulnerabilidad explotada (cadena)

1. Humana: el empleado ingresó sus credenciales en el portal falso (falla de concientización — RSK-003).
2. Técnica de MFA: el atacante disparó >40 notificaciones push en 5 minutos (MFA fatigue). El empleado, confundido, aprobó una para que pararan. El MFA push sin number matching y sin contexto no permitió al usuario distinguir una solicitud legítima de una fraudulenta (falla del control C-02).
3. De segmentación: una vez en la VPN, el atacante pudo alcanzar segmentos que no debían ser accesibles desde un usuario de Finanzas (falla de microsegmentación).
4. De monitoreo: la descarga masiva desde la DB no disparó una alerta crítica automatizada (falla del control C-06 / SIEM mal afinado).

Vínculo con la Etapa 1: el incidente fue posible porque RSK-002 quedó residual ALTO con un control de eficiencia Moderada (0.5). El análisis de riesgos lo anticipó; el incidente lo confirmó.

2.2.2 Cómo se detectó el incidente

La detección fue tardía y parcial, por dos vías casi simultáneas:

1. Vía externa (la primera): un cliente reportó a soporte que sus datos aparecían en un foro de la dark web. Soporte escaló a Seguridad 36 horas después del inicio del incidente.
2. Vía interna: el SIEM había registrado una alerta de anomalía por una descarga inusualmente grande desde la DB de clientes a una IP de la VPN, pero fue catalogada como falsa positivo por un analista del SOC sobrecargado.

Por qué tardó en detectarse (fallas)

• El SIEM no tenía una regla afinada para "volumen anormal de export de PII" — sólo alertaba por login fuera de horario.
• El SOC estaba bajo dotación mínima (fin de semana).
• No había DLP (Data Loss Prevention) que bloqueara o alertara la exfiltración de datos sensibles.
• El MFA fatigue generó múltiples eventos de login exitosos que se mezclaron con el ruido normal.

Conclusión de la detección: el incidente no fue detectado durante la exfiltración, sino después, por una denuncia externa. Esto evidencia una brecha en la capacidad de detección que la Etapa 3 debe cerrar.

2.2.3 Estado actual o situación del incidente

Al momento del análisis:

• Ransomware: contenido. El cifrado alcanzó 2 servidores de análisis no productivos antes de que el CSIRT aislara los hosts y bloqueara la comunicación con el C2 (command & control). No afectó el procesador de pagos (ACT-002) ni la DB principal (gracias a los backups y a la segmentación parcial).
• Exfiltración: consumada. ~480.000 registros de clientes fueron extraídos y publicados en la dark web. Los datos de tarjeta estaban tokenizados, pero los datos personales (DNI, email, teléfono) estaban en claro.

Impacto al negocio

2.2bCronología del incidente

Flujo completo del ataque, desde el phishing inicial hasta la contención. Deslizá horizontalmente para ver todas las fases.

Línea de tiempo detallada

2.3Respuesta al incidente

2.3.1 Contención

Acciones inmediatas para frenar la propagación:

1. Aislamiento del host comprometido: desconectar la laptop del empleado de Finanzas de la red.
2. Revocación de la sesión VPN y de todas las credenciales del usuario comprometido. Reset de contraseña + revocación de tokens MFA.
3. Bloqueo de la IP del C2 en el firewall y en el proxy de salida.
4. Aislamiento de los 2 servidores de análisis en cuarentena para preservar evidencia y detener el cifrado.
5. Activación del CSIRT y declaración de incidente Crítico según la política de incidentes (sección 1.5).
6. Comunicación al Comité de Seguridad y al CISO, que informa al CEO.

2.3.2 Erradicación

Acciones para eliminar la causa raíz y evitar recurrencia inmediata:

1. Reimage de la laptop comprometida y de los 2 servidores cifrados desde imágenes limpias.
2. Reset masivo de credenciales de todos los usuarios con acceso a la DB de clientes (medida cautelar).
3. Parchado del mecanismo de MFA: desactivación temporal del MFA push y paso a TOTP (código de 6 dígitos) como medida intermedia.
4. Cierre del vector de phishing: bloqueo del dominio falso, retroalimentación al filtro de correo, capacitación urgente al equipo de Finanzas.
5. Revisión de logs para confirmar que no hay otras persistencias (cuentas creadas, tareas programadas, backdoors).

2.3.3 Recuperación

(Tratada en forma general, por ser materia de continuidad del negocio.)

• Restauración de los 2 servidores desde backups verificados (control C-10/C-11).
• Validación de integridad de la DB de clientes mediante hashes y comparación con backups.
• Retorno gradual a operación normal con monitoreo reforzado 24/7 durante 2 semanas.

2.4Compliance y evidencia

2.4.1 Regulaciones afectadas

Evidencia a preservar: logs del SIEM, imágenes de disco de los hosts comprometidos, capturas del portal de phishing, registros de MFA, timeline de acciones del CSIRT. La integridad de los logs (ACT-006) es clave para la investigación y para defender a la organización ante reguladores.

3.1Nuevos controles

Cada control nuevo se vincula a una falla concreta del incidente.

3.2Cambios en políticas

3.3Ajustes en roles

3.4Incorporación de métricas

Se mantienen las 3 de la Etapa 1 (reajustando objetivos) y se suman 2 nuevas:

Cómo se usan: el CISO las presenta al Comité mensualmente. Si un KRI cruza el umbral, dispara una revisión de riesgo. Si un KPI no cumple, dispara un plan de acción. Las métricas hacen que la seguridad sea gestionable con datos, no con intuición.

3.5Mejora continua (PDCA)

NexoPay adopta el ciclo PDCA (Plan-Do-Check-Act) de ISO 27001 como motor de mejora continua. Hacé clic en cada fase del diagrama para ver su detalle.

• Plan (Planificar): definir objetivos y controles. Ej.: plan anual de seguridad, apetito de riesgo, nuevas políticas post-incidente.
• Do (Hacer): implementar. Ej.: desplegar FIDO2, DLP, EDR, capacitación.
• Check (Verificar): medir con los KPI/KRI y auditar. Ej.: revisión mensual del Comité, auditoría interna semestral, resultados de simulacros.
• Act (Actuar): ajustar lo que no funcionó. Ej.: tras el incidente, elevar la mitigación de RSK-002, reentrenar al equipo de Finanzas, afinar el SIEM.

Ciclo aplicado al incidente: el incidente fue un Check brutal que alimentó un Act concreto (todos los cambios de la Etapa 3). La mejora continua no es un lema: es el mecanismo que asegura que el próximo incidente sea detectado en minutos, no en días, y que el mismo vector no funcione dos veces.