🔒 Registro cerrado · Apertura oficial próximamente · Acceso exclusivo para alumnos activos
Iniciar SesiónVigilar cambios en la página de pago
5 tareas · 40 min · Principiante
El inventario, las huellas y los marcos se diseñan una vez; la página de pago cambia todas las semanas. Hace falta algo que mire la página tal como le llega al cliente y avise cuando cambie sin permiso. Anacona Hogar te entrega la configuración de su monitor, sus resultados de octubre, los cambios aprobados y el registro de despliegues. Se mide cuánto tarda un cambio en verse.
Objetivo de la sala
El inventario, las huellas y los marcos se diseñan una vez; la página de pago cambia todas las semanas. Hace falta algo que mire la página tal como le llega al cliente y avise cuando cambie sin permiso. Anacona Hogar te entrega la configuración de su monitor, sus resultados de octubre, los cambios aprobados y el registro de despliegues. Se mide cuánto tarda un cambio en verse.El requisito 11.6.1 de PCI DSS v4.0, obligatorio desde el 31 de marzo de 2025, completa al 6.4.3. Pide un mecanismo de detección de cambios y manipulación que avise al personal cuando se modifiquen sin autorización las cabeceras HTTP que afectan a la seguridad y el contenido de los scripts de la página de pago, tal como los recibe el navegador del cliente. El mecanismo debe ejecutarse al menos una vez por semana, o con la frecuencia que fije un análisis de riesgo específico hecho según el requisito 12.3.1.
Dos detalles deciden si el monitor sirve. El primero es mirar lo que recibe el navegador: un robot que descarga el HTML sin ejecutarlo no ve los scripts que otro script trae ni lo que publica un gestor de etiquetas. El segundo es comparar contra algo aprobado: un cambio solo es «no autorizado» si existe un registro de lo que sí se autorizó.
Responde para continuar
¿Qué debe vigilar el mecanismo que pide el requisito 11.6.1?
Ver pista de ayuda
El requisito habla de lo que recibe el navegador del cliente.
Cada resultado del monitor se cruza con los cambios aprobados. Un cambio con ticket que coincide con lo aprobado se incorpora a la línea base; uno sin ticket se investiga. Este cruce es el trabajo semanal de quien atiende el monitor, y es donde un aviso se vuelve un hallazgo.
Abre el laboratorio y lee monitor-configuracion.txt, monitor-ejecuciones.txt, cambios-aprobados.txt y despliegues.txt en la carpeta anacona-vigilancia.
Responde para continuar
¿En qué fecha detectó el monitor por primera vez un cambio en /pago que ningún ticket aprobaba? Escríbela en formato AAAA-MM-DD.
Ver pista de ayuda
Recorre las ejecuciones en orden y busca el ticket de cada cambio.
Una cabecera de seguridad que se relaja para una prueba y no vuelve a su estado es un cambio permanente con apariencia de temporal. La política de seguridad de contenido decide de qué dominios se aceptan scripts; un dominio añadido a esa lista sigue autorizado aunque el script que lo justificaba ya no esté.
Responde para continuar
¿Qué dominio se añadió a script-src y sigue en la cabecera después de retirar la prueba? Escríbelo sin esquema ni comodín.
Ver pista de ayuda
Compara la ejecución del 26 de octubre con la nota de la del 2 de noviembre.
La frecuencia del monitor es el tiempo máximo que un cambio puede vivir sin que nadie lo sepa. Un monitor semanal cumple el mínimo del requisito, pero eso no dice nada de si es suficiente para una tienda concreta: para eso existe el análisis de riesgo, y en Anacona no se hizo.
Responde para continuar
¿Cuántos días de calendario pasaron entre la fecha del cambio sin ticket en el servidor y la fecha de la ejecución que lo detectó? Resta las fechas y escribe solo el número.
Ver pista de ayuda
Busca la fecha del cambio en el registro de despliegues.
El comité quiere saber si hay que cambiar algo, ya que el monitor «cumple con el mínimo». Tienes una medida real de cuánto tardó un cambio en aparecer y sabes que el análisis de riesgo de la frecuencia no existe.
Responde para continuar
¿Qué propones al comité sobre el monitor de Anacona?
Ver pista de ayuda
La medida de la tarea anterior es un argumento, no un dato de adorno.
Whoami-Labs Pro
Whoami-Labs Pro utiliza cookies
Utilizamos cookies y almacenamiento local para el funcionamiento del sitio, seguridad de sesión y, si lo autorizas, analítica y marketing. Puedes aceptar, rechazar o personalizar. Política de Privacidad
Preferencias
Configuraciones de cookies
Elige qué categorías permitir. Las esenciales siempre están activas. Consulta la Política de Privacidad.
Esenciales
Siempre activas · sesión, CSRF, tema y esta preferencia
Necesarias para iniciar sesión, proteger formularios (CSRF) y recordar tu elección de cookies y tema. Sin ellas la plataforma no funciona de forma segura.
Analíticos
Hoy no activos en la plataforma; listos para cuando se conecten
Nos ayudan a entender uso de cursos y páginas. Si los activas, se usarán cuando conectemos analítica; hasta entonces no se carga ningún tracker.
Marketing
Hoy no activos; campañas futuras solo con tu permiso
Comunicaciones o campañas. No activos hoy en la plataforma; quedarán listos si los conectamos y solo si los permites.