Authorization and Scope

🎯

Learning Objectives

By the end of this lesson, students should be able to:

1. Define authorization in ethical security testing.
2. Explain why written authorization is important.
3. Define assessment scope.
4. Distinguish between in-scope and out-of-scope assets.
5. Explain rules of engagement.
6. Identify common testing restrictions.
7. Explain scope creep.
8. Describe emergency stop procedures.
9. Explain how third-party systems affect authorization.
10. Create a basic authorization and scope checklist.

📖

Lesson Content

Authorization and scope are two of the most important foundations of
ethical security testing. Technical skill alone does not make a security
assessment ethical. A professional must know exactly what they have
permission to test, when they may test it, what activities are allowed,
and what activities are prohibited.

This lesson explains how security professionals establish boundaries
before an assessment begins.

1. What Is Authorization?

Authorization is formal permission given by the appropriate system owner,
organization, or authorized representative allowing a security
professional to perform specified security activities.

Authorization establishes that the assessment is permitted. Without
authorization, security testing against another person’s or
organization’s system may become unauthorized activity.

Golden Rule:
Never assume that a publicly accessible system is automatically
authorized for security testing.

2. Why Authorization Matters

Authorization protects both the organization and the security tester.
It establishes a documented understanding of what the security team is
expected and permitted to do.

Authorization helps to:

Define permission to conduct testing.
Establish responsibility.
Identify approved targets.
Reduce misunderstandings.
Define testing limitations.
Protect business operations.
Support legal and organizational compliance.
Provide an escalation path when problems occur.

3. Written Authorization

Professional security assessments should be supported by written
authorization whenever possible.

The document should identify the organization, authorized personnel,
approved targets, assessment dates, permitted activities, restrictions,
contacts, and reporting expectations.

4. What Is Scope?

Scope defines the boundaries of a security assessment.
It answers the question:
“Exactly what are we allowed to test?”

Scope can include technical assets, applications, domains, networks,
cloud resources, physical locations, accounts, APIs, mobile applications,
and other approved resources.

5. In-Scope Assets

In-scope assets are the systems and resources that the security team is
authorized to assess.

Examples may include:

training.example.test
Approved web applications
Approved API endpoints
Specified test servers
Approved cloud resources
Authorized test accounts

These examples are illustrative. Real security testing should only be
performed against targets explicitly authorized by the owner.

6. Out-of-Scope Assets

Out-of-scope assets are systems that must not be tested.

An organization may have several connected systems but authorize testing
against only one application. The existence of a technical connection
does not automatically extend the authorization.

Examples of exclusions may include:

Production payment systems
Third-party infrastructure
Customer-owned systems
Employee personal devices
Critical infrastructure
Systems specifically excluded by management

7. Rules of Engagement

Rules of engagement, commonly called ROE, describe how the assessment
will be conducted.

They transform a general authorization into practical operational
instructions.

Rules of engagement can specify:

Testing dates
Testing hours
Approved source IP addresses
Approved accounts
Permitted techniques
Restricted techniques
Prohibited activities
Emergency procedures
Communication channels
Evidence requirements
Reporting requirements

8. Time Restrictions

Some organizations allow security testing only during specific periods.
This reduces the possibility that testing will interfere with critical
business operations.

For example, an organization may permit testing between 10:00 PM and
2:00 AM while restricting testing during peak business hours.

Security professionals should follow the approved schedule unless the
authorization is formally changed.

9. Testing Restrictions

An assessment may authorize some security activities while prohibiting
others.

For example, an organization might authorize vulnerability assessment
and controlled validation while explicitly prohibiting destructive
testing, denial-of-service testing, or access to production customer
records.

10. Production vs Testing Environment

Organizations may maintain separate development, testing, staging, and
production environments.

A security professional must confirm which environment is authorized.
Testing a development application does not automatically authorize
testing the production version.

11. Third-Party Systems

A company may use third-party services such as hosting providers,
payment platforms, cloud services, email providers, or external APIs.

Authorization from one organization does not necessarily grant permission
to test infrastructure owned by another organization.

Third-party testing may require additional approval from the relevant
provider.

12. Scope Creep

Scope creep occurs when testing gradually expands beyond the originally
approved boundaries.

For example, a tester may discover another application belonging to the
same organization and decide to test it even though it was not included
in the original authorization.

The correct response is to stop and obtain approval before expanding
the assessment.

13. Emergency Stop Procedure

A professional assessment should have a clear procedure for stopping
testing if an unexpected problem occurs.

Possible triggers include:

Unexpected service disruption
Possible data corruption
Unexpected access to sensitive information
Security incident
Customer impact
System instability

14. Emergency Contacts

The assessment plan should identify people who can be contacted if a
serious issue occurs.

Contacts may include:

Security manager
IT administrator
System owner
Incident response team
Project manager
Emergency technical contact

15. Scope Validation Before Testing

Before beginning an assessment, the security team should review the
scope carefully.

A basic scope validation should confirm:

