Requirements for an effective emulation

Last updated: April 23, 2026

To obtain accurate and relevant results from threat emulations, it is essential to properly configure access, context, and asset information. A good initial setup not only improves testing quality but also helps detect deeper vulnerabilities and reduce noise.

When an asset has the right information, agents can operate with greater context, achieving better coverage, more precise prioritization, and more actionable findings.

Required access and permissions

To ensure emulations run without interference, it's important to guarantee proper access to the asset.

IP whitelisting

It is required to allow Strike's IPs within security controls (WAF, IDS, rate limiting, etc.).

IPs to whitelist:

  • 52.4.41.179/32

  • 3.217.45.182/32

  • 18.210.150.0/32

  • 3.91.124.199/32

👉 These IPs must be enabled before starting the testing.

This allows:

  • Avoiding blocks during tests

  • Simulating real attacks without interruptions

  • Reducing false negatives

Without this configuration:

âš  Tests may be blocked.

âš  Coverage is affected.

âš  Results may not reflect real risk.

👉 Whitelisting is essential to guarantee testing quality and accuracy.

Authentication

If the asset requires login or restricted access, it is recommended to configure authentication methods.

Supported types:

  • Username and password

  • Tokens / API keys

  • Custom headers

💡 Without authentication, testing is limited only to the asset's public surfaces.

Access to private environments

If the asset is not public, access can be configured through:

  • VPN

  • Private networks

  • Specific access configurations

This allows extending testing to internal or protected environments.

If the asset is not public, it is necessary to configure access via VPN.

Strike currently supports only the following protocols:

  • OpenVPN

  • WireGuard

👉 Other access methods may be evaluated in very specific cases.

This allows extending testing to internal or protected environments.

Context and documentation

Context is one of the most important factors for improving emulation quality.

Asset context

Describing how the asset works helps better focus the tests:

  • What the system does

  • Critical flows

  • Sensitive data

  • Relevant business logic

💡 The more context provided, the more relevant the simulated attack scenarios will be.

Technical documentation

It is essential to attach technical documentation when creating the asset. Without this information, testing coverage is significantly limited, the attack paths that can be analyzed are reduced, and results may be incomplete or of lower quality. The quality of threat emulations depends directly on the level of context available.

Supported types:

  • Swagger / OpenAPI

  • Postman collections

  • Architecture or flow diagrams

This allows:

  • Identifying more complex attack paths

  • Improving testing coverage

  • Reducing false positives

Testing configuration

The platform allows adjusting how and when emulations are executed.

Execution restrictions

Conditions can be defined to adapt testing to the environment:

  • Rate limit (number of requests per minute)

  • Time windows when tests should not be executed

  • Exclusion of certain types of tests

Examples of exclusions:

  • Denial-of-service attacks (DoS)

  • Aggressive brute force

  • Destructive tests

This is especially useful in production environments.

Best practices

To maximize testing value:

✔ Provide clear and up-to-date asset context ✔ Add technical documentation when available ✔ Configure authentication to expand coverage ✔ Review restrictions based on the environment

What to avoid

To maintain process quality and security:

✖ Uploading logs without context ✖ Including irrelevant or outdated documentation ✖ Sharing sensitive credentials in files ✖ Adding information that does not contribute to testing

Proper initial configuration allows threat emulations to be more accurate, relevant, and aligned with the real business risk.