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 catalogo. 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 especifico
• Cuantos falsos positivos genera con tu trafico 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 produccion
• La calidad del soporte tecnico 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, deteccion de amenazas, respuesta a incidentes, todo)
• ¿Que presupuesto esta aprobado? (incluir licencias, infraestructura, personal)
• ¿Que timeline de decision existe?

Requisitos tecnicos:

• Sistemas operativos a cubrir (versiones especificas)
• Numero de endpoints (actual y proyeccion a 2 anos)
• 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 evaluacion ponderados:

Criterio	Peso	Descripcion
Deteccion	25%	Capacidad de detectar tecnicas ATT&CK relevantes
Respuesta	15%	Acciones de contencion y remediacion
Usabilidad	15%	Facilidad de investigacion, triaje y operacion 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 tecnico y SLAs
TCO	5%	Coste total incluyendo licencias, infra y personal

Los pesos son un punto de partida. Cada organizacion 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 adquisicion o desaparicion
3. Fit con tu stack: si tu entorno es Microsoft, evaluar Defender tiene sentido logico
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 produccion:

• 5-10 endpoints Windows (versiones que uses en produccion)
• 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 compilacion 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 tecnicas ATT&CK individuales
• MITRE Caldera: plataforma de adversary emulation automatizada
• Invoke-AtomicRedTeam: modulo 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 tecnicas ATT&CK mas relevantes para tu organizacion.

Escenario 1: Initial Access y Execution

Test	Tecnica 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	Ejecucion de HTML Application via mshta.exe
PowerShell download	T1059.001	Download-cradle con IEX y DownloadString

Escenario 2: Persistence

Test	Tecnica 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	Tecnica ATT&CK	Descripcion
Process Injection	T1055.001	Inyeccion de codigo 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	Tecnica ATT&CK	Descripcion
LSASS dump	T1003.001	Volcado de memoria de LSASS
SAM dump	T1003.002	Extraccion de hashes SAM
Kerberoasting	T1558.003	Solicitud de tickets Kerberos para cracking offline
DCSync	T1003.006	Replicacion de hashes de AD via DRS

Escenario 5: Lateral Movement

Test	Tecnica ATT&CK	Descripcion
PsExec	T1569.002	Ejecucion remota via PsExec
WMI remote	T1047	Ejecucion remota via WMI
RDP hijacking	T1563.002	Session hijacking de RDP

Escenario 6: Exfiltration y Impact

Test	Tecnica ATT&CK	Descripcion
Data staging	T1074.001	Recopilar y comprimir datos
DNS exfil	T1048.001	Exfiltracion via queries DNS
File encryption	T1486	Simulacion de cifrado ransomware (archivos de test)

Ejecucion de escenarios

Para cada escenario, documentar:

1. Timestamp de ejecucion: hora exacta del test
2. Resultado del ataque: ¿se completo o fue bloqueado?
3. Tiempo hasta deteccion: cuanto tardo el EDR en alertar (si lo hizo)
4. Categoria de deteccion: telemetria, alerta generica, tecnica ATT&CK identificada
5. Accion automatica: ¿bloqueo, cuarentena, aislamiento?
6. Calidad de la alerta: ¿proporciona contexto suficiente para investigar?
7. Artefactos correlacionados: ¿agrupa eventos relacionados en un unico incidente?

Framework de puntuacion

Deteccion (25%)

Puntuacion	Criterio
5	Detecta la tecnica ATT&CK especifica con contexto rico
4	Detecta con alerta generica (sin tecnica especifica)
3	Registra la telemetria pero no genera alerta
2	Deteccion parcial (solo parte del escenario)
1	Deteccion 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	Investigacion completa en una sola pantalla, intuitiva
4	Investigacion requiere 2-3 clicks pero flujo logico
3	Funcionalidad presente pero interfaz confusa
2	Requiere training significativo para uso basico
1	Interfaz inutilizable sin documentacion 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	Tecnica	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 deteccion		23/30	26/30	20/30

Tabla resumen ponderada

Criterio	Peso	Vendor A	Vendor B	Vendor C
Deteccion	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: mas 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 deteccion mayor a 15 minutos: para tecnicas de ejecucion e initial access, la deteccion debe ser en segundos o minutos (no horas)
• Consumo de recursos inestable: picos de CPU o memoria que afectan la operacion normal

Del vendor

• No permite pruebas de evasion: un vendor que prohibe ejecutar tests de bypass no confia en su producto
• Requiere configuracion "especial" para la PoC: si necesitan activar funciones que no estan habilitadas por defecto, pregunta por que no lo estan
• No proporciona soporte durante la PoC: la calidad del soporte durante la evaluacion 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 minima de 3 anos o penalizaciones por cancelacion
• No participa en MITRE ATT&CK Evaluations: si el vendor evita la evaluacion mas 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-instalacion, no puedes medir el impacto real
• Solo se prueban demos del vendor: los escenarios deben incluir tecnicas que tu threat model identifica como criticas, no solo las que el vendor sabe que detecta bien
• Decision ya tomada: si la PoC es una formalidad para justificar una decision previa, ahorra tiempo y recursos

Despues de la PoC

Documentacion de resultados

Crear un informe estructurado con:

1. Resumen ejecutivo: recomendacion en 1 pagina
2. Metodologia: escenarios ejecutados, herramientas usadas, entorno de test
3. Resultados por criterio: tablas de puntuacion con evidencia
4. Analisis de gaps: tecnicas no detectadas por cada vendor y su riesgo
5. TCO comparativo: coste a 3 anos 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 deteccion, 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 periodo 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 deteccion
2. Expansion (4-8 semanas): despliegue gradual por departamento o localidad
3. Produccion (ongoing): todos los endpoints con prevencion habilitada
4. Optimizacion (continuo): tuning de reglas, exclusiones, integraciones

Conclusion

Una PoC bien ejecutada cuesta tiempo y esfuerzo, pero es la unica forma de tomar una decision 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.