Autenticación multi-factor (MFA): la nueva apuesta de seguridad de PCI DSS v3.2

Uno de los cambios más significativos en la versión 3.2 del estándar PCI DSS (publicada a finales de abril de 2016) [1] consistió en la expansión del requerimiento 8.3 para incluir el uso de autenticación multi-factor para cualquier conexión que no sea de consola. El concepto de “autenticación multi-factor” entró a remplazar al concepto de “autenticación de dos factores” empleado en versiones anteriores del estándar. Sin embargo, aún hay muchas preguntas relacionadas con este tema y el concepto no ha quedado del todo claro a pesar de los grandes beneficios que trae a la organización, teniendo en cuenta que su implementación satisfactoria hubiera podido minimizar el impacto en el robo de tarjetas en casos tan sonados como el de Target en Estados Unidos [2].

En este artículo se revisarán en detalle las diferencias entre estos dos conceptos y su aplicabilidad en los modelos de autenticación requeridos en PCI DSS.

¿Cuál es la diferencia entre autenticación multi-factor (MFA) y autenticación de dos factores (2FA)?
Para poder validar la identidad de un usuario o aplicación se hace uso de los siguientes factores de autenticació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)
  • SYA (Something You Are): Algo que el usuario es o hace (como una huella digital)
Si únicamente se emplea uno de estos factores, un potencial atacante que tenga acceso a esa información podría acceder a un sistema haciéndose pasar por un usuario legítimo. Por ello, para reforzar la seguridad en el proceso de autenticación y – de paso – implementar el concepto de “no repudio” (en el cual el usuario autenticado no puede negar que no ha sido el quien ha ejecutado esa acción) se hace uso de la combinación de dos o más de estos factores.

El término autenticación multi-factor (MFA) entró a remplazar todas las apariciones del concepto de autenticación de dos factores (2FA) en los requerimientos 8.3, 8.3.1, 8.3.2 y 8.5.1. A pesar del cambio de nombre, el concepto sigue siendo el mismo: El uso de dos (o más) factores en el proceso de autenticación.

El argumento principal del cambio de nombre del concepto se encuentra en la ampliación del mismo para no limitarlo únicamente a “dos factores” sino a “dos o más factores”, considerando que actualmente el uso de dos factores en exclusiva puede contener debilidades de seguridad si no se implementa correctamente [3].

¿Se puede hacer uso de dos o más contraseñas diferentes para realizar una autenticación de dos factores o multi-factor?
No, básicamente porque bajo ese concepto se está empleando dos veces un único factor (algo que sabes – SYK), que entra en conflicto con la definición de 2FA/MFA que requiere - como mínimo - una combinación de 2 de los 3 factores de autenticación disponibles.

¿Es la autenticación de dos pasos (2SA) lo mismo que autenticación multi-factor (MFA) o autenticación de dos factores (2FA)?
El concepto de autenticación de dos pasos permite la presentación de una segunda pantalla de autenticación únicamente si la primera ha sido satisfactoria. Algunos ejemplos de este modelo han sido implementados por Google [4], Twitter [5], Facebook [6], Amazon AWS [7] y Microsoft Azure [8] como respuesta a los robos masivos de credenciales de autenticación ocurridos en los últimos meses.

Para que una implementación de 2SA esté alineada con PCI DSS, se deben cumplir las siguientes premisas:
  • Para la autenticación se debe emplear una combinación de mínimo dos de los tres factores de autenticación.
  • Los factores de autenticación empleados deben ser independientes entre sí. Esto implica que el acceso al segundo factor de autenticación no debe depender del primero.

