Skip to content

EVD-ANTIMALWARE — Evidencia de Antimalware y Anti-Phishing PCI DSS ​

Fecha: 2026-04-03 Entidad evaluada: BIO TECHNOLOGY CENTER S.A.S. (Fintrixs) QSA: ControlCase Infraestructura: DigitalOcean Kubernetes (DOKS) — Región nyc1

Este documento consolida la evidencia para las preguntas de antimalware PCI DSS: Q31, Q32, Q1028, Q1029.


1. Q31 — Solución Antimalware Desplegada ​

1.1 Estrategia antimalware — Infraestructura de contenedores ​

Fintrixs opera una infraestructura 100% basada en contenedores (Kubernetes en DigitalOcean). La estrategia antimalware se adapta a este modelo de infraestructura inmutable:

1.2 Componentes por tipo de sistema ​

1.2.1 Contenedores Kubernetes (CDE + App) ​

AspectoDetalle
Tipo de protecciónEscaneo de imágenes pre-despliegue + detección runtime
Herramienta de escaneoTrivy (Aqua Security)
VersiónÚltima estable (actualización automática en CI/CD)
ModoActivo — bloquea despliegue si se detectan vulnerabilidades críticas
Base de datos de vulnerabilidadesNVD + GitHub Advisory + vendor advisories
Frecuencia de escaneoEn cada build (push a rama) + escaneo periódico del registry
Detección runtimeFalco DaemonSet (en implementación — ver Q80)

Justificación de no usar AV tradicional en contenedores:

FactorAnálisis
InmutabilidadLas imágenes de contenedores son inmutables; no se modifican en runtime
Superficie de ataque reducidaImágenes distroless o Alpine mínimas; sin shell ni paquetes innecesarios
Eficacia del AV tradicionalLos agentes AV están diseñados para sistemas operativos completos; no son efectivos en contenedores efímeros
Riesgo de malware tradicionalBajo — los contenedores no ejecutan software descargado por usuarios ni abren archivos adjuntos
Control compensatorioEscaneo de imágenes en CI/CD + NetworkPolicies + Falco runtime = protección equivalente o superior

1.2.2 VMs de Compliance (Collector, VAPT, CDD) ​

VMSistema operativoAntimalwareVersiónEstado
CollectorUbuntu 24.04 LTSClamAV + AppArmor (24 perfiles enforce)Última estableActivo
VAPTWindows Server 2022Microsoft Defender AntivirusIntegrado en WindowsVerificar por RDP
CDDWindows Server 2022Microsoft Defender AntivirusIntegrado en WindowsVerificar por RDP

1.2.3 Estaciones de trabajo de desarrollo ​

PlataformaSolución antimalwareGestión centralizadaPolítica
macOSCrowdStrike Falcon / Microsoft Defender for EndpointSí (consola centralizada)Protección en tiempo real activada, escaneo completo semanal
WindowsMicrosoft Defender for EndpointSí (Microsoft 365 Defender)Protección en tiempo real activada, escaneo completo semanal
Linux (dev)ClamAV + FalcoGestión por scriptsEscaneo programado diario

1.3 Evaluación periódica de componentes no susceptibles a malware ​

ComponenteSusceptible a malwareJustificaciónFrecuencia de revisión
Contenedores K8s (CDE)No (infraestructura inmutable)Imágenes construidas en CI/CD, sin acceso de usuario, sin escritura en filesystemAnual (TRA — ver Q1027)
Contenedores K8s (App)No (infraestructura inmutable)Mismo razonamiento que CDEAnual (TRA)
Managed PostgreSQLNoServicio gestionado por DigitalOcean; sin acceso al OS subyacenteAnual (referencia AOC DO)
DigitalOcean Load BalancerNoServicio gestionado; sin acceso al sistemaAnual (referencia AOC DO)
VMs de ComplianceSíSistemas operativos completos con acceso SSH/RDPN/A — AV obligatorio
Estaciones de trabajoSíUsuarios interactúan con el sistema, abren archivos, navegan internetN/A — AV obligatorio

Evidencia requerida para auditoría:

  • [ ] Captura de Trivy ejecutándose en pipeline CI/CD con resultado de escaneo
  • [ ] Captura de la versión de Trivy y su base de datos de vulnerabilidades
  • [ ] Captura de CrowdStrike/Defender activo en al menos 2 estaciones de trabajo
  • [ ] Captura de Defender activo en VMs Windows (VAPT, CDD)
  • [ ] Captura de ClamAV activo en Collector VM
  • [ ] Documento de evaluación de componentes no susceptibles a malware (firmado)

2. Q32 — Consola de Gestión de Antivirus ​

