Requirements for an effective emulation

To get accurate and relevant results, it's key that your assets and your Threat Emulations have access, context, and restrictions properly configured. A good initial setup improves the quality of testing, makes it possible to detect deeper vulnerabilities, and reduces noise.

This article summarizes what you need to review before your first run, with links to the details of each topic.

Access

• Allow Strike's IPs in your firewall, WAF, IDS, or rate limiting before the first run. Without this, testing may be blocked and the results may not reflect the real risk. To see the list of IPs and how to allow them, see How to allow Strike's IPs.

• Add credentials if your assets have a login. Without credentials, testing is limited to the public surface. For more detail, see How to add credentials for testing and How to provide test credentials for Strike's AI agent.

• Configure access to private networks if your assets are not public. When creating the Threat Emulation, turn on Requires VPN / jump host in the Before we test panel. For more detail, see Access to your internal network via VPN.

Context and documentation

• Complete the Description of each asset: what the system does, its critical flows, sensitive data, and relevant business logic. The more context, the more relevant the attack scenarios.

• Attach technical documentation to the asset, such as Swagger / OpenAPI, Postman collections, or architecture diagrams. It helps identify more complex attack paths, improve coverage, and reduce false positives.

• Use Additional information in the Threat Emulation for context that applies only to that Threat Emulation.

For more detail, see How to add a new asset and What to include in an asset's Description and in Additional information.

Restrictions

In the Threat Emulation configuration, you can define restrictions to adapt testing to your environment, which is especially useful in production:

• Exclude tests: types of intrusive tests you don't want to run, for example DoS or destructive payloads.

• Schedule restrictions: time windows during which testing is not allowed.

• Rate limit: maximum number of requests per minute.

For more detail, see How to create a Threat Emulation.

Before each run

At the start of each run, the Pre-flight Check verifies that your assets are reachable and that the credentials work. If it finds a problem, it shows you how to fix it. For more detail, see How the Pre-flight Check works.

Best practices

• Keep your assets' Description clear and up to date.

• Add technical documentation when available.

• Configure credentials to expand coverage.

• Review the restrictions based on each asset's environment.

What to avoid

• Uploading logs without context.

• Including irrelevant or outdated documentation.

• Sharing sensitive credentials in attached files.

• Adding information that doesn't contribute to testing.