La verificación de las firmas le permite obtener dos de las tres características principales de seguridad que HTTPS brindaría: integridad y autenticidad . Se puede argumentar para este uso que no existe un requisito estricto para el tercero, confidencialidad , aunque el conocimiento de parches específicos podría conducir a la divulgación de información posiblemente de uso a un atacante, CWE-200 .
Si esto se permite a través de un firewall que debe cumplir con PCI DSS, se debe documentar el uso de un protocolo inseguro (PCI-DSS v3.0):
1.1.6 Documentación y justificación comercial para el uso de todos los servicios, protocolos y puertos permitidos, incluida la documentación de las funciones de seguridad implementadas para aquellos protocolos considerados inseguros.
La respuesta entonces es no, no se requiere HTTPS para este propósito. Sin embargo, el proceso debe documentarse y, si es necesario, se deben realizar algunos pasos manuales, como el mantenimiento de certificados, y también se debe tener en cuenta que §6.2 requiere una revisión y que la §6.4.5 y los subordinados requieren procesos de control de cambios para la aplicación de parches.
Otras medidas de mitigación que podrían recomendarse son
- bloquear la regla de firewall HTTP saliente en destinos limitados si es apropiado (aunque la entrega a través de los CDN hace que esto no tenga sentido)
- bloquear la regla del cortafuegos en función del tiempo o habilitar / deshabilitar manualmente
- en su lugar, use un proxy HTTP en una zona de red diferente, además del registro auditable y el alcance futuro de DLP , esto elimina la necesidad de HTTP y DNS salientes en los clientes