Blog de Internet Security Auditors

Blog de Internet Security Auditors: 20 controles adicionales para optimizar los niveles de seguridad provistos por PCI DSS

Escrito por Internet Security Auditors | Sep 27, 2017 4:00:00 AM
Desde el 2006, el PCI SSC ha realizado un trabajo muy importante en cuanto a la estandarización de controles de seguridad para la protección de datos de tarjetas de pago. Sin embargo, esta labor es una carrera contra el tiempo: cada día aparecen nuevas vulnerabilidades y los controles de seguridad se quedan cortos si no se actualizan para gestionarlas. Prueba de ello fue la publicación adelantada (fuera del ciclo tradicional de 3 años ) de la versión 3.1 de PCI DSS en abril de 2015 para cubrir los problemas derivados de la masificación en la explotación de las vulnerabilidades CVE-2014-0160 (HEARTBLEED) y CVE-2014-3566 (POODLE).

Figura 1. Ciclo de vida de los estándares PCI DSS y PA DSS
Por otro lado, el impacto que implica un cambio en el estándar PCI DSS al agregar un nuevo control o modificar uno ya existente, deriva en inversión de tiempo y dinero en comercios y proveedores de servicio afectados, lo cual añade una capa adicional de complejidad para lograr que exista una protección efectiva en un corto plazo. Es por ello que cada cambio viene acompañado de un periodo de gracia para permitir la alineación del entorno con este nuevo cambio, tiempo que – a la larga – es una ventana de exposición en la cual se debe asumir el potencial riesgo al que esté expuesta la organización mientras que la aplicabilidad del control entra en vigencia.

Siendo así, son múltiples las variables que se deben tener en cuenta en el momento de actualizar estos estándares: complejidad técnica o física del nuevo control, impacto en la operación, cobertura generalista de los entornos afectados, compatibilidad con las plataformas de hardware y software, cambios en la cultura y el día a día del mantenimiento de los controles del estándar, resistencia al cambio por parte de las entidades afectadas, costes vinculados, etc.

