PoC de EDR: Cómo Evaluar un EDR para tu Organización

Por que hacer una PoC

Comprar un EDR basandose solo en los resultados de MITRE Engenuity, el cuadrante de Gartner o una demo del vendor es como comprar un coche basandose en las fotos del catálogo. Una PoC (Proof of Concept) te permite conducir el coche en tus propias carreteras.

Los resultados de laboratorio no capturan:

• Como se comporta el agente en tu hardware y software específico
• Cuantos falsos positivos genera con tu tráfico legitimo
• Si la consola es usable por tu equipo con su nivel de experiencia
• Como se integra con tu SIEM, SOAR y herramientas existentes
• El impacto real en rendimiento de los endpoints de producción
• La calidad del soporte técnico cuando algo falla

Una PoC bien ejecutada responde a estas preguntas con datos reales, no con promesas del vendor.

Planificacion de la PoC

Fase 0: definir objetivos y criterios (1 semana antes)

Antes de contactar a ningun vendor, documenta:

Objetivos de negocio:

• ¿Que problema concreto resuelve el EDR? (compliance, detección de amenazas, respuesta a incidentes, todo)
• ¿Que presupuesto esta aprobado? (incluir licencias, infraestructura, personal)
• ¿Que timeline de decisión existe?

Requisitos técnicos:

• Sistemas operativos a cubrir (versiones especificas)
• Número de endpoints (actual y proyeccion a 2 años)
• Integraciones necesarias (SIEM, SOAR, ticketing, cloud)
• Requisitos de retencion de datos
• Requisitos regulatorios (ENS, GDPR, PCI DSS, NIS2)
• Restricciones de soberania de datos (¿datos pueden salir de EU?)

Criterios de evaluación ponderados:

Criterio	Peso	Descripcion
Detección	25%	Capacidad de detectar técnicas ATT&CK relevantes
Respuesta	15%	Acciones de contencion y remediación
Usabilidad	15%	Facilidad de investigación, triaje y operación diaria
Rendimiento	15%	Impacto en CPU, RAM, I/O y red en endpoints
Integracion	10%	Compatibilidad con stack existente (SIEM, SOAR, API)
Cobertura	10%	Plataformas soportadas (Windows, Linux, macOS, cloud)
Soporte	5%	Calidad del soporte técnico y SLAs
TCO	5%	Coste total incluyendo licencias, infra y personal

Los pesos son un punto de partida. Cada organización debe ajustarlos segun sus prioridades.

Fase 1: seleccion de vendors (1 semana)

Criterios para la shortlist:

1. Participacion en MITRE ATT&CK Evaluations: vendors que no participan levantan sospechas
2. Cuota de mercado y estabilidad: evitar vendors con riesgo de adquisición o desaparicion
3. Fit con tu stack: si tu entorno es Microsoft, evaluar Defender tiene sentido lógico
4. Presupuesto realista: no incluir vendors cuyo pricing este claramente fuera de rango
5. Soporte regional: ¿tienen soporte en tu zona horaria e idioma?

Fase 2: preparacion del entorno (1 semana)

Endpoints de test:

Montar un entorno representativo de producción:

• 5-10 endpoints Windows (versiones que uses en producción)
• 2-3 endpoints Linux (si aplica)
• 1-2 endpoints macOS (si aplica)
• Incluir al menos un servidor con carga real (no solo estaciones de trabajo)

Baseline de rendimiento:

Antes de instalar ningun agente, documentar:

• Tiempo de arranque del sistema
• Uso de CPU y RAM en estado normal
• I/O de disco en operaciones tipicas
• Latencia de red
• Tiempo de compilación o procesamiento de una tarea representativa

Este baseline es critico para medir el impacto real del agente EDR.

Herramientas de ataque:

Preparar las herramientas para ejecutar escenarios de prueba:

• Atomic Red Team: libreria de tests atomicos para técnicas ATT&CK individuales
• MITRE Caldera: plataforma de adversary emulation automatizada
• Invoke-AtomicRedTeam: módulo PowerShell para ejecutar tests Atomic
• PurpleSharp: simulador de adversarios para Active Directory

Escenarios de prueba

Los escenarios deben cubrir las fases del ataque (kill chain) y las técnicas ATT&CK más relevantes para tu organización.

Escenario 1: Initial Access y Execution

