Lineamientos de uso de Mirror Strategy

Características del consumidor

Al ser una solución de backend, gran parte de la seguridad de los servicios reposa sobre la seguridad del consumidor por quien interactúa con los distintos usuarios de la solución. Debido a lo anterior, para satisfacer los requerimientos de seguridad de FEMSA, el consumidor de los servicios de Mirror Strategy debe cumplir con las siguientes características:

Autenticación y autorización

Los datos de acceso a los sistemas de información deberán estar compuestos por un ID o nombre de usuario y contraseña que debe ser única para cada usuario o tercero, exceptuando la primera autenticación.
Se debe solictar al menos un identificador de usuario y un factor de autenticación de categoría 2 (mediante información que sólo el usuario conoce), 3 (contraseñas dinámicas de un solo uso) o 4 (mediante datos biométricos). La longitud del identificador de usuario deberá ser de al menos seis caracteres. El identificador de usuario deberá ser único para cada usuario y permitirá identificar todas las operaciones realizadas por el propio usuario.
Se deberá utilizar un factor de identificación de categoría 3 (contraseñas dinámicas de un solo uso para ejecución de operaciones sensibles como el establecimiento de límites de monto, alta o cambio de cuentas destino, alta o cambio de datos de notificación, transferencias monetarias, pagos de servicios, pagos de impuestos o creación de tarjetas digitales. Estas contraseñas dinámicas deben tener un tiempo de validez no mayor a dos minutos, solo puede ser utilizada una vez, debe tener una longitud de ocho posiciones y no debe ser replicable ni conocida previamente a su publicación.
Durante el inicio de sesión se debe impedir la lectura de la información de identificación y autenticación del usuario en la pantalla del dispositivo de acceso sustituyendo con asteriscos la información.
Deberá contar con un procedimiento para invalidar los factores de autenticación cuando un usuario o el negocio cancele el servicio de banca electrónica o cuando dicho usuario deje de ser cliente del negocio.
Una vez iniciada la sesión por parte del cliente, debe mostrar la fecha y hora del último inicio de sesión y el nombre y apellido del usuario.
Deberá establecer procesos y mecanismos automáticos para bloquear el uso de contraseñas y otros factores de autenticación cuando se intente ingresar a la aplicación utilizando información de autenticación incorrecta en hasta tres ocasiones consecutivas.
Deberá proporcionar al cliente una opción para desactivar el servicio Pago Móvil o Banca Móvil de manera temporal en caso de requerirlo así como establecer procedimientos para reactivar el uso cuando el usuario lo disponga.
Se deberá bloquear la clave del usuario si se han realizado 3 intentos fallidos (contraseñas inválidas).
Se debe bloquear la clave de usuario si se ingresa de forma incorrecta cinco veces consecutivas, la cuenta debe ser bloqueada automáticamente por un periodo mínimo de 15 minutos la primera vez, y 360 minutos en caso de reincidencia dentro de las siguientes 24 horas o hasta que un administrador la desbloquee.(AA6)
Se debe bloquear el usuario de proceso si se realizan cinco intentos fallidos de autenticación.
No se permite cambiar la contraseña más de dos veces en un mismo día.
Deberá evitar el acceso concurrente con un mismo identificador de usuario.
Deberá contar con procesos de borrado de cuentas dentro de los sistemas.
Deberá contar con un proceso para la administración de cuentas de administradores.
Deberán existir controles técnicos para el acceso de usuarios privilegiados (Por ejemplo: doble factor de autenticación, filtros de IP, firewalls, comunicaciones encapsuladas, etc).
Se deben indicar las características que debe cumplir la contraseña.
Utilizar la autenticación condicional basados en geolocalización, dispositivo y transacción en los sistemas que lo permitan.
Se deberá contar con un módulo de autogestión para el usuario, que le permite el desbloqueo y restablecimiento de contraseñas.
La contraseña debe contener al menos tres de los siguientes cuatro tipos de caracteres: o Letra mayúscula. o Letra minúscula. o Número. o Carácter especial y/o de puntuación.
El historial de contraseña debe incluir las 15 últimas.
Deberá permitir a los clientes cambiar sus contraseñas o NIPs, solicitando al usuario la contraseña actual. Deberá permitir al usuario obtener una nueva contraseña en caso de haberla olvidado.
Debe validar que las contraseñas tengan al menos 8 caracteres de longitud.
La longitud mínima de la contraseña para cuentas de clientes debe ser de 6 caracteres
La longitud mínima de la contraseña para cuentas de usuarios debe ser de 10 caracteres
La longitud mínima de la contraseña para cuentas de administradores debe ser de 15 caracteres
La longitud mínima de la contraseña para cuentas de servicio debe ser de 25 caracteres
Se requerirá un doble factor de autenticación mediante contraseñas dinámicas de un solo uso (OTP) o envio de correo electronico y con una vigencia no mayor a 2 minutos durante el primer loggeo del usuario en la aplicación.
Se requerirá un doble factor de autenticación mediante contraseñas dinámicas de un solo uso (OTP) o envio de correo electronico y con una vigencia no mayor a 2 minutos en los cambios respecto de los factores de autenticación.
Se requerirá un doble factor de autenticación mediante contraseñas dinámicas de un solo uso (OTP) o envio de correo electronico y con una vigencia no mayor a 2 minutos en la alta y/o modificación del los medios de notificaciones al cliente
Se requerirá un doble factor de autenticación mediante contraseñas dinámicas de un solo uso (OTP) o envio de correo electronico y con una vigencia no mayor a 2 minutos al momento de generar una operación crítica definida por el negocio (realizar un pago, hacer una solicitud de préstamo, alta/baja/cambio de beneficiarios, etc.)
Despues de 5 intentos fallidos de intento de sesión, se debe bloquear la cuenta de usuario por un segundo. La duración del bloqueo luego se duplica después de cada intento fallido adicional, hasta un máximo de 15 minutos.
Deberá prever mecanismos y procedimientos por medio de los cuales el usuario deba cambiar la contraseña inmediatamente después de que la aplicación la haya definido o generado.
Para el manejo de contraseñas, deberá mantener procedimientos que proporcionen seguridad en la información contenida en los dispositivos de autenticación en su custodia, la distribución, así como en la asignación y reposición de dichas contraseñas y factores de autenticación; no permitirá contar con mecanismos, algoritmos o procedimientos que les permitan conocer, recuperar o descifrar los valores de cualquier información relativa a la autenticación de sus usuarios.
No está permitido el uso de patrones (repetición de caracteres, números o letras consecutivos, etc.) como autenticación de clientes.
Deberá cifrar o truncar la información de las cuentas u operaciones de sus usuarios y cifrar las contraseñas, números de identificación personal (NIP), respuestas secretas, o cualquier otro factor de autenticación, en caso de que se almacenen.
Está prohibido el uso de usuarios genéricos.
La contraseña de cuentas de servicio o plataformas que no soportan doble factor de autenticación deben tener Expiración para usuario administrador de sistema 180 días.
La contraseña de cuentas de servicio o plataformas que no soportan doble factor de autenticación deben tener h) Las cuentas de servicios no deben permitir inicio de sesión de ningún tipo (consola, escritorio remoto y/o red).
La contraseña de cuentas de servicio o plataformas que no soportan doble factor de autenticación deben tener c) Expiración para cuentas de servicio sin bóveda de contraseñas 90 días, con bóveda de contraseñas no aplica.
Debe verificar que exista el principio de privilegio mínimo: los usuarios solo deben poder acceder a funciones, archivos de datos, URL, controladores, servicios y otros recursos para los que poseen una autorización específica.
Deberá estar autenticada por medio del AD de Digital@Femsa.
Deberá autenticar la comunicación entre componentes.
La función "Recordar contraseña" para las aplicaciones no se utilizará ni se habilitará. Si es posible, se aplicará a través de la configuración del sistema.
Las contraseñas no estén basadas en algún dato que otra persona pueda adivinar u obtener fácilmente mediante información relacionada con la persona, por ejemplo, nombres, números de teléfono, fecha de nacimiento, etc

