Latch al rescate para cumplir con el requerimiento 8.3.1 de Autenticación Multi-Factor (MFA) de PCI DSS 3.2

ElevenPaths    23 mayo, 2017
A modo de introducción, PCI DSS es un estándar internacional que regula el almacenamiento, procesamiento y transmisión de datos de tarjetas de crédito, nació como respuesta a la estandarización en un estándar común por parte de las marcas de tarjeta de crédito, ya que antes c/u tenía un estándar distinto de seguridad. Para esto se creó un Council (PCI Council) compuesto por personas de bancos, marcas y empresas a fines, quienes desarrollan y mantienen una serie de estándares y certificaciones asociadas a seguridad de la información asociado a tarjetas de crédito.
Como respuesta a las últimas grandes brechas de seguridad ocurridas sobre todo en grandes comercios de retail mediante phishing (Target, Home Depot y otras brechas) es que el Council se ha visto obligado a actualizar con más frecuencia el estándar PCI DSS, en su última versión la 3.2 de abril del 2016 incluye un nuevo requerimiento de seguridad o mejor dicho, una nueva exigencia para cumplirlo. El requerimiento principal del cual hablamos es el número 8: “Identificar y autenticar el acceso a los componentes del sistema”. En este requerimiento en el punto 8.3.1 aparece una nueva consideración importante acerca de la autenticación multi-factor (MFA), necesaria para todos los accesos que no son de consola y remotos al entorno de cumplimiento PCI DSS, recordemos que la base de la autenticación multi-factor surge del uso de dos o más factores durante el proceso de autenticación. Estos factores son:
  • 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) 
La nueva exigencia del punto 8.3.1 explicada en un boletín enviado por el council en diciembre del 2016 indica lo siguiente:

If the user can’t tell which factor failed to grant access, then you have MFA.”
Este nueva exigencia cambia todo el escenario actual presente y que la mayoría de las entidades han implementado, ya que se consideraba como válido implementar una autenticación multi-factor por pasos, siempre que en cada uno de estos pasos se validara un factor de autenticación distinto (por ejemplo, en un paso se validara “algo que el usuario sabe” y en el siguiente “algo que el usuario es o tiene”).
En el nuevo escenario, dicha autenticación por pasos no será válida según el estándar PCI DSS y va a ser necesario que los múltiples factores de autenticación se validen en el mismo momento, de manera que, en el caso de una autenticación fallida, el usuario no sepa cuál de los factores de autenticación introducidos es el incorrecto.

Con este nuevo planteamiento, muchas de las soluciones actuales de autenticación multi-factor se han visto afectadas, ya que no serán válidas en entornos PCI DSS la mayoría de autenticaciones remotas basadas en certificados personales, dónde se realiza una autenticación por pasos (el sistema valida el certificado personal antes de pedir la contraseña al usuario). Otros métodos comerciales que se basan en el envío de tokens a dispositivos móviles o correo electrónico tampoco serán válidos, ya que en muchos de éstos métodos se requiere un primer paso, donde el usuario se autentica con una contraseña (primer factor de autenticación), y si ésta es correcta, el sistema envía al dispositivo escogido por el usuario un token, que éste debe introducir en un segundo paso de autenticación.
Con Latch este proceso de autenticación se realiza de manera automática y en paralelo (siempre cuando hayamos preconfigurado el autobloqueo en Latch, ósea que el candado este siempre cerrado, esto es lo que siempre recomendamos desde 11 Paths y es el objetivo principal de Latch), por lo cual se cumple con lo exigido por el punto 8.3.1 y la explicación del boletín enviado en diciembre del 2016, en palabras simples, al tratar de ingresar, no se puede identificar cuál de los factores de autenticación falla, a continuación un ejemplo grafico de las 2 formas del proceso (autenticación de 2 pasos vs MFA, simultanea).
Doble factor de autenticación en pasos secuenciales usando TOTP de Latch:
  1.  Se solicitan las credenciales de acceso.
  2. Si el usuario se equivoca al ingresar las credenciales, se indica el error en la misma pantalla, hasta este punto no se ha solicitado el 2do factor de autenticación.
  3. Al ingresar correctamente ambas credenciales, un formulario distinto solicita el 2do factor de autenticación, en este caso un pin generado por Latch.
     
  4. Si el usuario se equivoca al ingresar el 2do factor de autenticación, la misma pantalla informa sobre el error.

