SWIFT Customer Security Controls Framework v2019 - Traducción

Descripción detallada Avisos legales
Marco de controles de seguridad del cliente V2019

Programa de seguridad del cliente
Tabla de contenido
CONTROL DE CAMBIOS ............................................................................................................................................ 3

INTEGRACIÓN CON EL GOBIERNO DE SEGURIDAD Y GESTIÓN DE RIESGOS .................................................. 4
ÁMBITO DE APLICACIÓN DE CONTROLES DE SEGURIDAD ................................................................................. 4
TIPOS DE ARQUITECTURA ....................................................................................................................................... 5
Arquitectura A1 – Los usuarios con interfaz de comunicación ............................................................................. 6
Arquitectura A2 – Stack parcial sin interfaz de comunicación ............................................................................... 6
Arquitectura A3 – Conector ....................................................................................................................................... 7
Arquitectura B - No huella de usuario local ............................................................................................................. 7

DESCRIPCIONES DETALLADAS DE CONTROL ...................................................................................................... 9
1. Restringir el acceso a Internet y proteger los sistemas críticos de TI General de Medio Ambiente.. 10
1.1. Protección del ambiente de SWIFT ......................................................................................................... 10
1.2. Control de cuenta privilegiada del sistema operativo ........................................................................... 13
1.3. Protección de plataforma de virtualización ............................................................................................ 14

2. Reducir la superficie de ataque y las vulnerabilidades ......................................................................... 14
2.1. Seguridad interna del flujo de datos ....................................................................................................... 14
2.2. Actualizaciones de seguridad ................................................................................................................. 15
2.3. Fortalecimiento del Sistema ................................................................................................................... 16
2.4. Seguridad de flujo de datos de backoffice ............................................................................................. 17
2.5. Protección de datos de transmisión externa ......................................................................................... 17
2.6. Confidencialidad e integridad de la sesión del operador...................................................................... 18
2.7. Escaneo de Vulnerabilidades .................................................................................................................. 19
2.8. Outsorcing de Actividad crítica ............................................................................................................... 19
2.9. Controles comerciales de transacciones ............................................................................................... 20
2.10. Hardening de Applicación........................................................................................................................ 21

3. Asegure físicamente el entorno .............................................................................................................. 22
3.1. Seguridad Física ....................................................................................................................................... 22

4. Evitar el Compromiso de Credenciales .................................................................................................. 23
4.1. Política de Contraseñas ........................................................................................................................... 23
4.2. Multifactor de Autenticación.................................................................................................................... 24

5. Administrar identidades y segregar privilegios ..................................................................................... 25
5.1. Control de Acceso Lógico ....................................................................................................................... 25
5.2. Administración de Token ......................................................................................................................... 26
5.3. Proceso de selección de personal .......................................................................................................... 27
5.4. Almacenamiento físico y lógico de la contraseña ................................................................................. 27

6. Detectar actividad anómala en sistemas o registros de transacciones .............................................. 28
6.1. Protección contra malware ...................................................................................................................... 28
6.2. Integridad del software............................................................................................................................. 29

6.3. Integridad de la Base de Datos ................................................................................................................ 29
6.4. Registro y Monitoreo ................................................................................................................................ 30
6.5. Detección de Intrusos .............................................................................................................................. 31

7. Plan de Respuesta a incidentes e intercambio de información ........................................................... 32
7.1. Planificación de respuesta a incidentes cibernéticos ........................................................................... 32
7.2. Entrenamiento de Seguridad y concientización .................................................................................... 33
7.3. Pruebas de penetración ........................................................................................................................... 33
7.4. Escenarios de Evaluación de Riesgo ..................................................................................................... 34

Glosario ..................................................................................................................................................................... 35
CONTROL DE CAMBIOS
Los controles de seguridad del Marco de controles de seguridad del cliente V2019 promueve 3 controles de
recomendados de la versión anterior a obligatorios (2.6, 2.7, y 5.4) y presenta 2 nuevos controles recomendados (1.3A
y 2.10A). También puede servir de orientación adicional y aclara, en su caso, las directrices de aplicación o
implementaciones alternativas.
La siguiente tabla resume los cambios más significativos en el contenido de este documento en comparación con la
versión anterior. La tabla no incluye cambios editoriales que SWIFT hace para mejorar la facilidad de uso y la
comprensión del documento.
CONTROL CAMBIO
Controles recomendados promovidos a obligatorios
2.6A Confidencialidad e integridad de la sesión Manda el uso de protocolos seguros para las sesiones interactivas
del operador
2.7A Escaneo de Vulnerabilidades Mandar al menos una exploración anual y actuar sobre los resultados.
5.4A Almacenamiento físico y lógico de la Mandato almacenamiento seguro de credenciales
contraseña
Nuevos controles recomendados
1.3A Protección Plataforma de virtualización Presenta una guía de recomendados
2.10A Hardening de Aplicaciones Presenta una guía de recomendado para Interfaz certificadas SWIFT
Orientación adicional
2.4A Seguridad de flujo de datos de backoffice Lista soluciones más convencionales tales como claves asimétricas,
AES GCM para facilitar la adopción de los flujos de back office
4.1 Política Contraseña Añadir orientación con respecto a la política de contraseñas personales o
PIN del dispositivo móvil
5.2 Administración de token Añadir orientación con respecto a módulo de seguridad de hardware
(HSM) de dispositivos de entrada de PIN (PED)
7.3A Pruebas de penetración una guía adicional (se realiza cada 2 años por parte del personal
independiente, equipo rojo interna o recursos externos) antes de
encomendarle, en una versión futura
La alineación con la realidad - alternativa válida implementación
1.1 Protección del ambiente de SWIFT El uso condicional del servidor de intercambio de información no está en
la zona segura de SWIFT.
2.3 Fortalecimiento del sistema Mantener larga duración Fortalecimiento marcando o volver a aplicar las
configuraciones regularmente
4.2 Multifactor de Autenticación Consulte los principios estándar y las soluciones genéricas, como la
contraseña única de tiempo (TOTP), el token personal o el conector base
SAML al proveedor de identidad interno (IdP) con autenticación
multifactor.
Aclaración controles existentes
alcance de los controles de seguridad Incluya, según corresponda, los componentes Alliance Instant y
DirectLink.
Tipos de arquitectura Arquitectura A1 también incluye configuraciones de lo cual el usuario sólo
opera una interfaz de comunicación, no necesariamente una Stack
completa
1.1 Protección del ambiente de SWIFT Aclarar noción de servidor de seguridad
2.2 Actualizaciones de seguridad Aclarar la verificación de integridad necesaria antes de aplicar
actualizaciones de seguridad
2.3 Fortalecimiento del sistema SWIFT HSM está fuera del ámbito de este control
3.1 Seguridad Física Las cajas VPN de Alliance Connect están fuera del alcance global,
pero se espera que estén en un entorno con controles físicos
apropiados
4.2 Multifactor de Autenticación Aclarar donde la MFA debería ser implementado
6.1 Protección contra malware entrada adicional relacionada con el ámbito de aplicación de escaneo
6.3 Integridad de la Base de Datos Aclarar este control está fuera de alcance para el tipo de arquitectura
A3
7.1 Planificación de respuesta a incidentes Información adicional que enlaza con la hoja de ruta de recuperación
cibernéticos de SWIFT ISAC
7.4A Escenarios de Evaluación del riesgo Proporciona antecedentes adicionales y algunas prácticas pertinentes
para cumplir con el objetivo de control
Objetivos y Principios
Los controles de seguridad se basan en tres objetivos marco general, apoyados por ocho principios de seguridad. Los
objetivos son la estructura más alto nivel de seguridad en el entorno local del usuario. Los principios asociados
elaborados en las áreas de enfoque de mayor prioridad dentro de cada objetivo. Los objetivos y los principios
correspondientes incluyen:
Figura 1: Objetivos marco y los principios
Los 29 controles de seguridad (19 obligatorios y 10 controles de recomendados) que se detallan en este documento
sostienen estos objetivos y principios. Los controles están diseñados para ayudar a mitigar los riesgos de seguridad
cibernética específica que los usuarios de SWIFT se enfrentan debido al panorama de las amenazas ciberné tico.
Dentro de cada control de seguridad, SWIFT ha documentado los conductores de riesgo más comunes que el control
está diseñado para ayudar a mitigar. Hacer frente a estos riesgos tiene como objetivo prevenir o minimizar las
consecuencias de negocio indeseables y potencialmente fraudulentas, tales como:
 Envío no autorizado o modificación de transacciones financieras.
 Procesamiento de transacciones entrantes SWIFT alteradas o no autorizadas
 Negocios realizados con una contraparte no autorizada.
 Incumplimiento de confidencialidad (de datos comerciales, sistemas informáticos o detalles del operador)
 Violación de integridad (de datos comerciales, sistemas informáticos o detalles del operador)
En última instancia, estas consecuencias representan riesgos a nivel de la empresa, incluyendo:

 Riesgo financiero
 Riesgo legal
 Riesgo regulatorio
 Riesgo reputacional
INTEGRACIÓN CON EL GOBIERNO DE SEGURIDAD Y GESTIÓN DE RIESGOS

SWIFT anima a los usuarios a considerar la gestión de riesgos cibernéticos en los términos más amplios posibles,
incluyendo más allá del alcance de la infraestructura SWIFT del usuario y los controles de seguridad de SWIFT. Para la
gestión más eficaz de los riesgos, los usuarios no deben ver la implementación de estos controles de seguridad como
una actividad de una sola vez, ni tan exhaustiva o todo incluido. Los usuarios deben procurar incluir los controles de
SWIFT en un gobierno de seguridad cibernética en curso y programa de riesgo dentro de su organización que tiene
en cuenta el buen juicio y las mejores prácticas más recientes, teniendo en cuenta la infraestructura específica del
usuario y configuraciones. Como resultado, los usuarios pueden volver a utilizar y beneficiarse de las políticas,
procedimientos y controles que se han establecido para gestionar otras áreas de riesgo cibernético existentes.
Además, los usuarios deben tener el nivel adecuado de rendición de cuentas y la supervisión de sus actividades de
gestión de riesgos cibernéticos. Por lo general, un oficial de seguridad Jefe de Información juega un papel destacado
en este dominio por la dirección de las prioridades del programa de seguridad y solicitando el apoyo y la orientación
adecuada de la Junta.
ÁMBITO DE APLICACIÓN DE CONTROLES DE SEGURIDAD
Los controles de seguridad en este documento están en el ámbito para abarcar un conjunto definido de componentes
en el entorno local del usuario (ver Figura 2).
Figura 2: Ámbito de controles de seguridad
Los controles de seguridad se aplican a los siguientes componentes en el estudio:
 capa de intercambio de datos – El flujo de datos entre la oficina de apoyo (o capa de middleware) y la
infraestructura de SWIFT local.

 infraestructura de SWIFT local – El conjunto de componentes de SWIFT específicos gestionados por o para
los usuarios, incluidas las aplicaciones, componentes de red, Token y otros medios extraíbles y hardware de
soporte. Ejemplos de SWIFT local de la infraestructura puesta a punto y componentes, dependiendo del
usuario tipo de arquitectura, son:
o Zona Segura: zona segmentada que separa los sistemas relacionados con SWIFT de la empresa
en general (más detallado en Control 1.1). Esta zona puede expandirse más allá de la infraestructura
SWIFT local y puede incluir sistemas que no sean SWIFT.
o Interfaz de mensajería: Software de interfaz de mensajería que admite el uso de los servicios de
mensajería instantánea SWIFT FIN, InterAct, FileAct y SWIFTNet. El software proporciona los medios
para que los usuarios conecten estas aplicaciones empresariales a los servicios de mensajería
SWIFT y, por lo general, se conectan directamente a la interfaz de comunicación. SWIFT proporciona
las Interfaz de mensajería (por ejemplo, Alliance Access y Alliance Messaging Hub o Alliance
Messaging Hub Instant) y por proveedores de terceros certificados.
o Interfaz de comunicación: software de interfaz de comunicación que proporciona un enlace entre
la red SWIFTNet y el software de interfaz de mensajería. Las Interfaz de comunicación proporcionan
una integración centralizada, automatizada y de alto rendimiento con diferentes aplicaciones
financieras internas e Interfaz específicas de servicios. Las Interfaz de comunicación son
proporcionadas por SWIFT (por ejemplo, Alliance Gateway o Alliance Gateway Instant) y por
proveedores externos certificados.
o SWIFTNet Link (SNL): SNL es el producto de software obligatorio para acceder a los servicios de
mensajería a través de una red IP segura. Este documento hace referencia a la SNL como parte del
alcance de la interfaz de comunicación.
o Conector: los conectores son softwares locales diseñados para facilitar la comunicación con una
interfaz de mensajería o comunicación, o ambos. Cuando se utiliza un conector, los componentes de
la interfaz son ofrecidos por un proveedor de servicios (por ejemplo, por una oficina de servicios,
infraestructura de hub o SWIFT). Alliance Lite2 AutoClient, DirectLink, soluciones de transferencia de
archivos y productos equivalentes se consideran soluciones de conexión.
o SWIFT Hardware Security Modules, tokens conectados y tarjetas inteligentes.
o Firewall, enrutadores, etc. dentro o alrededor de la infraestructura SWIFT (dedicada o compartida).
o Interfaz gráfica de usuario (GUI): software que produce la interfaz gráfica para un usuario (por ejemplo,
Alliance Web Platform Server-Embedded y productos equivalentes).
 Operadores: Los operadores son los usuarios finales individuales y administradores que interactúan
directamente con la infraestructura de SWIFT local a nivel de aplicación o sistema operativo.
 PC del Operador: Estos son el usuario final o dispositivo informático administradores (típicamente un
ordenador de sobremesa o portátil) que se utilizan para llevar a cabo sus funciones (uso, operar o mantener)
la infraestructura de SWIFT local.
o Este componente puede referirse a un servidor de intercambio de información, y no el operador del
personal dispositivo de cálculo, si se implementa tal arquitectura.
o Los términos, "propósito general de PC del operador" y "PC operador con funciones específicas" son se
define como:
PC de operador de propósito general se encuentra en el entorno de TI de la empresa en general y se
utiliza para las actividades comerciales diarias, incluido el acceso a la infraestructura SWIFT local.
PC Operador dedicado se encuentra en la zona segura y está dedicado a interactuar con los componentes
de la zona segura (a veces también se conoce como una consola operativa).
Cuando se usa solo, el PC del operador incluye PC de operador de propósito general y dedicados.
Los siguientes componentes están fuera de alcance:

 Back office y middleware del usuario: los sistemas responsables de la lógica empresarial, la generación de
transacciones y otras actividades que se producen antes de la transmisión a la infraestructura SWIFT local.
Por ejemplo, las implementaciones de back office como SAP y el libro mayor general están fuera de alcance.
Las implementaciones de middleware como IBM® MQ generalmente están fuera del alcance, pero deberían
proporcionar los controles necesarios para proteger el intercambio de datos con la infraestructura SWIFT local
(por ejemplo, el cifrado de los datos en tránsito, la autenticación de la fuente o la integridad de los datos en
tránsito también como administración similar a un componente específico de SWIFT identificado
anteriormente) cuando no existen otros controles en el mensaje o los datos en sí.
 Entorno general de TI para empresas: la infraestructura general de TI que se usa para brindar soporte a la
organización en general (por ejemplo, PC de propósito general, servidor de correo, servicios de directorio,
etc.).
 Las conexiones a la red SWIFT suministrada por los Socios de la Red SWIFT, la conexión a Internet a la red
SWIFT y las cajas VPN de Alliance Connect administradas de forma remota por SWIFT también están fuera
del alcance. Sin embargo, se espera que las cajas VPN de Alliance Connect estén en un entorno con controles
físicos adecuados en línea con el control de seguridad 3.1.
Aunque no son obligatorios para los fines del proceso de certificación, los controles de seguridad re flejan buenas
prácticas de seguridad y es apropiado implementarlos más allá del entorno dentro del alcance en la cadena de
transacciones de extremo a extremo más amplia.
TIPOS DE ARQUITECTURA
Cada usuario debe identificar cuál de los tipos de arquitectura de cuatro de referencia (Figuras 3-6) se asemeja más
estrechamente su propio despliegue de arquitectura para determinar qué componentes son en su alcance. Dependiendo
del tipo de arquitectura, pueden o no pueden aplicar algunos controles de seguridad. Las cuatro arquitecturas de
referencia son los siguientes:
Arquitectura A1 – Los usuarios con interfaz de comunicación

La interfaz de comunicación es propiedad y está dentro del entorno del usuario. Este tipo de arquitectura también
incluye soluciones alojadas en el que el usuario posee (HAS) la licencia para la interfaz de comunicación que opera o
que se opera por sí mismo o en nombre de otro usuario (s).
Tanto la interfaz de mensajes y una interfaz de comunicación (Stack completa) son propiedad como se representa en
la siguiente figura.
Figura 3: Arquitectura A1 – Stack completa dentro de la ubicación del usuario
En el caso de los usuarios no operan o tener una interfaz de mensajería, pero una interfaz de comunicación (tal como en la
figura siguiente), que todavía se consideran como la arquitectura A1.
Figura 3b: Arquitectura A1 - Interfaz de comunicación dentro de la ubicación del usuario

