Criar um asset é o primeiro passo para começar a executar threat emulations sobre um ativo real do negócio. Um asset bem configurado permite obter resultados mais precisos, maior cobertura de testing e uma melhor priorização dos riscos.

Para criar um asset é necessário ter papel Owner ou Operator.

Antes de avançar, é importante considerar que a qualidade do testing depende diretamente das informações e do acesso configurado.

💡 Quanto mais contexto, documentação e acesso o asset tiver, melhores serão os resultados das emulações.

Passo a passo

Clique em + Add New Asset na seção Assets. O processo tem 3 etapas:

Passo 1 — General

Nesta etapa se define a identidade e o contexto do asset.

Informações básicas

• Domain / URL

  Endereço do ativo (ex: https://app.minhaempresa.com)

• Asset name

  Nome claro para identificá-lo (ex: Backoffice, API de pagamentos)

• Test environment

  Ambiente onde está implantado: Development, Staging ou Production

• Asset relevance

  Nível de criticidade do asset para o negócio. Permite priorizar o testing e focar as emulações conforme o impacto potencial.

Contexto do asset (recomendado)

Descrever o funcionamento do sistema melhora significativamente a qualidade dos testes:

• O que o asset faz

• Fluxos principais

• Dados sensíveis

• Lógica de negócio relevante

• Stack tecnológico e arquitetura (se aplicável)

💡 O contexto permite simular cenários de ataque mais realistas.

O que evitar

• Incluir prompts do tipo "atue como pentester…"

• Adicionar listas completas de endpoints (isso deve ir em arquivos anexos)

• Fornecer contexto genérico que não agregue valor

👉 Manter o contexto claro e focado melhora a qualidade do testing.

Documentação técnica (recomendado)

É possível anexar arquivos que ajudem a entender o sistema:

• Swagger / OpenAPI

• Postman collections

• Diagramas de arquitetura ou de fluxos

• PDFs com documentação funcional

👉 É altamente recomendável incluir:

• Lista completa de endpoints (via OpenAPI ou Postman)

• Fluxos de negócio principais (ex: login, pagamentos, onboarding)

• Descrição da arquitetura do sistema (microsserviços, APIs, integrações, etc.)

👉 Isso permite:

• Identificar rotas de ataque mais complexas

• Melhorar significativamente a cobertura do testing

• Reduzir ruído e falsos positivos

• Detectar vulnerabilidades que não são visíveis pela superfície

Sem essa informação, a cobertura do testing fica limitada e os resultados podem ser incompletos.

Passo 2 — Settings

Nesta etapa se configura como o agente vai interagir com o asset.

Autenticação (recomendado)

Permite testar áreas protegidas do sistema.

Tipos suportados:

• Usuário e senha

• Cookies

• Headers personalizados

💡 Sem autenticação, o testing se limita à superfície pública.

Recomendações

• Usar credenciais de testing, não usuários reais

• Para APIs, preferir autenticação por headers (Authorization)

• Carregar múltiplas credenciais se houver diferentes papéis a avaliar

Acesso a ambientes privados

Se o asset não é público, é possível configurar o acesso por VPN. A Strike suporta os protocolos OpenVPN e WireGuard por padrão, o que permite avaliar sistemas internos ou restritos de forma controlada.

Restrições de testing

Permitem adaptar as emulações conforme o ambiente:

• Rate limit: quantidade de requests por minuto

• Schedule restrictions: horários em que os testes não devem ser executados

• Test exclusions: categorias de testing a excluir

Exemplos:

• DoS / stress testing

• Força bruta agressiva

• Testes destrutivos

👉 Especialmente útil para ambientes produtivos.

Passo 3 — Confirmation

Antes de criar o asset, é exibido um resumo completo da configuração:

• Informações gerais

• Contexto e documentação

• Acessos configurados

• Restrições

Uma vez confirmado, o asset é criado e fica pronto para começar as threat emulations.

Depois de criar o asset

Uma vez criado o asset, é necessário ativá-lo para começar o testing.

Ativação do asset

Para iniciar as threat emulations, o usuário deve:

1. Clicar em Start testing

2. Definir a profundidade do testing

3. Configurar a recorrência

4. Confirmar que as IPs da Strike estão na whitelist*

Uma vez completados esses passos, o asset inicia sua primeira execução.

💡 Importante: antes de ativar o testing, é necessário garantir que as IPs da Strike estejam corretamente habilitadas nos controles de segurança.

*Você pode consultar o detalhe das IPs na seção "Acesso e permissões necessárias" dentro do artigo Requisitos para uma emulação efetiva.

Considerações

• O asset pode ser editado a qualquer momento

• As mudanças impactam no próximo ciclo de testing

• A qualidade do testing dependerá da configuração definida

Checklist antes de iniciar o testing

Antes de ativar o asset, verificar:

• Contexto claro e relevante do sistema

• Documentação técnica anexa (OpenAPI, PDFs, etc.)

• Credenciais configuradas e válidas

• Restrições definidas conforme o ambiente

• Ambiente corretamente identificado (Development / Staging / Production)

• Nível de criticidade definido

👉 Um asset bem configurado melhora significativamente a qualidade dos resultados.

Boas práticas

✔ Definir corretamente o ambiente e a criticidade

✔ Adicionar contexto claro do negócio

✔ Incluir documentação técnica

✔ Configurar autenticação quando possível

✔ Revisar periodicamente novos assets detectados automaticamente pela plataforma

👉 Uma vez carregados os assets iniciais, a plataforma pode descobrir novos ativos de forma contínua por meio de capacidades de inteligência artificial que analisam e expandem a superfície de ataque. Revisá-los e gerenciá-los permite ampliar a cobertura do testing e reduzir pontos cegos.