Manejo de la sesión

Se deberá generar un nuevo Token por cada sesión.
Deberá verificar que la aplicación no permita revelar tokens de sesión en parámetros de URL o mensajes de error.
Se deberá validar que el cierre de sesión y la expiración invaliden el Token de la sesión, de modo que el botón de retroceso no reanude una sesión autenticada.
Se requiere prevenir que la sesión pueda ser usada por un tercero, dando por terminada la sesión en caso de inactividad por más de 15 minutos, un minuto en caso de transacciones monetarias, o al identificar cambios relevantes en los parámetros de comunicación.
Se requiere prevenir que la sesión pueda ser usada por un tercero, dando por terminada la sesión en caso de inactividad por más de 15 minutos.
Se deberá comunicar al usuario que al momento de re-dirigir a servicios de terceros, se cerrará automáticamente la sesión abierta y que ingresará a otra cuya seguridad no depende ni es responsabilidad de Digital@Femsa.
Se requiere que los tokens de sesión basados en cookies tengan establecido el atributo 'Secure' , 'HttpOnly', 'SameSite' y ´__Host-'.
Se deberá impedir el acceso en forma simultánea, mediante la utilización de un mismo Identificador de usuario.
Se deben utilizar identificadores de sesión impredecibles.
Se debe asegurar que el manejo de la sesión fuerce el paso de credenciales en cada llamada.