Arquitectura A2 – Stack parcial sin interfaz de comunicación
La interfaz de mensajería se encuentra dentro del entorno del usuario, sino un proveedor de servicios (por ejemplo, una
oficina de servicios, SWIFT Alliance Gateway remoto o un hub grupo) posee la licencia y gestor de la interfaz de
comunicación. Este tipo de arquitectura también incluye soluciones de hospedaje de la interfaz de mensajería en la que el
usuario tiene la licencia para la interfaz de mensajería.
Figura 4: Arquitectura A2 - Stack parcial dentro de la ubicación del usuario

Arquitectura A3 – Conector
Una aplicación de software (por ejemplo, Alliance Lite2 AutoClient, Direct Link o soluciones de transferencia de
archivos STPlink) se usa dentro del entorno del usuario para facilitar la comunicación de aplicación a aplicación con
una interfaz en un proveedor de servicios (por ejemplo, una oficina de servicios, Alliance Lite2, un centro de grupo).
Opcionalmente, esta configuración se puede utilizar en combinación con una solución GUI (usuario a aplicación).
Conector
Figura 5: Arquitectura A3 - Conector
Arquitectura B - No huella de usuario local

Ninguno de los componentes de infraestructura SWIFT específica se utiliza en el entorno del usuario. Dos tipos de montajes
están cubiertos por este tipo de arquitectura:
 Los usuarios solo acceden a los servicios SWIFT a través de una aplicación GUI en el proveedor de servicios
(usuario a aplicación). La PC o el dispositivo utilizado por esos usuarios se debe considerar como una PC de
operador (de propósito general) y se debe proteger en consecuencia.
 Las aplicaciones de back-office de los usuarios se comunican directamente con el proveedor de servicios
(aplicación a aplicación) mediante un producto de middleware (por ejemplo, IBM® MQ o similar) o API del proveedor
de servicios. La categorización de esta configuración como arquitectura tipo B está en línea con el alcance de los
controles de seguridad, que excluye las aplicaciones de back office y middleware del usuario. Sin embargo, SWIFT
recomienda encarecidamente implementar los controles de tipo A3 de arquitectura en estas aplicaciones de
middleware y API.
Figura 6: Arquitectura B - No huella de usuario
Los controles de seguridad aplicables para arquitecturas de A1, A2, y A3 son idénticos. Estas arquitecturas se hace
referencia colectivamente en las siguientes páginas como tipo “A”. Menos controles de seguridad se aplican a los
usuarios que utilizan la arquitectura de tipo "B”.
Estructura Controles de seguridad

Cada control de la seguridad en este documento está estructurado en tres partes: información general de control, definición
de control, y la guía de implementación, como se describe a continuación.
 Información General de Control
o Número de control y el Título: Cada control tiene un único número y el título. Si el número de control se
añade con una "A", esto significa que el control es "RECOMENDADO".
o Tipo de control: Esto identifica el control como "OBLIGATORIO" o "RECOMENDADO". Los usuarios deben
poner en práctica todos los controles obligatorios que les sean aplicables teniendo en cuenta su tipo de
arquitectura. Controles de recomendados se consideran buenas prácticas de seguridad y son muy
recomendables para su aplicación adicional.
o Aplicabilidad de los tipos de arquitectura: Los controles son aplicables ya sea a los usuarios con un solo
tipo de arquitectura A o ambos tipos A y B. Los usuarios con arquitectura de tipo B no están obligados a
cumplir con los controles aplicables al tipo A solamente.
 Definición de control
o Objetivo de control: Establece el objetivo de seguridad para lograr independencia del método de
aplicación.
o Componentes dentro del alcance: los componentes específicos relacionados con SWIFT que están cubiertos
por este control en particular. (Ver también Alcance de los Controles de Seguridad).
o Factores de Riesgo: detalla los riesgos específicos que se abordan en este control de seguridad. En el
Apéndice A se documenta una matriz completa de riesgos.
 Guía de implementación
o Declaración de control: Los medios sugeridos por los cuales se puede cumplir el Objetivo de Control.
o Contexto de control: Información adicional introductoria sobre este control.
o Directrices de implementación: Método formulado por SWIFT para la implementación del control.
Importante: Los usuarios deben autoafirmarse con el cumplimiento con todos los objetivos de control obligatorios. Los
detalles adicionales sobre las opciones de implementación para el cumplimiento se describen en la siguiente sección.
Seguridad controles de cumplimiento

Para cumplir con un control de seguridad, los usuarios deben implementar una solución que cumpla con el objetivo de control
establecido, aborde los factores de riesgo y cubra el alcance documentado.
Los usuarios pueden hacer esto por cualquiera de los siguientes métodos:
1. Implementar una solución utilizando la guía de implementación proporcionada en este documento.
2. Implementar una solución alternativa a la guía de implementación formulada por SWIFT, que cumple por igual el
objetivo de control y aborda los riesgos relacionados.
SWIFT reconoce que algunos usuarios pueden optar por una implementación alternativa. Si un usuario elige
implementar una solución alternativa que se desvíe significativamente de la implementación formulada por SWIFT,
entonces el usuario debe considerar lo siguiente en el diseño de la solución:
a. Alcance: ¿la solución cubre los componentes del control dentro del alcance?
b. Controladores de riesgos: ¿la solución mitiga los riesgos documentados? (ver Apéndice A para una matriz
de riesgo)
c. Eficacia: ¿la solución es efectiva en la práctica? (Por ejemplo, es poco probable que las políticas que están
documentadas, pero no se promulguen o no se apliquen) sean efectivas.
Los usuarios son en última instancia responsables de evaluar la idoneidad de la guía de implementación formulada por
SWIFT o de determinar si desean adoptar soluciones de implementación alternativas. La sección de guía de implementación
no debe considerarse como una "lista de verificación de auditoría" porque cada implementación de usuario puede variar.
Por lo tanto, los usuarios deben evaluar qué elementos de la guía son relevantes, dado su entorno específico, para cumplir
el objetivo de control.
Es la expectativa de que solo un pequeño subconjunto de usuarios, generalmente instituciones grandes o complejas,
considerarán rutas de implementación alternativas para uno o más controles. En todos los casos, los usuarios son
responsables de evaluar su propia adhesión a los controles obligatorios y el cumplimiento de la autoprueba,
independientemente de la solución de implementación implementada.
Controles de seguridad Cuadro resumen

La siguiente tabla proporciona una visión general de todos los controles de seguridad obligatorios y de asesoramiento,
estructurados de acuerdo con el principio que admiten y con referencia al tipo de arquitectura al que se refieren. Además, la
tabla identifica la relevancia de los controles, según el tipo de arquitectura. Los controles de asesoramiento se anotan con
una "A" después del número de control (por ejemplo, "2.4A") en todo este documento, y también aparecen sombreados en
la tabla a continuación.
Tipo de
Arquitectura
Controles de seguridad "OBLIGATORIO" y "RECOMENDADO" A B
1. Restringir el acceso a Internet y proteger los sistemas críticos de TI General de Medio Ambiente
1.1. Protección del ambiente de SWIFT X
1.2. Control de cuenta privilegiada del sistema operativo X
1.3A. Protección de plataforma de virtualización X
2. Reducir la superficie de ataque y las vulnerabilidades
2.1. Seguridad interna del flujo de datos X
2.2. Actualizaciones de seguridad X X
2.3. Fortalecimiento del Sistema X X
2.4A. Seguridad de flujo de datos de backoffice X X
2.5A. Protección de datos de transmisión externa X
2.6. Confidencialidad e integridad de la sesión del operador X X
2.7. Escaneo de Vulnerabilidades X X
2.8A. Outsorcing de Actividad crítica X X
2.9A. Controles comerciales de transacciones X X
2.10A. Hardening de Applicación X
3. Asegure físicamente el entorno
3.1. Seguridad Física X X
4. Evitar el Compromiso de Credenciales
4.1. Política de Contraseñas X X
4.2. Multifactor de Autenticación X X
5. Administrar identidades y segregar privilegios
5.1. Control de Acceso Lógico X X
5.2. Administración de Token X X
5.3A. Proceso de selección de personal X X
5.4. Almacenamiento físico y lógico de la contraseña X X
6. Detectar actividad anómala en sistemas o registros de transacciones
6.1. Protección contra malware X X
6.2. Integridad del software X
6.3. Integridad de la Base de Datos X
6.4. Registro y Monitoreo X X
6.5A. Detección de Intrusos X
7. Plan de Respuesta a incidentes e intercambio de información
7.1. Planificación de respuesta a incidentes cibernéticos X X
7.2. Entrenamiento de Seguridad y concientización X X
7.3A. Pruebas de penetración X X
7.4A. Escenarios de Evaluación de Riesgo X X
DESCRIPCIONES DETALLADAS DE CONTROL
Tipo de Arquitectura Credicorp Capital Colombia
En junio de 2018, SWIFT cambió el alcance de los tipos de arquitectura de referencia y pasamos de tipo B a tipo A.
A3 porque tenemos Conectividad con Alliance Enterprice pero adicionalmente tenemos un CONECTOR que es con el que
enviamos y recibimos la información que es el STPlink y a que también tenemos en sitio solo los PC de los usuarios finales.
1. Restringir el acceso a Internet y proteger los sistemas críticos de TI General de Medio Ambiente
1.1. Protección del ambiente de SWIFT

Tipo de control: Obligatorio
Objetivo de Control: Garantizar la protección de la infraestructura SWIFT local del usuario a partir de elementos
potencialmente comprometidas del entorno de TI en general y el medio ambiente externo.
Componentes dentro del alcance:
Alliance Enterprice Credicorp

 interfaz de mensajería  Servidor de intercambio de información
 Interfaz de comunicación 
 GUI
 SWIFTNet Link
 Módulo de Seguridad de Hardware (HSM)
 Conector
 Operador PC propósito dedicados y generales
Factores de Riesgo:
 Compromiso de la empresa sistema de autenticación
 Compromiso de credenciales de usuario
 repetición de credenciales
 La exposición a ataques basados en Internet
 Acceso no autorizado
Guía de implementación
Declaración de control:
Una zona segura segregada protege la infraestructura SWIFT del usuario de los compromisos y los ataques a la empresa
más amplia y ambientes externos.
Contexto de control:
La segmentación entre la infraestructura de SWIFT local del usuario y su red de la empresa más grande reduce la superficie
de ataque y ha demostrado ser una forma eficaz de defenderse de los ataques cibernéticos que comúnmente implican
compromiso del entorno de TI de la empresa en general. la segmentación efectiva incluirá la separación a nivel de red, las
restricciones de acceso y restricciones de conectividad.
Pautas de implementación:
a) En general los objetivos de diseño para implementar la segregación entorno
 Implementar una “zona segura” para separar y proteger la infraestructura de SWIFT local desde el compromiso de
los sistemas y servicios situados fuera de la zona de seguridad.
 Para la mayor medida posible, contraseñas y otros autenticadores que son utilizables dentro de la zona segura
(especialmente para cuentas privilegiadas) no se almacenan o utilizan en cualquier forma (hashed, cifrado, o de
texto claro) en sistemas fuera de la zona segura. Esto no se aplica a los archivos de copia de seguridad cifradas.
Si el sistema de servicios de autenticación está residiendo fuera de la zona segura de SWIFT:
o O bien el sistema está en otra zona de seguridad existente que tiene controles similares
o O el sistema sólo se utiliza para filtrar las conexiones con el componente de infraestructura SWIFT
(controlando entonces la conectividad en el límite de la zona segura). En tal caso, el acceso lógico a la
componente de infraestructura SWIFT está asegurada por otro mecanismo de autentificación que reside
en la zona segura (otro IAM o la componente visitada sí mismo).
 La zona segura tiene un ámbito apropiado para el entorno de cada usuario, incluida la posible reutilización de las
zonas seguras existentes (por ejemplo, un "entorno de producción" seguro, "entorno de back office" o "zona de
sistemas de pago") para incluir la infraestructura SWIFT local.
 Todos los componentes dentro de la zona segura están protegidos al mismo nivel de seguridad, control de acceso,
confianza, y pueden comunicarse libremente dentro de la zona. Los usuarios pueden considerar implementar una
segregación adicional entre los componentes de la zona segura.
 El Apéndice B contiene diagramas de arquitectura ilustrativos que muestran ejemplos de las muchas formas en
que se puede diseñar una zona segura.
b) Alcance de la zona segura

 La zona de seguridad contiene, pero no se limita a todos los componentes de la infraestructura de SWIFT local.
Esto incluye: la interfaz de mensajes, interfaz de comunicación, interfaz gráfica de usuario basada en navegador,
SWIFTNet Link, Módulo de seguridad de hardware (HSM), conector, servidor de salto (ver detalles más abajo), y
cualquier operador PC aplicable, exclusivamente dedicada a la operación o administración de infraestructura local
de SWIFT.
o PC del operador de propósito general no están incluidos en la zona segura.
o El PC dedicado del operador con software relacionado con SWIFT instalado (es decir, "thick client" GUI
software) se encuentran en la zona segura, o el software está instalado solo en el servidor de salto al que
pueden acceder las PC del operador de propósito general fuera de la seguridad zona.
o Sistema Back Office y middleware (por ejemplo, aplicaciones de IBM® MQ) no están necesariamente
incluidos en la zona segura, pero puede ser considerada para su inclusión en función del tamaño elegido
y el alcance de la zona segura.
o Los sistemas de prueba son preferiblemente totalmente segregados de sistemas de producción (incl. HSM
separadas) y configurado para tráfico de prueba único apoyo (por ejemplo, utilizando sólo certificados Lite
y sólo la configuración de los terminales lógicos de prueba). Si no está completamente segregada, estos
sistemas deben mantenerse al mismo nivel de seguridad que los sistemas de producción.
o sistemas de desarrollo no están dentro de la zona segura y no están conectados a la red SWIFT.
o Las cajas de Alliance Connect VPN están en un entorno seguro con controles físicos adecuados (en línea
con control de 3,1).
 El tamaño de la zona segura y el alcance se define de una manera que es más adecuado para el entorno del
usuario. Las opciones pueden incluir, pero no están limitados a:
o Una zona segura dedicada sólo para la infraestructura de SWIFT local.
o Una expansión de un área de seguridad existente (por ejemplo, un “entorno de producción” segura o “pago
zona de sistemas”) para incluir la infraestructura SWIFT local. El tamaño y el alcance de esta zona pueden
variar significativamente dependiendo del entorno existente.
 Software, sistemas y servicios dentro de la zona de seguridad se evaluó la necesidad y se retiraron de la zona si
no apoyar las operaciones o la seguridad de la zona. (Por ejemplo, evaluar la necesidad de acceso al correo
electrónico.)
 Todas las Interfaz de mensajería (Alliance Access y equivalentes) y la interfaz de comunicación (Alliance Gateway
y equivalente) productos dentro de la zona de seguridad son SWIFT-certificado. La lista de Interfaz certificadas es
mantenido y publicado por SWIFT swift.com.
c) Protección de la zona segura

c.1 Protección de Fronteras
 La capa de transporte Firewall de estado que se utilizan para crear separación lógica en el límite de la zona segura.
o servidores de seguridad de capa de transporte que crean el límite de la zona segura deben ser física o
virtualmente dedicados a la protección de la zona de seguridad. En el caso de un servidor de seguridad
es compartida para separar otras zonas, se debe tener cuidado para asegurar que el compromiso del
servidor de seguridad no debe afectar a la protección de la zona segura (como el despliegue de diferentes
instancias virtuales firewall, dedicando una a la zona de seguridad, evaluación de riesgos formal o pruebas
de penetración).
o ACL, y los Firewall de aplicación pueden ser usados para proporcionar protecciones adicionales para la
zona segura, pero son no suficiente por sí solo.
o dispositivos capa 2 (capa de enlace de datos, tales como interruptores) pueden compartirse entre la zona
segura y otros usos (segregación VLAN).
o El acceso administrativo a los dispositivos de red se protege usando ya sea una red fuera de banda o a
través de acceso controlado dentro de banda (por ejemplo, una VLAN de administración). El acceso
administrativo al servidor de seguridad (s) la protección de la zona de seguridad no se basa en el sistema
de autenticación de usuario de la empresa.
o conectividad de entrada y de salida para la zona de seguridad se limita en la mayor medida posible. Un
proceso se lleva a cabo para analizar, revisar y hacer cumplir las reglas de firewall que rigen la
conectividad.
 No "permitir cualquier" se implementan reglas de firewall y todos los flujos de red están
autorizados explícitamente (lista blanca).
 Generalmente, la conectividad de cruzar el límite de la zona segura se limita a: comunicaciones