Más allá de la seguridad provista actualmente en los entornos certificados en PCI DSS y sin ánimo de desmeritar el gran esfuerzo que el PCI SSC ha realizado todos estos años, a continuación se enumeran 20 controles de seguridad adicionales que minimizarían aún más el riesgo residual posterior a una implementación correcta del estándar. Esta lista ha sido elaborada con la experiencia de años de despliegue y auditoría de múltiples entornos de PCI DSS y se ofrecen como una guía de recomendaciones para aquellas empresas que quieren optimizar sus niveles de seguridad más allá de los estipulados en el estándar o incluso quieran emplear estos controles adicionales como parte de sus controles compensatorios en el caso de requerirlos.
  1. Búsqueda periódica de datos de tarjeta de pago almacenados en texto claro en medios de almacenamiento

    Uno de los objetivos principales de PCI DSS es la protección de los datos almacenados, gestionado en el requisito 3. Sin embargo, el estándar carece de un control que permita validar la efectividad de implementación de dichos controles, lo cual es una verdadera lástima ya que se permitiría la identificación preventiva y la activación de acciones correctivas del potencial problema, evitando la exposición a una exfiltración no controlada.

    En este caso, la idea sería que existiera un control que exigiera ejecutar de forma periódica una búsqueda de datos de tarjetas de pago que puedan estar almacenados de forma insegura en los medios de almacenamiento del entorno. En caso de identificarse alguno, significaría que los controles desplegados no son suficientes o no se encuentran correctamente implementados.

    A pesar de que este control no se encuentra en el estándar PCI DSS, sí que se encuentra en el Anexo A3: “Validación suplementaria de las entidades designadas (DES)”, solamente requerido para aquellas entidades designadas por una marca de pago o adquirente a la que le exigen una validación adicional de los requisitos de PCI DSS existentes.
  2. Uso de soluciones de prevención de pérdida de datos (“Data Loss Prevention” - DLP) para minimizar la exfiltración de datos por canales no autorizados

    Las soluciones de prevención de pérdida de datos permiten la monitorización, detección y bloqueo de información confidencial almacenada, procesada y/o transmitida, permitiendo controlar una potencial exfiltración causada por errores no intencionales o por acciones intencionales maliciosas. Este software se puede instalar a nivel perimetral o en estaciones de trabajo y servidores (“endpoint”).

    Con una instalación de solución de este estilo se reforzarían los controles procedimentales descritos en el req. 4.2 para evitar el envío de PAN no cifrados por medios de mensajería de usuario final (correo electrónico, mensajería instantánea, etc.) y el req. 12.3.10 para evitar que personal que tiene acceso remoto al entorno pueda copiar, mover y/o almacenar los datos del titular de la tarjeta en unidades de disco locales y/o en dispositivos electrónicos extraíbles y permitiría la identificación temprana de datos de tarjeta en canales no autorizados.
  3. Integración con otros estándares como PA y PTS (POI/HSM) para que los activos afectados dentro del alcance estén obligatoriamente certificados

    El PCI SSC ha publicado una serie de estándares adicionales a PCI DSS para cubrir otros elementos potencialmente susceptibles a incidentes con datos de tarjetas de pago:
    • PA DSS (Payment Application Data Security Standard), para aplicaciones de pago desarrolladas y licenciadas por terceros
    • PCI PTS (PIN Transaction Security) – POI (Point of Interaction), para la protección de datos de tarjetas en dispositivos de punto de interacción
    • PCI PTS (PIN Transaction Security) – PIN, para la protección del número de identificación personal (Personal Identification Number – PIN)
    • PCI HSM, para definir controles lógicos y físicos de seguridad para módulos de seguridad de hardware (Hardware Security Module – HSM), empleados para la protección de claves y procesos de encriptación.

    Cada uno de estos estándares es certificable para el elemento afectado.

    No obstante, al día de hoy no se exige explícitamente en el estándar PCI DSS que si dentro de un entorno existen terminales de pago (datafonos), dispositivos HSM o aplicaciones de pago de terceros, éstos tengan que estar certificados u homologados, lo cual desvirtúa de cierta manera la existencia de ese ecosistema de estándares.

    En términos ideales, cualquier componente que pueda ser afectado por un estándar del PCI SSC y que esté presente en un entorno de PCI DSS debería estar certificado u homologado para garantizar su correcta integración y el mantenimiento con los mismos niveles de riesgo de forma trasversal. El solo hecho de permitir la interacción con un componente ajeno a estos estándares puede abrir una brecha en la seguridad del entorno, implicando mayor esfuerzo por parte del comercio o proveedor de servicios afectado para mantener un nivel de riesgo aceptable. 
  4. Requerir escaneo antimalware a nivel perimetral

    El requerimiento 5 de PCI DSS exige que se implemente un software antimalware en todos los sistemas que se puedan ver afectados por software malicioso. Esto quiere decir que el control antimalware se realizará en el potencial elemento afectado. Sin embargo, este es un control tardío.

    En el mercado existen soluciones que permiten implementar las mismas técnicas antimalware en tráfico HTTP, SMTP, FTP e inclusive integrar las firmas y patrones heurísticos para la monitorización de tráfico de red como complemento a los sistemas de detección y prevención de intrusiones (IDS/IPS) descritos en el req. 11.4. Si esto se implementa, se lograría detectar y bloquear el software malicioso antes de que llegue a las estaciones de trabajo y/o servidores, complementando la seguridad antimalware en términos generales.
  5. Complementar los controles antimalware a nivel de sistema operativo agregando nuevas funcionalidades tales como DEP, ASRL, etc.

    A pesar de que muy seguramente este punto puede ser cubierto por la implementación correcta del req. 2.2 en el proceso de configuración segura de sistemas operativos, estaría muy bien que PCI DSS exigiera el despliegue de controles de seguridad adicionales, tales como Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR) y Structured Exception Handling Overwrite Protection (SEHOP), entre otros, dentro de las actividades de securización de plataformas operativas.

    De esta manera se complementaría la seguridad provista por la protección antimalware con configuraciones adicionales a nivel de sistema operativo para prevenir ataques de desbordamiento de buffer (buffer overflow) y ejecución de código arbitrario empleados por exploits.
  6. Definición de controles de protección en redes virtuales y/o definidas por software (SDN)

    El requisito 1 de PCI DSS describe los controles a ser implementados para la protección del entorno de red, haciendo énfasis en el uso de firewalls y enrutadores. Sin embargo, este requisito está muy orientado a su implementación en redes y arquitecturas tradicionales.

    Sin embargo, con la llegada de la virtualización, los equipos activos de red también han sido afectados, siendo remplazados por sus contrapartes virtuales (virtual switch, virtual firewall, etc.), tecnologías que suelen ser olvidadas en el proceso de despliegue de controles de PCI DSS al no estar citadas de forma explícita.

    Siendo así, una revisión del requisito 1 complementándolo con acciones de securización de elementos de red virtualizados sería una muy buena opción y alinearía dichos controles con estas tecnologías.
  7. Requerir de soluciones de filtrado de paquetes a nivel de host

    Siguiendo con el requisito 1, PCI DSS establece controles de filtrado a nivel de red entre diferentes segmentos. Solamente se exige un filtrado de paquetes a nivel de host (firewall personal) en aquellas estaciones que se conectan de forma remota al entorno (req. 1.4).

    No obstante, una muy buena alternativa para complementar la seguridad de filtrado a nivel perimetral sería la de requerir el despliegue de una solución de filtrado de paquetes a nivel de host. De esta forma, se reforzarían los controles de securización del requisito 2.2.2 en servicios, protocolos y daemons y se limitaría el potencial impacto en el caso de un error en las reglas de filtrado perimetral revisadas únicamente cada seis meses (req. 1.1.7), aplicando el concepto de defensa en profundidad. 
  8. Requerir cifrado a nivel de canal dentro del entorno de cumplimiento

    Uno de los controles más controvertidos de PCI DSS es el del cifrado de los canales de comunicación dentro del entorno de cumplimiento. Solamente se exige en el caso de acceso administrativo que no sea de consola (req. 2.3), permitiendo que tráfico que pueda contener datos de tarjetas de pago pueda ser transmitido sin cifrar dentro del entorno.

    La implementación del cifrado de comunicaciones dentro del entorno permitiría que toda la comunicación interna fuese punto a punto, eliminando potenciales riesgos derivados de la interceptación no autorizada de tráfico y previniendo que los equipos activos de red a nivel interno tengan acceso a los datos en claro evitando su almacenamiento en ficheros de log, depuración, etc. Esto se puede lograr de una manera muy fácil empleando los componentes nativos de IPSEC en sistemas operativos, empleando los controles de cifrado de tráfico de las propias aplicaciones (bases de datos, por ejemplo) o a través de técnicas de tunelización de tráfico vía TLS o SSH, por ejemplo. El impacto sería mínimo y la ganancia en términos de seguridad sería tangible inmediatamente.

  9. Definir controles para la gestión de nombres de dominio (DNS) tanto a nivel externo como interno

    Uno de los elementos “huérfanos” en PCI DSS es el sistema de resolución de nombres (Domain Name System – DNS). Lo ideal sería que existiese un control específico - al igual que sucede con la sincronización de tiempo descrita en el req. 10.4 - en el cual se describan los controles que se deben aplicar a este servicio en un entorno PCI DSS, incluyendo la definición de un servidor DNS central interno, la gestión de consultas con DNS raíz externos “confiables” y las consideraciones de seguridad adicionales (como DNSSEC) que podrían desplegarse para robustecer la seguridad de este servicio y evitar ataques de tipo “pharming”.

    Actualmente, este servicio estaría cubierto de forma general por el req. 2, aunque – como se puede ver – la necesidad de un control específico estaría más que justificada.

    Igualmente, tampoco se especifican controles de seguridad de resolución de nombres a nivel externo. Por ejemplo: Una empresa de comercio electrónico que cuenta con un sitio web y ha registrado un dominio a su nombre. Ese dominio (que directamente redirecciona todo el tráfico de la transacción de un cliente a una dirección IP en particular) puede estar registrado en una empresa (registrador de dominios) con un nivel de seguridad deficiente, con lo cual un atacante no tendría que vulnerar los sistemas del entorno PCI DSS sino simplemente focalizarse en atacar a ese proveedor, cambiar el registro DNS a otra dirección IP bajo su control y hacerse a todo el tráfico de tarjetas de ese comercio electrónico. Es por ello que al igual que otros proveedores de servicio, los proveedores de registro de nombres de dominio deberían cumplir y estar certificados por PCI DSS para garantizar una seguridad en toda la cadena transaccional.
  10. Establecer controles de seguridad para DHCP

    Otro “huérfano” en términos de controles de PCI DSS es el servicio de configuración dinámica de host (Dynamic Host Configuration Protocol – DHCP). Al igual que como se sucede con NTP y como se justificó con DNS, en el caso que se emplee DHCP en la red de PCI DSS se deberían establecer los patrones de configuración y sus limitaciones de ámbito para evitar que equipos no autorizados puedan obtener toda la información de direccionamiento y enrutamiento del entorno al conectarse.

    Igualmente, estaría cubierto actualmente por el req. 2 pero un control específico no estaría mal.

  11. Definir controles para la gestión de certificados digitales empleados en comunicaciones HTTPS (y otros elementos en los cuales pudieran usarse)

    El requerimiento 4 de PCI DSS establece la necesidad de asegurar los canales de comunicación con redes públicas abiertas, exigiendo que si se usa TLS los certificados digitales empleados sean “de confianza”.

    Sin embargo, no se cuenta con ningún control para la protección de dichos certificados. No se indica cómo se deben almacenar, si deben ser protegidos con un passphrase, los roles y responsabilidades de quienes puedan gestionarlos, los controles en su ciclo de vida, etc. Es decir: se cuenta con controles para garantizar la seguridad del tráfico empleando certificados digitales, pero no del proceso para implementar dicha securización.

    Por otro lado, si se emplean certificados digitales en otros flujos dentro del entorno PCI DSS, tampoco se indica cómo se gestionarán, lo cual puede exponer a la organización a un potencial problema al no estar formalizado este proceso.
  12. Controles adicionales a estaciones con conexión remota y uso de servidores de salto

    Las estaciones que cuentan con acceso remoto al entorno de PCI DSS deben cumplir con varios controles: Tener un firewall personal (req. 1.4) y usar autenticación multifactor (req. 8.3). Sin embargo, no se indica cómo se puede garantizar que la estación que se conecta cumpla con los niveles de seguridad del entorno en términos de actualizaciones de seguridad, actualización de patrones antivirus, controles de acceso, etc. exponiendo al entorno a que, si una estación remota está infectada o comprometida, dicho compromiso podría ampliarse al resto del entorno si la conexión se autoriza. Esto aplica no solamente a ordenadores sino también a dispositivos móviles que se permitan en el entorno.

    De acuerdo con esto, una estrategia sería el uso de control de acceso a la red (Network Access Control – NAC). Mediante la implementación de una tecnología de estas características se permitiría garantizar que los equipos que se conecten cumplan con las políticas del resto del entorno, estén actualizadas y que la estación en sí sea autenticada. Si no, la estación afectada se aísla o se limita su conexión hasta que no esté alineada con los requerimientos de la red.

    Igualmente, se debería requerir de forma obligatoria el uso de un servidor bastión o de salto (jump station) para conexiones remotas administrativas. Este servidor recibiría y centralizaría todo este tráfico hacia el entorno de cumplimiento, evitando exponer las diferentes consolas administrativas, registrando con detalle todos los saltos a equipos internos y aplicando controles de acceso puntuales posteriores a la autenticación del usuario.
  13. Requerir obligatoriamente el uso de salts en operaciones de hash para la protección de datos de tarjeta de pago almacenados

    Ya es bien sabido por todo el personal de seguridad de la información que uno de los principales ataques contra las funciones hash es el uso de “tablas arcoíris” (rainbow tables), que permiten identificar el dato que generó determinado hash mediante la comparación con tablas de valores precomputados. Teniendo presente que el formato del PAN es conocido de antemano (entre 13 y 16 dígitos con los 6 primeros dígitos en claro (BIN/IIN) y el último dígito determinista), cuesta muy poco esfuerzo con la capacidad de cómputo actual generar una tabla precomputada para tales valores. Con este riesgo en mente, se hace obligatorio el uso de valores de tipo salt (valor pseudoaleatorio que se concatena al dato a proteger antes de obtener su hash) que compliquen aún más la obtención de un PAN desde su hash si se emplea esta técnica para la protección de los datos almacenados (req. 3.4).

    Actualmente, el uso de salts es solamente una recomendación y su uso es discrecional.
  14. Complementar los controles de diagramas de red requiriendo la descripción de direcciones IP / hostnames

    Los requisitos 1.1.2 y 1.1.3 de PCI DSS especifican la necesidad de mantener un diagrama de red y un diagrama de flujo actualizados. Sin embargo, no se exige mayor detalle en estos diagramas, lo cual puede dejar incompleto el objetivo de los requisitos, que es el de identificar de forma clara la ubicación de los componentes del entorno.

    Si dichos requisitos se complementan exigiendo el detalle de direccionamiento IP y hostnames, el entendimiento y comprensión de los diagramas será más fácil y se podrá integrar de una forma más sencilla con el inventario de activos del requisito 2.4.
  15. Complementar el detalle requerido en el inventario de activos del entorno

    El requisito 2.4 pide mantener un inventario de activos del entorno. Sin embargo, no entra en mayor detalle de lo que debe contener más allá del hardware y software y una descripción de la función/uso de cada componente. Como tal, este requisito se queda corto en la cantidad de información y la utilidad que proporciona.

    Una alternativa sería exigir una “Cardholder Data Matrix” (CHDM) en toda regla.  El concepto de CHDM va mucho más allá de un simple listado y permite centralizar en un único documento toda la información de los activos del entorno, proporcionando una visión completa del alcance.

    Esta CHDM debería contener la siguiente información detallada (que de por sí ya se requiere en diferentes partes del estándar):
    • Personal vinculado con el entorno
    • Aplicaciones
    • Servidores y estaciones de trabajo
    • Equipos de red y seguridad perimetral
    • Soportes (CD, papel, etc.)- Req. 9.7.1
    • Canales de comunicación y redes
    • Instalaciones físicas
    • Listado de terceros (Proveedores) – Req. 12.8.1
    • Ubicación datos PCI DSS – Req. 3.1
    • Claves de cifrado – Req. 3.5.1 (actualmente sólo requerido para proveedores de servicio)
    • Documentación
  16. Protección a nivel de memoria física, virtual y swap

    El gran talón de Aquiles de las técnicas de criptografía simétrica y asimétrica es el uso de memoria intermedia para el almacenamiento temporal de claves, datos a encriptar en claro, contraseñas, passphrases, etc. mientras que se realizan las operaciones de encriptación y desencriptación. El requerimiento 3 de PCI DSS describe los controles de encriptación en el almacenamiento de datos, mientras que el requerimiento 4 hace lo propio con los controles en la transmisión de datos.

    Si se parte de la premisa que PCI DSS se debe aplicar en el almacenamiento, transmisión y procesamiento de datos, ¿qué pasa con los controles orientados a la protección de los datos en memoria intermedia (RAM, memoria virtual y swap), empleada en el procesamiento? A hoy, no hay ninguna referencia en el estándar. No obstante, existe una FAQ (1042)  que habla de ello:
    “ .. If the cardholder data is stored in non-persistent memory (e.g. RAM), encryption of cardholder data is not required. However, proper controls must be in place to ensure that memory maintains a non-persistent state. For example, if the memory is being written to a file, then appropriate PCI DSS requirements are applicable to that file. Where appropriate, this data should be securely purged as soon as possible - for example, from swap files and temporary folders…”
    Actualmente, existen diferentes herramientas nativas en la gran mayoría de sistemas operativos que permiten realizar encriptación de las áreas de paginación (swap) y de ficheros de hibernación/suspensión, así como controles de acceso restrictivos a nivel de memoria RAM para prevenir volcados de la misma y ataques con malware del tipo “RAM scraping” , que deberían ser contemplados en el estándar.
  17. Requerir una formación específica para operadores y administradores de la plataforma

    El requisito 12.6 de PCI DSS exige una formación general de concienciación sobre seguridad en el momento de la contratación y por lo menos de forma anual para los empleados del entorno. Yendo más allá, el requisito 6.5 pide una formación específica anual para desarrolladores y el requisito 12.10.4 para el personal vinculado al proceso de respuesta a incidentes. Siendo así, ¿por qué no exigir una formación específica en PCI DSS para operadores y administradores de la plataforma? Para este personal, no es suficiente una formación general, es indispensable una formación focalizada que permita garantizar que existe un conocimiento pleno del estándar en las labores del día a día.
  18. Definición de controles para la gestión de autenticación de aplicaciones

    El requisito 8 de PCI DSS contiene una serie de controles para la gestión del proceso de autenticación de usuarios interactivos (es decir: que tienen a un humano por detrás). Sin embargo, ¿cómo se debe proceder con las cuentas de aplicación (aquellas cuentas que permiten que dos o más aplicaciones se autentiquen mutuamente sin interacción humana)? La ausencia de un control específico para la gestión de este tipo de cuentas – que por lo general cuentan con altos privilegios - podría permitir que un potencial atacante acceda de forma no autorizada al entorno, ya que sus niveles de seguridad no suelen ser tan robustos como en cuentas interactivas.

    En este caso, se requeriría definir una persona o rol responsable de esas cuentas, establecer controles de seguridad apropiados a las mismas (teniendo presente que si se usan contraseñas éstas no se pueden cambiar de forma periódica, que no se puede agregar autenticación multifactor, que un bloqueo de esta cuenta por accesos erróneos puede implicar una parada crítica en la operación del entorno, que la credencial de autenticación debe estar almacenada y disponible en algún lugar por la aplicación y que no se puede cambiar después del primer uso) y hacerles seguimiento de forma continua.
  19. Nombramiento de un responsable de PCI DSS en la organización

    La implementación y mantenimiento de PCI DSS en una empresa es un proyecto en sí, con sus restricciones en términos de tiempo, alcance y costes. Además, se trata de un proyecto trasversal a las áreas afectadas, que requiere para su correcta gestión un responsable que asuma el cargo de similar al de un gestor de proyecto (“Project Manager”).

    Los requisitos 12.4 y 12.5 requieren la asignación de responsabilidades para ciertas acciones (políticas, monitorización de alertas, respuesta a incidentes, gestión de cuentas y acceso a datos). Sin embargo, la asignación de un rol para la gestión general de PCI DSS solamente se exige a proveedores de servicio (req. 12.4.1) y a entidades designadas (A3.1.1).

    En este caso, la idea sería que el mismo requisito cubriera también a los comercios, lo que permitiría que estas entidades contaran con un responsable de PCI DSS a nivel general, el cual velaría por el soporte de la Dirección y el seguimiento general del cumplimiento del estándar.

  20. Alineación de PCI DSS con otras normativas de protección de datos de carácter personal

    De acuerdo con la ISO/IEC 29100:2011 (Information technology -- Security techniques -- Privacy framework), el Número Primario de Cuenta (PAN – Primary Account Number) se puede catalogar como Información de Identificación Personal (PII – Personally Identifiable Information), ya que se trata de un identificador que se puede relacionar con una persona natural. De acuerdo con ello, se deberían generar políticas orientadas al usuario final (al titular de tarjeta) para que cuente con toda la información necesaria para ejercer control sobre sus propios datos, delegados al comercio o al proveedor de servicio para la ejecución de la transacción.