Gestión de Accesos e Identidades

Deberá existir una adecuada segregación de funciones entre el rol de gestión de usuarios privilegiados y el resto de roles.
Si requiere usuarios de servicio, debe contar con la aprobación del CTSO (CyberArk - (posiblemente)).
Las ID de usuario de servicios deberán estar plenamente identificadas y solo pueden usarse si son necesarias. Estas deberán tener asignados siempre un custodio el cual será responsable de su uso.
El acceso de los administradores al ambiente productivo sólo es permitido mediante el uso de bóveda de contraseñas.

Validación, limpieza y codificación

Deben contar con controles que previenen ataques de fuerza bruta o de bloqueo de cuentas como CAPTCHA o limitación de velocidad.
Debe de contar con store procedures u otros mecanismos protegidos contra inyecciones de código para las consultas a bases de datos.
Debe de contar con mecanimos para prevenir inyecciones de código malicioso en plataformas, servidores web, servidores de aplicaciones y bases de datos.

Protección de datos

Implementar mecanismos de enmascaramiento o anonimización si es necesario usar datos reales (interno, restringidos o confidenciales) en un ambiente no productivo.
Evitar el almacenamiento en cachés de aplicaciones o balanceadores de carga, datos confidenciales y restringidos.
Configurar una política de "limpieza" cuando se almacenan datos temporales en caché por un periodo para evitar su exposición.

Comunicaciones

La gestión de las claves para datos en tránsito, deberán ser gestionadas por Digital@Femsa.
Todos los sitios web deberán tener configurados los siguientes headers: X-Content-Type-Options, Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy.
Los parámetros de la cadena de consulta (URL) de cualquier HTTP verb no deben contener datos confidenciales.
La información transmitida mediante notificaciones y/o correos electrónicos no debe contener vínculos activos.
Los componentes que se comunican a través de Internet deben validar la autenticidad del certificado (Certificate/Public Key Pinning) o usar un mecanismo de autenticación mutua.
Los componentes de la aplicación deben validar las cadenas y los certificados TLS o utilizar mecanismos de autenticación mutua.
Se deben utilizar certificados SSL válidos y validar la cadena para reconocer de forma unívoca al servidor.
No deben utilizarse certificados “*” (wildcard) ni autofirmados.
Los certificados, tanto internos como externos, deben ser emitidos por una autoridad de certificación reconocida por Digital@Femsa y la revocación tendrá que estar activada para un periodo máximo de dos años.
El acceso remoto seguro debe controlarse estrictamente a través de la autenticación y las claves públicas / privadas con frases de contraseña fuertes o autenticación de dos factores.

Código malicioso

Se deben ocultar todas las rutas referentes a acceso a consolas, portales de administrador, recursos de archivos, así como los reedireccionamientos a los mismos.
Se deberá usar software que sea estrictamente requerido. Durante el desarrollo de herramientas o software, se deberán desactivar los componentes y bibliotecas que no se requieran.
Se deberán realizar verificaciones y evaluaciones de software de terceros, incluyendo frameworks de desarrollo o bibliotecas de software populares.
Se deben ejecutar los intérpretes con el nivel de privilegios mínimo

Vulnerabilidades encontradas

Vulnerabilidad por CSRF(Cross-site request forgery)

Identificada al implementar la configuración y uso de Apykey como medio de autenticación entre servicios en el servicio Aggregation Service:

Esta vulnerabilidad fue revisada con el equipo de desarrollo de Spin ya que al implementar el ApiKey en todos sus servicios presentan el mismo problema. Se llego a la conclusión que se podía mantener como un falso positivo ya que los servicios están en una subnet privada y son accedidos por medio de un balanceador privado, por lo que solo pueden ser consumidos por los servicios de Spin.

Vulnerabilidades por licencias

Estas vulnerabilidades son identificadas en los diferentes jar de librerías de terceros como las de Spring, Tomcat, Lockbag, etc:

Estas son librerías ampliamente usadas y de momento se acordo verlos como falsos positivos, pero se quedó que en cuanto se actualizara la base de datos de Snyk y si siguen saliendo se evaluara la exclusion o remediación de estos.

Third Party Partners

Consideraciones de seguridad-Mirror strategy