bidireccionales con aplicaciones de back-office y MV-SIPN (Multi-Vendor Secure IP Network),
comunicaciones entrantes de operador PC aprobados para uso general en el servidor de
intercambio de información, y los datos de administración saliente (registro de datos, copias de
seguridad).
 Las reglas del Firewall son revisadas por lo menos anualmente.
 Conexiones a través de los servidores de seguridad de frontera se registran.
c.2 Comunicación entre componentes en la zona segura.

La restricción de la comunicación entre los componentes en la zona de seguro es una mejora opcional. Cuando se
consideran las siguientes soluciones pueden ser implementadas:
 ACL de red o firewalls basados en host restringir el tráfico en una base de host-a-host dentro de la zona segura.
 de hardware individuales o firewalls basados en la red entre los componentes en la zona de seguridad se pueden
usar opcionalmente.
d) El acceso a los sistemas de zonas seguras

d.1 Acceso operador local (usuario final y el administrador)
 La zona de seguridad ha puesto en marcha uno de los siguientes diseños para restringir el acceso del operador
(sesiones interactivas o de línea de comandos) en la zona de seguridad:
o Los operadores se conectan desde PC operador específicas situadas en la zona segura (es decir,
ordenadores situados dentro de la zona segura, y se utiliza sólo para fines zona segura).
o Los operadores se conectan desde su PC operador de propósito general a la zona segura a través de un
servidor de salto dentro de la zona segura (por ejemplo, usando una solución de tipo Citrix o Microsoft
Terminal Server). Como el punto de entrada en la zona segura, el servidor salto implementa prácticas de
seguridad sólidas, incluyendo:
 Garantizar que todos los controles de seguridad en el estudio de este documento se aplican (por
ejemplo: la seguridad actualizaciones, el Fortalecimiento del sistema)
 servidor de intercambio de información separado para los administradores de sistemas (con
múltiples factores de autenticación) y los usuarios finales,
 La restricción del acceso a los operadores autorizadas,
 La eliminación de cualquier software innecesario,
 La restricción de actividad de riesgo (por ejemplo: envío / recepción de correo electrónico),
 Sin acceso a Internet,
 Habilitar el registro.
 Los operadores se conectan desde su PC en general operador propósito y sólo acceden a la mensajería o interfaz
de comunicación utilizando una interfaz gráfica de usuario basada en navegador (por ejemplo, Alliance Web
Plataform). controles de seguridad específicos aplicables a esta configuración:
o Acceso a Internet restringido en el PC en general operador propósito usando una de las siguientes
opciones:
 No hay conexión a internet
 El acceso a Internet a través de un escritorio remoto o una solución de máquina virtual
 Acceso a Internet desde el PC en general operador propósito de destinos URL única lista blanca
a través de un proxy con la inspección de contenido, en combinación con controles de bloqueo /
filtrado adecuados y permitiendo sólo las conexiones salientes iniciadas.
o La interfaz gráfica de usuario basada en navegador está situada en la zona segura y está separada
lógicamente de la mensajería y la interfaz de comunicación,
o múltiples factores de autenticación se implementan en su caso (en la interfaz gráfica de usuario basada
en navegador, en el interfaz de mensajería, o en la interfaz de comunicación),
o Esta configuración no se puede utilizar para las actividades de administración del sistema operativo.
 sistemas SWIFT dentro de la zona de seguridad restringen el acceso administrativo a puertos sólo esperados,
protocolos y direcciones IP de origen.
d.2 acceso de los operadores a distancia (teletrabajo, “de guardia” deberes, o la administración remota)
 El acceso remoto a la zona segura desde fuera de la red de usuario local requiere primero la autenticación VPN a
la red local antes de acceder a la zona de seguro a través de los mismos canales seguros como operadores locales.
 Una evaluación del riesgo se lleva a cabo por el usuario para tener en cuenta los controles de seguridad adicionales
que sean implementadas para el acceso remoto, como el uso de la infraestructura de escritorio virtual, canales
dedicados para la conectividad (por ejemplo, servidores dedicados de salto para los usuarios remotos, líneas
arrendadas).
e) La limitación del acceso a Internet

 acceso a Internet desde los sistemas dentro de la zona segura (por ejemplo, el servidor de intercambio de
información o PC operador con funciones específicas) está muy restringido y lo ideal sería bloqueado.
- La implementación de una arquitectura de servidor salto sin conexión a Internet elimina el requisito para
restringir acceso a Internet en los ordenadores conectados operador de propósito general individuales.
 Cuando sea posible, las actividades que requieren internet se llevan a cabo fuera de la zona segura. Ejemplos de
actividades pueden incluir la realización de actividades cotidianas en swift.com, o la descarga de parches de
seguridad para la transferencia segura a la zona segura.
 Si se necesita acceso a Internet desde dentro de la zona de seguridad, el acceso sólo debe concederse a los
destinos de la lista blanca de URL a través de un proxy con la inspección de contenido y controles de bloqueo /
filtrado adecuados. Conexiones sólo se permiten si se inicia en la dirección de salida.
 No se permite el uso general de navegación por Internet desde dentro de la zona segura.
f) La segregación de General de la empresa de servicios de TI

 Para proteger la zona de seguridad contra el robo y/o el compromiso de la empresa de autenticación (LDAP,
RADIUS, de múltiples factores) Credencial de Servicios, sistemas de zonas seguras utilizan un sistema de
autenticación separado del servicio de autenticación de la empresa. Por ejemplo, los sistemas de zonas seguras
no son un miembro del servicio de directorio de la empresa, sino que son miembros de un servicio de directorio
zona segura.
 Apoyar la infraestructura de TI, tales como la gestión de activos, bases de datos, almacenamiento de datos,
servicios de seguridad (por ejemplo, parches) y los servicios de red (por ejemplo, DNS, NTP) que se utiliza dentro
de la zona de seguridad está protegido de compromiso de credenciales dentro de la empresa más grande. Las
instituciones deben realizar un análisis de los puntos de conexión que aseguran que estos sistemas no almacenan
Authenticators (contraseñas, Token, etc.) para los sistemas de cuentas y en su alcance en cualquier formato (hash
y cifrado, texto plano) fuera de la zona segura. La infraestructura de TI de apoyo no tiene por qué ser exclusivo de
los sistemas SWIFT y puede ser compartida dentro de la zona segura.
Mejoras opcionales:
 Sistemas dentro de la zona segura implementan listas blancas de aplicaciones, permitiendo que sólo las
aplicaciones fiables para ser ejecutados.
Consideraciones para implementaciones alternativas:

Las instituciones con un alto nivel de madurez programa de seguridad dentro de su organización pueden considerar la
implementación de controles alternativos tales como las que se sugieren a continuación. Las soluciones alternativas
específicas deben ser apropiados al riesgo de cada entorno, y considerar el esfuerzo necesario para implementar,
administrar y mantener la solución.
 No segregar los servicios de autenticación zona de seguridad del servicio de autenticación de la empresa requerirá
la implementación de un conjunto completo de controles de defensa en profundidad para proteger de detectar y
adversarios que cruzan el límite de la zona segura. Los controles pueden incluir: sólo lectura limitar relaciones de
confianza entre el entorno de empresa más grande y la zona segura (tal como de una sola vía relaciones de
confianza), la restricción de operador y el acceso administrativo, implementar fuertes controles de acceso
privilegiado, la aplicación de acceso, cuando sea posible, lo que permite el registro detallado, y la implementación
de capacidades centralizadas de vigilancia y de detección activos.
 Si los servicios de TI de las empresas en general (por ejemplo, el análisis de vulnerabilidades, administración de
firewall límite) son compartidos entre la zona segura y otros entornos, las credenciales utilizadas en todo el entorno
deben ser monitoreados para asegurar que sólo se utilizan cuando y donde se esperaba.
 Si un servidor de la empresa en general se utiliza inicialmente para llegar a la zona de seguridad, el servidor
sólo se utiliza para filtrar el acceso a la conectividad legítimo. Identidad y acceso a la administración de
componentes de la zona segura y/o el servidor salto todavía se basa en los servicios de autenticación que se
ofrecen dentro de la zona segura de SWIFT u otra zona de seguridad existente que tiene controles similares.
 Si la zona segura tiene dependencias en las funciones de la empresa compartida (tales como los servicios de
directorio, servidores o redes) que están fuera del ámbito de aplicación, el usuario debe asegurarse de que
cualquier compromiso de tales funciones no pondrá en peligro la seguridad de los componentes en el estudio.
1.2. Control de cuenta privilegiada del sistema operativo

Objetivo de Control: Restringir y controlar la asignación y el uso de las cuentas del sistema operativo de nivel de
administrador.

 zona segura: las cuentas del sistema operativo de nivel  N/A
de administrador
Factores de Riesgo:
 Supresión de registros y pruebas forenses
 El exceso de privilegio o de acceso
 La falta de trazabilidad
 cambios en el sistema no autorizadas
El acceso a las cuentas del sistema operativo de nivel de administrador está restringido en la mayor medida posible. El uso
se controla, vigila y sólo se permite para las actividades relevantes, tales como la instalación del software y la configuración,
el mantenimiento y las actividades de emergencia. En los demás casos, se utiliza una cuenta con menos privilegios de
acceso.
proteger firmemente las cuentas de administrador en el sistema operativo reduce la oportunidad de que un atacante utilizar
los privilegios de la cuenta como parte de un ataque (por ejemplo, la ejecución de comandos, la eliminación de pruebas).
 se definen cuentas de administrador como:
o Ventanas: una función de cuenta de administrador y los miembros de los grupos con privilegios de
administrador (por ejemplo, las cuentas con depuración del sistema de archivos o privilegios). Por lo
general, el grupo Administradores de organización, grupo de administradores de dominio y el grupo de
administrador local.
o Linux / Unix: cuenta root (User ID=0) y los miembros del grupo raíz.
o La unidad central: administrador del sistema o función programador del sistema
 El acceso a las cuentas del sistema operativo de nivel de administrador está restringido en la mayor medida posible
a menos que necesita para instalar, configurar, mantener, operar y actividades de apoyo de emergencia. El uso de
la cuenta de administrador se limita a la duración de la actividad (por ejemplo, las ventanas de mantenimiento).
 Accede con cuentas de administrador incorporadas no está permitido, excepto para realizar actividades en las que
dichas cuentas se necesitan específicamente (por ejemplo, la configuración del sistema) o en situaciones de
emergencia (Cuenta de vidrio Break). Las cuentas individuales con privilegios de administrador o cuentas con la
capacidad de escalar hasta el acceso administrativo, (como 'sudo') se utilizan en su lugar.
 acceso a la cuenta de administrador individuo y su uso se registran de manera que las actividades puedan ser
reconstruidos para determinar la causa raíz de los incidentes.
 contraseñas de administrador están estrechamente controlados con controles de acceso físico al registrado
físicamente.
Mejoras opcionales:
 Los sistemas están configurados para no permitir log-in de cuentas de nivel de administrador incorporadas, excepto
a través de un modo de mantenimiento (por ejemplo, modo de usuario único o modo seguro). Esto prohíbe
efectivamente iniciar sesión en la cuenta como un servicio, trabajo por lotes, a través de servicios de escritorio
remoto, o por la escalada de privilegios de otra cuenta.
1.3. Protección de plataforma de virtualización

Tipo de control: RECOMENDADO
Objetivo de Control: Plataforma de virtualización segura y máquinas virtuales (VM) que alojan componentes relacionados
con SWIFT al mismo nivel que los sistemas físicos.

La plataforma de virtualización (también denominada hipervisor) y las máquinas virtuales utilizadas para alojar cualquiera
de los siguientes componentes relacionados con SWIFT:

 interfaz de mensajería  servidor de intercambio de información
 Interfaz de comunicación  Operador PC propósito dedicados y generales
 GUI  Firewall
 SWIFTNet Link
 conector
Factores de Riesgo:
 Acceso no autorizado al hipervisor y sus módulos de configuración.
 Proliferación incontrolada de máquinas virtuales que conducen a máquinas incontrolables, no parcheadas y no
contabilizadas
 Proliferación incontrolada de máquinas virtuales que conduce a un acceso no autorizado a los datos
 Falta de visibilidad en la segregación de la red y el control de las redes virtuales cuando no se utiliza la protección
de seguridad de la red (como firewalls físicos o sistemas de detección de intrusos)
Plataforma de virtualización segura, máquinas virtualizadas e infraestructura virtual compatible (por ejemplo, firewalls) al
mismo nivel que los sistemas físicos.
Al implementar controles apropiados, SWIFT no limita el uso de la tecnología virtual para ningún componente de la
infraestructura SWIFT local o la infraestructura de soporte asociada (por ejemplo, firewalls virtuales).
 Los mismos requisitos de seguridad se aplican a la plataforma de virtualización (a veces también llamada
hipervisor), a las máquinas virtuales y a la infraestructura virtual de apoyo, como a todos los demás sistemas y
componentes de infraestructura (que abarcan, por ejemplo, restricciones de acceso privilegiado, inicio de sesión,
instalación de parches de seguridad, restricción de acceso a internet).
 El host o sistema de la plataforma de virtualización está sujeto a protección física y evita el acceso físico no
autorizado.
 La plataforma de virtualización debe fortalecerse de acuerdo con uno o más de los siguientes:
o Guía de configuración de seguridad del proveedor,
o Guía de configuración de seguridad estándar de la industria (por ejemplo, 2 CIS, DISA STIG, NIST),
o una configuración de seguridad estándar o local de un regulador o conjunto de controles del mismo rigor
que el proveedor o guía de la industria.
Nota: SWIFT espera que este control sea obligatorio, al usar la virtualización, en una versión futura de este
documento.
2. Reducir la superficie de ataque y las vulnerabilidades
2.1. Seguridad interna del flujo de datos

Objetivo de Control: Asegurar la confidencialidad, la integridad y autenticidad de los flujos de datos entre aplicaciones
relacionadas con SWIFT locales y su enlace con el PC del operador.

 N/A  PC del operador (o el servidor de intercambio de
información)
 componentes de infraestructura relacionados con
SWIFT
Factores de Riesgo:
 La pérdida de la confidencialidad de los datos sensibles

 La pérdida de la integridad de los datos sensibles
 sistema de tráfico no autenticado
 Acceso no autorizado
se implementan mecanismos de confidencialidad, integridad y autenticación para proteger los flujos de datos de aplicación
a aplicación y de operador a aplicación relacionados con SWIFT.
Protección de datos internos fluye salvaguardas contra la divulgación no intencional, modificación, y el acceso de los datos
en tránsito.
 Todos los flujos de datos entre las aplicaciones relacionadas con SWIFT están protegidos mediante un mecanismo