2.1 Consola centralizada de escaneo de contenedores ​

AspectoDetalle
HerramientaTrivy (integrado en CI/CD) + DigitalOcean Container Registry Scanning
DashboardGitHub Actions (resultados de escaneo en cada PR/push)
AccesoEquipo de desarrollo y seguridad via GitHub
URLRepositorio GitHub → Tab "Actions" → Workflow "Container Scan"

2.2 Frecuencia de actualización de firmas/base de datos ​

ComponenteFuente de actualizaciónFrecuenciaMecanismo
Trivy (CI/CD)NVD + GitHub Advisory Database + vendor feedsContinuo — se descarga la última DB en cada ejecucióntrivy image --download-db-only previo a escaneo
CrowdStrike FalconCrowdStrike Intelligence CloudCada 1–4 horas (automático)Agente actualiza firmas automáticamente
Microsoft DefenderMicrosoft Security IntelligenceCada 1–4 horas (automático)Windows Update + cloud-based protection
ClamAV (Collector VM)ClamAV MirrorCada 4 horas (freshclam)Cron job configurado

2.3 Configuración de la consola ​

2.4 Controles contra desactivación no autorizada ​

SistemaControlEvidencia
Trivy en CI/CDPipeline es obligatorio para merge; no se puede skipearRegla de branch protection en GitHub
CrowdStrikePolítica anti-tamper; solo admin de consola puede desactivarCaptura de política de protección contra manipulación
Microsoft DefenderTamper protection activada; requiere admin global para desactivarCaptura de configuración en portal
ClamAVServicio clamd monitoreado por systemd; restart automáticosystemctl status clamav-daemon

2.5 Retención de logs de antimalware ​

FuenteRetención onlineRetención archivadaTotalReq. PCI DSS
Trivy scan results (CI/CD)3 meses (GitHub Actions logs)9 meses (exportación a S3/Spaces)12 meses10.7
CrowdStrike events3 meses (consola cloud)9 meses (exportación periódica)12 meses10.7
Microsoft Defender events3 meses (portal Defender)9 meses (exportación a syslog)12 meses10.7
ClamAV logs3 meses (Collector VM local)9 meses (rsyslog → archivo)12 meses10.7

2.6 Ejemplo de resultado de escaneo ​

Trivy — Escaneo de imagen card-vault-service:latest:

ComponenteTipoID VulnerabilidadSeveridadEstado
node:20-alpineOS packageCVE-2024-XXXXMediumFixed in 20.12.1
opensslLibraryCVE-2024-YYYYLowAccepted risk
(sin hallazgos críticos)———PASS

Evidencia requerida para auditoría:

  • [ ] Captura de consola de CI/CD mostrando escaneo exitoso y fallido
  • [ ] Captura de frecuencia de actualización de firmas (automático)
  • [ ] Captura de controles anti-tamper en cada plataforma
  • [ ] Ejemplo de logs de antimalware con retención configurada
  • [ ] Captura de DigitalOcean Container Registry scan results

3. Q1028 — Antimalware para Medios Removibles ​

3.1 Análisis de aplicabilidad ​

3.2 Entorno cloud (Kubernetes + VMs) ​

EntornoMedios removiblesJustificación
Pods Kubernetes (CDE + App)No aplicaLos contenedores no tienen acceso a hardware físico; no hay puertos USB
VMs de Compliance (Collector, VAPT, CDD)No aplicaMáquinas virtuales en DigitalOcean; sin acceso a puertos físicos del host
Managed PostgreSQLNo aplicaServicio gestionado; sin acceso al sistema subyacente

3.3 Estaciones de trabajo — Política de medios removibles ​

ControlConfiguraciónHerramienta
Escaneo automático al insertar USBActivado en tiempo realCrowdStrike / Defender — device control
Bloqueo de ejecución automáticaAutorun desactivado por GPO/MDMMicrosoft Intune / CrowdStrike policy
Logging de dispositivos USBRegistro de cada dispositivo conectadoCrowdStrike / Defender event log
Cifrado de dispositivos USB (si se permite)Obligatorio BitLocker To GoPolítica de dispositivos

3.4 Política de uso de medios removibles ​

ReglaDescripción
Uso en sistemas CDEProhibido — no hay acceso físico a la infraestructura cloud
Uso en estaciones de trabajoRestringido — solo dispositivos autorizados por IT
Transferencia de datos sensibles via USBProhibido — toda transferencia de datos PCI debe ser via canales cifrados
Escaneo previo al usoObligatorio — el AV debe escanear el dispositivo antes de acceder a su contenido

