¿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.