seguro (por ejemplo, "Autenticación local (LAU) en combinación con una protección de confidencialidad" o "TLS
bidireccional") para respaldar la confidencialidad, integridad y autenticación mutua de flujos de datos. Esto incluye
los siguientes flujos de datos:
- aplicación RMA a la interfaz de mensajería,
- GUI a la interfaz de mensajería,
- GUI para interfaz de comunicación,
- interfaz de mensajes de interfaz de comunicación.
 La comunicación entre el PC del operador y las aplicaciones relacionadas con SWIFT está protegida mediante un
mecanismo seguro (por ejemplo, TLS de una vía) para respaldar la confidencialidad, integridad y autenticación de
la conexión a la aplicación.
 Los protocolos seguros utilizan algoritmos criptográficos actuales y comúnmente aceptados (por ejemplo, AES –
Advanced Encryption Standard, ECDHE – Elliptic Curve Diffie-Hellman Ephemeral), con longitudes de claves de
acuerdo con las mejores prácticas actuales. Puede encontrar más directrices sobre algoritmos criptográficos que
admiten protocolos seguros en SWIFT Knowledge Base TIP 5021566.
2.2. Actualizaciones de seguridad

Objetivo de Control: Minimizar la aparición de vulnerabilidades técnicas conocidas dentro de la infraestructura de SWIFT
local, asegurando el soporte del proveedor, la aplicación de actualizaciones de software obligatorias y aplicar actualizaciones
de seguridad oportunas alineados con el riesgo evaluado.

 PC del operador (o el servidor de intercambio de
información)
 componentes de infraestructura relacionados con
SWIFT
Factores de Riesgo:
 Explotación de vulnerabilidades de seguridad conocidas
Todo el hardware y software dentro de la zona segura y en las PC del operador se encuentran dentro del ciclo de vida de
soporte del proveedor, se han actualizado con actualizaciones de software obligatorias y se han aplicado las actualizaciones
de seguridad rápidamente.
El cierre de vulnerabilidades de seguridad conocidas es eficaz en la reducción de las diversas vías que un atacante puede
utilizar durante un ataque. Un proceso de actualización de seguridad que sea integral, repetible y aplicado de una manera
oportuna, es necesario cerrar continuamente estas vulnerabilidades conocidas cuando los parches de seguridad están
disponibles.
 Soporte del proveedor:
o Todo el software (incluidos los sistemas operativos) y el hardware (incluidos los dispositivos de red) se
encuentran dentro de la ventana del ciclo de vida del producto con soporte activo del proveedor (incluido
el soporte extendido), si corresponde.
o Se han establecido contratos de mantenimiento o licencia para el acceso a actualizaciones,
actualizaciones menores y otras funciones de mantenimiento críticas
 Actualizaciones de software obligatorias
o Las versiones o actualizaciones obligatorias que se aplican a un componente SWIFT local se instalan
dentro del plazo especificado por el proveedor.
 Aplicación de actualizaciones de seguridad

o Se implementó un proceso de evaluación de riesgos para determinar el tratamiento más adecuado de las
actualizaciones / parches de seguridad del proveedor. Las consideraciones de evaluación de riesgos
pueden incluir: la criticidad del parche informada por el proveedor, la exposición y vulnerabilidad del
usuario, los controles de mitigación y el impacto operacional.
o Los plazos de implementación definidos por el usuario se establecen para aplicar parches según la
criticidad, el tipo de sistema y las pruebas de parches requeridas.
o En ausencia de procesos internos y cronogramas establecidos, SWIFT recomienda el uso de la Versión 3
del Common Vulnerability Scoring System (CVSS) como una guía para la criticidad, con los siguientes
objetivos de implementación de parches:
 Crítico (9.0+ puntuación): aplica el plazo de 1 mes de lanzamiento
 Alta (7,0 - 8.9 Valoración): se aplica un plazo de 2 meses de su lanzamiento
 Bajo / Medio (<7,0 score): definido por el usuario.
 Fuente e integridad validación de software y actualizaciones de seguridad
o Antes de aplicar el software y las actualizaciones de seguridad, se valida su fuente legítima y se deben
realizar verificaciones de integridad (por ejemplo, validación de suma de comprobación).
2.3. Fortalecimiento del Sistema

Objetivo de Control: Reducir la superficie de ataque cibernético de componentes relacionados con SWIFT mediante la
realización de Fortalecimiento del sistema.

 Sistemas operativos para aplicaciones relacionadas  Los sistemas operativos para PC del operador (o el
con SWIFT servidor de intercambio de información)
 Infraestructura de apoyo dentro de la zona segura (por
ejemplo, Firewall, routers)
Nota: Los HSM – Hardware Security Module SWIFT son FIPS 140-2 Nivel 3 compatibles con el sistema operativo subyacente
endurecido y están fuera del alcance de este control.
Factores de Riesgo:
 El exceso de la superficie de ataque
 La explotación de la configuración del sistema inseguro
Fortalecimiento de seguridad se lleva a cabo y se mantiene en todos los componentes en el estudio.
El fortalecimiento del sistema aplica el concepto de seguridad de "privilegio mínimo" a un sistema al deshabilitar funciones
y servicios que no son necesarios para las operaciones normales del sistema. Este proceso reduce las capacidades del
sistema, las características y los protocolos que una persona maliciosa puede usar durante un ataque.
 Todos los sistemas dentro del alcance están endurecidos de acuerdo con uno o más de los siguientes:
o Guía de configuración de seguridad del proveedor,
o Guía de configuración de seguridad estándar del sector (por ejemplo, CIS, DISA STIG, NIST),
o Una configuración de seguridad estándar o local de un regulador o un conjunto de controles del mismo
rigor que el vendedor o la guía de la industria.
 Los requisitos de configuración específicos de la aplicación pueden invalidar las configuraciones de Fortalecimiento
objetivo para mantener un estado operativo adecuado para los sistemas relacionados con SWIFT.
 Como mínimo, el proceso de Fortalecimiento debe:
o Cambiar las contraseñas por defecto,
o Deshabilitar o eliminar cuentas de usuario innecesarias,
o Deshabilitar o restringir servicios, puertos y protocolos innecesarios,
o Eliminar software innecesario,
o Restrinja los puertos físicos (por ejemplo, USB) según corresponda,
o Ajusta cualquier configuración por defecto que se sepa que es vulnerable.
Los proveedores y los estándares de la industria enumerados anteriormente pueden proporcionar una guía
detallada sobre el cumplimiento de estos objetivos mínimos.
 Las desviaciones de la norma de Fortalecimiento seleccionado se documentan junto con la justificación de la
desviación y mitigaciones potencial aplicadas.
 Sistemas se mantienen seguro:
o Al verificar con regularidad, al menos dos veces al año, los sistemas en comparación con las
configuraciones de seguridad identificadas según la guía anterior para tomar cualquier acción correctiva
relevante
o O aplicando regularmente las configuraciones seguras identificadas.
2.4. Seguridad de flujo de datos de backoffice

Objetivo de Control: Asegurar la confidencialidad, integridad y autenticidad mutuo de los flujos de datos entre la oficina de
nuevo (o middleware) aplicaciones y la conexión de componentes de infraestructura SWIFT.

 N/A  Los sistemas operativos para PC del operador (o el
servidor de intercambio de información)
 Sistemas operativos para aplicaciones relacionadas
con SWIFT
 Infraestructura de apoyo dentro de la zona segura (por
ejemplo, Firewall, routers)
 capa de intercambio de datos: los flujos de
transacciones financieras
Factores de Riesgo:
 sistema de tráfico no autenticado
Se implementan mecanismos de autenticación basados en confidencialidad, integridad y el nivel mutuo o de mensajes para
proteger los flujos de datos entre las aplicaciones de back-office (o middleware) y la conexión de componentes de la
infraestructura SWIFT.
Protección de los flujos de datos entre la oficina de apoyo (o middleware) primer salto, como se ve desde la zona de
seguridad y las garantías de conexión de infraestructura SWIFT contra el hombre en el medio, la divulgación no intencional,
modificación y acceso a los datos en tránsito.
 Los flujos de datos entre los sistemas de back-office (o sistemas middleware) y componentes de la infraestructura
SWIFT directamente conectados están protegidos mediante un mecanismo de seguro (por ejemplo, "LAU en
combinación con una protección de la confidencialidad" u otra solución de autenticación basado en mensajes, DSIG
XML, AES GCM Authenticated Encryption, de 2 vías TLS) que proporciona confidencialidad, integridad y
autenticación mutua de los flujos de datos.
 Esto incluye el flujo de datos entre:
o Back-office (o middleware) y la interfaz de mensajería,
o Back-office (o middleware) y la interfaz de comunicación,
o Back-office (o middleware) y el conector.
 Los protocolos seguros utilizan algoritmos criptográficos actuales y comúnmente aceptados (por ejemplo, AES,
ECDHE), con longitudes de claves de acuerdo con las mejores prácticas actuales. Puede encontrar más directrices
sobre algoritmos criptográficos que admiten protocolos seguros en SWIFT Knowledge Base TIP 5021566.
notas:
 Para las aplicaciones de middleware (como IBM® MQ) que se conectan directamente a los componentes de la
infraestructura SWIFT, se espera que los usuarios implementen el mismo nivel de protección entre esta capa de
middleware y las aplicaciones de back-office. Como tal, la cadena de transacciones de extremo a extremo (entre
los sistemas de back-office y la infraestructura SWIFT) está protegida.
 Aunque este control está clasificado como recomendado, SWIFT recomienda implementar mecanismos de
protección de confidencialidad, integridad y autenticación como se especifica en las pautas de implementación.
 SWIFT espera que este control sea obligatorio en una versión futura de este documento.
2.5. Protección de datos de transmisión externa

Objetivo de Control: Proteger la confidencialidad de los datos relacionados con SWIFT transmitidos y que residan fuera de
la zona de seguridad.

 SWIFT relacionados con datos de la zona segura.  N/A
Factores de Riesgo:
 Compromiso de los datos de copia de seguridad de confianza
Los datos confidenciales relacionados con SWIFT que salen de la zona segura como resultado de las copias de seguridad,
la replicación de datos para la recuperación o el procesamiento fuera de línea están cifrados.
El cifrado de datos confidenciales que salen de la zona segura protege contra la divulgación involuntaria de los datos cuando
se extrae de su entorno operativo normal.
 Los datos sensibles relacionados con SWIFT según la clasificación de datos interna de los usuarios o las leyes
aplicables y regulaciones (como mínimo, las cargas útiles de mensajes, archivos, contraseñas y otros
Authenticators) se cifra cuando:
o Los datos se toman fuera de la zona segura (por ejemplo, back-ups, archivos),
o Los datos se encuentran en tránsito entre las zonas seguras (por ejemplo, los datos se transportan entre
los centros de datos).
 Los protocolos de cifrado utilizan un algoritmo criptográfico actual y comúnmente aceptado (por ejemplo, AES8,
ECDHE9), con longitudes de claves de acuerdo con las mejores prácticas actuales. Puede encontrar más
directrices sobre algoritmos criptográficos que admiten protocolos actualmente seguros en SWIFT Knowledge Base
TIP 5021566.
 La transmisión de datos cifrados cumple con las leyes y regulaciones aplicables.
 Si la criptografía de la protección de datos SWIFT ha sido comprometida, un proceso debe ser establecido para
aplicar la nueva criptografía y asegurar o destruir todas las copias de los datos comprometidos.
Consideraciones para implementaciones alternativas:

 Si los datos no pueden ser cifrados, como mínimo la transmisión de datos fuera de la zona segura debe ser
protegida a través de una red o la capa de transporte encriptada, y los datos están protegidos en el destino.
2.6. Confidencialidad e integridad de la sesión del operador

Objetivo de Control: Proteger la confidencialidad e integridad de las sesiones interactivas operador de conexión a la
infraestructura de SWIFT local.

 N/A  PC del operador (o servidor salto): sesiones de sistema
operativo
 PC del operador (o servidor salto): sesiones para
aplicaciones de interfaz en la zona segura
 zona segura: la sesión a las aplicaciones relacionadas
con SWIFT y HSM y sistemas operativos de
ordenadores operador con funciones específicas
Factores de Riesgo:
 Pérdida de confidencialidad operativa
 La pérdida de la integridad operativa
La confidencialidad y la integridad de las sesiones interactivas operador que conectan a la zona segura se salvaguarda.
sesiones de operador con la infraestructura SWIFT locales representan una amenaza única debido a una actividad inusual
o inesperado es más difícil de detectar durante las sesiones interactivas de lo que es durante la actividad de aplicación a
aplicación. Por lo tanto, es importante para proteger la integridad y confidencialidad de estas sesiones operador para reducir
cualquier posibilidad de uso indebido.
 Todas las sesiones interactivas están protegidas por un protocolo criptográfico (por ejemplo, SSH, HTTPS).
 Los protocolos utilizan un algoritmo criptográfico actual y comúnmente aceptado (por ejemplo, AES, ECDHE), con
longitudes de claves de acuerdo con las mejores prácticas actuales. Puede encontrar más directrices sobre
algoritmos criptográficos que admiten protocolos seguros en SWIFT Knowledge Base TIP 5021566.
 Las sesiones del operador y otros tipos de sesión (por ejemplo, la vigilancia o mantenimiento) tienen una función
de bloqueo de espera de inactividad que limita la sesión para el marco de tiempo mínimo necesario para realizar
tareas de negocio como de costumbre.
o A 15 minutos de bloqueo se recomienda para las sesiones de usuario final.

 Si el tiempo de espera no se implementa a nivel de aplicación, que debe aplicarse en el nivel del sistema operativo
de la aplicación o en el servidor de intercambio de información.
2.7. Escaneo de Vulnerabilidades

Objetivo de Control: Identificar las vulnerabilidades conocidas dentro del entorno de SWIFT local mediante la implementación
de un proceso de escaneo de vulnerabilidades regular y actuar sobre los resultados.

 N/A  PC del operador (o el servidor de intercambio de
información)
 zona segura: todas las aplicaciones relacionadas con
el SWIFT y sistemas operativos
Factores de Riesgo:
Los sistemas de PC de zona segura y operador se exploran en busca de vulnerabilidades utilizando una herramienta de
escaneo actualizada y confiable, y los resultados se consideran para las acciones de resolución adecuadas.
La detección de vulnerabilidades conocidas permite analizar, tratar y mitigar las vulnerabilidades. La mitigación de las
vulnerabilidades reduce la cantidad de vías que un actor malintencionado puede usar durante un ataque. Es necesario un
proceso de exploración de vulnerabilidades que sea completo, repetible y se realice de manera oportuna, para detectar
continuamente las vulnerabilidades conocidas y permitir acciones adicionales.
 Análisis de vulnerabilidad se realiza al menos anualmente, así como después de cualquier cambio significativo en
el medio ambiente (por ejemplo, nuevos componentes de servidor, red cambio de diseño).
o Las herramientas de exploración de vulnerabilidades provienen de un proveedor de renombre y se
actualizan con los perfiles de exploración dentro de un mes antes de la exploración.
o El tipo más adecuado de análisis de vulnerabilidades (utilizando credenciales o cajas negras) se
selecciona para el ambiente. Cualquier credencial administrativa utilizada para la exploración está
apropiadamente protegida.
o Se han implementado suficientes medidas de seguridad basadas en el riesgo para minimizar cualquier
impacto operacional (por ejemplo, ejecutar exploraciones en modo seguro u omitir sistemas que pueden
verse afectados negativamente por la exploración).
 Todas las pruebas de vulnerabilidad a través de los servicios y productos relacionados con SWIFT son consistentes
con la Política de Pruebas cliente.
 El resultado de la exploración de vulnerabilidades se documenta (con acceso restringido) y se analiza para la acción
y remediación adecuadas (como la aplicación de actualizaciones de seguridad en línea con el control 2.2).
 Se recomienda el escaneo trimestral, mensual o idealmente en tiempo real.
2.8. Outsorcing de Actividad crítica

Objetivo de Control: Garantizar la protección de la infraestructura SWIFT local a partir de los riesgos expuestos por la
externalización de las actividades críticas.

 N/A  Control de la organización
Factores de Riesgo:
La exposición a las prácticas de seguridad de baja calidad
Las actividades críticas externalizadas están protegidas, como mínimo, al mismo nivel de atención que si se operara dentro
de la organización de origen.
Cuando las actividades críticas, como el mantenimiento de la red y el sistema, se subcontratan a un tercero (por ejemplo,
un proveedor de TI externo), es esencial que, como mínimo, se mantenga el estándar original de cuidado de la seguridad
(además del cumplimiento de este marco de control de seguridad) para garantizar que no se introduzcan nuevas debilidades
o vulnerabilidades.
Nota:
SWIFT define las siguientes operaciones como crítico:
 Gestión de seguridad y gestión de cambios del hardware y software (incluidas las aplicaciones y el sistema
operativo) que admiten el servicio SWIFT,
 Operaciones relacionadas con RMA,
 Acceder a datos confidenciales del usuario (por ejemplo, contenido del mensaje),
 Seguimiento de eventos que contienen datos sensibles del usuario.
 Gestión y configuración de la red.
 Operaciones de transacción relacionadas con SWIFT (por ejemplo, creación o modificación de un mensaje de
transacción financiera dentro de la interfaz de mensajería).
 Los Acuerdos de Nivel de Servicio (SLA) y un Acuerdo de No Divulgación (NDA 1) se establecen con cualquier
tercero a quien se hayan subcontratado actividades críticas. Estos acuerdos de nivel de servicio definen el estándar
de atención bajo el cual esas operaciones críticas son llevadas a cabo por un tercero.
 Una Evaluación de Riesgo de la tercera parte se lleva a cabo al inicio del trabajo y se revisa de forma regular a
partir de entonces.
2.9. Controles comerciales de transacciones

Objetivo de Control: Restrinja la actividad de transacción a las contrapartes validadas y aprobadas y dentro de los límites
esperados del negocio normal.
Se requiere este control para:

 N/A  GUI
 zona segura: interfaz de mensajería
 zona segura: interfaz de comunicación
 zona de seguridad: conector
Factores de Riesgo:
 Negocios realizados con una contraparte autorizada
 anomalías detecta o actividad sospechosa
Implemente controles de RMA y controles de detección, prevención y validación de transacciones para restringir la actividad
de transacciones dentro de los límites esperados o negocios normales.
La implementación de controles comerciales que restringen las transacciones SWIFT en la mayor medida posible reduce la
oportunidad tanto para el envío como para la recepción de transacciones fraudulentas. Estas restricciones se determinan
mejor a través de un análisis de la actividad comercial normal. Los parámetros se pueden configurar para restringir el negocio
a umbrales aceptables en función de la actividad "normal".
 Aplicación de gestión de relaciones (RMA)
o Los principios apropiados de conocimiento de su cliente y la diligencia debida se realizan durante la
creación y el mantenimiento de las relaciones de RMA.
o Las relaciones de RMA se revisan al menos una vez al año para garantizar que las relaciones obsoletas
se eliminen de manera oportuna.
 Control de transacciones
o Implemente controles que detecten prevengan o validen adicionalmente las transacciones fuera de los
límites esperados del negocio normal. Ejemplos incluyen:
 El envío y la aprobación de transacciones SWIFT están restringidos fuera del negocio normal. En
los casos de procesamiento SWIFT centralizado durante las 24 horas, restrinja o supervise las
transacciones según corresponda para dar soporte a los negocios como de costumbre.
1 Un acuerdo de confidencialidad (ADC), acuerdo de no divulgación (en inglés non-disclosure agreement o NDA), también referidos como
contratos o convenios de confidencialidad, es un contrato legal entre al menos dos entidades para compartir material confidencial o
conocimiento para ciertos propósitos, pero restringiendo su uso público. De manera más formal, estos textos se pueden titular también
como Acuerdo de Confidencialidad y No Divulgación. Un ADC crea una relación confidencial entre los participantes para proteger
cualquier secreto comercial. Por tanto, un ADC puede proteger información de una empresa privada.
 Disponer de un proceso para emitir y verificar los mensajes de confirmación (por ejemplo, para
verificar que las confirmaciones de MT900 y MT910 coinciden con las transacciones que se han
producido en las cuentas),
 Conciliación de los registros contables de la entidad con los mensajes de estado de cuenta del
día (por ejemplo, MT 940 y MT 950),
 La reconciliación se realiza a diario entre los mensajes que se envían a / desde la oficina interna
y a / desde la red SWIFT,
 Se realiza un seguimiento de los números de sesión dentro de la interfaz de mensajería para
garantizar que la numeración secuencial de la sesión esté intacta, sin brechas inesperadas.
 Limite las sesiones activas de SWIFTNet FIN al horario comercial (por ejemplo, las sesiones
automatizadas de terminales lógicas se desconectan al final del día hábil). En los casos de
procesamiento SWIFT centralizado las 24 horas, restringir o monitorear las transacciones según
corresponda para dar soporte a los negocios como de costumbre,
 Supervisar transacciones no características (por ejemplo, cantidades excepcionalmente altas,
beneficiarios o monedas inusuales).
o Mejoras opcionales:
 Las cuentas de la aplicación y del sistema operativo están restringidas a los intentos de inicio de
sesión que se producen fuera de las horas operativas específicas del rol esperado.
 La reconciliación independiente se realiza con los datos de transacción de los usuarios obtenidos
de forma segura de una fuente secundaria (por ejemplo, a través de los informes de validación
diaria de SWIFT) o verificando que la transacción sea genuina con el emisor y/o el destinatario.
2.10. Fortalecimiento de la aplicación

Objetivo de Control: Reduzca la superficie de ataque de los componentes relacionados con SWIFT mediante el
Fortalecimiento de la aplicación en las interfaces de comunicación y mensajería certificadas por SWIFT y las aplicaciones
relacionadas.

 interfaz de mensajería  N/A
 Interfaz de comunicación
 GUI
 SWIFTNet Link
 conector
 Las aplicaciones adicionales instaladas en los
componentes anteriores y manejo de datos
relacionados con SWIFT
Factores de Riesgo:
 El exceso de la superficie de ataque
 Explotación de configuración de la aplicación insegura
Todas las interfaces de mensajería (por ejemplo, Alliance Access, Alliance Messaging Hub y equivalentes) y las interfaces
de comunicación (por ejemplo, Alliance Gateway y equivalentes) de los productos dentro de la zona segura cuentan con la
certificación SWIFT. El Fortalecimiento de la seguridad se lleva a cabo y se mantiene en todos los componentes dentro del
alcance.
El Fortalecimiento de la aplicación aplica el concepto de seguridad de "privilegio mínimo" a una aplicación al deshabilitar
funciones y servicios que no se requieren para las operaciones normales. Este proceso reduce las capacidades,
características y protocolos de la aplicación que una persona maliciosa puede usar durante un ataque. También asegura
que se cambien las credenciales predeterminadas potenciales.
Además, SWIFT ejecuta un Programa de Certificación de Interfaz para garantizar que las interfaces estén alineadas con las
prácticas actuales y para brindar al cliente garantías adicionales, garantías y una mejor visibilidad de las capacidades de los
productos individuales. Tras la validación exitosa de los resultados de las pruebas por parte de SWIFT Test Authority, la
certificación se publica en el Registro de Certificación. De acuerdo con los Términos y Condiciones Generales de SWIFT,
los clientes deben utilizar una interfaz certificada.
 Asegúrese de que las Interfaz de mensajería y comunicación estén certificadas por SWIFT (la lista de Interfaz
certificadas se publica en el Registro de Certificación en www.swift.com).
o La interfaz certificada por SWIFT debe cumplir con todos los requisitos de conformidad de seguridad
(obligatorios y de recomendados) definidos en el SWIFT Certified Interface Programme.
 Si aún no se han cumplido algunos requisitos de conformidad de seguridad, el usuario debe
actualizar a una interfaz certificada que implemente al menos los requisitos mínimos obligatorios
de conformidad de seguridad.
 Se debe contactar al proveedor de la interfaz en caso de duda sobre la disponibilidad de algunas
funcionalidades de seguridad o su configuración y uso adecuados.
 Todas las aplicaciones dentro del alcance están reforzadas considerando uno o más de los siguientes:
o Guía de seguridad del proveedor, operativa o de configuración.
o La configuración de seguridad estándar o los controles de un local o regulador están configurados con el
mismo rigor que la guía del proveedor.
 Como mínimo, el proceso de Fortalecimiento de la aplicación debe:
o Cambiar las contraseñas existentes predeterminadas,
o Deshabilitar o eliminar cuentas de usuario innecesarias,
o Deshabilitar o restringir componentes, adaptadores o conectores innecesarios,
o Configurar de forma segura los adaptadores, conectores o conexiones remotas,
o Eliminar los paquetes innecesarios,
o Ajusta cualquier configuración por defecto que se sepa que es vulnerable.
 Las desviaciones de las reglas de Fortalecimiento seleccionadas se documentan junto con la justificación de la
desviación.
Nota: SWIFT espera que este control sea obligatorio en una versión futura de este documento.
3. Asegure físicamente el entorno
3.1. Seguridad Física

Objetivo de Control: Impedir el acceso físico no autorizado a equipos sensibles, entornos de trabajo, sitios de alojamiento y
almacenamiento.

 N/A 
PC del operador (o el servidor de intercambio de
información), incluido el equipo desmontable
 zona segura: todo el hardware
 plataforma de virtualización (también conocido como el
hipervisor)
Nota: cajas Alliance Connect VPN están fuera de alcance, pero espera que sea en un ambiente con controles físicos
apropiado como se describe aquí a continuación.
Factores de Riesgo:
 Acceso físico no autorizado
Existen controles de seguridad física para proteger el acceso a equipos sensibles, sitios de alojamiento y almacenamiento.
La implementación de controles de seguridad física protege contra amenazas internas y externas, y reduce los ataques
oportunistas habilitados por el acceso a los sistemas físicos.
 Seguridad de equipos removibles
o El equipo extraíble sensible (por ejemplo, el Dispositivo de entrada de PIN (PED), las teclas PED, las
tarjetas inteligentes relacionadas con SWIFT, los tokens USB, los dispositivos TOTP) se supervisa o
almacena de forma segura cuando no está en uso.
o Los equipos extraíbles sensibles que se requieren para operaciones continuas normales (por ejemplo,
discos intercambiables en caliente, dispositivos HSM) se alojan en un centro de datos o como mínimo, en
una habitación cerrada.
o Los medios de respaldo (por ejemplo, cintas) están asegurados físicamente.
 Seguridad del entorno laboral.
o Las PC del operador están ubicadas en un entorno de trabajo seguro donde el acceso se controla y se
otorga solo a los empleados y otros trabajadores y visitantes autorizados. No se requiere un área física
separada para las PC del operador que acceden a los sistemas SWIFT.
o Las impresoras utilizadas para transacciones SWIFT están ubicadas en un entorno de trabajo seguro y su
acceso está restringido.
o El USB y otros puntos de acceso externos en las PC del operador están deshabilitados en la mayor medida
posible, mientras que aún admiten operaciones (por ejemplo, cuando se requieren tokens para autenticar
las operaciones de mensajes).
 Seguridad para trabajadores remotos (por ejemplo, teletrabajadores, personal de operaciones "de guardia")
o Se establece una política de seguridad para respaldar los casos de uso esperados para trabajadores
remotos. Los siguientes elementos se consideran al establecer la política:

 Seguridad física del entorno de teletrabajo esperado.
 Reglas para el equipo personal utilizado para fines comerciales de SWIFT (por ejemplo, las PC
personales no se pueden usar para acceder a la infraestructura de SWIFT, sin embargo, los
dispositivos móviles personales se pueden usar como un segundo factor de autenticación).
 Seguridad durante el uso en entornos públicos,
 Seguridad en transporte público y privado,
 Almacenamiento de equipos,
 Acceso no autorizado a equipos (por ejemplo, de familiares o amigos),
 Requisitos de acceso remoto (VPN recomendada con autenticación multifactor),
 Protección de los dispositivos móviles utilizados para la autenticación, como la verificación OTP
o SMS (se recomienda habilitar las funciones de contraseña y bloqueo automático),
 Controles compensatorios (por ejemplo, escritorio virtual que impide el almacenamiento local;
cifrado de disco completo),
 Reporte de incidentes de seguridad (por ejemplo, robo) mientras se trabaja de forma remota.
 Seguridad del entorno del servidor.
o Los servidores se alojan en un centro de datos o como mínimo, en una sala cerrada con acceso limitado
y controlado (por ejemplo, mediante el uso de tarjetas de control de acceso o datos biométricos).
 Idealmente, los servidores están montados en rack. Se realiza una evaluación de riesgos para
determinar si un bastidor separado y exclusivo, o el bloqueo del bastidor, es apropiado en función
de los controles de acceso físico existentes del centro de datos.
o El entorno del servidor tiene videovigilancia con detección de movimiento y equipos de grabación. La
implementación de la videovigilancia de grabación y retención de imágenes cumple con las leyes y
regulaciones aplicables. Lo ideal es que las imágenes se conserven durante al menos tres meses.
o No hay referencia física a SWIFT en los servidores (por ejemplo, etiquetas).
o Los puertos externos (por ejemplo, USB, bus serie) en los servidores se deshabilitan en la mayor medida
posible mientras se siguen dando soporte a las operaciones.
 Registro de acceso físico y revisión
o Se registra el acceso físico a las áreas de equipos sensibles (por ejemplo, centro de datos,
almacenamiento seguro).
o Los registros de acceso físico están disponibles para auditorías e investigaciones y se conservan durante
un mínimo de 12 meses y cumplen con las leyes y regulaciones aplicables.
o El acceso físico se revoca (o modifica) rápidamente cuando un empleado cambia de rol o abandona la
organización.
o Las listas de control de acceso físico se revisan al menos una vez al año.
4. Evitar el Compromiso de Credenciales
4.1. Política de Contraseñas
Objetivo de Control: Asegúrese de que las contraseñas sean lo suficientemente resistentes a los ataques de contraseñas
comunes implementando y aplicando una política de contraseñas efectiva.

 N/A  Inicio de sesión en el PC del operador (o el servidor de
intercambio de información)
 zona segura: las cuentas de aplicaciones y sistema
operativo
 Tokens personales y dispositivos móviles personales
se utilizan como factor de posesión para la
autenticación de múltiples factores (ver 4.2 Control)
Factores de Riesgo:
 Rompiendo contraseñas, adivinando u otro compromiso computacional
Todas las cuentas de aplicaciones y sistemas operativos aplican contraseñas con parámetros apropiados, como la longitud,
la complejidad, la validez y la cantidad de intentos de inicio de sesión fallidos. De manera similar, los tokens personales y
los dispositivos móviles aplican contraseñas o números de identificación personal (PIN) con los parámetros adecuados.
La implementación de una política de contraseñas que protege contra ataques de contraseñas comunes (por ejemplo,
adivinar y fuerza bruta) es efectiva para proteger contra el compromiso de la cuenta. Los atacantes a menudo usan los
privilegios de una cuenta comprometida para moverse lateralmente dentro de un entorno y progresar en el ataque. Otro
riesgo es el compromiso de las claves de autenticación locales para alterar la integridad de las transacciones.
Sin embargo, es importante reconocer que las contraseñas por sí solas generalmente no son suficientes en el panorama
actual de amenazas cibernéticas. Los usuarios deben considerar este control en estrecha relación con el requisito de
autenticación multifactor.
 Se establece una política de contraseña que cubre también la configuración del PIN, se ajusta a los estándares
actuales de la industria o a las mejores prácticas de la industria, y define los siguientes criterios:
o Caducidad de la contraseña,
o Longitud de la contraseña, composición, complejidad y otras restricciones,
o Reutilización de contraseña,
o Bloqueo tras intentos fallidos de autenticación y remedio.
o Los requisitos de contraseña pueden modificarse según sea necesario para casos de uso específicos:
 En combinación con un segundo factor (por ejemplo, una contraseña de un solo uso),
 Destino de autenticación (por ejemplo, sistema operativo, aplicación, dispositivo móvil, token),
 Tipo de cuenta (operador general, operador privilegiado, cuenta de aplicación a aplicación o
claves de autenticación locales).
Se pueden encontrar más recomendaciones de buenas prácticas sobre la configuración de parámetros de
contraseña y PIN en SWIFT Knowledge Base TIP 5021567 y 5022038.
 La política de contraseñas se desarrolla teniendo en cuenta las vulnerabilidades conocidas basadas en contraseñas
en el entorno informático. Por ejemplo, requerir una contraseña de más de 15 caracteres para los sistemas Windows
impide que Windows calcule el hash de contraseña LM (LAN Manager) altamente vulnerable.
 La política de contraseña establecida se aplica a través de medios técnicos (por ejemplo, a través de la política de
grupo de Active Directory o dentro de la configuración de la aplicación) siempre que sea posible.
 La efectividad de la política de contraseña se revisa regularmente (se recomienda anualmente).
 Las configuraciones del sistema relacionadas con la administración de contraseñas y el almacenamiento están
alineadas con las mejores prácticas de la industria y los proveedores (por ejemplo, habilitando la configuración del
registro "NoLMHash" en Windows).
 Las contraseñas utilizadas para los sistemas de zona segura están significativamente más expuestas si las
contraseñas se almacenan en sistemas de autenticación fuera de la zona segura (por ejemplo, un Active Directory
de empresa). En cambio, las contraseñas para los sistemas de zona segura se almacenan, en la mayor medida
posible, solo dentro de la zona (por ejemplo, en un Active Directory para sistemas de producción) como se describe
en la guía para el diseño de la zona segura.
Nota: Es importante que los usuarios implementen contraseñas seguras y preferiblemente, una autenticación sólida, para
todos los sistemas utilizados dentro de la cadena de transacciones de extremo a extremo, y no limiten estos controles solo
a la infraestructura SWIFT.
4.2. Multifactor de Autenticación
Objetivo de Control: Evite que el compromiso de un solo factor de autenticación permita el acceso a los sistemas SWIFT
mediante la implementación de la autenticación multifactor.

Dependiendo de la aplicación:
 N/A  log-in PC operador
 El acceso del operador para saltar servidor
 Operador del proceso de inicio de sesión en la interfaz
de mensajería (incl. hosted DB) y la interfaz de
comunicación
 sistema operativo anfitrión de la interfaz de mensajes
(incl. hosted DB)) y la interfaz de comunicación.
Factores de Riesgo:
 Repetición de credenciales
 Rompiendo contraseñas, adivinando u otro compromiso computacional.
 El robo de contraseñas
