How to set a security assessment objective

A useful objective names the target and the access you want to test. “Test our security” leaves the result open to interpretation. “Obtain Domain Admin in the test domain” gives the assessment a condition it can work toward and report against.

Start with the asset you are protecting. Then decide what access to that asset would constitute a compromise.

Name the target and the action

These examples name a target and the access to test:

• Directory control: obtain Domain Admin in the named Active Directory domain.
• Data access: read a designated test document from the finance file share.
• Administrative access: obtain administrator access to the named backup server.

Use names that distinguish the target from similar systems. For a data objective, agree on what evidence is needed and which data the test may access. A designated test document can make success clear without making the objective “collect everything.”

Set scope separately

The objective describes the result you want to test. Scope describes where the campaign is authorized to act, with exclusions for systems you want to leave out. Review the reversible changes included in the campaign setup before deployment.

A request to reach a server does not authorize testing every system connected to it. Check the target ranges, exclusions, deployment position and starting credentials before creating the campaign. A custom objective names the access you want tested. Leaving it blank tests Domain Admin on every reachable domain.

Choose the starting access deliberately

A campaign without credentials asks whether it can establish the first foothold. An assumed-breach campaign asks what a specified identity can reach. Choose the starting point that matches the concern you are investigating.

For example, concern about a compromised employee account calls for that account’s level of access. Supplying an administrator account would answer a different question.

Work through a backup-server objective

Suppose you want to know whether a compromised employee account could give an attacker control of your backup server. This is a hypothetical example of planning an assessment.

“Test our backups” could mean reading a backup file, changing a backup job or administering the server. Choose the access that answers your concern. For server control, an objective could be “Obtain administrator access to backup-01.” A successful ordinary login would leave that objective unreached.

Use starting credentials with the employee access you intend to test. Identify the server precisely in the objective, then check that the authorized scope includes it and any systems you intend the campaign to test along the way. An excluded system may prevent the campaign from pursuing a route through it.

Agree on the evidence you need before running the campaign. In this example, evidence of administrator access to backup-01 would answer the objective. Demonstrating that access would not, by itself, show that backups were deleted or that recovery would fail. Those are different questions with different test requirements.

Read the outcome against the objective

A reached objective should have a route and evidence of the access gained. Read that evidence before deciding which credential exposure or permission needs attention.

Read the campaign status and objective outcome alongside the access it established.

You can start a fresh campaign after making a change. Set its objective and scope to test the affected system or permission, then review the new evidence.

The quickstart covers setup and the report. Review campaign controls before deploying.