Requisitos documentales de PCI DSS

Es muy frecuente que, cuando una organización se enfrenta al reto de implantar el cumplimiento con el estándar PCI DSS, se centre en los aspectos tecnológicos y se deje en segundo plano los aspectos puramente documentales o procedimentales. Sin embargo, si queremos cumplir con el estándar, y si queremos que un auditor QSA certifique que alcanzamos dicho cumplimiento, es indispensable cumplir también con todos los requisitos documentales del estándar.

¿Y cuales son dichos requisitos documentales? Pues vamos a verlos a continuación. Antes sin embargo, advertir que la agrupación en la que los recojo es una propuesta personal y que podrían agruparse de diferente manera sin ningún problema. Lo importante es que todos los requisitos documentales del estándar se cumplan y se recojan en alguna política, normativa o procedimiento:

1. Política de Seguridad de la Información:

a. Debe publicarse y distribuirse a todos los usuarios, incluidos proveedores, partners y contratistas.

b. Debe hacer referencia a todos los requisitos de la PCI DSS:

• Instalación y mantenimiento de la configuración de firewalls para la protección de los datos.
• No empleo de contraseñas y otros parámetros de seguridad establecidas por defecto por los proveedores.
• Protección de los datos almacenados.
• Cifrado de la transmisión de la información del titular de tarjetas e información sensible a través de redes públicas.
• Empleo y actualización periódica de programas y software antivirus.
• Desarrollo y mantenimiento de sistemas y aplicaciones seguros.
• Restricción del acceso a los datos en función de la necesidad de conocer (con base en el negocio).
• Asignación de un identificador único para todas las personas con acceso al sistema.
• Restricción del acceso físico a los datos de titulares de tarjetas.
• Revisión y monitorización de todos los accesos a los recursos de red y a los datos de titulares de tarjetas.
• Prueba periódica de la seguridad de los sistemas y los procesos.
• Mantenimiento de una política que contemple la seguridad de la información para los empleados y contratistas.

c. Debe documentar un proceso anual de evaluación de riesgos que identifique las amenazas, vulnerabilidades produzca como resultado una evaluación formal de riesgos. (Ejemplos de metodologías de evaluación de riesgos incluyen, pero no están limitados a: OCTAVE, ISO 27005 y NIST SP 800-30.)

d. La política debe revisarse y en caso necesario actualizarse con carácter anual de manera que refleje los cambios en los objetivos del negocio o el entorno de riesgos.

2. Normativa de Roles y Responsabilidades de Seguridad de la Información:

a. Debe definir claramente la responsabilidad de todos los empleados en lo que a Seguridad de la Información se refiere.

b. Debe asignar formalmente la responsabilidad sobre la seguridad de la información a un Jefe de seguridad u otro miembro de la gerencia relacionado con la seguridad.

c. Debe asignar formalmente la responsabilidad de crear, mantener y distribuir procedimientos de respuesta y escalado ante incidentes de seguridad.

d. Debe asignar formalmente la responsabilidad de supervisar y analizar las alertas de seguridad, así como su pertinente escalado.

e. Debe asignar formalmente la responsabilidad de administración de cuentas y gestión de autenticación.

f. Debe asignar formalmente la responsabilidad de supervisar y controlar todos los accesos a los datos.

3. Normativa de configuración de los firewalls y los routers:

a. Proceso formal para probar y aprobar todos los cambios y las conexiones de red en la configuración de los firewalls y de los routers.

b. Obligación de tener un firewall en cada conexión a Internet y entre cualquier DMZ y la zona de la red interna.

c. Descripción de grupos, roles y responsabilidades para una administración lógica de los componentes de la red.

d. Procedimentar la revisión de los conjuntos de reglas existentes al menos cada seis meses.

e. Anexo que incluya una lista de servicios, protocolos y puertos necesarios para las operaciones.

f. En caso de que existan servicios, protocolos y puertos no seguros permitidos (por ejemplo FTP, Telnet, POP3, IMAP, etc..) documentar que medidas de seguridad existen para asegurar dichos protocolos, servicios o puertos.

4. Normativas de configuración de sistemas:

a. Deben generarse para cada distribución o tipología de sistema operativo.

b. Deben estar basadas en buenas prácticas de la industria (CIS, ISO, SANS, NIST, etc..).

c. Deben aplicarse al configurar nuevos sistemas antes de su puesta en producción.

d. Las normativas deben recoger la configuración de seguridad que debe implementarse en cada tipología de sistema.

e. Deben obligar a documentar y justificar para cada servidor los servicios, daemons o protocolos habilitados.

