Rules of engagement, testing windows and target selection

Objective 1.1 in this course covers planning and scoping — CompTIA describes it as defining rules of engagement, testing windows and target selection. Lesson 1 covered what is being scoped; this is how the scope gets written.

Why this matters

The rules of engagement are the document you will be judged against — by the client if something breaks, by your own management if a finding is disputed, and by a court in the worst case. It is also the document that decides whether the engagement is useful, because a scope that excludes the interesting half of the estate produces a report nobody needed.

Exam scenarios in this area tend to describe a situation mid-engagement and ask what you do. The answer nearly always comes back to what the ROE says, or to stopping and amending it.

The lesson

Turning a client's goal into a scope somebody can test

Clients arrive with an outcome, not a scope: "we want to know if we'd survive a ransomware attack", "our biggest customer is asking for a pen test report".

The translation is a conversation, and it is your job to lead it:

• What question do you want answered? Compliance-driven work and risk-driven work look different and should be scoped differently.
• What would a bad outcome look like? This surfaces the assets that actually matter, which are rarely the ones with the most CVEs.
• What has already been tested, and what changed since?
• What can you not afford to have go down? Feeding straight into the restrictions below.

A good scope is written so that a competent stranger could pick it up and know exactly what they may touch. If it needs you in the room to interpret, it is not finished.

In-scope and out-of-scope, written so neither side can be surprised

Both lists are load-bearing, and the second is the one people skip.

In scope should be unambiguous and enumerable: address ranges in CIDR, fully-qualified domain names, named applications and their environments, the specific accounts provided, and the physical sites if any.

Out of scope should name the things a reasonable tester might otherwise assume were fair game: the production database at certain hours, a legacy system awaiting decommission, third-party-hosted assets, subdomains that resolve elsewhere, anything belonging to a parent or sibling company.

Two details worth getting right:

• Say what happens when scope is ambiguous mid-test. The default should be "stop and ask", and having written that down converts a judgement call into following the procedure.
• Watch for scope defined by name rather than by address. A hostname can resolve to a CDN or a shared host you are not authorised to touch, and DNS can change during the engagement. Resolve and confirm ownership before testing.

Testing windows, blackout periods and who to wake at 3am

The window says when testing may occur. It exists for two reasons: reducing the business impact of something going wrong, and making the client's monitoring interpretable — their analysts need to know which alerts were you.

• Blackout periods protect month-end processing, trading hours, a product launch, or the day the auditors are in.
• Out-of-hours testing reduces disruption but increases risk: fewer people are available if you break something, and their responders may treat your activity as a live incident.
• Emergency contacts on both sides, with numbers that work at 3am, and a named decision-maker who can authorise stopping.

The related habit: keep a timestamped activity log of what you ran and when. When the client asks whether the outage at 02:14 was you, that log is the only thing that can answer honestly.

Third-party assets, cloud tenancy and the permission you do not have

This is lesson 4's material seen from the scoping side, and it belongs in the scope document rather than in your head.

For every in-scope asset, the scope should record who owns the infrastructure under it. A cloud-hosted application sits on a provider's platform, and that provider has its own rules about testing on its infrastructure — those apply in addition to the client's authorisation, never instead of it. Shared hosting, managed services and SaaS all raise the same question.

Where the answer is "not the client", the options are: exclude it, or obtain the third party's permission in writing before the window opens. There is no third option, and an exam scenario that offers you one is testing whether you know that.

Handling scope creep mid-engagement

Scope creep arrives in three shapes, and they need different responses.

1. The client asks for more, often casually — "while you're in there, could you also look at…". The answer is not no; it is not without a change to the authorisation. A written amendment, however brief, signed by someone with standing.
2. You find something interesting just outside scope. A subdomain that resolves to an unlisted host; a trust relationship to another domain. Report its existence as a finding. Do not test it. The interest is exactly the pressure the rule exists to resist.
3. The environment moves under you. New hosts appear mid-test, or an address changes hands. Confirm against the scope before touching, because an address that was in scope on Monday may belong to someone else by Thursday.

The principle behind all three: authorisation is specific, and it does not stretch to cover things that seem similar.

What to take into the exam

• Scope is written for a competent stranger; if it needs interpretation it is not finished.
• The out-of-scope list is as important as the in-scope one.
• Resolve names to addresses and confirm ownership — a hostname is not a target.
• Provider rules apply on top of client authorisation for hosted assets.
• Scope creep of any shape gets a written amendment, never a verbal yes.
• Keep a timestamped activity log; it is what answers "was that you?".