En marzo de 2008, Heartland Payment Systems (una de las mayores pasarelas de pago de Estados Unidos, con cerca de 100 millones de transacciones con tarjeta por mes provenientes de más de 175.000 comercios, por aquel entonces) sufría uno de los mayores incidentes de seguridad del siglo XXI: más de 134 millones de datos de tarjetas de pago fueron comprometidos debido a un ataque de SQL Injection que permitió la introducción de malware dentro de su red de datos, facilitando la captura no autorizada de tráfico (a través de keyloggers y sniffers) y la posterior exfiltración de los datos comprometidos (bandas magnéticas completas, PAN y nombres de titulares).

No fue hasta enero del 2009 cuando Heartland descubrió y notificó el incidente. Los costes asociados con las investigaciones forenses, las multas y compensaciones provenientes de acciones legales de los afectados, las penalizaciones de las marcas, el remplazo de tarjetas (plásticos) de los usuarios, los gastos vinculados al fraude con las tarjetas comprometidas, los problemas derivados de la negativa de las marcas a procesar con ellos y el proceso de recuperación técnico del incidente superaron los 145 millones de dólares.

Después de una larga investigación, se logró determinar que tres personas (Albert González y dos ciudadanos rusos) fueron los delincuentes detrás de este incidente. González también estuvo involucrado con el incidente de TJX (94 millones de datos de tarjetas comprometidos) y fue condenado en 2010 a 20 años de prisión.

Figura 1. Mayores brechas de seguridad del siglo XXI (fuente: csoonline.com)

Esta historia podría ser una más de las tantas vinculadas con incidentes de seguridad, de no ser por dos agravantes que complicaron aún más la situación:

  1. VISA y MasterCard ya habían notificado previamente a Heartland acerca de múltiples transacciones sospechosas provenientes de sus redes (lo que, finalmente, permitió que Heartland empezara con las investigaciones, ya que internamente ellos no se habían percatado de lo que estaba sucediendo), y
  2. Heartland había sido auditada y certificada en PCI DSS en 2007 y en 2008 por Trustwave, una compañía homologada por el PCI SSC como PCI Qualified Security Assessor Company (QSAC), sin que se hubiera detectado ningún problema. Durante el incidente, Heartland aparecía en las listas de proveedores de servicios certificados en PCI DSS de VISA.

Posterior al incidente, en 2009 VISA removió a Heartland de sus listas y no le permitió procesar transacciones a través de sus redes. En 2010, Heartland se recertificó en PCI DSS (esta vez con otro asesor, VeriSign) y fue nuevamente aceptado por VISA, luego de demostrar que se habían corregido todas las vulnerabilidades vinculadas con el incidente. Algo similar sucedió por la misma época con RBS WorldPay, otra compañía que también estaba certificada en PCI DSS, y que tuvo un incidente de seguridad con 1,5 millones de datos de tarjetas comprometidos.

Pero la historia no terminó ahí. 10 años después, en junio de 2018, dos empresas aseguradoras (Lexington Insurance Co. y Beazley Insurance Co.) demandaron a Trustwave (la compañía que auditó en su momento a Heartland) por prácticas negligentes, debido a que tuvieron que asumir más de 30 millones de dólares en demandas asociadas con el incidente de Heartland. Trustwave, por su parte, se defendió argumentando que “una auditoría de PCI DSS no era el equivalente a gestionar la seguridad de Heartland”. El juicio aún está en curso.

Aprovechando esta historia, a continuación se aclararán algunas dudas respecto al alcance de las certificaciones PCI DSS en términos de responsabilidades, tanto por parte del cliente (auditado) como por parte del auditor.

¿Quién es el responsable directo del cumplimiento de PCI DSS?

Esta pregunta tiene una única respuesta: la entidad que procesa, almacena o transmite datos de tarjetas de pago de sus clientes.

Al margen de la realización de una auditoría o del rellenado de un cuestionario de autoevaluación (SAQ), la entidad afectada debe velar por mantener siempre los niveles de seguridad exigidos por PCI DSS.

¿Cumplir con PCI DSS me hace invulnerable a los incidentes de seguridad?

Esta es otra pregunta en que siempre se hacen las empresas, ya que existe un amplio desconocimiento al respecto.

Para empezar, es muy importante aclarar la diferencia entre dos conceptos clave que por lo general se suelen confundir: cumplimiento y seguridad.

  • Cumplimiento: Acciones que validan que un comportamiento está alineado con las normas establecidas en un momento específico.
  • Seguridad: Acciones continuas orientadas a lograr un estado de exención de peligros, daños o riesgos.

Una comparación de estos dos criterios con un escenario de la vida real podría ser el siguiente:

Para conducir un coche se requiere superar una serie de pruebas y obtener un certificado (licencia de conducción). La obtención de dicho certificado implica que el candidato a conductor validó sus aptitudes con base en unas reglas previamente establecidas (“normativas”) y que esa licencia se otorgó con base en los resultados obtenidos en un momento determinado (“auditoría”). No se puede garantizar que el conductor siempre tendrá el mismo nivel de destreza en el futuro o que se podrá comportar de forma correcta en situaciones no examinadas (ya que el examen se realiza con base en un “muestreo”). Todo este proceso vendría a ser “cumplimiento”, por lo general validado mediante una auditoría.

No obstante, el hecho de tener esa licencia no asume per se que el conductor nunca vaya a tener un accidente, que pueda conducir otro tipo de vehículo o que realice una conducción temeraria con riesgos que anteriormente no eran asumidos, para lo cual es necesaria la ejecución de acciones adicionales para lograr un estado que permita que las aptitudes evaluadas y las aptitudes actuales se mantengan a lo largo del tiempo en un nivel similar o mejores que en el momento de la revisión. Este proceso continuo es lo que se denomina “seguridad“.

Entonces, ¿qué valor agregado me ofrece el realizar una auditoría de PCI DSS?

¿Recordáis el “círculo de Deming”? Una auditoría es solamente una de las tareas contempladas dentro de la espiral de mejora continua (“Check”):

En el caso de PCI DSS, es un estándar que requiere el despliegue, implementación, monitorización y optimización continua de una serie de controles de seguridad en un entorno específico. La auditoría de PCI DSS simplemente es una acción realizada por un tercero (o por la propia empresa, en el caso de un cuestionario de autoevaluación – SAQ) en un momento específico del tiempo (“foto fija”) en la que se pretende identificar potenciales incumplimientos y desviaciones en dichos controles y generar unas recomendaciones de mejora. La implementación de dichas recomendaciones son responsabilidad exclusiva del auditado (empresa).

Por ello, una auditoría de PCI DSS no exime de ninguna manera a una organización de poder ser víctima de un incidente en un futuro. Son simplemente recomendaciones y verificaciones para garantizar que el proceso continuo de seguridad es correcto en un momento dado. Es responsabilidad de la empresa auditada el mantener y optimizar en el tiempo los niveles de seguridad identificados en la auditoría.

degradacion_seguridad

Figura 3. Degradación de los niveles de cumplimiento en ausencia de acciones de seguimiento y mejora

¿Cuáles son las limitaciones en una auditoría de PCI DSS?

Por lo general, los proyectos de auditoría de PCI DSS tienen las mismas tres variables que cualquier otro proyecto, conocidas como “el triángulo de hierro”: alcance, coste y tiempo.

Figura 2. “Triángulo de hierro” en gestión de proyectos

  • El alcance viene dado por la identificación del entorno de cumplimiento (“scope”) de PCI DSS,
  • El coste viene dado por los recursos que estarán vinculados al proyecto: personal, equipamiento, desplazamientos, etc., y
  • El tiempo estará definido por el calendario del proyecto (inicio, ejecución y cierre).

Para que un proyecto sea viable, se deben aplicar restricciones en cada uno de estos puntos. De lo contrario, el proyecto sería irrealizable.

Es por ello que – en función de la complejidad del entorno – se suelen aplicar técnicas de muestreo, en las cuales se escogen activos representativos del entorno y los resultados de sus verificaciones se extrapolan a los demás activos. Esto facilita que los proyectos sean aceptables en términos de coste/beneficio. No obstante, el uso de técnicas de muestreo conlleva un riesgo tácito: que en el entorno pueda existir un activo vulnerable que no coincide con los resultados del muestreo, dejando a la organización expuesta a riesgos ocultos.

Por otro lado, existen otros elementos menos explícitos que pueden afectar a una auditoría, haciendo que sus resultados varíen en términos de calidad:

  • La propia cultura de seguridad de la organización auditada: Si una organización es negligente y simplemente asume una auditoría de PCI DSS como una acción burocrática para cumplir con los requisitos de los adquirientes y/o de las marcas, se verá abocada a una “falsa sensación de seguridad” que la expondrá a riesgos no gestionados.
  • La experiencia y el valor agregado de la empresa QSA: A pesar de que el PCI SSC ha definido unos criterios bastante robustos para garantizar que el trabajo de una empresa QSA será óptimo, todo depende de la experiencia, disciplina y organización tanto del auditor como de la empresa QSA. Por ello, es muy importante que la empresa auditada defina sus propios criterios (“due diligence”) para la contratación de este tipo de servicios, validando por su parte las referencias, proyectos ejecutados y perfil de los auditores que participarán en el proyecto. Es recomendable que de forma periódica se cambie la empresa de auditoría (o, por lo menos, los asesores QSA que participan en el proyecto) para obtener diferentes criterios, evitar conflictos de interés y garantizar independencia.