Test	Técnica ATT&CK	Descripcion
Macro maliciosa	T1566.001	Documento Office con macro que ejecuta PowerShell
ISO con LNK	T1566.001	Archivo ISO que monta y ejecuta .lnk con payload
HTA execution	T1218.005	Ejecución de HTML Application via mshta.exe
PowerShell download	T1059.001	Download-cradle con IEX y DownloadString

Escenario 2: Persistence

Test	Técnica ATT&CK	Descripcion
Registry Run Key	T1547.001	Persistencia via clave de registro Run
Scheduled Task	T1053.005	Tarea programada con schtasks.exe
WMI Event Sub	T1546.003	Persistencia via WMI event subscription
Service creation	T1543.003	Crear servicio Windows para persistencia

Escenario 3: Defense Evasion

Test	Técnica ATT&CK	Descripcion
Process Injection	T1055.001	Inyección de código en proceso legitimo
Timestomping	T1070.006	Modificar timestamps de archivos
Masquerading	T1036.005	Renombrar ejecutable como proceso del sistema
AMSI Bypass	T1562.001	Intentar desactivar AMSI

Escenario 4: Credential Access

Test	Técnica ATT&CK	Descripcion
LSASS dump	T1003.001	Volcado de memoria de LSASS
SAM dump	T1003.002	Extracción de hashes SAM
Kerberoasting	T1558.003	Solicitud de tickets Kerberos para cracking offline
DCSync	T1003.006	Replicación de hashes de AD via DRS

Escenario 5: Lateral Movement

Test	Técnica ATT&CK	Descripcion
PsExec	T1569.002	Ejecución remota via PsExec
WMI remote	T1047	Ejecución remota via WMI
RDP hijacking	T1563.002	Session hijacking de RDP

Escenario 6: Exfiltration y Impact

Test	Técnica ATT&CK	Descripcion
Data staging	T1074.001	Recopilar y comprimir datos
DNS exfil	T1048.001	Exfiltración via queries DNS
File encryption	T1486	Simulación de cifrado ransomware (archivos de test)

Ejecución de escenarios

Para cada escenario, documentar:

1. Timestamp de ejecución: hora exacta del test
2. Resultado del ataque: ¿se completo o fue bloqueado?
3. Tiempo hasta detección: cuanto tardo el EDR en alertar (si lo hizo)
4. Categoría de detección: telemetria, alerta generica, técnica ATT&CK identificada
5. Accion automática: ¿bloqueo, cuarentena, aislamiento?
6. Calidad de la alerta: ¿proporciona contexto suficiente para investigar?
7. Artefactos correlacionados: ¿agrupa eventos relacionados en un único incidente?

Framework de puntuacion

Detección (25%)

Puntuacion	Criterio
5	Detecta la técnica ATT&CK específica con contexto rico
4	Detecta con alerta generica (sin técnica específica)
3	Registra la telemetria pero no genera alerta
2	Detección parcial (solo parte del escenario)
1	Detección con delay significativo (mayor a 5 minutos)
0	No detecta nada

Respuesta (15%)

Puntuacion	Criterio
5	Bloquea automaticamente y aísla el endpoint
4	Bloquea el proceso malicioso automaticamente
3	Ofrece acciones de respuesta con 1 click
2	Requiere multiples pasos manuales para responder
1	Respuesta disponible solo via API
0	Sin capacidad de respuesta

Usabilidad (15%)

Puntuacion	Criterio
5	Investigación completa en una sola pantalla, intuitiva
4	Investigación requiere 2-3 clicks pero flujo lógico
3	Funcionalidad presente pero interfaz confusa
2	Requiere training significativo para uso básico
1	Interfaz inutilizable sin documentación del vendor
0	No evaluable

Rendimiento (15%)

Puntuacion	Criterio
5	Impacto indetectable (diferencia dentro del margen de error respecto al baseline)
4	Impacto menor (aumento de CPU/RAM inferior al 5%)
3	Impacto moderado (5-10% en alguna metrica)
2	Impacto notable (10-20% en alguna metrica)
1	Impacto severo (mayor al 20% o problemas de estabilidad)
0	Inestabilidad del sistema o incompatibilidades

Plantilla de comparacion

Tabla resumen por escenario

