¿Alguna vez se ha sentido frustrado por el cumplimiento de las normas de seguridad? No es el único. Todos tenemos una especie de "criptonita" cuando se trata del cumplimiento. Pedí a algunos de nuestros auditores de InfoSec que compartieran su criptonita. Sus respuestas se centraron en el dolor du jour, las nuevas versiones 4.0 y 4.01 de la norma PCI DSS. Así que, querido lector, vayamos al meollo de la cuestión.
La primera respuesta es Chris CamejoJefe de Prácticas de Cumplimiento :
Nunca pregunté
"Mi criptonita del cumplimiento es cuando una organización nos pregunta por qué le obligamos a hacer algo que nunca antes había tenido que hacer. A menudo se trata de controles de seguridad que han sido aprobados por auditores anteriores. Me hace cuestionar mi comprensión del marco (y a veces mi cordura). Decir "todos los demás auditores con los que has hablado están equivocados" me parece egoísta, así que a menudo vuelvo a la fuente para comprobar mi comprensión, pero normalmente me encuentro con un requisito bastante claro, respaldado por documentos de orientación y preguntas frecuentes que a menudo contienen ejemplos específicos relevantes."
"Después de muchos años, he llegado a la conclusión de que algunos auditores caen en la misma trampa que las organizaciones a las que evalúan: hacen suposiciones sobre lo que significa un requisito sin entenderlo realmente en su contexto ni consultar orientaciones adicionales (odio decirlo, pero probablemente yo era ese tipo al principio de mi carrera de compliance). Esto perjudica a las organizaciones que están siendo evaluadas, ya que se enfrentan a sorpresas repentinas durante la auditoría si un nuevo auditor tiene una mejor comprensión de los requisitos que el auditor anterior. A veces también funciona al revés. Me encuentro con organizaciones que hacen cosas que no son necesarias 'a efectos de cumplimiento' debido a una interpretación errónea de los requisitos".
Desde el principio
"Siempre ha habido ideas erróneas sobre la forma en que PCI DSS (y otros marcos de cumplimiento) definen su ámbito de aplicación y lo que es aceptable para determinados requisitos. Muchos de estos conceptos erróneos se han abordado en diversos documentos de orientación y preguntas frecuentes que nadie salvo los expertos en cumplimiento más dedicados se han tomado el tiempo de leer y entender. En mi opinión, muchos de los "cambios" de la versión 4.0 de PCI DSS consisten en incorporar información de los documentos de orientación y las FAQ a la propia norma, consolidando lo que siempre se ha esperado en un lugar donde es más probable que se vea. Un ejemplo es el diagrama de flujo del ámbito de aplicación añadido a la Sección 4 de las PCI DSS. Ha permitido a muchas organizaciones comprender mejor lo que se incluye en el ámbito de aplicación y lo que se excluye. El secreto es que este diagrama de flujo había estado oculto durante años en el documento PCI Scope and Segmentation Guidance, donde muy poca gente reparaba en él, y es ahora cuando se ha incorporado a la propia norma DSS.
Nuevo para ti
"He visto que algunos clientes achacan los cambios a que son necesarios para adaptarse a la nueva versión 4.0 de la norma PCI DSS, cuando el resultado del cambio es algo que deberían haber estado haciendo todo el tiempo. Por un lado, esto significa que los cambios son eficaces: obligan a las organizaciones a converger hacia una comprensión única y coherente del alcance y los requisitos de la PCI DSS, en lugar de que algunas organizaciones se salgan con la suya. Por otro lado, como consultor, es doloroso tener que decir a un cliente que se ha equivocado y que debe replantearse su enfoque del cumplimiento.
Estaba atrapado
"Como jefe de práctica, a menudo participo en la ingeniería preventa, ayudando a definir los compromisos de cumplimiento para nuestros clientes potenciales. A menudo trato con organizaciones que tienen dificultades porque uno de sus socios o clientes les exige contractualmente el cumplimiento de un marco específico. Muy a menudo, me encuentro intentando explicar que el marco de cumplimiento no se aplica a su organización por una razón u otra. A menudo es porque la organización no procesa el tipo de información a la que se aplica el marco, o porque la organización no está en el tipo de negocio al que se aplica el marco. La verdadera razón es que el socio o cliente que pide a la organización que cumpla la normativa no entiende en qué consisten los propios marcos de cumplimiento y hace las preguntas equivocadas. Después de responder a demasiadas llamadas de este tipo, escribí un artículo explicando la aplicabilidad de los marcos que a menudo se aplican de forma inadecuada".
Proveedores de servicios
"De acuerdo con el requisito 12.8.5 de la PCI, los comerciantes deben documentar las responsabilidades de los proveedores de servicios, pero siempre ha sido difícil obtener esta información de los proveedores de servicios. El nuevo requisito 12.9.2 debería facilitar las cosas, ya que ahora la PCI DSS exige a los proveedores de servicios que ayuden a sus clientes a comprender sus responsabilidades. Pero hay una trampa: algunas grandes organizaciones publican matrices de responsabilidad que dejan más preguntas que respuestas (por ejemplo, en la matriz de Microsoft Azure, todos los sub-requisitos x.1.1 y x.1.2 están marcados como responsabilidad exclusiva del cliente, incluso para los requisitos en los que Microsoft ha reclamado responsabilidad compartida o exclusiva para otros sub-requisitos). Si Microsoft es responsable de determinados subrequisitos, también debe ser responsable de sus propias políticas, procedimientos y asignación de funciones para dichas responsabilidades de acuerdo con los subrequisitos x.1.1 y x.1.2. Los proveedores de servicios tienen un largo camino por recorrer para ayudar a sus clientes a entender exactamente cuáles son sus responsabilidades.
Chris tenía mucho que decir.
Continuación Lee QuintonLee Quinton, otro antiguo QSA de PCI, trabaja en el Reino Unido.
Arrastrando los pies
"Para abordar el último punto de Chris más específicamente, también están luchando con el hecho de que su cumplimiento se requiere en los próximos dos o tres meses, mientras que el proveedor de servicios PCI de terceros (TPSP) no necesita cumplir durante seis a nueve meses, y no tienen ningún tipo de matriz de responsabilidad desarrollada para ayudar a su cliente a cumplir con el requisito 12.8.5".
Todas las QSA que entrevisté se hicieron eco del problema que plantea el requisito PCI 12.8.5.
El siguiente artículo es Linus GarinPCI QSA. Aunque es el QSA más joven y reciente de TrustedSec, ha acumulado experiencia en diversos entornos y sectores.
¿Es un MAP?
"También estoy teniendo dificultades similares con los requisitos 12.8 y 12.9. Estoy ayudando a Chris a crear una matriz de responsabilidades TPSP para un cliente y es BRUTAL. Mapear las responsabilidades de cada TPSP es como un juego de adivinanzas, especialmente cuando los TPSPs no proporcionan una versión de sus responsabilidades o un COA (o no lo tienen o el cliente es incapaz de recogerlos por alguna razón). Y para los TPSP que tienen su propia matriz de responsabilidades, como Azure y Cloudflare, como dijo Chris, hay discrepancias en la matriz que crean más preguntas que respuestas. Hay controles que están marcados como no aplicables para TPSP cuando claramente deberían serlo, como las cosas 12.10. ¿Debería seguir su matriz de responsabilidad o usar el "juicio e interpretación de la QSA" para anular su matriz de responsabilidad?"
"Así que el cliente acaba con un TPSP que dice una cosa y un QSA que dice otra, lo que no es bueno para su (y nuestra) experiencia".
El siguiente es el ilustre autor y QSA, Arthur Cooper (Coop).
Mantenerse al día
"Tiene razón, señor. En mi humilde opinión, este asunto del TPSP ha sido la PEOR parte de mi tiempo como QSA."
Coop también busca una rápida resolución de las normas de seguridad del sector con PCI. Por ejemplo, muchos dispositivos de pago POS/POI actualmente aprobados utilizan el Estándar de Cifrado de Datos Triple (3DES) como parte del esquema de Clave Única Derivada por Transacción (DUKPT), pero a partir del 31 de diciembre de 2023, el Instituto Nacional de Estándares y Tecnología (NIST) ha desaprobado este esquema y aconseja a las organizaciones que lo abandonen debido a preocupaciones de seguridad y a la disponibilidad de algoritmos de cifrado más robustos.
Como autor original del requisito 10 de la norma PCI DSS cuando formaba parte del Consejo de la PCI, Coop pide con frecuencia al Consejo actual que aclare diversos aspectos de la norma.
El siguiente artículo es Steph SaundersSteph Saunders, PCI QSA y especialista en implementación de seguridad desde hace mucho tiempo. Ha apoyado controles de seguridad en toda la empresa y considera que muchas empresas se enfrentan a muchos retos en términos de cobertura global y configuración coherente de IAM, especialmente con MFA en la actualidad.
Conéctese a
"Para las empresas que han pasado por varios ciclos de innovación técnica, muchas configuraciones de IAM simplemente no son compatibles o no están centralizadas. Dejando a un lado las diferencias técnicas, la gestión descentralizada también significa a menudo que desactivar cuentas de forma oportuna, coherente o transparente es completamente diferente de un sistema a otro."
"Muchas normas de cumplimiento, como la PCI, no son muy prescriptivas sobre cómo configurar correctamente la AMF (por ejemplo, las mejores prácticas para evitar la reutilización de tokens). Muchas normas como la PCI aún no incluyen la autenticación aceptable sin contraseña, a pesar de las muchas opciones que existen."
La próxima puerta trasera de utilidad XZ
"Con el nuevo requisito PCI 6.3.2 de realizar un inventario de todo el software a medida y personalizado, ¿hasta dónde debemos llegar? Por ejemplo, ¿con qué nivel de detalle debe una empresa inventariar y gestionar las bibliotecas de código abierto? ¿Qué pasa con las bibliotecas a las que estas bibliotecas llaman? ¿Por qué no llegar a cinco niveles de profundidad, y con qué nivel de garantía? Muchas empresas no saben dónde debe detenerse la diligencia".
¿Con qué diligencia habría evitado el ataque de la puerta trasera de la utilidad XZ?
"Muchas empresas no saben cuáles de sus proveedores de servicios se ven afectados por el cumplimiento de la normativa. Muy a menudo, los fabricantes de sistemas operativos (por ejemplo, Microsoft) y dispositivos de red (por ejemplo, Cisco) son tratados como proveedores de productos básicos y no como proveedores de servicios. Pero si estos mismos proveedores no proporcionan actualizaciones a tiempo, pueden seguir siendo el punto débil en el próximo alcance de los datos. ¿Hasta dónde debe llegar la diligencia debida?
El siguiente es tu bloguero, Steve Maxwellun PCI QSA entre otras normas.
¿Qué, estos trapos viejos?
¿Cuál es mi mayor criptonita en materia de cumplimiento? Como ya han dicho otros, es el reto de hacer un seguimiento de la cobertura de seguridad por parte de los proveedores de servicios de transferencia de tecnología. Los proveedores de servicios anuncian públicamente que mantienen a sus clientes alejados de los problemas de cumplimiento, pero la letra pequeña que comparten en privado con sus clientes suele ser mucho más modesta.
Son como miembros de la realeza vestidos de punta en blanco para la entrada por la alfombra roja. Una vez dentro, cuando se les pregunta por su atuendo, responden: "¿Qué, estos trapos viejos? Tener su pastel y comérselo también hace más difícil que sus clientes demuestren que respetan las normas.
Muchos clientes de la PCI consideran necesario exigir mejor información de la que ofrecen actualmente los TPSP. Es posible que el sector de la PCI tenga que responsabilizar a los TPSP de documentar con precisión los controles de seguridad de los clientes. Hasta que la mayoría de los TPSP sean más precisos, los clientes que intenten demostrar su propio cumplimiento pueden ser prudentes a la hora de demostrar y documentar dónde termina su capacidad de influir en la seguridad, e intuitivamente, dónde se demuestra que el TPSP apoya o al menos no permite el acceso o los controles del cliente. No es una solución perfecta, pero es la única opción disponible actualmente para muchos clientes que dependen de la PCI.
Es una característica, no un error
Haciendo referencia al artículo de Chris "There All Along", yo llamo a esto el problema de la "falta de una única fuente de verdad". Por ejemplo, veo ciertos requisitos de información en una única plantilla de información, sólo en la DSS, sólo en una FAQ, o sólo en una plantilla OCR, pero de alguna manera no en la plantilla SAQ D.
El hecho de que la verdad pueda encontrarse en muchos lugares significa que, en el mejor de los casos, hay que buscar en todos los sitios posibles antes de sacar conclusiones. En el peor, significa sacar una conclusión errónea de una sola fuente cuando hay otras. Baste decir que tengo que llevar una lista de aparentes contradicciones en las diversas fuentes de ICP. Aunque muchos no aprecian el margen de maniobra que se da a las QSA a la hora de interpretar el alcance y los requisitos de la PCI, esta necesidad es tan frecuente que se considera una característica.
Límites del control de documentos
Si sigue sin haber claridad, la única opción del cliente puede ser probar y documentar sus limitaciones en términos de impacto sobre la seguridad de los datos de los titulares de tarjetas. Por ejemplo, si un procesador de pagos que almacena todos los datos de los titulares de tarjetas no afirma disponer de todos los controles lógicos de acceso a los datos almacenados, el cliente puede tener que hacer una lista de todos los usuarios y probar su capacidad para acceder o gestionar el acceso a los datos. Si no hay acceso a los datos almacenados, esto debe documentarse y se espera que los TPSP sean pronto más precisos y útiles en sus informes.
Referencia al objetivo del enfoque personalizado
Mi método más sencillo de interpretar los confusos controles DSS es leer el objetivo del enfoque adaptado. Si la entidad evaluada aborda el objetivo de forma exhaustiva, es probable que pueda demostrar que está cubierta. Por el contrario, si una entidad ha cumplido los requisitos de la PCI según el enfoque definido, pero no ha cumplido el objetivo del enfoque personalizado, es probable que no esté cumpliendo muchos de los demás requisitos. El objetivo del enfoque personalizado es la forma más sencilla de evitar interpretaciones erróneas.
Estimado lector, ¿coincide esto con su experiencia? Nuestros asesores pueden ayudarle en todas estas áreas, así que no dude en solicitar su ayuda.