También vale la pena aclarar que es muy importante que la empresa auditada acompañe y verifique los resultados de la auditoría y que ejecute internamente revisiones periódicas adicionales para detectar posibles falencias en el entorno no identificadas.

Si ocurre un incidente de seguridad, ¿sirve para algo haber demostrado cumplimiento con PCI DSS (o con cualquier otro estándar de seguridad)?

Esta es otra pregunta que suelen hacer los directivos para justificar la inversión en seguridad y en auditorias.

PCI DSS, al igual que cualquier otro estándar de seguridad, incluye controles orientados a la gestión de amenazas conocidas. Si ocurre un incidente de seguridad en una empresa auditada (o alineada con PCI DSS) y se comprueba que ese incidente podría haber sido gestionado con un control descrito en el propio estándar que no estaba implementado en su momento, sencillamente estaríamos frente a un caso de negligencia. Es responsabilidad de la empresa aplicar y mantener los controles del estándar.  En este tipo de casos, todo el impacto del incidente (costes, pérdida de imagen, investigaciones, multas, etc.) debe ser asumido por la empresa afectada.

Por otro lado, si el incidente fue causado por vulnerabilidades no conocidas (“ataques de día cero“) o por otras causas no imputables al auditado y no contempladas en el estándar PCI DSS, entonces las marcas y los adquirientes analizarán las causas y apoyarán a la empresa afectada durante el proceso de recuperación.

¿Tiene alguna responsabilidad una empresa de auditoría si su auditado sufre un incidente de seguridad?

Después de haber enumerado las limitaciones de la auditoría y haber aclarado que la responsabilidad del despliegue y mantenimiento de los controles de seguridad está del lado de la empresa auditada, vale la pena aclarar las responsabilidades del auditor si su auditado ha sufrido un incidente de seguridad.

En el documento “QSA Program Guide” del PCI SSC se definen todas las tareas que debe cumplir una empresa QSA, dentro de las cuales se encuentran:

  • Cumplimiento con los requisitos del programa de QSA.
  • Validar de forma correcta el alcance de cumplimiento de PCI DSS en sus clientes.
  • Recopilar toda la evidencia necesaria para sustentar los resultados de la auditoría.
  • Aplicar y mantener un juicio independiente en todas las decisiones de verificación de PCI DSS.
  • Cumplir con los criterios de calidad del PCI SSC.

Igualmente, la empresa QSA requiere adquirir una póliza de seguros para cubrir con cualquier potencial coste derivado de malas praxis durante sus tareas de auditoría.

Si se comprueba que la empresa QSA ha incumplido con los criterios del Council, se aplicarán una serie de acciones correctivas dependiendo del problema, que van desde los llamados de atención del PCI SSC hasta la retirada de la credencial como empresa QSA, sin excluir la aplicabilidad de las pólizas de seguros mencionadas anteriormente.

Obviamente, todo esto requiere de una investigación detallada de cada caso, para determinar responsabilidades y acciones correctivas.

Conclusión

A esperas de los resultados del juicio contra Trustwave, cuyo resultado podrá cambiar de forma significativa las responsabilidades de las empresas de auditoría, las conclusiones de dicho incidente son las siguientes:

  • Una auditoría es simplemente una “foto fija” del estado de seguridad de una organización en un momento dado y cuyo objetivo es detectar posibles desviaciones y generar recomendaciones de mejora. En el caso de PCI DSS, estas auditorías suelen ser anuales.
  • El cumplimiento con PCI DSS no implica que la empresa certificada quede eximida de cualquier riesgo, al igual que sucede con cualquier otro estándar o marco de trabajo de ciberseguridad.
  • Se requiere de un proceso continuo de monitorización y mejora continua a lo largo del tiempo de los controles de seguridad, cuya responsabilidad es enteramente de la empresa auditada.
  • Es imposible para un auditor poder determinar si una empresa certificada en PCI DSS puede seguir manteniendo sus niveles de cumplimiento al día siguiente después de la auditoría, ya que esto está fuera de sus responsabilidades.
  • Se requieren acciones de diligencia debida (“due diligence”) por parte de la empresa auditada para la contratación de sus auditores.
  • Si ocurre un incidente, se realizará una investigación para determinar hasta qué punto el auditor pudo haber fallado.
  • Si se detectan irregularidades en el trabajo del auditor, el PCI Council cuenta con acciones correctivas para gestionarlo.

Finalmente, aclarar: la responsabilidad final de la implementación de los controles de PCI DSS es enteramente de la empresa auditada. La auditoría simplemente hace una verificación del estado de dichos controles en un momento dado para detectar posibles desviaciones, sin que ello implique eximir a la empresa de futuros riesgos.