Múltiples factores de autenticación se utilizan para el acceso de los usuarios a las aplicaciones interactivas relacionadas con
SWIFT y las cuentas del sistema operativo.
El multifactor de autenticación requiere la presentación de dos o más de los factores de autenticación común se mencionan
a continuación:
 SYK (Something You Know): Algo que el usuario sabe (como una contraseña)
 SYH (Something You Have): Algo que el usuario tiene (como una smart card, token)
 SYA (Something You Are): Algo que el usuario es o hace (como una huella digital)
La implementación de la autenticación multifactor proporciona una capa adicional de protección contra los ataques de
autenticación comunes (por ejemplo, shoulder surfing (mirar por encima del hombro es una técnica de ingeniería social),
reutilización de contraseñas o contraseñas débiles) y brinda mayor protección contra el compromiso de la cuenta. Los
atacantes a menudo usan los privilegios de una cuenta comprometida para moverse lateralmente dentro de un entorno y
progresar en un ataque.
En la aplicación de autenticación de múltiples factores, se aplican los siguientes principios:
 Cuando se basa en un factor de conocimiento (generalmente una contraseña) combinado con un factor de posesión
(un dispositivo móvil), el dispositivo utilizado para el segundo factor no debe ser el mismo que el dispositivo utilizado
para ingresar el primer factor. Como tal, el uso de una aplicación para generar el segundo factor en el mismo
dispositivo / PC utilizado para ingresar el primer factor (contraseña) no se considera suficiente para acceder a los
sistemas SWIFT locales.
o Las soluciones segundo factor basado en SYH incluyen (lista no exhaustiva): TOTP, RSA SecurID,
Digipass, Aplicación para móviles, Número de transacción de autenticación (TAN) Tabla, token USB
personal. Solución que se ha seleccionado como por propia gestión de riesgos del usuario.
o Un SYA se combina de forma más segura con un SYH que con un SYK.
 La autenticación multifactor se implementa al menos en una etapa / paso de autenticación que enfrenta el usuario