f. Deben obligar a documentar cual es la función principal de cada servidor

5. Normativa de retención y disposición de datos de titulares de tarjeta:

a. Debe documentarse todas las localizaciones en las que se están guardando los datos de titulares de tarjeta.

b. Debe documentar los requisitos legales, reglamentarios y del negocio relativos a la retención de los datos, incluidos los requisitos específicos para la retención de datos de titulares de tarjetas (por ejemplo, es necesario guardar los datos de titulares de tarjetas durante X tiempo por Y razones de negocio).

c. Debe documentarse que proceso, automático o manual, se lleva a cabo de manera trimestral para identificar y eliminar de manera segura los datos de titulares de tarjetas almacenados que excedan los requisitos de retención definidos.

d. Debe documentar qué proceso se lleva a cabo para la recepción, el tratamiento y la eliminación segura de los datos de autenticación confidenciales (CVV)

e. Debe exigir que que los números de tarjeta (PAN) se oculten (los primeros seis y los últimos cuatro dígitos es la cantidad máxima de dígitos que pueden aparecer) al visualizar los datos de los titulares de las tarjetas, excepto en los casos en que existe una necesidad comercial legítima de visualizar el PAN completo.

6. Procedimientos de Gestión de Claves criptográficas:

a. El alcance de este procedimiento debe incluir todas las claves usadas para el cifrado de datos de tarjeta.

b. Debe requerir el uso de claves sólidas.

c. Debe detallarse como se realiza la distribución segura de las claves.

d. Debe detallarse como se procede a almacenar de manera segura las claves.

e. Debe establecerse el periodo de validez de las claves (máximo 2 años) y debe documentarse el procedimiento para cambiar la clave una vez agotado dicho periodo.

f. Debe establecerse el procedimiento a seguir para reemplazar las claves en caso de haberse debilitado la integridad de las mismas o en el caso de que se sospeche que exista riesgo de compromiso de las claves.

g. El procedimiento para el cambio de claves debe garantizar que las claves sustituidas no sigan siendo utilizadas por las aplicaciones para el cifrado.

h. Si se utilizan operaciones manuales de gestión de claves criptográficas en texto claro, estas operaciones deben aplicar conocimiento dividido y control doble (por ejemplo, utilizando dos o tres personas, cada una de las cuales conoce su propia parte de la clave, para reconstruir toda la clave).

i. Debe documentarse los mecanismos existentes destinados a prevenir la sustitución no autorizada de claves.

j. El procedimiento debe exigir que los custodios de claves declaren (por escrito o electrónicamente) que comprenden y aceptan sus responsabilidades como custodios de claves.

7. Normativa de uso aceptable de los sistemas:

a. Se debe prohibir explícitamente el envío del PAN no cifrados por medio de tecnologías de mensajería de usuario final (por ejemplo, el correo electrónico, la mensajería instantánea, el chat, etc.).

b. Se deben detallar cuáles son los usos aceptables para cada tecnología y cuáles son las acciones explícitamente prohibidas.

c. Política de utilización para tecnologías críticas para empleados (por ejemplo, tecnologías de acceso remoto, tecnologías inalámbricas, dispositivos electrónicos extraíbles, computadoras portátiles, asistentes digitales/para datos personales [PDA], utilización del correo electrónico y de Internet) para definir el uso adecuado de dichas tecnologías. Esta política debe incluir:

• Requerir la aprobación explícita de la gerencia para utilizar las tecnologías.
• Todo uso de este tipo de tecnologías se autentique con ID de usuario y contraseña, u otro elemento de autenticación (por ejemplo, token).
• Mantener un listado de todos los dispositivos y personal autorizado para utilizar los dispositivos.
• Requerir el etiquetado de los dispositivos con propietario, información de contacto y objetivo.

d. Se deben incluir ubicaciones aceptables para el uso de las tecnologías de red

e. Mantener un listado del software autorizado por la empresa y prohibir explícitamente la instalación y uso del software no incluido en el mismo.

f. Debe requerir la desconexión automática de sesiones para tecnologías de acceso remoto después de un período específico de inactividad.

g. Debe requerir la activación de tecnologías de acceso remoto para proveedores y socios de negocios sólo cuando éstos lo requieran, con desactivación automática después de la utilización.

h. Debe prohibir copiar, mover o almacenar datos de titulares de tarjetas en unidades de disco locales y dispositivos electrónicos extraíbles al acceder a dichos datos a través de tecnologías de acceso remoto. (o directamente prohibir el acceder a estos datos mediante este tipo de tecnologías si no está justificado por motivos de negocio).