Escenario	Técnica	Vendor A	Vendor B	Vendor C
Macro maliciosa	T1566.001	5/5	4/5	5/5
Registry Run Key	T1547.001	4/5	5/5	3/5
Process Injection	T1055.001	3/5	5/5	4/5
LSASS dump	T1003.001	5/5	5/5	5/5
PsExec	T1569.002	4/5	4/5	2/5
DNS exfil	T1048.001	2/5	3/5	1/5
Total detección		23/30	26/30	20/30

Tabla resumen ponderada

Criterio	Peso	Vendor A	Vendor B	Vendor C
Detección	25%	4.2	4.5	3.8
Respuesta	15%	3.5	4.8	3.0
Usabilidad	15%	4.0	3.5	4.5
Rendimiento	15%	4.5	3.8	4.2
Integracion	10%	3.0	4.0	4.5
Cobertura	10%	4.0	4.5	3.5
Soporte	5%	3.5	4.0	4.5
TCO	5%	3.0	2.5	4.0
Total ponderado		3.88	4.10	3.82

Red flags durante la PoC

Del producto

• El agente causa BSOD o panic: incompatibilidad grave. Descalifica automaticamente
• Falsos positivos excesivos: más de 50 alertas falsas por endpoint por dia indica tuning deficiente
• Gaps en telemetria critica: si no detecta LSASS dump o Process Injection, la cobertura es insuficiente
• Latencia de detección mayor a 15 minutos: para técnicas de ejecución e initial access, la detección debe ser en segundos o minutos (no horas)
• Consumo de recursos inestable: picos de CPU o memoria que afectan la operación normal

Del vendor

• No permite pruebas de evasion: un vendor que prohibe ejecutar tests de bypass no confia en su producto
• Requiere configuración "especial" para la PoC: si necesitan activar funciones que no están habilitadas por defecto, pregunta por que no lo están
• No proporciona soporte durante la PoC: la calidad del soporte durante la evaluación predice la calidad post-compra
• Pricing opaco: si no proporcionan un presupuesto claro durante la PoC, espera sorpresas despues
• Clausulas de lock-in: contratos con permanencia mínima de 3 años o penalizaciones por cancelacion
• No participa en MITRE ATT&CK Evaluations: si el vendor evita la evaluación más transparente del mercado, pregunta por que

Del proceso

• PoC demasiado corta (menos de 2 semanas): no da tiempo a evaluar rendimiento sostenido ni falsos positivos
• Sin baseline de rendimiento: sin datos pre-instalación, no puedes medir el impacto real
• Solo se prueban demos del vendor: los escenarios deben incluir técnicas que tu threat model identifica como criticas, no solo las que el vendor sabe que detecta bien
• Decisión ya tomada: si la PoC es una formalidad para justificar una decisión previa, ahorra tiempo y recursos

Despues de la PoC

Documentación de resultados

Crear un informe estructurado con:

1. Resumen ejecutivo: recomendacion en 1 página
2. Metodologia: escenarios ejecutados, herramientas usadas, entorno de test
3. Resultados por criterio: tablas de puntuacion con evidencia
4. Análisis de gaps: técnicas no detectadas por cada vendor y su riesgo
5. TCO comparativo: coste a 3 años incluyendo licencias, personal e infraestructura
6. Recomendacion: vendor preferido con justificacion basada en datos

Negociacion

Los resultados de la PoC son palanca de negociacion:

• Si un vendor tiene gaps en detección, negociar mejoras antes de firmar
• Si el rendimiento es un problema, solicitar compromisos de optimizacion
• Comparar TCO entre vendors como base de negociacion de precio
• Solicitar período de prueba extendido si quedan dudas

Plan de despliegue

Una vez seleccionado el vendor, planificar el despliegue por fases:

1. Piloto (2-4 semanas): 50-100 endpoints representativos en modo detección
2. Expansión (4-8 semanas): despliegue gradual por departamento o localidad
3. Producción (ongoing): todos los endpoints con prevención habilitada
4. Optimizacion (continuo): tuning de reglas, exclusiones, integraciones

Conclusion

Una PoC bien ejecutada cuesta tiempo y esfuerzo, pero es la única forma de tomar una decisión de EDR basada en datos reales de tu entorno. Los resultados de MITRE, los cuadrantes de analistas y las demos del vendor son puntos de partida, no la respuesta final. Tu infraestructura, tu equipo y tus amenazas son unicos: la PoC es donde esa realidad se encuentra con las promesas del producto.