final cuando accede a una aplicación SWIFT:
o Para administradores de sistemas operativos:
 En el límite de la zona segura (servidor de intercambio de información),
 En el inicio de sesión de la PC del operador dedicado (dentro de la zona segura).
 Para usuarios finales en orden descendente de robustez de seguridad:
o En las aplicaciones SWIFT individuales (en la GUI basada en navegador, en la interfaz de mensajería o
en la interfaz de comunicación),
o En el límite de la zona segura (servidor de intercambio de información),
o En el inicio de sesión de la PC del operador dedicado (es decir, dentro de la zona segura).
 La autenticación multifactor se implementa para el acceso administrativo de usuarios remotos, generalmente para
la autenticación VPN.
 Los sistemas de autenticación multifactor están mucho más expuestos si las credenciales de autenticación se
almacenan fuera de la zona segura (por ejemplo, dentro de un Active Directory empresarial). Si es factible, el
sistema de autenticación que soporta la solución multifactorial está ubicado dentro de la zona segura.
 Los factores de autenticación presentados se asignan individualmente y respaldan la responsabilidad individual del
acceso a los servicios, el sistema operativo y las aplicaciones.
 Si se implementa el inicio de sesión único (por ejemplo, SAML), entonces se requiere un segundo factor en el inicio
de sesión único o en una etapa posterior.
Nota:
Todas las Interfaz de mensajería y comunicación de proveedores de terceros certificadas por SWIFT y SWIFT deben admitir
o integrar la autenticación multifactor.
5. Administrar identidades y segregar privilegios
5.1. Control de Acceso Lógico

Objetivo de Control: Hacer cumplir los principios de seguridad de acceso en la necesidad de conocer, mínimo privilegio y la
separación de funciones para las cuentas del operador.

 N/A  Todas las cuentas de operador (por ejemplo, sistemas
operativos, aplicaciones y HSM)
Factores de Riesgo:
 El exceso de privilegio o de acceso
 La segregación de violaciones de derechos
 Acceso no autorizado
Las cuentas se definen de acuerdo con los principios de seguridad de acceso en la necesidad de conocer, mínimo privilegio
y la separación de funciones.
La aplicación de los principios de seguridad de (1) necesidad de saber, (2) mínimos privilegios y (3) la separación de
funciones es esencial para restringir el acceso a la infraestructura SWIFT local. La administración efectiva de las cuentas de
los operadores reduce las oportunidades para que una persona maliciosa use las cuentas como parte de un ataque.
Una política de control de acceso lógico se documenta y se aplicará en cuenta los siguientes principios:
 Necesito saber
o Solo los operadores (usuarios finales y administradores) que tienen un requisito continuo para acceder a
la zona segura pueden tener cuentas dentro de la zona segura.
o Los privilegios solo se asignan a un operador con una necesidad de información validada (por ejemplo, la
configuración del sistema garantiza que los operadores solo tengan acceso a la información, los archivos
y los recursos del sistema necesarios para sus tareas definidas). El acceso a otras funciones del sistema
está deshabilitado.
 Mínimos Privilegios
o La configuración del sistema garantiza que los privilegios de usuario y administrador se controlan de una
manera que permite que todos los privilegios se adapten a las necesidades individuales.
o Las cuentas se otorgan solo los privilegios que se requieren para la operación normal y de rutina. Los
privilegios adicionales solo se otorgan de forma temporal.
 Segregación de funciones y 4-Eyes.
o La guía documentada del proveedor sobre la separación de roles se sigue en la documentación específica
del proveedor.
o Los deberes sensibles están separados. Esto significa que algunas funciones no pueden ser
representados por el mismo individuo, tales como:
 Envío de transacciones y aprobación de transacciones.
 Administrador de aplicaciones y roles de oficial de seguridad
 Administradores de redes y sistemas operativos.
o Los permisos sensibles están separados para evitar eludir el principio de 4-Eyes. Como mínimo, esto
requisito se aplica para acceder a las operaciones de control y configuración de seguridad en los siguientes
componentes: Mensajería y la interfaz de comunicación, sitios y monumentos históricos, SWIFTNet Online
Operations Manager y canal seguro.
 Revisión y revocación de la cuenta
o Los privilegios se revocan rápidamente cuando un empleado cambia de rol o abandona la organización.
o Las cuentas se revisan al menos anualmente (idealmente con mayor frecuencia) y se ajustan según sea
necesario para hacer cumplir los principios de seguridad de acceso.
 Un procedimiento de emergencia para acceder a cuentas privilegiadas se documenta para su uso cuando las
personas autorizadas no están disponibles debido a circunstancias inesperadas:
o Se registra cualquier uso operacional del procedimiento.
o Se controla el acceso a las cuentas de emergencia privilegiadas. El uso se registra y la contraseña se
cambia después del uso de emergencia.
5.2. Administración de Token

Objetivo de Control: Garantizar la correcta gestión, seguimiento y el uso de tokens de autenticación de hardware conectados
(si se utilizan Token).

 tokens de autenticación de hardware conectados  N/A
utilizados para las actividades de SWIFT
 Dispositivo de entrada de PIN (PED) utilizada para
operaciones de HSM
Factores de Riesgo:
 Autenticación de token de robo
 gestión de HSM mal utilizado
Los tokens de autenticación de hardware conectados se administran de manera adecuada durante la asignación,
distribución, revocación, uso y almacenamiento.
La protección de los tokens de autenticación de hardware conectados es esencial para salvaguardar la cuenta del operador
o sistema relacionada y refuerza las buenas prácticas de seguridad, proporcionando una capa adicional de protección contra
los atacantes.
 Se utiliza un proceso controlado para la asignación y distribución de tokens de hardware conectados utilizados para
las operaciones SWIFT (por ejemplo, token USB, token HSM, tarjeta inteligente).
 La asignación de tokens se revisa al menos una vez al año (idealmente con mayor frecuencia).
 Los tokens de hardware asignados personalmente se revocan cuando la persona ya no requiere acceso y,
posiblemente, debe eliminarse (recuperarse y destruirse).
 Se mantiene un registro de la propiedad de los tokens de hardware asignados.
 Los tokens de hardware se retiran físicamente del sistema y se aseguran o supervisan cuando no están en uso.
 Cuando se utiliza un PED remoto, se aplican las siguientes prácticas de seguridad:

o Las claves PED deben estar almacenadas y solo el personal relevante debe tener acceso a ellas (los
originales y las copias deben almacenarse en una caja fuerte y se debe hacer un seguimiento del acceso)
o Los flujos al HSM deben asegurarse de acuerdo con la Guía de seguridad de la Alianza que solicita limitar
el software implementado en la PC remota. Dicha PC debe ser una PC del operador dedicada y no una
PC del operador de uso general estándar.
5.3. Proceso de selección de personal

Objetivo de Control: Garantizar la confiabilidad del personal operativo del entorno de SWIFT local, mediante la realización
de control del personal.

 N/A  Todos los empleados, contratistas y personal con
acceso a los sistemas relacionados con SWIFT
Factores de Riesgo:
 Personal poco fiable o operadores de sistemas
El personal operativo de la infraestructura local de SWIFT es examinado antes de iniciar labores en el cargo y posteriormente
de forma periódica.
Un proceso de verificación de personal, autorización interna o externa, proporciona una garantía adicional de que los
usuarios finales o administradores de la infraestructura SWIFT local son confiables y reduce el riesgo de amenazas internas.
En la medida en que lo permitan las leyes y regulaciones aplicables y la información disponible, se recomiendan las
siguientes pautas y las verificaciones especificadas:
 Todo el personal dentro del alcance es examinado al menos cada 5 años.
 El proceso de selección inicial idealmente incluye las siguientes verificaciones:
o Verificación de identidad,
o Confirmación de los detalles completos de las calificaciones,
o Confirmación del historial de empleo anterior,
o Detalles de cualquier proceso civil o penal pasado o pendiente contra el empleado,
o Validación de cualquier participación en negocios externos que pueda resultar en un conflicto de intereses,
o Verificación de crédito financiero.
 El proceso de verificación periódico incluye las siguientes verificaciones:
o Detalles de cualquier proceso civil o penal pendiente contra el empleado,
o Validación de cualquier participación en negocios externos que pueda resultar en un conflicto de intereses,
o Verificación de crédito financiero.
5.4. Almacenamiento físico y lógico de la contraseña

Objetivo de Control: Proteger las contraseñas física y lógicamente almacenadas.

 zona segura: todas las aplicaciones, sistemas  Cuentas y contraseñas definidas en los siguientes
operativos, HSM y relacionadas Token y componentes componentes:
de red.  PC del operador (o servidor salto): sistema operativo
 SWIFTNet Online Gerente de Operaciones y swift.com  PC del operador (o servidor salto): sesión de usuario
interactiva.
Factores de Riesgo:
 El robo de contraseñas
Cualquier contraseña registrada para las cuentas con privilegios se almacenan en un lugar físico o lógico protegido, con
acceso restringido sobre la base de la necesidad de saber.
El almacenamiento seguro de contraseñas grabadas (repositorio) asegura que las contraseñas no son fácilmente accesibles
a los demás, protegiendo así contra el robo de la contraseña simple.
Este control se refiere al almacenamiento de emergencia, privilegiada o cualquier otra contraseña de cuentas.
 Las contraseñas escritas en medios físicos están protegidas a través de:
o Colocación dentro de un sobre de seguridad sellado, a prueba de manipulaciones,
o Almacenamiento en una caja fuerte certificada (por ejemplo, Underwriters Laboratories (UL) Class TL o
EN-1143-1),
o Registro de acceso a la ubicación de almacenamiento y la contraseña de la cuenta a la que se accedió.
 Las contraseñas almacenadas lógicamente (digitalmente) están protegidas a través de:
o Encriptación en reposo u ofuscación (es decir, sin almacenamiento de texto sin formato),
o Acceso autenticado a la ubicación de almacenamiento, idealmente con el registro de acceso.
 Las contraseñas no se registran en los manuales de usuario u otro material operativo a menos que la contraseña
se almacene de acuerdo con la guía anterior.
 Si se otorga acceso de emergencia a un operador que, en condiciones normales no tendría acceso, la contraseña
se cambiará inmediatamente después y opcionalmente, también la combinación de la caja fuerte de
almacenamiento.
 Las contraseñas no están codificadas en los scripts u otro código de software.
6. Detectar actividad anómala en sistemas o registros de transacciones
6.1. Protección contra malware

Objetivo de Control: Asegúrese de que la infraestructura de SWIFT local está protegida contra los programas maliciosos.

 N/A  PC del operador (o servidor salto) - sistemas
operativos Windows
 zona segura: los servidores relacionados con SWIFT--
sistemas operativos Windows
Factores de Riesgo:
 Ejecución de código malicioso
El software antimalware de un proveedor de confianza se instala y se mantiene al día en todos los sistemas.
El malware es un término general que incluye muchos tipos de software intrusivo y no deseados, como virus. La tecnología
antimalware (un término más amplio para el antivirus) es eficaz en la protección contra código malicioso que tiene un perfil
digital o comportamiento conocido.
 El escaneo antimalware en acceso (también conocido como escaneo en tiempo real o en segundo plano) se realiza
en todos los sistemas dentro del alcance. El escaneo completo bajo demanda se programa al menos semanalmente
para servidores y diariamente para las computadoras de los operadores. Por razones de rendimiento, las
exploraciones completas se realizan en momentos de bajo uso y/o fuera del horario comercial.
 El alcance del escaneo debe incluir todos los archivos de los sistemas en alcance. La exclusión de elementos o
directorios del escaneo está sujeta a una evaluación de riesgos considerando la configuración de la infraestructura
del usuario, los requisitos y políticas de seguridad interna, las capacidades del producto y los siguientes principios:
o Se espera que el software (como .exe, bibliotecas, scripts) y los datos estáticos (como los archivos de
configuración) se analicen en el acceso o en la instalación y luego de manera regular, cuando se
complementen con un mecanismo de integridad en tiempo de ejecución (en línea con la Verificación de
integridad del software representada en el control 6.2) que permite la identificación de cambios de archivos
o adiciones inesperadas.
o El contenido del servidor de la base de datos (archivos de datos) podría excluirse del análisis cuando los
datos se hayan validado antes de ser almacenados.
 El software antimalware de un proveedor de renombre se instala en todas las plataformas informáticas y se
actualiza de acuerdo con la frecuencia de escaneo.
 Los sistemas que no pueden actualizar sus perfiles o ejecutar exploraciones programadas se detectan y corrigen.
 Se comprueba la compatibilidad del software antimalware con el entorno operativo.
 El software antimalware está configurado en modo de prevención, si es posible, después de evaluar el impacto
operacional. Se recomienda configurar el software antimalware para poner en cuarentena los archivos sospechosos
y dar una alarma al departamento de seguridad del usuario en lugar de eliminarlos inmediatamente. Esto permite
que el departamento de seguridad del usuario investigue la alerta y posiblemente, evite futuros "falsos positivos" al
tiempo que permite la recuperación de archivos en caso de que se confirme que son legítimos.
 Asegúrese de que la transferencia de cualquier contenido de archivo no contenga ningún tipo de virus u otros datos
que puedan crear riesgos para el remitente, SWIFT o el receptor.
Mejoras opcionales:
 Los sistemas antimalware utilizan una combinación de capacidades basadas en firmas y basadas en heurísticas.
 Las soluciones antimalware se implementan en sistemas que no son Windows.
6.2. Integridad del software

Objetivo de Control: Asegurar la integridad del software de las aplicaciones relacionadas con SWIFT.

 zona de seguridad: conector  N/A
 zona segura: GUI a la interfaz de mensajes y la
comunicación
 zona segura: aplicación de interfaz de mensajería
 zona segura: aplicación de interfaz de comunicación
 zona segura: RMA
 zona segura: SNL
Factores de Riesgo:
 Cambios en el sistema no autorizadas
Una verificación de la integridad del software se lleva a cabo a intervalos regulares en interfaz de mensajes, interfaz de
comunicación y otras aplicaciones relacionadas con SWIFT.
Las comprobaciones de integridad de software proporcionan un control de detección contra la modificación inesperada de
software operacional.
 Comprobaciones de integridad de software se llevan a cabo en los componentes incluidos en el estudio en el
arranque y, además al menos una vez por día.
Opciones para la aplicación:
o Integrado en el producto,
o Tercero archivo de vigilancia de la integridad de la herramienta (FIM).
 Comprobación de la integridad del software descargado se lleva a cabo a través de la verificación de la suma de
comprobación en el momento de su despliegue.
Mejoras opcionales:
 Una comprobación de integridad se lleva a cabo en la memoria.
 Una comprobación de integridad se lleva a cabo a nivel del sistema operativo.
 Sistemas dentro de la zona segura implementan listas blancas de aplicaciones en el sistema operativo que permite
solamente conocidos y aplicaciones fiables para ser ejecutados.
6.3. Integridad de la Base de Datos

Objetivo de Control: Asegurar la integridad de los registros de base de datos para la interfaz de mensajes SWIFT.

 Bases de datos para productos de interfaz de  N/A
mensajería
Nota: este requisito no es relevante para la arquitectura A3 que no tiene una interfaz de mensajería en el entorno del
usuario.
Factores de Riesgo:
Una comprobación de integridad de la base de datos se realiza a intervalos regulares en las bases de datos que las
transacciones SWIFT récord.
Comprobaciones de integridad de base de datos proporcionan un control de detección contra la modificación inesperada a
los registros almacenados en la base de datos.
 La funcionalidad de comprobación de integridad de la base de datos está habilitada para garantizar la integridad a
nivel de registro (suma de comprobación o firma de los registros) y confirmar que no existen brechas en la
numeración de transacciones secuenciales.
 Opciones para implementaciones:
o Integrado en la aplicación de interfaz de mensajería,
o Integrado en la base de datos del producto.
Mejoras opcionales:
 Se realiza una verificación completa de la integridad de la base de datos a intervalos regulares, idealmente cada
dos semanas.
 La verificación de integridad realiza una verificación referencial completa en todos los registros (por ejemplo, no
hay registros huérfanos entre tablas) y busca registros eliminados inesperadamente.
 Se utiliza una instancia de base de datos dedicada para fines de SWIFT. La comprobación de integridad realiza
una comprobación de referencia completa de todos los registros (por ejemplo, no hay registros huérfanos entre las
tablas) y la búsqueda de los registros inesperadamente eliminados.
 Una instancia de base de datos dedicado se utiliza para fines de SWIFT.