Figura 2. Principios de protección de privacidad de ISO/IEC 29100:2011

Este nuevo conjunto de controles entraría a complementar los acuerdos contractuales de la organización con sus proveedores de servicio (req. 12.8.2) y de los proveedores con sus clientes (req. 12.9), agregando responsabilidades entre la entidad y los titulares de tarjetas.

Conclusión
El estándar PCI DSS (en su versión 3.2 en el momento de la publicación de este artículo) ha permitido que los comercios y los proveedores de servicio que hacen uso de datos de tarjetas de pago puedan gestionar de una forma tolerable el riesgo derivado del almacenamiento, procesamiento y transmisión de esta información. Al tener que ser implementado en diferentes entornos tecnológicos y arquitecturas, la definición y redacción de sus controles ha sido bastante generalista, lo cual implica que el riesgo residual puede llegar a ser bastante significativo en función del escenario en el que se aplique.

Para complementar los controles “base” incluidos en PCI DSS se pueden usar controles adicionales como los descritos en este artículo. Si bien se trata de meras recomendaciones, si se incluyeran dentro de PCI DSS harían de este estándar una versión “con esteroides”.

Obviamente, la lista de estos controles adicionales no es exhaustiva, ya que la seguridad no es perfecta y siempre habrá cabida a mejoras. Siendo así, ¿se te ocurren otros controles que puedan mejorar los niveles de seguridad provistos por PCI DSS?

Autor: David Eduardo Acosta - CISSP Instructor, CISM, CISA, CRISC, CHFI Instructor, CEH, PCI QSA, OPST, BS25999 L. A. 
Dpto. Consultoría 
Ver post completo