Autenticación multifactor en conformidad con el PCI DSS 3.2

El 1 de febrero de 2018 entró en vigencia el Requisito 8.3 del Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS 3.2), que convirtió en obligatoria la autenticación multifactor para accesos no realizados mediante consola a computadoras y sistemas que contienen datos de titulares de tarjetas, y también para el acceso remoto al entorno de datos del titular de la tarjeta (CDE). A principios de este año, el Consejo sobre Normas de Seguridad de la PCI publicó además pautas para las implementaciones de la autenticación multifactor.

El PCI DSS 3.2

El PCI DSS se aplica a todas las entidades involucradas en el procesamiento de tarjetas de pago, entre ellos comerciantes, procesadores, compradores, emisores y proveedores de servicios. También se aplica a todas las demás entidades que almacenan, procesan o transmiten datos de titulares de tarjetas o datos de autenticación confidenciales.

Desde la publicación del PCI DSS, se realizaron dos actualizaciones importantes: la versión 2.0 en noviembre de 2010 y la 3.0 en octubre de 2013. La subversión más reciente, la versión 3.2, se publicó en abril de 2016. En esta se agregaron algunos requisitos nuevos que se consideraron prácticas recomendadas hasta el 31 de enero de 2018; después de esa fecha, pasaron a ser requisitos obligatorios. Estos cambios garantizan que los estándares estén actualizados a la par de las amenazas emergentes y los cambios en el mercado. El cambio más significativo es el Requisito 8.3 revisado, que está relacionado con la autenticación multifactor.

Algunos de estos cambios se introdujeron en respuesta a incidentes de pirateo graves que ocurrieron en los EE. UU., entre ellos las filtraciones de datos en Target y Home Depot. Durante estos, los piratas accedieron a nombres, números de tarjetas de crédito y otra información sobre millones de personas. Tan solo la filtración de Target en 2013 puso en riesgo la información de tarjetas de pago de 40 millones de clientes y expuso parcialmente a otros 70 millones. Tras una extensa investigación, Target pagará $ 18,5 millones mediante un acuerdo de violación de la seguridad. Desde esta filtración, la cadena de tiendas minoristas ha gastado $ 202 millones en honorarios legales y otros costos.

El Requisito 8.3 y la autenticación multifactor

El primer cambio en el Requisito 8.3 es la introducción del término “autenticación multifactor” en lugar del anterior “autenticación de dos factores”, ya que pueden utilizarse dos o más factores. Al cambiar la terminología, dos factores de autenticación se convierten en el requisito mínimo.

El segundo y fundamental cambio es la ampliación del Requisito 8.3 y lo convierte en dos subrequisitos: se requiere la autenticación multifactor para todo el personal con acceso administrativo no realizado mediante consola y para todo el personal con acceso remoto al CDE.

El nuevo Requisito 8.3.1 hace referencia a la autenticación multifactor para todo el personal con acceso administrativo no realizado mediante consola al CDE. En este caso, "acceso no realizado mediante consola" significa el acceso lógico que se produce a través de una red y no a través de una conexión física directa, incluido el acceso desde redes internas y el acceso desde redes externas o remotas.

El nuevo Requisito 8.3.2 incorpora el Requisito 8.3 anterior y hace referencia a la autenticación multifactor para todo el personal con acceso remoto al CDE. Este requisito está pensado para aplicarse a todo el personal, incluidos usuarios en general, administradores y proveedores (para soporte y mantenimiento) con acceso remoto a la red, en el caso de que ese acceso remoto pueda producir un acceso al CDE.

Pautas para la autenticación multifactor

Desde el cambio al Requisito 8.3, el Consejo sobre Normas de Seguridad de la PCI recibió una serie de preguntas sobre la forma en que deberían implementarse los distintos factores, tanto de las organizaciones que piensan implementar AMF como de los asesores de seguridad que están evaluando hacerlo.

Para responder estas preguntas, el Consejo publicó Suplemento de información: autenticación multifactor versión 1.0 con el objetivo de describir las prácticas recomendadas y los principios aceptados por la industria para una implementación de AMF, entre ellos:

• Definición, independencia y protección de los factores de autenticación
• Uso indebido de los multifactores, incluida la autenticación en varios pasos