6.4. Registro y Monitoreo

Objetivo de Control: los eventos de seguridad de discos y detectar acciones anómalas y las operaciones dentro del entorno
de SWIFT local.

 N/A  Capa de intercambio de datos: Red
 PC del operador (o servidor salto): sistema operativo
 zona de seguridad: conector
 zona segura: GUI a la interfaz de mensajes y la
comunicación
 zona segura: todas las aplicaciones de servidor y
sistemas operativos
 zona segura: la red y HSM
 zona segura: la base de datos
Factores de Riesgo:
 Detección de anomalías o actividad sospechosa
Se implementan capacidades para detectar actividades anómalas y existe un proceso o herramienta para almacenar y
revisar los registros con frecuencia.
El desarrollo de un plan de registro y monitoreo es la base para detectar efectivamente el comportamiento anormal y los
posibles ataques. A medida que el entorno operativo se vuelve más complejo, también lo será la capacidad de registro y
monitoreo necesaria para realizar una detección adecuada. La simplificación del entorno operativo permitirá un registro y
monitoreo más directo.
 Objetivos generales para el registro y monitoreo:
o Implementar un plan para el registro de actividades relevantes para la seguridad y configurar alarmas para
eventos de seguridad sospechosos (cuando sea compatible con la aplicación).
o Implementar un plan para monitorear eventos de seguridad en registros y para monitorear otros datos (por
ejemplo, actividades comerciales en tiempo real a través de la GUI) y establecer un plan para tratar las
alarmas informadas.
 Toda la actividad de registro y monitoreo cumple con las leyes y regulaciones aplicables y los contratos de empleo
que sustituyen cualquier guía de implementación.

 Registrando:
o Se implementan capacidades de registro para detectar el uso anormal dentro de la zona segura, así como
cualquier intento de socavar la efectividad de los controles dentro de la zona segura.
o Los registros proporcionan rastreabilidad del uso de la cuenta a la persona apropiada.
o Los registros de auditoría de la aplicación de la interfaz de mensajería y comunicación se conservan por
no menos de 12 meses y están suficientemente protegidos de un compromiso a nivel de administrador
empresarial (por ejemplo, los archivos de registro se transfieren a un sistema separado con diferentes
credenciales de administrador del sistema).
o Los registros de auditoría de la PC, el firewall y la base de datos del operador se retienen por no menos
de 31 días.
o Los registros mínimos que registrar incluyen:
- Historial de línea de comandos para cuentas de sistema operativo privilegiadas en servidores,
- Los registros de la aplicación de interfaz de mensajería y comunicación y los registros del sistema
operativo que detallan el comportamiento anormal del sistema (por ejemplo, actividad fuera del
horario laboral normal, múltiples intentos fallidos de inicio de sesión, errores de autenticación,
cambios en los grupos de usuarios),
- Los registros del Firewall,
- Registros de base de datos (si están disponibles y como mínimo, en el caso de soluciones de
base de datos alojadas).
 Monitoreando:
o Existen procedimientos para identificar actividades de inicio de sesión sospechosas en cualquier sistema
operativo privilegiado o cuenta de aplicación.
o Se han implementado procesos de monitoreo para revisar los datos de monitoreo de la base de datos, las
aplicaciones y los servidores, ya sea diariamente a través de revisiones humanas o mediante el monitoreo
automatizado con alertas.
o Se implementan procesos de monitoreo para revisar los datos de monitoreo de la red de manera regular.
o Se informa sobre actividades inusuales o sospechosas para investigación adicional al equipo de seguridad
apropiado.
Mejoras opcionales:
 Se implementa una capacidad de registro centralizado, que minimiza el número de ubicaciones de registro a
inspeccionar.
 El registro de sesiones se implementa para registrar toda la actividad realizada por cuentas privilegiadas en
servidores de zona segura SWIFT.
6.5. Detección de Intrusos

Objetivo de Control: Detectar y prevenir la actividad de la red anómala en y dentro del entorno de SWIFT local.

 N/A  De red (capa de intercambio de datos y dentro de la
zona segura)
Factores de Riesgo:
 anomalías detecta o actividad sospechosa
La detección de intrusiones se lleva a cabo para detectar el acceso no autorizado a la red y la actividad anómala.
Los sistemas de detección de intrusos se implementan más frecuentemente en una red - el establecimiento de una línea de
base para las operaciones normales y enviar notificaciones cuando se detecta una actividad anormal en la red. Como una
red operativa se vuelve más compleja (por ejemplo, los sistemas de comunicación a muchos destinos, acceso a Internet),
también lo hará la capacidad de detección de intrusión necesario para realizar una detección adecuada. Por lo tanto, la
simplificación de comportamiento de la red es un elemento útil para soluciones de detección de intrusos más sencillas y
eficaces. sistemas de detección de intrusiones a menudo combinan los métodos de detección en firmas y basadas en
anomalías. Algunos sistemas tienen la capacidad de responder a cualquier intrusión detectada (por ejemplo, terminación de
la conexión).
 El sistema de detección de intrusos está configurado para detectar actividad anómala dentro de la zona segura y
en el límite de la zona segura.
 La actividad de la red que se debe rastrear para el análisis de detección de intrusiones puede incluir:
o Conexiones entrantes y salientes en horario no comercial,
o Transferencias de archivos inesperados desde la zona segura,
o Uso inesperado de puerto o protocolo (por ejemplo, P2P).
 El sistema tiene un proceso repetible para actualizar periódicamente las firmas de intrusión conocidas.
 Si se detecta una intrusión, se genera una alarma y, si la herramienta lo permite, se activa un mecanismo de
defensa manual o automáticamente.
 Las intrusiones detectadas se gestionan a través del proceso estándar de respuesta a incidentes.
Mejora opcional:
 Los sistemas de detección de intrusos tienen la capacidad de inspeccionar flujos encriptados.
7. Plan de Respuesta a incidentes e intercambio de información
7.1. Planificación de respuesta a incidentes cibernéticos

Objetivo de Control: Garantizar un enfoque coherente y eficaz para la gestión de incidentes cibernéticos.

 N/A  control de la organización
Factores de Riesgo:
 El exceso de daño disposición cibernética deficientes
El usuario tiene un plan de respuesta incidente cibernético definido y probado.
Disponibilidad y capacidad de recuperación adecuada es de importancia clave para el negocio. En este sentido, la definición
y la prueba de un plan de respuesta a incidentes cibernéticos es una forma muy eficaz de reducir el impacto y la duración
de un incidente real cibernético. A medida que se aprendan las lecciones ya sea mediante pruebas de este plan, o por medio
de incidentes reales, es esencial aplicar estos aprendizajes y mejorar el plan. Además, la planificación para el intercambio
de amenazas e incidentes información es fundamental para ayudar a la comunidad financiera más amplia en la aplicación
de una protección eficaz contra los ataques cibernéticos.
 El usuario ha desarrollado y actualiza anualmente un plan de respuesta a incidentes cibernéticos. Existe un plan
de respaldo y recuperación formal para todas las líneas de negocio críticas para apoyar las actividades de respuesta
a incidentes.
o El plan de respuesta a incidentes cibernéticos incluye datos de contacto actualizados (internos y externos)
y temporizadores de escalamiento. Dicho plan tiene que incorporar:
- La hoja de ruta de recuperación de incidentes de seguridad cibernética que proporciona una lista
no exhaustiva de pasos o acciones que un cliente debe seguir en caso de una infracción de
seguridad cibernética y consulte el Soporte de SWIFT. Los detalles se describen en el Boletín
SWIFT-ISAC # 10047.
- Las políticas de seguridad interna, las leyes y las regulaciones dentro de la jurisdicción de un
usuario deben cumplirse y considerarse en la planificación de respuesta a incidentes
cibernéticos.
 Como mínimo, el plan se revisa anualmente y se prueba al menos cada dos años para garantizar la recuperación
segura de las operaciones comerciales críticas con un tiempo de interrupción minimizado después de un incidente
de ciberseguridad.
 El plan de respuesta a incidentes cibernéticos incluye pasos para:
o Notificar oportunamente a las partes interesadas y al liderazgo internos apropiados,
o Notificar de inmediato a las partes interesadas de la organización externa relevantes (por lo general,
regulador (es), supervisor (es), autoridades de aplicación de la ley),
o Notificar de inmediato al Centro de atención al cliente de SWIFT a través del canal predeterminado y
cumplir con otras obligaciones aplicables a los usuarios en caso de un incidente de seguridad, incluida la
obligación de cooperar y proporcionar material forense según lo requiera SWIFT.
o Contener rápidamente el sistema afectado al identificar y limitar la exposición del ataque,
o Involucrar a profesionales expertos en ciberseguridad para identificar y abordar el incidente cibernético.
Es responsabilidad del usuario tomar medidas correctivas rápidas para investigar, limpiar toda la
infraestructura y reanudar las operaciones seguras lo antes posible.
o Revise la exactitud de las autoprotecciones actuales del usuario y, según corresponda en la Política de
controles de seguridad de SWIFT, invalide dichas certificaciones y envíe nuevas certificaciones.
o Realizar análisis de problemas posteriores al incidente para identificar y remediar las vulnerabilidades.
o Documentar completamente el incidente.
 El usuario tiene un plan documentado para el intercambio oportuno de información sobre amenazas a las
organizaciones de intercambio de inteligencia, a los reguladores locales / de la ley (según lo requerido en la
jurisdicción de cada usuario) y a SWIFT. El intercambio de información sobre amenazas puede potencialmente
respaldar el análisis de la causa raíz y el intercambio de Indicadores de Compromisos (COI) anonimizados con la
comunidad.
 La información que se debe compartir se evalúa primero para garantizar el cumplimiento de las leyes y regulaciones
aplicables (por ejemplo, la privacidad de los datos personales, la confidencialidad de las investigaciones) y protege
contra el intercambio no deseado de datos confidenciales o datos más allá de la relevancia del incidente.
 El usuario tiene la capacidad de consumir inteligencia de amenazas compartida por SWIFT, por ejemplo, en forma
de IOC. El usuario tiene procedimientos establecidos para:
o Asegúrese de que la información se distribuye a los contactos correctos dentro de la organización,
o Bloquee el tráfico hacia / desde las direcciones IP / URL mencionadas en los IOC.
7.2. Entrenamiento de Seguridad y concientización

Objetivo de Control: Asegúrese de que todo el personal conozca y cumplan con sus responsabilidades de seguridad
mediante la realización de actividades regulares de formación y sensibilización de seguridad.

 N/A  Todos los empleados, contratistas y personal con
acceso a los sistemas SWIFT (uso, mantenimiento o
administración).
Factores de Riesgo:
 El aumento de riesgo para la seguridad del personal sin la debida capacitación
períodos de sesiones anuales de sensibilización de seguridad se llevan a cabo para todos los miembros del personal,
incluyendo la formación específica de funciones para las funciones de SWIFT con acceso privilegiado.
Un programa de formación y concienciación sobre la seguridad fomenta un comportamiento consciente de la seguridad y
adecuada de los empleados y administradores, y refuerza en general buena práctica de seguridad. Además, es
particularmente importante que los usuarios de acceso privilegiado tienen el conocimiento y la experiencia adecuada.
 El personal completa conciencia anual de seguridad y capacitación. Los temas pueden incluir:
o Capacitación en productos y servicios relacionados con SWIFT (por ejemplo, a través de SWIFTSmart
que está disponible para todos los usuarios),
o Concientización sobre las amenazas de seguridad cibernética dentro de la industria de servicios
financieros o relevante para el rol y las responsabilidades del personal,
o Seguridad y gestión de contraseñas.
o seguridad del dispositivo,
o hábitos de operación seguros (por ejemplo, identificación de spam y phishing, descarga de archivos,
prácticas de navegación),
o Notificación de eventos y actividades sospechosas,
o Detección y respuesta a incidentes cibernéticos en línea con el plan de respuesta de la organización.
o Programa interno o externo que opcionalmente permite al personal obtener y mantener certificaciones.
 La capacitación se imparte a través del canal más apropiado, incluida la capacitación basada en computadora, la
capacitación en el aula y los seminarios web.
 Las personas que tienen acceso a las aplicaciones, datos, certificados, redes, etc. de SWIFT tienen un nivel de
conocimiento adecuado y conocen los riesgos cibernéticos pertinentes (por ejemplo, a través de los COI publicados
por SWIFT), las mejores prácticas y los procesos.
7.3. Pruebas de penetración

Objetivo de Control: Validar la configuración de seguridad operacional y determinar las deficiencias de seguridad mediante
la realización de pruebas de penetración.

 N/A  PC del operador (o servidor salto): todo el hardware,
software y red
 capa de intercambio de datos
 zona segura: todo el hardware, software y
componentes de red (exclusivo de aplicaciones y

servicios SWIFT-central, tales como SWIFTNet
InterAct, FileAct FIN específico de SWIFT, SWIFTNet
instantánea o WebAccess)
Factores de Riesgo:
 Desconocido vulnerabilidades de seguridad o configuraciones incorrectas de seguridad
Aplicación, host, y penetración de la red de prueba se lleva a cabo en y dentro de la zona de seguridad y en los PC del
operador.
Las pruebas de penetración se basan en ataques simulados que usan tecnologías similares a los desplegados en los
ataques reales. Se utiliza para determinar las vías de que los atacantes podrían usar, y la profundidad a la que los atacantes
puede ser capaz de acceder al entorno de destino. La realización de estas simulaciones es una herramienta eficaz para
identificar las debilidades en el ambiente que pueden requerir la corrección, mejora, o controles adicionales.
 La organización utiliza un enfoque basado en el riesgo para determinar el alcance preferido (por ejemplo, la zona
de seguridad, o un servidor específico incluyendo posibles otros servicios de apoyo a la zona segura), método (por
ejemplo, prueba de caja blanca, prueba de la caja negro) y ataque origen (por ejemplo, interno, desde dentro o
fuera de la zona segura, o ataque externo) para la prueba.
 Las pruebas de penetración se llevan a cabo por lo menos cada 2 años, así como después de cambios significativos
en el entorno (por ejemplo, los nuevos dispositivos de servidor o de la red, la red de cambio de diseño).
 Las pruebas de penetración son cuidadosamente planeada y llevada a evitar posibles impactos sobre la
disponibilidad o integridad.
 Las pruebas de penetración se llevan a cabo por el personal experto independiente por parte del equipo a cargo
de la infraestructura de SWIFT (Equipo Rojo interna o recursos externos).
 componente de red y pruebas de penetración host (por ejemplo, la regla bases y configuraciones revisión) se
realizan en el entorno de producción de servicio.
 garantías suficientes están en su lugar para minimizar cualquier impacto operativo de la realización de la prueba
de penetración.
 El resultado de la prueba de penetración se documenta (con acceso restringido) y se utiliza como una entrada para
el proceso de actualización de seguridad.
Nota: se espera que este control se convierte en obligatoria en una próxima versión de este documento.
Mejora opcional:
 Las pruebas de penetración se realizan en aplicaciones SWIFT-específicos mientras que se adhiere a la Política
de Pruebas SWIFT Cliente. Esta prueba de penetración aplicación SWIFT específica se realiza en el entorno de
prueba para evitar posibles impactos sobre la disponibilidad o integridad.
7.4. Escenarios de Evaluación de Riesgo

Objetivo de Control: Evaluar el riesgo y la disposición de la organización basada en escenarios de ataque cibernético
plausibles.

 N/A  control de la organización (personas, procesos e
infraestructura)
Factores de Riesgo:
 El exceso de daño disposición cibernética deficientes
 sensibilidad a la exposición no identificada cibernética
las evaluaciones de riesgos de escenarios impulsada Se llevan a cabo para mejorar la preparación de respuesta a incidentes
y aumentar la madurez del programa de seguridad de la organización.
evaluaciones de riesgo basadas en escenarios probar varios ataques realizados por todo tipo de personas no autorizadas
en la infraestructura relacionada con SWIFT-organizada.
Considere las siguientes amenazas no exhaustivos: suplantación del usuario final, la manipulación de mensajes, mensaje
de espionaje, las debilidades de software de terceros, sistemas comprometedoras o ataques de denegación de servicio
(DoS) que afectan a la disponibilidad del servicio. Los resultados de la evaluación y mitigación existentes ayudan a identificar
las áreas de riesgo que pueden requerir acciones futuras, mitigaciones de riesgo o la actualización del plan de respuesta a
incidentes cibernéticos. acciones identificadas, mitigaciones, o actualizaciones han de ser comunicados y seguida por cierre
de acuerdo a su criticidad de acuerdo con el proceso de Seguridad de la Información de Gestión de Riesgos (ISRM).
Existen varios marcos ISRM y se pueden consultar (por ejemplo, en NIST, ENISA, COBRA o ISO sitios o de un local o
controles estándar o de regulador de conjunto del mismo rigor como la orientación de la industria) para definir ISRM
adecuada del usuario y los recursos (tales como Controles CIS-crítico de seguridad). Estos marcos se pueden utilizar para
empezar a aplicar un proceso básico de gestión de riesgos para ser mejorado aún más para hacer frente a los riesgos
específicos de los usuarios.
 Una actividad de evaluación y planificación de los riesgos escenario se llevó a cabo para:
