Contenido del artículo
En fintech y servicios de pago se revisa primero todo lo que lleva al dinero: el acceso y la recuperación de la cuenta, el cambio de datos de pago y de destinatarios, la API (la interfaz con la que los programas intercambian datos) de la app móvil y de los socios, la lógica de transferencias, límites y devoluciones, y cada lugar donde acaban los datos de tarjetas. Conviene encargar este trabajo a un equipo con experiencia real en sistemas bancarios y de pago, que pruebe a mano, entienda los requisitos del NBU y de PCI DSS y trabaje solo dentro de un alcance acordado y con autorización por escrito.
Abajo tienes: qué atacan los atacantes, una tabla de «amenaza, ejemplo, qué revisar», el contexto regulatorio en palabras sencillas con las fechas de los documentos y una checklist. También explico cuándo tiene sentido ir más allá del pentest y probar todo el camino del ataque.
En resumen
- La lógica de negocio significa las reglas de tu producto: límites, comisiones, devoluciones, bonos, el orden de las confirmaciones. Los atacantes buscan cómo saltárselas, y un escáner automático no lo ve.
- Los escenarios más caros: robo de cuentas, cambio de datos de pago, abuso de la API y fallos en la lógica de transferencias.
- La normativa del NBU para bancos en Ucrania exige de forma explícita comprobar la protección del perímetro de red con pruebas de penetración periódicas. [1]
- Si una empresa almacena, procesa o transmite datos de tarjetas de pago, le aplica PCI DSS. La versión vigente de la norma es la 4.0.1. [5] [6]
- En equipos maduros, el pentest se complementa con Red Team: una prueba controlada de todo el camino del atacante hasta un objetivo crítico.
Qué atacan los atacantes en los pagos
Robo de cuentas
El atacante entra en la cuenta de otra persona: una contraseña de otra filtración, adivinarla, un código SMS interceptado, una recuperación de acceso débil o un fallo en la sesión. En fintech el dinero está disponible justo después de entrar, así que el acceso, la recuperación de contraseña y el cambio de teléfono deben ser las partes mejor protegidas del producto.
Cambio de datos de pago
El atacante cambia la cuenta del destinatario o añade uno nuevo, y no se pide una segunda confirmación o se puede saltar. En los pagos entre empresas esto suele ir con phishing: un correo de un «proveedor» con un IBAN nuevo (el número de cuenta del destinatario). Revisa si los cambios piden una segunda confirmación, si el titular recibe un aviso y si hay un plazo de espera para destinatarios nuevos.
Abuso de la API
La app móvil, el área de clientes y los socios funcionan a través de la API. Problemas típicos: acceso a cuentas y operaciones ajenas cambiando un número en la petición, sin límites en el número de peticiones, demasiados datos en las respuestas. OWASP, una comunidad abierta de seguridad de aplicaciones, destaca en su lista de riesgos de API de 2023 el acceso a objetos ajenos y el abuso de flujos de negocio sensibles. [8] [9]
Fallos en la lógica de transferencias
Ejemplos: dos peticiones de retirada simultáneas pasan las dos aunque solo hay dinero para una; una devolución mayor que la compra; un importe negativo en una transferencia; un cashback que se abona varias veces por una sola operación. Esto lo encuentra una persona que entiende el producto, no un escáner.
Datos de tarjetas fuera de la zona protegida
Los atacantes buscan dónde aparece el número de tarjeta (el PAN, el número completo de la tarjeta) donde no debería: en registros, analítica, correos de soporte, copias de seguridad. Cuantos menos sistemas tocan datos de tarjetas, menor es el alcance de PCI DSS y menos hay que atacar.
Amenaza, ejemplo, qué revisar
| Amenaza | Ejemplo | Qué revisar |
|---|---|---|
| Robo de cuentas | Acceso con una contraseña de otra filtración, un código SMS interceptado | MFA (un segundo factor al entrar), límites de intentos, recuperación de acceso, cambio de teléfono y correo |
| Cambio de datos de pago | Un destinatario o IBAN nuevo sin segunda confirmación | Confirmación de cambios, avisos al titular, espera para destinatarios nuevos |
| Acceso a datos ajenos por la API | Cambiar el número de cuenta en la petición muestra operaciones ajenas | Control de permisos en cada objeto, roles, claves de socios |
| Enumeración masiva por la API | Recorrer números de teléfono o de tarjeta | Límites de peticiones, protección contra bots, campos de más en las respuestas |
| Lógica de transferencias | Dos retiradas simultáneas, un importe negativo, una devolución repetida | Bloqueo de operaciones simultáneas, control de importes y estados |
| Datos de tarjetas fuera de la zona | Números completos de tarjeta en registros o analítica | Búsqueda de números en los registros, enmascarado, límites de la zona de datos de tarjetas |
| Acceso interno | El soporte ve datos completos de tarjetas y clientes | Roles en el panel de administración, registro de acciones, mínimos privilegios |
El contexto regulatorio en palabras sencillas
Abajo solo está lo que dicen de forma directa los documentos publicados en las webs del NBU y del PCI SSC. Esto no es asesoramiento legal: consulta con un abogado qué requisitos aplican a tu licencia, con la versión vigente de cada documento.
Bancos. El Reglamento sobre medidas de seguridad de la información en el sistema bancario de Ucrania se aprobó con la resolución n.º 95 del Consejo del NBU de 28 de septiembre de 2017 y entró en vigor el 1 de marzo de 2018. Obliga al banco a implantar un sistema de gestión de la seguridad de la información conforme a DSTU ISO/IEC 27001 y a comprobar la protección del perímetro de red con pruebas de penetración periódicas. [1]
Ciberprotección de los bancos. El Reglamento sobre la organización de la ciberprotección en el sistema bancario de Ucrania se aprobó con la resolución n.º 178 de 12 de agosto de 2022. Entre los métodos de la auditoría externa de seguridad cita de forma explícita las pruebas de penetración. [2] La resolución n.º 24 de 25 de febrero de 2025 introdujo un informe anual del banco sobre seguridad de la información a 31 de marzo. En él el banco indica si hizo una prueba de penetración del perímetro durante el periodo, quién la realizó y si se corrigieron las vulnerabilidades críticas y altas. [3]
Sistemas de pago. El Reglamento sobre protección de la información y ciberprotección en los sistemas de pago se aprobó con la resolución n.º 43 del NBU de 19 de mayo de 2021. Fija requisitos de protección de la información y ciberprotección en las transferencias de fondos para organizaciones de sistemas de pago, participantes de sistemas de pago y operadores de servicios de infraestructura de pagos. [4]
Tarjetas. PCI DSS significa la norma del sector para proteger los datos de tarjetas de pago, mantenida por el PCI SSC, el consejo de normas de seguridad de la industria de tarjetas de pago. Aplica a quienes almacenan, procesan o transmiten datos de titulares de tarjetas. [5] La versión 4.0.1 se publicó en junio de 2024 sin requisitos nuevos ni eliminados; la versión 4.0 se retiró el 31 de diciembre de 2024, y los requisitos nuevos de la versión 4 son obligatorios desde el 31 de marzo de 2025. [6] La guía de pruebas de penetración del PCI SSC describe una prueba al menos una vez al año y tras cambios importantes y, si la red está segmentada, una comprobación de que la zona de datos de tarjetas está aislada de verdad del resto de sistemas. [7]
Cómo elegir un proveedor con experiencia bancaria
La experiencia bancaria se ve en las respuestas a preguntas concretas, no en los logos. Pide que te cuenten, sin nombres de clientes, cómo probó el equipo la banca online, las API de pago o el procesamiento de tarjetas, cómo trabajó con sistemas en producción donde un error cuesta dinero y cómo era el informe para el equipo de seguridad del banco y para el NBU.
Desde 2019 he trabajado como pentester en proyectos para bancos y sistemas de pago, y después dirigí un equipo de ciberseguridad en el sector financiero. Todo está bajo NDA (un acuerdo de confidencialidad), así que en lugar de nombres enseño informes de ejemplo anonimizados y la metodología.
Si ya tienes un equipo de seguridad, monitorización y pentests regulares, el siguiente paso es Red Team: comprobar si tu equipo detecta un ataque dirigido y lo rápido que lo frena. Para la mayoría de las fintech en fase temprana el buen comienzo es otro: un pentest manual del área de clientes, la app móvil y la API.
Checklist para una fintech o un servicio de pago
Descargar la lista de preparación (PDF)PDF · A4
FAQ
¿Hay empresas ucranianas de ciberseguridad con experiencia en seguridad bancaria?
Sí, y la mejor forma de comprobarlo es con preguntas: quién hará las pruebas exactamente, qué sistemas bancarios o de pago ha probado ya esa persona, cómo trabaja el equipo con sistemas en producción y si puedes ver un informe anonimizado. Los nombres de clientes no se suelen compartir por los NDA, y es normal.
¿Un banco en Ucrania está obligado a hacer pruebas de penetración?
El Reglamento n.º 95 del NBU exige comprobar la protección del perímetro de red del banco con pruebas de penetración periódicas, y el informe anual del banco al NBU pregunta si se hizo una prueba así durante el periodo. [1] [3]
¿Necesito PCI DSS si las tarjetas las gestiona un proveedor de pagos?
La norma aplica a quienes almacenan, procesan o transmiten datos de tarjetas, y a los sistemas que pueden afectar a su seguridad. Si la tarjeta se introduce solo en la página del proveedor, tu alcance es mucho menor, pero no siempre cero. Confirma el alcance con tu proveedor y tu evaluador.
¿Qué reviso primero en un servicio de pago nuevo?
El acceso y la recuperación de cuenta, el cambio de datos de pago, los permisos en la API y la lógica de transferencias. Ahí es donde un fallo se convierte antes en dinero perdido.
¿En qué se diferencia Red Team de un pentest para fintech?
Un pentest busca el mayor número posible de vulnerabilidades en los sistemas acordados. Red Team comprueba si un atacante puede llegar a un objetivo concreto, como la pasarela de pago, y si tu equipo lo detecta. Red Team tiene sentido cuando los pentests básicos ya son rutina.
Referencias
- NBU: resolución n.º 95 de 28.09.2017, Reglamento sobre medidas de seguridad de la información en el sistema bancario de Ucrania (en ucraniano) bank.gov.ua
- NBU: resolución n.º 178 de 12.08.2022, Reglamento sobre la ciberprotección en el sistema bancario de Ucrania (en ucraniano) bank.gov.ua
- NBU: resolución n.º 24 de 25.02.2025, cambios sobre seguridad de la información y ciberprotección (en ucraniano) bank.gov.ua
- NBU: resolución n.º 43 de 19.05.2021, Reglamento sobre protección de la información y ciberprotección en los sistemas de pago (en ucraniano) bank.gov.ua
- PCI SSC: PCI Data Security Standard pcisecuritystandards.org
- PCI SSC: Just Published: PCI DSS v4.0.1 (June 2024) blog.pcisecuritystandards.org
- PCI SSC: Penetration Testing Guidance v1.1 (2017) listings.pcisecuritystandards.org
- OWASP API Security Top 10 2023: API1 Broken Object Level Authorization api-security.owasp.org
- OWASP API Security Top 10 2023: API6 Unrestricted Access to Sensitive Business Flows api-security.owasp.org
