Analytics

jueves, 13 de febrero de 2014

Controles Manuales en el Cumplimiento de PCI DSS

En ocasiones el cumplimiento del estándar PCI DSS se vuelve “imposible”, no por la complejidad del estándar, ni por la dificultad en la operativa diaria, ni siquiera por los costes, simplemente por las limitaciones técnicas que pueden presentar algunos componentes de sistema del Entorno PCI DSS. 

Aunque a estas alturas los fabricantes deberían tener en cuenta las buenas prácticas en seguridad, no son pocos los elementos que carecen de posibilidades de configuración básicas que impiden mantener un nivel de seguridad aceptable, no únicamente para el cumplimiento de PCI DSS. Como ejemplo, podemos encontrar switches, cabinas de almacenamiento, IDS/IPS, Firewalls, tarjetas ILO, etc.

Bastante común es que estas limitaciones técnicas estén relacionadas con el control de acceso, o mejor dicho, la política de contraseñas del estándar PCI DSS, aunque también existen tecnologías que a día de hoy no permiten modificar parámetros por defecto, cuentas de usuario genéricas, obtener la hora de un servidor central o incluso el reenvío de logs a un servidor central.

Todas estas limitaciones técnicas suponen un desafío para el cumplimiento de PCI DSS, y por ello se hace necesario el desarrollo de técnicas y/o procesos (en ocasiones de controles compensatorios debidamente validados por un QSA) que permitan suplir estas carencias técnicas por controles manuales, en ocasiones conjuntamente con otros mecanismos de monitorización y auditoría.

Algunos ejemplos simples de estos controles pueden ser los siguientes:
  • Generar alertas cuando se detecte el uso de usuarios genéricos (Requerimiento 8.5.8) o de emergencias mediante la correlación de eventos, forzando el cambio de la contraseña después de cada uso y estableciendo un procedimiento controlado para la custodia de dicha contraseña.
  • Usar generadores de contraseñas complejas (Requerimiento 8.5.11) cada vez que vaya a procederse a cambiar la contraseña en un componente que no fuerce la complejidad establecida por el estándar, por ejemplo con herramientas como KeePass o Password Boy. Además, se podría complementar mediante revisiones periódicas que mediante el uso de técnicas de password cracking permitan verificar que la contraseña cumple con la complejidad y longitud necesaria.
  • En aquellos componentes que no permiten bloquear intentos de acceso fallidos (Requerimiento 8.5.13), que podrían detener un ataque de fuerza bruta, se recomienda aumentar significativamente la longitud mínima de la contraseña y añadir complejidad extra a la contraseña. Además de crear políticas de correlación que permitan generar alertas en caso de detectar intentos de inicio de sesión cercanos en el tiempo o incluso monitorizar los propios eventos de sesión fallida (si es que la tecnología es capaz de registrar apropiadamente dichos eventos).
  • Registro de las últimas contraseñas usadas en una base de datos segura y cifrada, para asegurarse que no se repita ninguna de las últimas 4 contraseñas usadas (Requerimiento 8.5.12), dejando anotado la fecha de uso y cambio de cada una de las contraseñas. Complementando dicho registro con pruebas periódicas de password cracking para validar que las contraseñas del histórico no están en uso de nuevo.
Obviamente cada entorno es distinto y será necesario buscar qué controles son más adecuados. Pero no hay que olvidar que se tratan de controles manuales y su uso debe limitarse ya que suponen un riesgo y que deben ser eliminados tan pronto como puedan eliminarse las carencias técnicas existentes en cada uno de los componentes de sistema del entorno PCI DSS. El no aplicar controles de seguridad suficientes, únicamente porque la tecnología no lo permite, no es admisible desde el punto de vista de seguridad y por supuesto para el cumplimiento de PCI DSS.


Autor: Marc Segarra - CISM, CISA, CISSP, PCI QSA, PCI PA QSA, ISO27001 Lead Auditor
Departamento de Consultoría