8. Procedimiento de gestión de cambios:

a. Debe exigir la instalación de todos los nuevos parches de seguridad relevantes dentro de un plazo de un mes.

b. Debe detallar como se realizan las pruebas previas a la instalación de los parches y cómo se procede a la instalación definitiva de los mismos.

c. El registro de cada cambio debe incluir toda la documentación que pueda ser relevane para el cambio.

d. El cambio debe ser aprobado por el responsable designado, y la aprobación debe adjuntarse a la documentación generada por el cambio.

e. Todos los cambios deben probarse antes de su puesta en producción.

f. En el caso de que el cambio incluya la puesta en producción de un nuevo software desarrollado internamente deberá garantizarse que se ha cumplido con la normativa de desarrollo de software

g. Todo cambio debe incluir el procedimiento de marcha atrás asociado.

9. Procedimiento de identificación de nuevas vulnerabilidades:

a. Debe definir los procesos seguidos para identificar nuevas vulnerabilidades de seguridad, y que se haya asignado una clasificación de riesgo a esas vulnerabilidades. (Como mínimo, las vulnerabilidades más críticas que representen los riesgos más altos se deben clasificar como “Alto”.)

b. Debe incluir y detallar el uso de fuentes externas de información sobre vulnerabilidades de seguridad.

10. Normativa de desarrollo de software:

a. Debe basarse en buenas prácticas de la industria (como por ejemplo, modelo en cascada, Incremental, Espiral, Agile, RAD, etc.)

b. Debe incorporar la seguridad en todo el ciclo de vida del desarrollo de software.

c. Debe garantizar que las cuentas, los ID de usuario y las contraseñas personalizadas de la aplicación se eliminan antes de activar los sistemas de producción o de que se pongan a disposición de los clientes.

d. Debe obligar a que el código sea revisado por un experto en técnicas de revisión de código ajeno al equipo de desarrollo después de cada cambio.

e. Debe indicar el procedimiento seguido para las revisiones. Éstas deben garantizar que no puedan existir las siguientes vulnerabilidades:

• Errores de inyección, en especial, errores de inyección SQL. (valide la entrada para verificar que los datos de usuario no pueden modificar el significado de los comandos y las consultas, utilice las consultas basadas en parámetros, etc.).
• Desbordamiento de buffer (validar límites del buffer y truncar cadenas de entrada).
• Almacenamiento cifrado inseguro (prevenir defectos de cifrado).
• Comunicaciones inseguras (cifrar adecuadamente todas las comunicaciones autenticadas y confidenciales).
• Manejo inadecuado de errores (no permitir que se filtre información a través de mensajes de error)
• Todas las vulnerabilidades altas identificadas según el Procedimiento de identificación de nuevas vulnerabilidades

f. Adicionalmente, en el caso de las aplicaciones web se debe revisar también:

• Lenguaje de comandos entre distinto sitios (XSS) (valide todos los parámetros antes de la inclusión, utilice técnicas de escape sensibles al contexto, etc.).
• Control de acceso inapropiado tal como referencias no seguras a objetos directos, no restricción de acceso a URL y exposición completa de los directorios (Autentique usuarios de forma correcta y desinfecte entradas. No exponga referencias a objetos internos a usuarios).
• Falsificación de solicitudes entre distintos sitios (CSRF). (No confíe en las credenciales de autorización ni en los tokens que los exploradores presentan automáticamente).

g. Las correcciones pertinentes se deben realizar antes de la puesta en producción de la aplicación.

h. El responsable designado debe revisar y aprobar los resultados de las pruebas antes de la puesta en producción de la aplicación.

i. La normativa debe exigir la capacitación acerca de las técnicas de codificación segura para los desarrolladores, que esté basada en las mejores prácticas de la industria.

11. Normativa de control de acceso lógico:

a. Los derechos de acceso a ID de usuarios privilegiadas se restrinjan a la menor cantidad de privilegios necesarios para cumplir con las responsabilidades del cargo.

b. Los privilegios se asignen a los individuos sobre la base de la clasificación y la función de su cargo.

c. Se debe requerir aprobación documentada de partes autorizadas (por escrito o electrónicamente) para toda asignación de ID de usuario, y que se deben especificar los privilegios requeridos. (Formulario de autorización de ID).

d. Debe exigir que los controles de acceso se implementen a través de un sistema de control de acceso automático.

e. Se debe documentar el procedimiento seguido para el restablecimiento de las contraseñas en caso de bloqueo. Este documento debe garantizar la identidad del usuario antes de proceder a dicho restablecimiento.