En este ejemplo no se cumple con MFA simultaneo y como indica el boletín enviado por PCI, el usuario no debe percatarse que factor es el que falla en el proceso de autenticación, lo que en este ejemplo no se cumple.

Doble factor de autenticación simultaneo con Latch
  1. Se solicitan las credenciales de acceso.
  2. Si el usuario se equivoca al ingresar las credenciales o el candado está cerrado en Latch (esto es fundamental y prerrequisito el candado siempre debe estar cerrado, esto se puede configurar con el auto bloqueo), El error no indica que factor fue el que fallo, en el ejemplo de la foto, el que no permitió el acceso fue Latch.
  3. Latch indica al usuario que “alguien” trato de ingresar al portal y pregunta si desea desbloquear el acceso, todo en simultaneo, esto se puede validar observando la hora en la pantalla del formulario web (Macbook) y de la pantalla de Latch en el Smartphone.
En este último ejemplo con Latch si se cumple lo indicado en el boletín de PCI, el usuario no sabe que factor es el que falla en el proceso de autenticación, por lo tanto si se cumple con el requisito 8.3.1 de PCI DSS 3.2.
Los invito a conocer más sobre Latch, sobre los #11PathsTalks y cualquier tema relacionado a seguridad de la información en nuestra comunidad.

Gabriel Bergel
CSA – Chief Security Ambassador

Te puede interesar

Comentarios

  1. Hola Gabriel:

    No sé si la cita de la aclaración del PCI Council está acompañada de más texto que pudiera solventar directamente esta primera duda que te planteo, un linkito al texto completo se agradecería 😉

    Primera: ¿se indica específicamente que es en la página de login del servicio donde no debe conocerse el factor de autenticación que ha fallado? Si Latch avisa por otro canal, la app en el móvil, de que ha habido un intento de acceso y ha fallado debido a que se tiene el pestillo cerrado me estoy enterando perfectamente de que el problema no estaba en las credenciales. No sé si especifica que el usuario legítimo sí puede saberlo o que si se informa por otro canal el aviso también es válido. En cualquier caso, propongo una posible solución para ello: que el aviso de Latch de acceso fallido no se haga de forma instantánea sino en un periodo acotado (minutos) y aleatorio.

    Aquí va la segunda: la seguridad de Latch se basa en la cuenta de usuario, también ésta protegida por credenciales, que se ha pareado con el servicio, así que ese "segundo factor" (Latch) no es de otra naturaleza. La segunda protección vuelve a sustentarse, como en las credenciales iniciales, en algo que se sabe. No veo que eso pueda considerarse MFA sino una aplicación múltiple encadenada de un único tipo de factor.

    Gracias por tus aclaraciones y comentarios por adelantado.

    Responder

  2. El aviso de acceso fallido debe ser en el portal o sistema al que estás tratando de acceder, pero no debes poder identificar que factor fue el que falló, como lo explico en el post, el aviso de Latch es una característica propia de Latch y PCI no dice nada respecto a avisar sobre el acceso fallido por otro canal, si Latch no te avisara no podría saber si tu cuenta se comprometió. Respecto a tu 2da consulta, la seguridad de Latch se basa en el id del portal o sistema que estás protegiendo más un código de pareo que te entrega Latch cuando enlazas por 1ra vez la cuenta, así se crea un Token que será tu "candado", las credenciales propias de Latch son para poder ingresar a Latch y si es un 2do factor porque Latch está en tu smartphone, "algo que tienes", espero haber respondido tus dudas, saludos

    Responder

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *