POL-006: Política de Gestión de Vulnerabilidades y Parches

Direccionamiento corregido el 2026-08-16 · AVISO-SUBREDES-2026-08

Este documento describía subredes por función —10.100.10.0/24, 10.100.20.0/24 y similares— que no existen en la infraestructura. La red de producción es plana, 10.100.0.0/16, con todos los sistemas en 10.100.0.x.

Las referencias se han sustituido por el mecanismo de separación real: cortafuegos aplicados por etiqueta y políticas de red del orquestador con denegación por defecto. Las zonas funcionales sí existen; su direccionamiento no.

Descripción completa en Arquitectura de red — descripción verificada.

Campo	Valor
ID	POL-006
Versión	1.0
Fecha de Emisión	2026-03-13
Próxima Revisión	2027-03-13
Propietario	CISO / Equipo DevOps
PCI DSS	Requisitos 6, 11
Preguntas ControlCase	Q33, Q34, Q74, Q75, Q76, Q77, Q78, Q79, Q80, Q81

---

1. Propósito

Definir el proceso de identificación, evaluación, clasificación y remediación de vulnerabilidades de seguridad, así como la gestión de parches para todos los sistemas en scope PCI DSS.

2. Identificación de Vulnerabilidades

2.1 Fuentes Externas Reputables

Fuente	URL	Frecuencia de Revisión
NVD (NIST)	nvd.nist.gov	Diaria (feed automatizado)
GitHub Security Advisories	github.com/advisories	En tiempo real (Dependabot)
npm Security Advisories	npmjs.com/advisories	En cada CI build (npm audit)
Snyk Vulnerability Database	snyk.io/vuln	Integración CI/CD
CERT/CC	cert.org	Semanal
Vendor Security Bulletins	DigitalOcean, PostgreSQL, Kong	Semanal
PCI SSC Bulletin Board	pcisecuritystandards.org	Mensual

2.2 Herramientas de Detección

Herramienta	Tipo	Alcance	Integración
npm audit	Dependency scanning	Dependencias Node.js	CI/CD pipeline
Trivy	Container scanning	Imágenes Docker	CI/CD pipeline
GitHub Dependabot	Dependency scanning	Todas las dependencias	GitHub
Snyk (si contratado)	SAST + SCA	Código fuente + dependencias	CI/CD
OWASP ZAP (si contratado)	DAST	APIs públicas	Periódico

3. Evaluación y Clasificación de Riesgo

3.1 Sistema de Clasificación

Severidad	CVSS Score	Tiempo de Remediación	Proceso
Crítica	9.0 - 10.0	30 días (instalación inmediata o controles compensatorios)	Patch de emergencia, notificación a Gerencia
Alta	7.0 - 8.9	30 días	Priorización en sprint actual
Media	4.0 - 6.9	90 días	Programación en siguiente sprint
Baja	0.1 - 3.9	180 días	Backlog priorizado

3.2 Proceso de Evaluación

1. Recibir alerta de vulnerabilidad (fuente o herramienta)
2. Determinar si aplica a nuestro entorno (¿usamos el componente afectado?)
3. Evaluar CVSS y contexto de explotabilidad
4. Clasificar severidad según tabla §3.1
5. Registrar en el Registro de Vulnerabilidades
6. Asignar responsable de remediación
7. Implementar parche o control compensatorio
8. Verificar remediación (re-escaneo)
9. Cerrar registro

3.3 Ejemplos de Proceso Seguido

Se mantienen registros de al menos 3 vulnerabilidades procesadas siguiendo este flujo, como evidencia de implementación.

4. Gestión de Parches

4.1 Proceso de Despliegue de Parches

Alerta → Evaluación → Aprobación → Test → Deploy Staging → Deploy Prod → Verificación
                         │                       │               │
                    Urgencia determina        CI/CD auto      Con aprobación
                    si es expedito            tests pass       manual

4.2 Cronograma de Parches

Tipo de Sistema	Frecuencia de Revisión	Ventana de Aplicación
Imágenes Docker (node:20-alpine)	Mensual	Sprint planning
Dependencias npm	Semanal (Dependabot)	Cada PR
PostgreSQL	Mensual (managed by DO)	Gestionado por DO
Kubernetes (DOKS)	Mensual (managed by DO)	Gestionado por DO
Kong	Mensual	Ventana de cambio
OS base (contenedores)	Rebuild mensual	CI/CD pipeline

4.3 Niveles de Parches Actuales

Se mantiene un registro actualizado del nivel de parches de cada sistema, revisable en el inventario de activos.

5. Escaneos de Vulnerabilidades

5.1 Escaneo Interno (Q74)