¿Cuándo se requiere el uso de la autenticación multi-factor?
En PCI DSS los requerimientos vinculados con MFA son el 8.3, 8.3.1, 8.3.2 y 8.5.1. En estos requerimientos se describen los escenarios en los cuales es indispensable el uso de la autenticación multi-factor. Sin embargo, antes de describir dichos escenarios, es importante introducir tres términos básicos:
  • Acceso diferente al de consola (“non-console access”): Acceso lógico a un componente del sistema a través de una interfaz de red en vez de una línea física directa al componente. En este caso, el usuario que se conecta no está presente físicamente frente a la consola del sistema y no puede interactuar directamente con la pantalla y el teclado local. Algunos ejemplos de accesos diferentes al de consola son los servicios de RDP (Remote Desktop Protocol) o interfaces de administración basadas en web (GUI).
  • Acceso administrativo (Administrative access): Privilegio concedido a una cuenta en particular que le permite ejecutar acciones privilegiadas en un sistema. Se excluyen de esta definición cuentas del sistema o de aplicación que ejecuten funciones automatizadas y cuentas de usuario con acceso limitado a recursos del sistema.
  • Acceso remoto (Remote access): Acceso a un ordenador o a una red de ordenadores desde fuera de dicha red. Estos accesos se pueden generar desde dentro de la red de la compañía (por ejemplo, desde otra VLAN) o desde una ubicación remota fuera de la red de la compañía (por ejemplo, una VPN).

Siendo así, la implementación de MFA se requiere en estos escenarios:
  • Requerimiento 8.3.1: Para accesos diferentes al de consola de cualquier cuenta con privilegios administrativos originados desde redes confiables (“trusted networks”, tales como redes internas) que permitan el acceso al CDE (Cardholder Data Environment). Este requerimiento es una mejor práctica y entra a ser obligatorio a partir de enero 31 de 2018
  • Requerimiento 8.3.2: Para todos los accesos remotos  al CDE o a cualquier red que permita acceso al CDE de usuarios, administradores y terceros (proveedores que ofrezcan servicios de soporte o mantenimiento) originados desde fuera de la red de la entidad (Internet o cualquier red no confiable (“untrusted network”) incluyendo redes de terceros)
  • Requerimiento 8.5.1: En el caso de proveedores de servicio, si se tiene acceso a redes de clientes (por ejemplo, para soporte de sistemas TPV) se requiere del uso de una credencial de autenticación exclusiva por cada cliente. Bajo este modelo, el concepto de MFA puede ser una alternativa de implementación. 

¿En dónde puede ser implementada la autenticación multi-factor?
La autenticación multi-factor puede ser implementada a nivel de red o a nivel de aplicación/sistema.
Si un usuario emplea MFA al ingresar al CDE, no es necesario que nuevamente se autentique con MFA en un sistema o aplicación dentro del CDE.

Para la elección e implementación de una solución particular de MFA se puede emplear la guía del NIST 800-63-2 “Electronic Authentication Guideline” que incluye una serie de mejores prácticas en el proceso de autenticación electrónica [9].

Como siempre, se recomienda el soporte de un Asesor QSA, quien podrá guiar a la organización en las mejores prácticas para la implementación y el despliegue de una solución de MFA que cumpla con los criterios de PCI DSS.

Referencias
[1] http://blog.isecauditors.com/2016/05/publicada-la-version-3-2-de-pcidss.html
[2] http://krebsonsecurity.com/2015/09/inside-target-corp-days-after-2013-breach/
[3] https://www.schneier.com/blog/archives/2005/03/the_failure_of.html
[4] https://www.google.es/landing/2step/
[5] https://support.twitter.com/articles/20170439#
[6] https://www.facebook.com/help/413023562082171?expanded_faq=270942386330392
[7] https://aws.amazon.com/es/iam/details/mfa/
[8] https://azure.microsoft.com/es-es/documentation/articles/multi-factor-authentication/
[9] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf


Autor: David Eduardo Acosta - CISSP, CISA, CISM, CRISC, PCI QSA, CCNA Security, OPST, CHFI Trainer, CEH, BS25999 L.A.
Departamento de Consultoría

No hay comentarios:

Publicar un comentario