Otro de los cambios relevantes en la versión 4.0 de PCI DSS fue la evolución de los escaneos internos de vulnerabilidades desde un enfoque basado en red (PCI DSS v3.2.1) a un enfoque autenticado, que permite visibilidad total de la configuración interna del host analizado. Este nuevo enfoque puede verse como una mejora sustantiva desde el punto de vista de seguridad, pero abre la puerta a otro problema: la gestión de las credenciales y permisos administrativos usados por este tipo de escaneos. En este artículo te explicamos cómo evitar sorpresas e implementar este control de una forma segura.
Tal y como se explicó en el artículo Análisis de PCI DSS v4.0 Parte VI: Requerimientos 10 y 11, probablemente uno de los cambios más relevantes en PCI DSS es el de la inclusión del concepto de “escaneos autenticados” (authenticated scanning). Este enfoque permite que los escaneos internos vayan más allá de la detección de vulnerabilidades desde el punto de vista de red y evolucione hacia la identificación de vulnerabilidades desde el punto de vista del activo (host), dando mayor visibilidad a los resultados e incorporando no solo las vulnerabilidades de los servicios publicados en redes de datos sino también del software local y su configuración.
Diferencias entre el escaneo de vulnerabilidades tradicional y el escaneo autenticado
El requerimiento en mención es el 11.3.1.2, que dice:
11.3.1.2 Los escaneos internos de vulnerabilidades deben ser ejecutados vía escaneos autenticados de la siguiente manera:
- Los sistemas que no pueden aceptar credenciales para el escaneo autenticado deben ser documentados.
- Se deben usar suficientes privilegios para aquellos sistemas que aceptan credenciales para el escaneo.
- Si las cuentas utilizadas para el escaneo autenticado pueden ser usadas para inicio de sesiones interactivas, entonces estas cuentas deben ser gestionadas de acuerdo con el requerimiento 8.2.2.
La cara buena de los escaneos autenticados
Como decía Benjamín Disraeli, «por regla general, el hombre que tiene más éxito en la vida es el que dispone de la mejor información». Desde el punto de vista de seguridad, entre más información se tenga de un activo, la definición de sus controles se puede perfilar de una forma más ajustada. Y este es el caso de los escaneos autenticados: le proveen más información a la entidad acerca del estado de un activo en particular, incluyendo puertos y protocolos expuestos, servicios en ejecución, usuarios y grupos, permisos, periféricos conectados, actualizaciones, etc. permitiendo conocer su nivel de seguridad en un momento en particular.
La cara mala de los escaneos autenticados
No obstante, para lograr tener ese nivel de visibilidad en un activo no es suficiente con permisos genéricos: se requieren privilegios de administración .
Desde el punto de vista técnico esto se puede lograr mediante dos enfoques:
- Mediante agentes: Se requiere la instalación de un agente en el host a analizar (agente local). Este agente debe ejecutarse con privilegios administrativos para que pueda evaluar el sistema de forma adecuada sin tener restricciones.
- Sin agentes (agentless): En sistemas en los que no se quiere o no se puede instalar agentes (ya sea por incompatibilidad con sistemas operativos soportados, por el uso de appliances, etc.), los escaneos se pueden realizar de forma remota sin agentes locales instalados. Para ello, el escáner debe contar con un método e conexión remota (SSH, SNMP, WMI, API, recursos compartidos, etc.) y contar con credenciales de administración válidas (nombres de usuario y contraseñas o certificados digitales) que deben ser provistas al escáner para poder autenticarse remotamente y ejecutar las pruebas necesarias.
Y es precisamente aquí en donde viene la ironía, ya que la herramienta de escaneo de vulnerabilidades se convierte automáticamente en un vector de ataque:
- Si la consola de la herramienta de escaneos se compromete, el atacante podrá controlar los agentes y/o acceder a las credenciales almacenadas.
- Si los agentes locales instalados son comprometidos, los sistemas que cuenten con esos agentes también estarán comprometidos (ya que se ejecutan con privilegios de administración).
- Si las credenciales usadas para los escaneos sin agente (que se supone que tienen privilegios administrativos) son comprometidas, todos los sistemas en donde se pueda hacer autenticación estarán comprometidos.
- Debido a que el escáner debe tener acceso irrestricto a nivel de red para poder analizar el host objetivo, un atacante puede emplear esos privilegios para acceder a las redes de los sistemas a escanear.
Recomendaciones
Tal y como se indica en el mismo requerimiento, estas cuentas deben ser gestionadas a través del requisito 8.2.2:
8.2.2 Los identificadores (ID) de grupo, compartidos o genéricos, u otras credenciales de autenticación compartidas sólo se deben utilizar cuando es necesario de forma excepcional, y se deben gestionar del siguiente modo:
- Se impide el uso de ID a menos que sea necesario para una circunstancia excepcional.
- El uso se limita al tiempo necesario para la circunstancia excepcional.
- Se documenta la justificación empresarial del uso.
- La dirección aprueba explícitamente su uso.
- Se confirma la identidad del usuario individual antes de concederle acceso a una cuenta.
- Cada acción realizada es atribuible a un usuario individual.
Estos controles pueden estar bien en determinadas circunstancias, pero dependiendo de la herramienta de escaneo y de la infraestructura a analizar, se pueden quedar cortos, exponiendo a la entidad a potenciales riesgos.
Por eso, desde PCI Hispano os recomendamos la implementación de los siguientes controles adicionales:
- Estipular periodos de tiempo específicos para los escaneos y monitorizar cualquier acción realizada con las cuentas empleadas en los escaneos autenticados fuera de esos periodos.
- Si se trata de cuentas centralizadas (por ejemplo, cuentas de directorio activo o LDAP):
- Rotar de forma frecuente las contraseñas utilizadas.
- Habilitar estas cuentas solamente cuando los periodos de escaneos estén activos.
- Si se puede, remover los privilegios administrativos a la cuenta cuando no esté en uso.
- Dependiendo de las restricciones del sistema operativo a analizar, emplear controles de escalamiento de privilegios (su, sudo, etc.)
- Restringir el uso interactivo de la cuenta empleada para los escaneos autenticados. Por ejemplo, en sistemas Unix se le puede asignar una shell no interactiva como /bin/nologin, /bin/false o /bin/true.
- Activar reglas de firewall a nivel perimetral o a nivel local en los sistemas que lo soporten para permitir los accesos remotos desde el escáner solamente durante los periodos de tiempo en los que se esté haciendo el escaneo. Una vez finalizado, las reglas se deben deshabilitar.
- Preferiblemente usar autenticación basada en certificados en vez de contraseñas.
- Si la organización cuenta con un sistema de gestión de accesos privilegiados (Privileged Access Management – PAM), entonces vincular las cuentas empleadas en los escaneos autenticados con dicha herramienta.
Finalmente, no se recomienda ejecutar escaneos autenticados con cuentas sin privilegios administrativos o con privilegios perfilados de forma manual, ya que los resultados de los escaneos pueden ser erróneos, parciales o tener falsos positivos.
ES 
EN