o Identificar posibles métodos para adversarios para obtener acceso no autorizado a la infraestructura local
de SWIFT Basándose en técnicas adversario observados o técnicas adversario-plausibles inferidas de
motivaciones y capacidades de adversarios,
o Analizar la eficacia de los controles de prevención y detección existentes para mitigar anticipada
o técnicas adversario para obtener acceso no autorizado al medio ambiente,
o Analizar la probabilidad y el impacto de vectores significativo y plausible de ataque dado controles
existentes,
o Analizar la eficacia de los controles de respuesta existentes para limitar el impacto de la significativa y
plausible
o vectores de ataque dados los controles existentes,
o Identificar la necesidad de controles preventivos o de detectives adicionales.
 actividad de evaluación y planificación se lleva a cabo por lo menos anualmente, y actualizar a través de las
actividades en curso de gestión de riesgos, cuando se producen cambios significativos en la tecnología, o cuando
la información sobre amenazas indica los cambios pertinentes en las capacidades o las motivaciones de un
adversario aplicable.
 inteligencia de amenazas actuales y ataques observados / probable (vectores, técnicas, actores, etc.) se utilizan
como base para los escenarios viables.
 Cada clase de activo (dispositivos de usuario final, servidores, dispositivos de red) se evalúa contra las amenazas
de forma regular base y cuando se introducen cambios o cuando se identifican nuevas amenazas.
Glosario
Término Definición
4-eyes principio Un principio de seguridad por el que dos individuos deben aprobar una acción antes de que se pueden
tomar. Este principio también se conoce como la regla de dos personas o la integridad de dos
personas.
Administrador Puede referirse a:
Administradores de la aplicación - responsables de la configuración, mantenimiento, y la
realización de actividades privilegiadas a través de una interfaz de aplicación
Los administradores del sistema - responsables de la configuración, el mantenimiento y la
realización de otras actividades privilegiadas a través de sistemas operativos u otro acceso
directo (no front-end)
cuenta de la aplicación cuentas de aplicación se definen como log-ons designados para una aplicación. Ellos no están
destinados a ser utilizados por un acceso humano o GUI. cuentas de aplicaciones tienen u na
contraseña que se almacena, recupera y se utiliza de forma automática por la aplicación. Una
cuenta de aplicación se utiliza típicamente para los propósitos de integración (por ejemplo, llamar
de API) o para apoyar a STPlink (Straight-Through-Processing: Procesamiento Directo -
componente permite evitar el uso de archivos planos cuando envíe mensajes).
Clase de activos Una categoría de calcular activo (por ejemplo, bases de datos, servidores, aplicaciones).
back office Los sistemas responsables de la lógica de negocio, generación de transacción, y otras actividades
que tienen lugar antes de la transmisión en la infraestructura de SWIFT local.
conector Los conectores son local de software diseñado para facilitar la comunicación con una interfaz de
mensajería o comunicación, o ambas cosas. Cuando se utiliza un conector, componentes de interfaz
son ofrecidos por un proveedor de servicios (por ejemplo, una oficina de servicios, la infraestructura
concentrador o SWIFT). Alianza Lite2 AutoClient, Enlace Directo, soluciones de transferencia de
archivos y productos equivalentes se consideran soluciones de conectores.
CVSS - Scoring System CVSS es un estándar abierto de la industria para evaluar la gravedad de las vulnerabilidades del
Common Vulnerability software mediante la asignación de las puntuaciones de gravedad de estas vulnerabilidades, lo
que permite la priorización de respuestas y recursos en línea con la amenaza.
Interfaz de comunicación software de interfaz de comunicación que proporciona un enlace entre la red SWIFTNet y el
software de interfaz de mensajería. Interfaz de comunicación proporcionan una integración
centralizada, automatizada y de alto rendimiento con diferentes aplicaciones financieras internas
e Interfaz específicas del servicio. Interfaz de comunicación son proporcionados por SWIFT (por
ejemplo, Alliance Gateway o Alliance Gateway instantánea) y por los vendedores de certificados
de terceros.
incidente de seguridad Cualquier acto malicioso o evento sospechoso que compromete, o era un intento de comprometer, un
cibernética entorno informático.
capa de intercambio de El transporte de datos entre el back office (o capa de middleware) y la infraestructura de SWIFT local.
datos
PC operador dedicado Un operador de PC situado en la zona segura y dedicada a interactuar con los componentes de
la zona segura.
Usuario final Las personas que requieren un acceso interactivo a la aplicación (por ejemplo, para las
transacciones comerciales, monitoreo y control de acceso). Esto incluye agentes de seguridad y
administradores de aplicaciones responsables de la configuración y el mantenimiento de la
aplicación.
En general entorno de TI La infraestructura de TI en general utilizado para apoyar la organización amplia. Esto incluye servicios
(empresa) de TI generales y PC generales operador propósito.
servicios de TI generales Apoyar la infraestructura de TI, tales como servicios de autenticación, gestión de activos, bases
de datos, almacenamiento de datos, servicios de seguridad (por ejemplo, parches) y los servicios
de red (por ejemplo, DNS, NTP).
PC del operador de Un PC operador situado en el entorno general de la empresa y se utiliza para las actividades
propósito general diarias del negocio.
Interfaz gráfica de Software que produce la interfaz gráfica para el usuario

usuario (GUI) (Es decir, Alliance Web Platform y productos equivalentes).
token de hardware Un token USB, una tarjeta inteligente o un dispositivo similar.
Interactiva log-in / sesión El modelo de sesión que indica un intercambio de datos (por ejemplo, cuando un usuario introduce
datos o un comando y el sistema devuelve datos).
Indicadores de Los artefactos que se pueden observar en una red o sistema operativo que podría indicar compromiso
compromiso (COI) del sistema.
servicios de TI Un conjunto de componentes en apoyo de los procesos de negocio dentro de la zona de seguridad,
tales como una liberación y parches plataforma de despliegue, Active Directory.
servidor de intercambio Un servidor utiliza para proporcionar acceso a la zona segura de usuario de la red corporativa del
de información usuario (por ejemplo, Citrix o de escritorio remoto).
Autenticación local Autenticación local, abreviado como LAU, proporciona integridad y autenticación de los archivos
(LAU) intercambiados entre aplicaciones. Autenticación local requiere que la entidad de envío y recepción
utilizan la misma clave para calcular una firma de archivo de autenticación local.
infraestructura de SWIFT El conjunto de componentes de SWIFT-específicos dentro de entorno de producción del usuario,
local incluyendo los sistemas, aplicaciones, hardware de soporte, Token, y otros autentificadores.
interfaz de mensajería software de interfaz de mensajería que apoya el uso de los servicios de mensajería de SWIFT
(FIN, InterAct y FileAct). El software proporciona los medios para que los usuarios se conecten a
las aplicaciones de negocio servicios de mensajería de SWIFT y por lo general se conecta
directamente a la interfaz de comunicación. Interfaz de mensajería son proporcionados por
SWIFT (por ejemplo, Alliance Access o Alliance mensajería Hub) y por los proveedores de
certificados de terceros.
middleware Software que permite a dos programas separados para interactuar entre sí (por ejemplo, IBM MQ,
BizTalk).
autenticación de múltiples Autenticación de múltiples factores es un método de autenticación de usuario donde se requieren al
factores menos dos componentes diferentes para autenticar un usuario. Siguientes factores de autenticación
se pueden seleccionar:
factor de conocimiento (algo que el usuario sabe), por ejemplo, un PIN o una contraseña
factor de posesión (algo que el usuario tiene), por ejemplo, un token de HSM, una Digipass, teléfono
móvil o un dispositivo de contraseña RSA Una Hora
factor humano (algo que el usuario es), por ejemplo, la huella digital o cualquier otra biométrica
Red de lista de control de Una lista de control de acceso a la red se refiere a las reglas que se aplican a los números de puertos
acceso (ACL) o direcciones IP para controlar el tráfico de entrada y salida. Estas listas están disponibles en un
dispositivo de red.
Dispositivos de red Componentes utilizados para ayudar en la gestión, encaminamiento, y la seguridad de la red (por
ejemplo, enrutadores, conmutadores, Firewall).
Sistema Operativo (OS) Las cuentas de usuario en un servidor o PC que se utiliza para el acceso directo al sistema
cuentas operativo.
Operador En conjunto se refiere a ambos tipos individuales a continuación: los usuarios finales - los individuos
que requieren un acceso interactivo a la aplicación (por ejemplo, para las transacciones comerciales,
monitoreo y control de acceso). Esto incluye agentes de seguridad y administradores de aplicaciones
responsables de la configuración y el mantenimiento de la aplicación. Los administradores del sistema
operativo - responsable de la configuración, el mantenimiento y la realización de otras actividades
privilegiadas en los sistemas operativos de alojamiento de la infraestructura SWIFT local.
PC del operador El PC utilizado por los operadores para llevar a cabo sus funciones.
ALFILER Número de Identificación Personal - Un número secreto que actúa como una contraseña de
impedir que otros obtengan acceso no autorizado o el uso de una ficha, dispositivo móvil o la
tarjeta.
cuenta privilegiada Una cuenta en un sistema operativo o una aplicación que concede acceso elevado más allá de
la de un usuario típico. Incluye cuentas de administrador de sistemas operativos, y el oficial de
seguridad o el propietario de la aplicación de cuentas en las aplicaciones.
La aplicación de gestión Un filtro que permite al usuario limitar los corresponsales de la que los mensajes pueden ser recibidos,
de relaciones (RMA) así como el tipo de mensajes que puede ser recibida. El uso del mecanismo de aplicación de gestión
de relaciones es obligatorio para el servicio FIN. Está disponible en una base opcional para SCORE
FileAct FileAct y genérico.
Acceso remoto El acceso a un ordenador desde fuera de la red local. Por ejemplo, desde casa o desde la red de
otra organización.
inicio de sesión remoto Inicie una sesión en un sistema iniciado través de una conexión de red en lugar de hacerlo
directamente desde el PC local.
zona segura Una zona segmentada en los locales de usuario separados de la empresa general. La zona segura
contenga sistemas relacionados con SWIFT (por ejemplo, interfaz de mensajes, interfaz de
comunicación), y opcionalmente otros sistemas protegidos.
entorno de servidor centro de datos o en otro lugar de alojamiento de servidores físicos garantizados.
oficina de servicios UNA oficina de servicios es un usuario SWIFT o no usuario
organización que proporciona servicios para conectar usuarios de SWIFT. Los servicios ofrecidos por
una oficina de servicios suelen incluir compartir, hosting, o hace funcionar los componentes de
conectividad de SWIFT, iniciar la sesión, o la gestión d sesiones o en nombre de la seguridad usuarios
de SWIFT. oficinas de servicios están sujetos al Programa de infraestructura compartida.
Proveedor de servicio Una organización que proporciona servicios a los usuarios de SWIFT con respecto a la operación del
día a día de su conexión SWIFT. Los servicios ofrecidos incluyen típicamente compartir, o hacer
funcionar los componentes de conectividad de SWIFT, iniciar la sesión, o la gestión de sesiones o la
seguridad para los usuarios de SWIFT. Esas organizaciones incluyen los proveedores de
infraestructura compartida (por ejemplo, oficina de servicios, proveedores de conectividad
compartidos, Lite2 para aplicaciones de negocios, Alianza Lite2, Alliance Gateway remoto,
concentrador de grupo).
un solo usuario o modo modo de operación que limita los privilegios del usuario protegida.
seguro
identificador de software token de autenticación en forma lógica (software).
cliente pesado Un programa de software instalado y ejecutado en el PC del operador local, en lugar de a través de
una interfaz de navegador.
Tercero Una entidad independiente del usuario o proveedor de conectividad de SWIFT SWIFT del usuario. Por
ejemplo, un proveedor de TI externalizados.
Número de autenticación Un tipo de De un solo uso de contraseña generalmente utilizado en conjunción con un ID estándar y
de transacción (TAN) contraseña. Inicialmente se presenta en una lista (tabla).
Transport Layer Security Un protocolo criptográfico que asegura la confidencialidad y la integridad de la red y protege contra
(TLS) los ataques de repetición.
Usuario Una organización que SWIFT ha admitido bajo las Normas corporativas como un usuario autorizado
de servicios y productos de SWIFT. Los criterios de elegibilidad para convertirse en un usuario de
SWIFT se establecen en las normas corporativas.
cuentas de usuario de Las cuentas de usuario establecidos en la capa de aplicaciones para conceder acceso y permisos a
aplicaciones la aplicación (es decir, que no operan cuentas del sistema).

SWIFT Customer Security Controls Framework v2019 - Traducción

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SWIFT Customer Security Controls Framework v2019 - Traducción

Hochgeladen von

Copyright:

Verfügbare Formate

Descripción detallada Avisos legales

Marco de controles de seguridad del cliente V2019

CONTROL DE CAMBIOS ............................................................................................................................................ 3

Arquitectura A1 – Los usuarios con interfaz de comunicación ............................................................................. 6

Arquitectura A2 – Stack parcial sin interfaz de comunicación ............................................................................... 6

Arquitectura A3 – Conector ....................................................................................................................................... 7

Arquitectura B - No huella de usuario local ............................................................................................................. 7

1.1. Protección del ambiente de SWIFT ......................................................................................................... 10

1.2. Control de cuenta privilegiada del sistema operativo ........................................................................... 13

1.3. Protección de plataforma de virtualización ............................................................................................ 14

2.1. Seguridad interna del flujo de datos ....................................................................................................... 14

2.2. Actualizaciones de seguridad ................................................................................................................. 15

2.3. Fortalecimiento del Sistema ................................................................................................................... 16

2.4. Seguridad de flujo de datos de backoffice ............................................................................................. 17

2.5. Protección de datos de transmisión externa ......................................................................................... 17

2.6. Confidencialidad e integridad de la sesión del operador...................................................................... 18

2.7. Escaneo de Vulnerabilidades .................................................................................................................. 19

2.8. Outsorcing de Actividad crítica ............................................................................................................... 19

2.9. Controles comerciales de transacciones ............................................................................................... 20

2.10. Hardening de Applicación........................................................................................................................ 21

3.1. Seguridad Física ....................................................................................................................................... 22

4.1. Política de Contraseñas ........................................................................................................................... 23

4.2. Multifactor de Autenticación.................................................................................................................... 24

5.1. Control de Acceso Lógico ....................................................................................................................... 25

5.2. Administración de Token ......................................................................................................................... 26

5.3. Proceso de selección de personal .......................................................................................................... 27

5.4. Almacenamiento físico y lógico de la contraseña ................................................................................. 27

6.1. Protección contra malware ...................................................................................................................... 28

6.2. Integridad del software............................................................................................................................. 29

6.3. Integridad de la Base de Datos ................................................................................................................ 29

6.4. Registro y Monitoreo ................................................................................................................................ 30

6.5. Detección de Intrusos .............................................................................................................................. 31

7.1. Planificación de respuesta a incidentes cibernéticos ........................................................................... 32

7.2. Entrenamiento de Seguridad y concientización .................................................................................... 33

7.3. Pruebas de penetración ........................................................................................................................... 33

7.4. Escenarios de Evaluación de Riesgo ..................................................................................................... 34

Figura 1: Objetivos marco y los principios

En última instancia, estas consecuencias representan riesgos a nivel de la empresa, incluyendo:

INTEGRACIÓN CON EL GOBIERNO DE SEGURIDAD Y GESTIÓN DE RIESGOS

Figura 2: Ámbito de controles de seguridad

Los controles de seguridad se aplican a los siguientes componentes en el estudio:

infraestructura de SWIFT local.

Los siguientes componentes están fuera de alcance:

referencia son los siguientes:

Arquitectura A1 – Los usuarios con interfaz de comunicación

Figura 3: Arquitectura A1 – Stack completa dentro de la ubicación del usuario

Figura 3b: Arquitectura A1 - Interfaz de comunicación dentro de la ubicación del usuario

Figura 4: Arquitectura A2 - Stack parcial dentro de la ubicación del usuario

Figura 5: Arquitectura A3 - Conector

Arquitectura B - No huella de usuario local

Figura 6: Arquitectura B - No huella de usuario

Estructura Controles de seguridad

Seguridad controles de cumplimiento

Controles de seguridad Cuadro resumen

DESCRIPCIONES DETALLADAS DE CONTROL

Tipo de Arquitectura Credicorp Capital Colombia

1.1. Protección del ambiente de SWIFT

Componentes dentro del alcance:

Alliance Enterprice Credicorp

b) Alcance de la zona segura

c) Protección de la zona segura

c.2 Comunicación entre componentes en la zona segura.

d) El acceso a los sistemas de zonas seguras

e) La limitación del acceso a Internet