Crear un asset es el primer paso para comenzar a ejecutar threat emulations sobre un activo real del negocio. Un asset bien configurado permite obtener resultados más precisos, mayor cobertura de testing y una mejor priorización de riesgos.

Para crear un asset es necesario tener rol Owner u Operator.

Antes de avanzar, es importante tener en cuenta que la calidad del testing depende directamente de la información y el acceso configurado.

💡 Cuanto más contexto, documentación y acceso tenga el asset, mejores serán los resultados de las emulaciones.

Paso a paso

Haz clic en + Add New Asset desde la sección Assets. El proceso consta de 3 etapas:

Paso 1 — General

En esta etapa se define la identidad y contexto del asset.

Información básica

• Domain / URL
  Dirección del activo (ej: https://app.miempresa.com)

• Asset name
  Nombre claro para identificarlo (ej: Backoffice, API de pagos)

• Test environment
  Entorno donde está desplegado: Development, Staging o Production

• Asset relevance
  Nivel de criticidad del asset para el negocio. Permite priorizar el testing y enfocar las emulaciones según el impacto potencial.

Contexto del asset (recomendado)

Describir el funcionamiento del sistema permite mejorar significativamente la calidad de las pruebas:

• Qué hace el asset

• Flujos principales

• Datos sensibles

• Lógica de negocio relevante

• Stack tecnológico y arquitectura (si aplica)

💡 El contexto permite simular escenarios de ataque más realistas.

Qué evitar

• Incluir prompts tipo “actúa como pentester…”

• Agregar listados completos de endpoints (esto debe ir en archivos adjuntos)

• Proveer contexto genérico que no aporte valor

👉 Mantener el contexto claro y enfocado mejora la calidad del testing.

Documentación técnica (recomendado)

Se pueden adjuntar archivos que ayuden a entender el sistema:

• Swagger / OpenAPI

• Postman collections

• Diagramas de arquitectura o flujos

• PDFs con documentación funcional

👉 Es altamente recomendable incluir:

• Listado completo de endpoints (vía OpenAPI o Postman)

• Flujos de negocio clave (ej: login, pagos, onboarding)

• Descripción de la arquitectura del sistema (microservicios, APIs, integraciones, etc.)

👉 Esto permite:

• Identificar rutas de ataque más complejas

• Mejorar significativamente la cobertura del testing

• Reducir ruido y falsos positivos

• Detectar vulnerabilidades que no son visibles desde la superficie

Sin esta información, la cobertura del testing se ve limitada y los resultados pueden ser incompletos.

Paso 2 — Settings

En esta etapa se configura cómo el agente va a interactuar con el asset.

Autenticación (recomendado)

Permite testear áreas protegidas del sistema.

Tipos soportados:

• Usuario y contraseña

• Cookies

• Headers personalizados

💡 Sin autenticación, el testing se limita a la superficie pública.

Recomendaciones

• Utilizar credenciales de testing, no usuarios reales

• Para APIs, preferir autenticación mediante headers (Authorization)

• Cargar múltiples credenciales si existen distintos roles a evaluar

Acceso a entornos privados

Si el asset no es público, es posible configurar acceso mediante VPN. Strike soporta protocolos OpenVPN y WireGuard de base, lo que permite evaluar sistemas internos o restringidos de forma controlada.

Restricciones de testing

Permiten adaptar las emulaciones según el entorno:

• Rate limit: cantidad de requests por minuto

• Schedule restrictions: horarios donde no ejecutar pruebas

• Test exclusions: categorías de testing a excluir

Ejemplos:

• DoS / stress testing

• Fuerza bruta agresiva

• Pruebas destructivas

👉 Especialmente útil para entornos productivos.

Paso 3 — Confirmation

Antes de crear el asset, se muestra un resumen completo de la configuración:

• Información general

• Contexto y documentación

• Accesos configurados

• Restricciones

Una vez confirmado, el asset se crea y queda listo para comenzar las threat emulations.

Después de crear el asset

Una vez creado el asset, es necesario activarlo para comenzar el testing.

Activación del asset

Para iniciar las threat emulations, el usuario debe:

1. Hacer clic en Start testing

2. Definir la profundidad del testing

3. Configurar la recurrencia

4. Confirmar que las IPs de Strike están whitelisteadas*

Una vez completados estos pasos, el asset comienza su primera ejecución.

💡 Importante: antes de activar el testing, es necesario asegurarse de que las IPs de Strike estén correctamente habilitadas en los controles de seguridad.

*Puedes consultar el detalle de IPs en la sección “Acceso y permisos necesarios” dentro del artículo Requisitos para una emulación efectiva.

Consideraciones

• El asset puede editarse en cualquier momento

• Los cambios impactan en el siguiente ciclo de testing

• La calidad del testing dependerá de la configuración definida

Checklist antes de iniciar el testing

Antes de activar el asset, verificar:

• Contexto claro y relevante del sistema

• Documentación técnica adjunta (OpenAPI, PDFs, etc.)

• Credenciales configuradas y válidas

• Restricciones definidas según el entorno

• Entorno correctamente identificado (Development / Staging / Production)

• Nivel de criticidad definido

👉 Un asset bien configurado mejora significativamente la calidad de los resultados.

Buenas prácticas

✔ Definir correctamente el entorno y criticidad
✔ Agregar contexto claro del negocio
✔ Incluir documentación técnica
✔ Configurar autenticación cuando sea posible
✔Revisar periódicamente nuevos assets detectados automáticamente por la plataforma

👉 Una vez cargados los assets iniciales, la plataforma puede descubrir nuevos activos de forma continua mediante capacidades de inteligencia artificial que analizan y expanden la superficie de ataque. Revisarlos y gestionarlos permite ampliar la cobertura del testing y reducir puntos ciegos.