Who authorized the assessment?
What assets are included?
What assets are excluded?
When may testing occur?
Which techniques are permitted?
Which techniques are prohibited?
Who is the emergency contact?
How should findings be reported?

16. Scope Documentation Example

Category	Example
Organization	Dwallnet Training Environment
Target	Authorized training application
Environment	Staging
Testing Period	Approved assessment window
Allowed Activities	Non-destructive security testing
Excluded Activities	Destructive testing
Emergency Contact	Designated security representative
Reporting	Formal security report

17. Authorized Accounts

Some assessments require test accounts.
These accounts should be explicitly approved and should not be confused
with real customer or employee accounts.

Using dedicated test accounts reduces the risk of exposing or modifying
real user information.

18. Data Handling Requirements

The scope document should explain how sensitive information discovered
during testing will be handled.

This may include:

Where evidence will be stored.
Who can access evidence.
How evidence will be encrypted.
How long evidence will be retained.
When evidence will be securely deleted.
How sensitive information will be removed from reports.

19. Communication Plan

Security testing should have an agreed communication process.

The team should know who receives daily updates, urgent findings,
critical alerts, technical questions, and the final report.

20. Handling a Newly Discovered Asset

During an assessment, a tester may discover a new server, domain,
application, or service that was not included in the original scope.

The correct approach is to document the discovery and request approval
before testing the new asset.

Remember:
Discovery does not automatically equal authorization.

21. Authorization Changes

Sometimes an organization needs to expand or reduce the assessment
scope after testing has started.

Changes should be documented and approved before the security team
operates under the new boundaries.

22. Authorization Checklist

Written authorization received.
System owner identified.
Testing team identified.
Approved targets listed.
Excluded targets listed.
Testing dates confirmed.
Permitted activities confirmed.
Prohibited activities confirmed.
Emergency contacts identified.
Evidence handling requirements documented.
Reporting process documented.

23. Practical Scenario

A company asks a security team to assess its public training portal.
The company authorizes testing of the staging environment but excludes
its payment system and production database.

During reconnaissance, the security team discovers a payment-related
subdomain.

Because the payment system is outside the approved scope, the team
documents the discovery but does not perform security testing against it.

The team informs the authorized contact and requests clarification if
additional testing is required.

This demonstrates proper respect for authorization and scope.

24. Practical Lab

Create a fictional authorization and scope document for a website or
application that you own or have permission to assess.

Include:

Organization name
System owner
Security assessment team
Assessment objective
In-scope assets
Out-of-scope assets
Testing dates
Testing hours
Allowed activities
Prohibited activities
Emergency stop procedure
Emergency contact
Evidence handling requirements
Reporting procedure

Use only systems that you own or have explicit authorization to assess.

25. Knowledge Check

What is authorization?
Why should security testing be authorized?
What is the purpose of scope?
What are in-scope assets?
What are out-of-scope assets?
What are rules of engagement?
What is scope creep?
Why are emergency contacts important?
What should a tester do when discovering an out-of-scope asset?
Why should third-party systems receive special consideration?

26. Key Terms

Authorization: Formal permission to conduct approved security activities.
Scope: Defined boundaries of a security assessment.
In-Scope: Assets and activities explicitly included in testing.
Out-of-Scope: Assets and activities excluded from testing.
Rules of Engagement: Instructions defining how an assessment should be conducted.
Scope Creep: Unapproved expansion of assessment activities.
System Owner: Person or organization responsible for an asset.
Emergency Contact: Authorized person to contact when a serious issue occurs.
Test Account: Account specifically created or approved for assessment purposes.
Third Party: External organization that owns or operates a service or system.

27. Summary

Authorization and scope establish the legal, operational, and technical
boundaries of an ethical security assessment.

A responsible security professional confirms authorization before
testing, understands every in-scope and out-of-scope asset, follows the
rules of engagement, protects sensitive information, respects testing
schedules, and stops when an activity falls outside the approved scope.

Good security testing begins with clear boundaries.

Next Lesson:
Security Assessment Methodology

💻

Code Example

<?php

/*
 * Safe authorization check for an assessment plan.
 * This does not perform any security testing.
 */

$assessment = array(
    'authorized' => true,
    'target'     => 'training.example.test',
    'environment'=> 'staging',
    'scope'      => 'approved'
);

if (
    $assessment['authorized'] !== true ||
    $assessment['scope'] !== 'approved'
) {
    die('Assessment cannot proceed.');
}

echo 'Assessment is within the approved scope.';

?>

⭐

Key Takeaways

• Authorization must exist before security testing begins.
• Scope defines the exact boundaries of an assessment.
• In-scope assets may be tested according to the approved rules.
• Out-of-scope assets must not be tested without additional authorization.
• Rules of engagement explain how testing should be performed.
• Scope creep must be avoided.
• Testing schedules and restrictions should be respected.
• Emergency contacts and stop procedures should be established.
• Third-party infrastructure may require separate authorization.
• Authorization and scope should be reviewed before and during an assessment.

Learning Objectives

Lesson Content