f. Se debe documentar el procedimiento seguido para generar una nueva contraseña a un usuario. Este procedimiento debe obligar a que el usuario cambie la nueva contraseña en su primer acceso.

g. Se debe recoger el procedimiento de baja de usuarios, y debe especificar que en caso de que un usuario cause baja de una empresa, se eliminarán de inmediato sus derechos de acceso a los sistemas.

h. Se debe documentar el procedimiento establecido en virtud del cual se inhabilitan o eliminan las cuentas que hayan permanecido inactivas durante 90 días.

i. Se debe recoger en esta normativa que sólo se habilitarán los accesos VPN para los proveedores el tiempo que sea estrictamente necesario, y que se registrarán y controlarán sus acciones durante dicho periodo.

j. Se deben prohibir el uso de cuentas o contraseñas de grupos, compartidas o genéricas.

k. La normativa debe establecer la siguiente política de contraseñas:

• Cambio de contraseñas cada 90 días como máximo.
• Longitud mínima de 7 caracteres.
• Las contraseñas deben contener caracteres numéricos y caracteres alfabéticos
• No se debe poder repetir las últimas 4 contraseñas usadas
• Se debe bloquear una ID si ha fallado su contraseña, como máximo, 6 veces seguidas. El desbloqueo debe ser hecho por un administrador o bien de manera automática tras 30 minutos de bloqueo.
• La sesión se debe bloquear automáticamente tras 15 minutos de inactividad y solicitar nuevamente la contraseña.

l. Se debe exigir que todas las bases de datos que contengan datos de titulares de tarjeta cuenten con su propio control de acceso no delegado en el del sistema operativo.

m. Sólo los DBA deben poder lanzar querys sobre las bases de datos.

12. Normativa de control de acceso físico:

a. Debe incluir la asignación de de placas de identificación a los empleados, y a visitantes, incluyendo lo siguiente:

• Asignación de placas de identificación.
• Cambio de requisitos de acceso
• Revocación de placas de identificación de personal local cesante y de visitante vencidas

b. El acceso al sistema de placas de identificación esté limitado al personal autorizado.

c. Las placas deben identificar claramente a los visitantes y han de ser fáciles de distinguir respecto a las placas del personal local.

d. Se debe incluir el procedimiento para el trato a los visitantes que debe contemplar:

• Se les debe asignar placas de identificación como visitantes.
• Estas placas no han de permitir el acceso a las localizaciones donde se guardan datos de titulares de tarjeta.
• Se debe obligar a las visitas a devolver las placas cuando abandonen las dependencias de la organización.
• Se debe mantener un registro de visitas en uso para registrar el acceso físico a las instalaciones de la empresa, así como también a las salas de informática y los centros de datos donde se guardan o se transmiten los datos de titulares de tarjetas. El registro debe incluir el nombre del visitante, la empresa a la que representa y el empleado que autoriza el acceso físico en el registro. Se debe conservar este registro durante un mes.

e. Se deben documentar todas las medidas de seguridad existentes para garantizar la protección física de medios (por ejemplo computadoras, dispositivos electrónicos extraíbles, recibos e informes en papel y faxes).

f. Documentar una política para controlar la distribución de medios que contengan datos de titulares de tarjetas:

• Todos los medios se deben clasificar de manera que la sensibilidad de los datos se pueda determinar.
• Todos los medios enviados fuera de la empresa deben ser registrados y contar con la autorización expresa de la gerencia
• Se deben enviar mediante correo certificado u otro método de envío que se pueda rastrear.
• Documentar el procedimiento para el almacenamiento seguro y mantenimiento de todos los medios.
• Requerir inventarios periódicos (anuales) de medios.
• Documentar el procedimiento seguido para la destrucción segura de medios:
  • Corte en tiras, incinere o haga pasta los materiales de copias en papel para que no se puedan reconstruir los datos de titulares de tarjetas.
  • En el caso de dispositivos electrónicos, garantizar que los datos sean irrecuperables y se entreguen mediante un programa con la función de borrado seguro de acuerdo con las normas aceptadas en la industria para lograr una eliminación segura, o bien destruya los medios de forma física (por ejemplo, degaussing o destrucción magnética).

13. Normativa de gestión de logs:

a. Debe obligar a recoger logs de seguridad de todos los sistemas y dispositivos incluidos en el alcance PCI DSS.

b. Debe incluir el procedimiento seguido para la revisión de registros de seguridad al menos una vez al día y requerir el seguimiento de las excepciones.