Parámetro	Valor
Frecuencia	Trimestral + después de cambios significativos
Tipo	Autenticado
Herramienta	Trivy / Nessus / OpenVAS
Alcance	Todos los contenedores, nodos, y bases de datos en scope
Re-escaneo	Obligatorio después de remediación de vulnerabilidades altas/críticas
Mantenimiento	Herramienta actualizada con últimas firmas antes de cada escaneo
Excepción	Sistemas que no aceptan credenciales: justificación documentada

5.2 Escaneo Externo ASV (Q75)

Parámetro	Valor
Frecuencia	Trimestral + después de cambios significativos
Proveedor	ASV aprobado por PCI SSC
Alcance	Todas las IPs públicas (Load Balancer, API)
Resultado	Informe ASV con estado Pass/Fail
Re-escaneo	Obligatorio hasta obtener Pass

6. Pruebas de Penetración

6.1 Metodología (Q76)

Las pruebas de penetración se realizan siguiendo:

• PTES (Penetration Testing Execution Standard) como marco metodológico
• OWASP Testing Guide v4 para pruebas de aplicaciones web
• NIST SP 800-115 como referencia técnica

Fases:

1. Reconocimiento (pasivo y activo)
2. Escaneo y enumeración
3. Análisis de vulnerabilidades
4. Explotación
5. Post-explotación
6. Reporte

6.2 Pentest Externo (Q77)

Parámetro	Valor
Frecuencia	Anual + después de cambios significativos
Alcance	Red y aplicación (capa de red + capa de aplicación)
Tipo	Black box + Gray box
Ejecutor	Empresa de seguridad independiente calificada
Informe	Incluye: hallazgos, severidad, evidencia, recomendaciones
Remediación	Según cronograma de §3.1

6.3 Pentest Interno (Q78)

Parámetro	Valor
Frecuencia	Anual + después de cambios significativos
Alcance	Red y aplicación interna
Tipo	Gray box (con credenciales básicas)
Ejecutor	Equipo interno calificado o empresa externa

6.4 Prueba de Segmentación (Q79)

Parámetro	Valor
Frecuencia	Semestral (como proveedor de servicios)
Alcance	Controles de segmentación entre CDE, App, DMZ, Mgmt
Método	Intento de penetración cross-segment
Verificación	Confirmar que tráfico no autorizado es bloqueado entre segmentos

7. IDS/IPS (Q80)

7.1 Implementación

Componente	Tecnología	Ubicación
Network IDS	DigitalOcean Cloud Firewall logs	Perímetro de cada segmento
Application IDS	Falco (runtime security)	Pods del CDE namespace
Log-based detection	Prometheus alerting rules	Monitoring namespace

7.2 Configuración

Aspecto	Detalle
Segmentos monitoreados	CDE (etiqueta fintrix-cde), DMZ (balanceadores publicados)
Versión	Según release actual de Falco / Prometheus
Políticas	Default Falco rules + custom PCI rules
Firmas	Actualizadas automáticamente
Alertas	Slack + Email + PagerDuty
Seguimiento	Todo alerta con ticket de seguimiento
Canales encubiertos	Falco configurado para detectar shells reversos, comunicación DNS sospechosa

8. File Integrity Monitoring — FIM (Q81)

8.1 Implementación

Aspecto	Detalle
Herramienta	OSSEC / Wazuh / Falco
Archivos monitoreados	Binarios críticos, archivos de configuración, scripts, certificados TLS
Frecuencia de comparación	Al menos semanal
Alertas	Inmediatas ante cambio no autorizado
Seguimiento	Toda alerta investigada y documentada

8.2 Archivos Críticos Monitoreados

Tipo	Ejemplos
Binarios del sistema	/usr/bin/, /usr/sbin/
Configuraciones	Kong config, network policies, Dockerfiles
Certificados	TLS certs, JWT signing keys
Scripts de inicio	Entrypoints de contenedores
Archivos de auditoría	Configuraciones de audit logging

9. Detección de Manipulación de Páginas de Pago (Q1037)

Aspecto	Detalle
Mecanismo	Content Security Policy (CSP) + Subresource Integrity (SRI)
Monitoreo	Headers HTTP verificados en cada respuesta
Frecuencia	Continuo (cada request)
Alertas	Violación de CSP genera alerta
Seguimiento	Investigación dentro de 24 horas

---

Historial de Revisiones

Versión	Fecha	Autor	Cambios
1.0	2026-03-13	DevOps / Seguridad	Documento inicial

Aprobación

Rol	Nombre	Firma	Fecha
CISO / Oficial de Seguridad	_________________	_________________	//____
Gerencia Ejecutiva	_________________	_________________	//____