Profundidad y recurrencia de una Threat Emulation
Last updated: October 16, 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.
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 un testing anual o antes de un lanzamiento. |
En entornos que cambian constantemente, un test 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.