Profundidad y recurrencia de una Threat Emulation
Last updated: October 26, 2026
En una Threat Emulation de tipo Full security defines dos parámetros que determinan la cobertura del testing y el consumo de créditos: la profundidad (Depth) y la recurrencia (Recurrence). Los configuras en el paso Test configuration al crear la Threat Emulation.
Las Threat Emulations de tipo Focused y Change-based no tienen profundidad ni recurrencia configurables porque su alcance y su momento de ejecución ya están definidos de otra forma: una Focused se ejecuta una sola vez y se enfoca en el objetivo que defines en Goal, y una Change-based se ejecuta automáticamente con cada pull request o release, enfocada en los cambios incluidos.
Profundidad
La profundidad define el nivel de análisis que el agente de IA de Strike aplica sobre los assets en scope. Hay dos niveles:
Nivel | Qué incluye | Ideal para |
|---|---|---|
Medium | Una pasada completa sobre toda la superficie en scope. | Chequeos de seguridad regulares y assets con exposición moderada, como herramientas internas o ambientes de staging. |
Deep | Incluye cadenas de explotación, lógica de negocio y abuso de autenticación. | Assets críticos, como APIs de producción, sistemas de pago o de autenticación. |
La regla general: a mayor criticidad del asset para tu negocio, mayor profundidad.
En las Threat Emulations de infraestructura, la profundidad es siempre Deep y no se puede cambiar.
Recurrencia
Con el switch Recurrence activado, la Threat Emulation se ejecuta automáticamente según la frecuencia que elijas. Si lo dejas apagado, se ejecuta una sola vez.
Opción | Ejecuciones por año | Cuándo usarla |
|---|---|---|
Monthly | 12 | Assets que cambian seguido o con alta exposición. Máxima cobertura en el tiempo. |
Quarterly | 4 | Balance entre frecuencia y consumo de créditos. |
Semiannual | 2 | Assets estables o con menor exposición. |
Recurrence apagado | 1 | Una validación completa puntual, por ejemplo, antes de un lanzamiento. |
En entornos que cambian constantemente, una ejecución puntual pierde vigencia rápido: pueden aparecer nuevas vulnerabilidades con cada deploy. La recurrencia permite detectar riesgos a medida que surgen y reducir el tiempo de exposición.
Recomendación: si no sabes cuál elegir, te recomendamos Quarterly. Mantienes tus assets validados a lo largo de todo el año, con un buen balance entre cobertura y consumo de créditos.
Cómo combinarlas
La cobertura final depende de la combinación de profundidad y recurrencia. Para elegir, considera:
Qué tan crítico es el scope para tu negocio: datos que maneja, exposición e impacto de una brecha.
Con qué frecuencia cambia.
Cuántos créditos tienes disponibles en tu plan.
Ejemplos:
Scope crítico y con cambios frecuentes: Deep con recurrencia Monthly.
Scope estable o de menor exposición: Medium con recurrencia Quarterly o Semiannual.
Impacto en los créditos
El consumo de una Threat Emulation de tipo Full security se calcula así:
Paths en scope × profundidad × ejecuciones por año
En la profundidad, Medium multiplica por 1 y Deep multiplica por 2.
Ejemplo: una Threat Emulation con 40 paths en scope, profundidad Deep y recurrencia Quarterly consume 40 × 2 = 80 créditos por ejecución, es decir 320 créditos por año.
Mientras configuras la Threat Emulation, la tarjeta de estimación muestra el consumo y se recalcula con cada cambio. Para más detalle, consulta Créditos: qué son y cómo se consumen.
Preguntas frecuentes
¿Puedo ejecutar una Full security una sola vez?
Sí. Deja apagado el switch Recurrence.
¿Las Threat Emulations Focused o Change-based tienen profundidad o recurrencia?
No. Una Focused Threat Emulation se ejecuta una sola vez sobre un objetivo puntual, y una Change-based se ejecuta con cada pull request o release. Para ver las diferencias, consulta Full security, Focused y Change-based: en qué se diferencian y cuándo usar cada uno.
¿Dónde configuro la profundidad y la recurrencia?
Al crear la Threat Emulation, en el paso Test configuration. Para el paso a paso, consulta Cómo crear una Threat Emulation.