Evidencia requerida para auditoría:

  • [ ] Captura de política de device control en CrowdStrike/Defender
  • [ ] Captura de Autorun desactivado en estaciones de trabajo
  • [ ] Declaración firmada de que la infraestructura cloud no permite medios removibles

4. Q1029 — Mecanismos Anti-Phishing ​

4.1 Capas de protección anti-phishing ​

4.2 Capa 1 — Filtrado de email ​

AspectoConfiguración
Proveedor de emailGoogle Workspace (fintrix.com)
Anti-phishingGoogle Workspace Security → Phishing Protection activado
Anti-spamFiltrado automático con machine learning
Escaneo de adjuntosDetección de malware en adjuntos antes de entrega
QuarantineMensajes sospechosos enviados a cuarentena del admin
Safe browsingAlertas de enlaces sospechosos en emails

4.3 Capa 2 — Autenticación de dominio (SPF / DKIM / DMARC) ​

ProtocoloRegistro DNSValorEfecto
SPFfintrix.com TXTv=spf1 include:_spf.google.com ~allSolo servidores de Google pueden enviar email como @fintrix.com
DKIMgoogle._domainkey.fintrix.com TXTClave pública DKIM de Google WorkspaceFirma criptográfica de emails salientes
DMARC_dmarc.fintrix.com TXTv=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100Emails que fallan SPF/DKIM van a cuarentena; reportes de abuso

Verificación de configuración:

bash
# Verificar SPF
dig TXT fintrix.com +short

# Verificar DKIM
dig TXT google._domainkey.fintrix.com +short

# Verificar DMARC
dig TXT _dmarc.fintrix.com +short

4.4 Capa 3 — Formación y simulaciones de phishing ​

ActividadFrecuenciaResponsableReferencia
Formación de concienciación sobre phishingAnual (parte de Q88)HR + CISOPendiente ControlCase training
Simulación de phishingTrimestralCISOHerramienta: KnowBe4 / GoPhish
Reporte de emails sospechososContinuoTodo el personalBotón "Report Phishing" en Gmail

Contenido de la formación anti-phishing:

TemaDescripción
Identificación de emails de phishingSeñales de alerta: remitente sospechoso, urgencia artificial, enlaces falsos
Spear phishingAtaques dirigidos a individuos específicos (CEO fraud, BEC)
Vishing y smishingPhishing por teléfono y SMS
Ingeniería socialTécnicas de manipulación psicológica
Procedimiento de reporteCómo reportar un email sospechoso al equipo de seguridad
ConsecuenciasImpacto de un ataque exitoso en la organización y datos PCI

4.5 Capa 4 — Controles técnicos adicionales ​

ControlImplementaciónEstado
MFA en acceso a emailGoogle Workspace → 2-Step Verification obligatoriaActivo
MFA en acceso a sistemas CDEWireGuard VPN + MFAActivo
Safe LinksGoogle Workspace → URL scanningActivo
Safe AttachmentsGoogle Workspace → attachment scanningActivo
Browser isolationChrome Enterprise → sitios de alto riesgo aisladosEn evaluación

4.6 Métricas de simulaciones de phishing ​

MétricaObjetivoAcción si se excede
Tasa de click en simulación< 15%Formación adicional obligatoria para quienes hicieron click
Tasa de reporte de phishing> 50%Reconocimiento positivo al equipo
Tiempo promedio de reporte< 30 minutosRevisión del proceso de reporte
Tasa de compromiso (credenciales ingresadas)< 5%Formación individual + revisión de acceso

4.7 Registro de simulaciones de phishing ​

# SimulaciónFechaTipoDestinatariosTasa de clickTasa de reporteAcciones
SIM-01Programado Q2 2026Spear phishing (CEO fraud)Todo el personalPendientePendientePendiente
SIM-02Programado Q3 2026Credential harvestingTodo el personalPendientePendientePendiente
SIM-03Programado Q4 2026Invoice fraudÁrea financieraPendientePendientePendiente
SIM-04Programado Q1 2027IT impersonationTodo el personalPendientePendientePendiente

Evidencia requerida para auditoría:

  • [ ] Captura de Google Workspace → Security → Phishing Protection configurado
  • [ ] Captura de registros DNS mostrando SPF, DKIM, DMARC
  • [ ] Resultados de al menos 2 simulaciones de phishing con métricas
  • [ ] Material de formación anti-phishing (presentación o módulo online)
  • [ ] Registros de asistencia a formación (referencia Q88)
  • [ ] Captura de MFA obligatoria en Google Workspace

Historial de revisiones ​

VersiónFechaAutorCambios
1.02026-04-03Equipo de Seguridad FintrixsCreación inicial del documento de evidencia de antimalware y anti-phishing

Documentación Confidencial — Solo para uso interno y auditoría PCI DSS