c. Debe obligar a retener los logs durante 1 año disponiendo de los últimos 3 meses para su consulta inmediata.

14. Plan de auditorías y revisiones periódicas:

a. Procedimiento trimestral para la detección de puntos de acceso inalámbrico no autorizados en las oficinas y en el datacenter:

• Debe ser capaz de detectar e identificar tarjetas WLAN insertadas en los sistemas.
• Debe ser capaz de detectar e identificar dispositivos inalámbricos conectados en los sistemas.
• Debe ser capaz de detectar e identificar dispositivos inalámbricos conectados a un puerto o dispositivo de red.

b. Escaneos internos de vulnerabilidad:

• Trimestrales.
• Después de cada cambio relevante en la infraestructura.
• Se solucionan todas las vulnerabilidades con un riesgo alto.

c. Escaneos externos de vulnerabilidad:

• Trimestrales.
• Después de cada cambio relevante en la infraestructura.
• Se solucionan todas las vulnerabilidades con un riesgo alto.
• Los realiza una tercera empresa certificada por el PCI Council como ASV.

d. Pentesting:

• A nivel de red y a nivel de aplicación.
• Externo e interno.
• Anuales o después de cualquier cambio significativo en la infraestructura IT.

e. Auditoría de aplicación web:

• Sólo en caso de no disponer de un Firewall de aplicación.
• Realizar una auditoría en tiempo de ejecución (no de código) con carácter anual de las aplicaciones web incluidas en el alcance PCI DSS.
• Realizar una auditoría en tiempo de ejecución (no de código) después de cualquier cambio en las aplicaciones web incluidas en el alcance PCI DSS.

15. Programa formal de concienciación en seguridad:

a. Debe incluir a todos los empleados

b. Debe proporcionar diversos métodos para informar y educar a los empleados en lo relativo a la concienciación (por ejemplo, carteles, cartas, notas, capacitación basada en Web, reuniones y promociones).

c. Los empleados deben recibir la capacitación sobre concienciación al ser contratados y al menos una vez al año.

d. El programa debe exigir a los empleados que reconozcan, por escrito o de forma electrónica, al menos una vez al año haber leído y entendido la política de seguridad de la información de la empresa.

16. Programa para supervisar el estado de cumplimiento con PCI DSS de los proveedores de servicios:

a. El programa debe incluir a todos los proveedores de servicios con los que se compartan datos de titulares de tarjeta (por ejemplo, centros de almacenamiento de copias de seguridad en cinta, proveedores de servicios gestionados tales como empresas de Web hosting o proveedores de servicios de seguridad, o bien quienes reciben datos para el diseño de modelos de fraude).

b. Se debe mantener un listado actualizado de proveedores de servicios.

c. Debe existir un acuerdo escrito que incluya un reconocimiento del proveedor de servicios respecto de su responsabilidad por la seguridad de los datos de titulares de tarjetas.

d. Antes del firmado con un nuevo proveedor de servicios se debe proceder a realizar una auditoría adecuada previa al compromiso con cualquier proveedor de servicios.

e. Se debe mantener un programa anual para supervisar el estado de cumplimiento con PCI DSS por parte del proveedor del servicio.

17. Plan de respuesta a incidentes:

a. Incluye roles, responsabilidades y estrategias de comunicación en caso de un riesgo que incluya como mínimo la notificación de las marcas de pago:

• Procedimientos específicos de respuesta a incidentes.
• Procedimientos de recuperación y continuidad comercial.
• Procesos de realización de copia de seguridad de datos.
• Análisis de requisitos legales para el informe de riesgos (Actualmente no aplica en España pues no existe legislación de este tipo).
• Cobertura y respuestas de todos los componentes críticos del sistema.
• Referencia o inclusión de procedimientos de respuesta a incidentes de las marcas de pago (Visa, Mastercard, AMEX, etc..)

b. El plan debe exigir que se pruebe su efectividad con carácter anual.

c. Debe documentar la respuesta permanente (24x7) a incidentes y cobertura de supervisión para cualquier evidencia de actividad no autorizada, detección de puntos de acceso inalámbricos no autorizados, alertas críticas de IDS y/o informes de cambios no autorizados en archivos de sistema críticos o de contenido.

d. El plan debe exigir que se capacite periódicamente al personal en cuanto a las responsabilidades de fallos de seguridad.

e. El plan debe contemplar un proceso para modificar y desarrollar el plan de respuesta a incidentes según las lecciones aprendidas, las evoluciones de la industria y los resultados de las pruebas realizadas en el mismo.