La inversión alternativa crece en España: impacto en los modelos operativos y de gestión de riesgos
Se espera que el sector alcance los 24,5 mil millones de dólares en 2028.
18 julio, 2024
2 min
La delincuencia organizada tiene como objetivo atacar una infraestructura clave del sector financiero. Se trata de la red de mensajería interbancaria de la Sociedad para las Telecomunicaciones Financieras Interbancarias Mundiales, la conocida red de mensajería Swift, que tradicionalmente ha sido blanco prioritario de ciberataques sofisticados y dirigidos, y que en los últimos tiempos ha sufrido ataques exitosos que han causado un gran impacto. En respuesta a esta situación, Swift introdujo en el 2016 su Programa de Seguridad del Cliente (CSP), con el objetivo de mantener un nivel de madurez de ciberseguridad adecuado, reducir el riesgo de ciberataques y minimizar el impacto financiero de las transacciones fraudulentas.
Como parte del CSP, Swift desarrolló el Marco de Controles de Seguridad del Cliente (CSCF), un conjunto de directrices para que los usuarios de Swift pudiesen operar de manera segura su entorno Swift. Así, el CSCF se basa en 3 objetivos de control, que constituyen el nivel más alto de seguridad en el entorno del usuario, apoyados en 7 principios que profundizan en las áreas específicas de cada objetivo de control.
Desde su aparición, las instituciones financieras que utilizan la red Swift están obligadas, al menos una vez al año, a declarar su nivel de cumplimiento con los controles de seguridad obligatorios del CSCF vigente. Esta declaración debe realizarse para cada uno de los Bank Identifier Codes (BIC) bajo su responsabilidad, a través del proceso “Know Your Customer – Security Attestation”. Esta plataforma permite a las entidades financieras compartir información sobre sus medidas de seguridad y cumplimiento con Swift y otros miembros de la red, facilitando una mayor transparencia y colaboración en la lucha contra los ciberataques.
A partir de julio de cada año, Swift publica una nueva versión del CSCF, y sus usuarios pueden comenzar la implementación de los controles obligatorios y recomendados aplicables. A comienzos del año siguiente, el usuario puede empezar el proceso de evaluación independiente y su atestación KYC-SA puede ser enviada un año después de la publicación de la versión.
Para que una atestación KYC-SA pueda ser considerada como Compliant, se deberá realizar una evaluación independiente por parte de un equipo interno (función de segunda o tercera línea de defensa), externo o mixto. Indiferente a quién lo realice, el equipo debe contar con experiencia reciente, en un plazo de no más de 2 años, sobre evaluaciones de Swift o similares (PCI DSS 4.0, ISO 27002, entre otras) y al menos una certificación relevante (PCI QSA, CISSP, CISA, CISM, entre otras). Solo para los usuarios que tengan un BIC de solo recepción, se podrá recurrir a un Self-Assessment por parte de la primera línea de defensa.
La versión 2025 del CSCF ha sido publicada el 1 de julio de 2024, en la cual el grupo de trabajo de Swift ha valorado, como en otros años, varias solicitudes de cambio, incluyendo cambios de alcance, aclaraciones de orientación, cambios estéticos y preguntas abiertas.
Tras haber ido subiendo el listón gradualmente a lo largo de los últimos años, Swift ha estabilizado las expectativas de seguridad con esta versión, al no hacer obligatorio ningún control recomendado o componente incluido en el ámbito de aplicación. La versión del 2025, al igual que la del 2024, contiene 32 controles de seguridad (25 obligatorios y 7 recomendados) adaptados a los tipos de arquitecturas.
Control 2.4A: “Seguridad del flujo de datos del backoffice”. De recomendado a obligatorio
Para apoyar la promoción gradual del control 2.4A hasta 2026, se prevén varios cambios en este control para identificar claramente los próximos hitos:
Tentativamente en una versión posterior a la del 2026, se prevé proteger los flujos legacy entre la zona segura del usuario y los primeros saltos del back-office. Por ello, Swift recomienda preparar a la mayor brevedad posible un plan de priorización de los flujos identificados entre la zona segura del usuario y los primeros saltos de back office en función de su postura de seguridad y un enfoque basado en el riesgo.
Para alinear las expectativas de todos los usuarios a los flujos Swift, todos los endpoints del usuario que se conecten indirectamente a Swift, es decir, a través de un proveedor de servicios, se considerarán gradualmente como un “conector de cliente”, independientemente de la naturaleza del endpoint. Y, a partir de la versión del 2026, este cambio puede obligar a algunos usuarios que anteriormente certificaban como arquitectura de tipo B, a certificar como arquitectura de tipo A4 cuando utilicen un conector de cliente.
Con todo ello, aunque los usuarios de Swift afectados por los cambios de la versión del 2025 tienen un margen considerable para empezar con sus adecuaciones, es importante que tengan claro las implicaciones y, por tanto, que tracen un plan basado en riesgo que les permita estar preparados para evaluaciones independientes estándares o exigidas por Swift a futuro.
En este sentido, contar con un Swift CSP Assessment Provider que cumple regularmente con estrictos criterios de elegibilidad, incluyendo experiencia, certificaciones externas relevantes, formación y certificación específicas de Swift es imprescindible para poder anticiparse y estar preparado con la seguridad de que se cumple con todos los requisitos establecidos. Solo así se podrá blindar esta estructura y maximizar el nivel de protección ante potenciales ataques y atacantes.
Deja un comentario