En la última sección, el Consejo explora casos de autenticación comunes y consideraciones para la autenticación multifactor.

Factores de autenticación

La autenticación multifactor requiere el uso de al menos dos de los tres factores de autenticación, como se describe en el Requisito 8.2 del PCI DSS:

• Algo que se conoce, como una contraseña, un PIN o la respuesta a preguntas secretas
• Algo que se tiene, como un dispositivo token o una tarjeta inteligente
• Algo que se es, como una biometría

En el sector ya se conoce plenamente esta definición, pero aún hay problemas al implementar estos diferentes factores de autenticación.

El SCC de PCI también menciona otros factores: "Otros tipos de información, como la geolocalización y la hora, pueden incluirse de forma adicional en el proceso de autenticación; sin embargo, siempre deben usarse al menos dos de los tres factores identificados anteriormente". Por ejemplo, se pueden usar los datos de geolocalización y hora para restringir el acceso remoto a la red de una entidad de acuerdo con el horario de trabajo de una persona. Aunque el uso de estos criterios adicionales podría reducir aún más el riesgo de pirateo de cuentas o actividad maliciosa, el método de acceso remoto deberá seguir requiriendo autenticación a través de al menos los siguientes dos factores: algo que se sabe, algo que se tiene o algo que se es".

Independencia de los factores de autenticación

La AMF debe implementarse con mecanismos de autenticación que sean independientes entre sí, para evitar que el acceso a uno de los factores otorgue acceso a cualquiera de los otros, y que la vulneración de uno de los factores no afecte la integridad ni la confidencialidad de cualquiera de los otros.

Algunos de los obstáculos descritos por el SSC de la PCI son los siguientes:

• En primer lugar, si se usa una combinación de nombre de usuario/contraseña para ingresar en la red de la compañía y estas mismas credenciales también otorgan acceso a una cuenta de correo electrónico a la cual se envía una contraseña de un solo uso como segundo factor, estos factores no son independientes. El primer factor (nombre de usuario/contraseña) otorga acceso a la cuenta de correo electrónico y, por lo tanto, al segundo factor.
• En segundo lugar, "un certificado de software almacenado en un equipo portátil (algo que se tiene) protegido por el mismo conjunto de credenciales utilizadas para iniciar sesión en el equipo portátil (algo que se conoce) puede no cumplir la premisa de independencia".
• En tercer lugar, "la transmisión de una contraseña de un solo uso (OTP) a un teléfono inteligente se ha considerado tradicionalmente un método fuera de banda efectivo. Sin embargo, si el mismo teléfono se usa para enviar la OTP (por ejemplo, a través de un navegador web), la efectividad de la OTP como factor secundario se anula de hecho". Al introducir credenciales a través del mismo dispositivo que recibe (o almacena/genera) un segundo factor, un pirata que controla el dispositivo puede capturar ambos factores de autenticación.

Protección de los factores de autenticación

Para evitar todo uso indebido de los factores de autenticación, estos deben protegerse contra el acceso y el uso no autorizados, según la definición del Requisito 8 del PCI DSS. Además, "en casos en que cualquier elemento de autenticación dependa de un dispositivo multiuso para consumidores (por ejemplo, un teléfono móvil o una tableta), además deben implementarse controles para mitigar el riesgo si el dispositivo llegara a ser vulnerado".

Comparación entre métodos de varios pasos y multifactor

El PCI DSS requiere que todos los factores en una autenticación multifactor sean verificados de forma conjunta antes de acceder al sistema. Si un usuario puede acceder a los datos de éxito/fracaso antes de enviar todos los factores, el proceso de autenticación general se convierte en una autenticación de factor único en varios pasos, más allá de que se utilice un factor diferente en cada paso. Esto no cumple con el requisito de autenticación multifactor.

Casos de autenticación comunes

En la última sección del Suplemento de información, el PCI DSS describe cuatro casos de autenticación multifactor que aclaran las diferentes condiciones para los factores de autenticación y la mejor forma de implementarlos.

Conclusión

A menos de tres meses de que entre en vigencia el Requisito 8.3 del PCI DSS, es hora de tomar medidas. Estoy convencido de que la publicación Suplemento de información: autenticación multifactor versión 1.0 es un buen punto de partida mientras se prepara para revisar, implementar o actualizar sus soluciones de autenticación multifactor.