M01-03 · Ethical hacking, authorization and rules of engagement

CEH M01-03 | Ethical Hacking, Legal Authorization and ROE

Module 01: Introduction to Ethical Hacking

Difficulty: ★☆☆☆☆ (Beginner)

Suggested study time: 8–10 minutes

Core concepts: Authorization, Scope, Rules of Engagement (ROE)

1. First, understand: why do hackers need authorization?

Today's most important sentence: being able to enter a system does not mean you have the right to enter it; being allowed to assess a system does not mean you may perform any operation you choose.

Let us connect these three lessons:

1.1 Understand through an everyday example

Suppose you live in an apartment and have recently become concerned about the security of your front-door lock.

You hire a locksmith.

You tell the locksmith:

“I want to know whether someone could easily open my front door. Please check it for me.”

The locksmith accepts the job and begins the inspection.

Three questions now arise:

Question A: may the locksmith inspect your front door?

Yes, because you authorized that inspection.

Question B: may the locksmith also inspect your neighbor's door?

No.

Even if your neighbor has exactly the same lock, the locksmith still has not received the neighbor's permission.

Question C: may the locksmith simply break your door?

Not necessarily.

You authorized “checking the lock's security,” not “destroying the door.”

Unless you agreed in advance to a testing method that might damage the lock, the locksmith must not decide to do that independently.

This illustrates the most important principle of ethical hacking:

Good intentions describe a motive. Legal authorization and compliance with the agreed rules are the basic conditions for conducting a test.

2. What is ethical hacking?

In Chinese, ethical hacking is commonly translated as 道德駭客 or 倫理駭客.

It means:

Using security techniques to assess weaknesses in systems and help an organization improve information security, after obtaining appropriate authorization.

2.1 How does an ethical hacker differ from a malicious hacker?

Suppose a school provides an online system for viewing grades.

Normally, students can view only their own grades.

One day, someone discovers that changing the student number in the URL might reveal another student's grades.

Three different situations could follow:

Note: these are simplified categories commonly used in security education, not formal legal classifications of a person's status.

Whether a hacker is a “good person” cannot be judged only by what they claim to want to do. Their authorization and actual actions also matter.

2.2 How does Taiwanese law address this?

Editorial supplement: This is an introductory summary checked against the Ministry of Justice text, not legal advice for a specific case; a document alone does not remove every legal responsibility.

For example, Article 358 of Taiwan's Criminal Code addresses conduct such as entering another person's account credentials without justification, defeating protective measures or exploiting system vulnerabilities to gain access to another person's computer.

Article 359 addresses obtaining, deleting or altering electronic records without justification and thereby causing damage. Article 360 addresses interfering with a computer system without justification and thereby causing damage.

These provisions remind us that believing one's motives are good does not eliminate the legal risks of security testing. Whether conduct constitutes an offense must still be assessed against the specific actions, legal elements and circumstances of the case. Mojlaw

In practice, therefore:

Before beginning a test, obtain explicit authorization from a party with the authority to grant it, and retain verifiable written records.

3. The three most important concepts: Authorization, Scope and ROE

This is the part most worth remembering today.

Think of these three concepts as taking a formal examination.

Let us examine them one at a time.

3.1 Authorization

Authorization answers: who has the authority to permit you to do this?

For example, you work as an engineer at a company.

The company provides an internal system:

https://internal.example.test

You have your own employee account and can log in normally.

Does that mean you may scan the server with Nmap or independently try to crack other people's passwords?

The answer is: no, it does not.

Two different kinds of permission are involved.

The first: access permission

You are permitted to use a particular company service.

Examples include logging in to the leave-request system, uploading documents or downloading reports you are entitled to access.

The second: security testing authorization

You are permitted to conduct security assessments of specified systems.

Examples include scanning a designated test server for open ports or checking a specified feature for access-control weaknesses.

These two permissions must not be confused.

The authorizing party must also have the corresponding authority.

For example, a company's IT manager may not have the authority to let you test an external cloud provider's entire infrastructure.

Remember for CEH

Authorization = whether appropriate permission has been granted.

However, authorization does not grant unlimited permission to operate.

3.2 Scope

Scope answers: what may you test?

Suppose Northstar has three systems:

Even if these three systems connect to one another, your testing permissions do not expand along those connections.

An everyday analogy

Suppose you are a fire-safety inspector.

Today, you have been commissioned to inspect Building A.

On the second floor, you discover a passage connecting it to Building B.

May you simply enter and inspect Building B?

No.

The reason is:

A connection between systems does not grant you authorization to test the other system.

Scope should identify explicitly excluded targets as well as permitted targets.

In practice, it can specify IP addresses, domains, services, features, test accounts and environment types.

3.3 Rules of Engagement (ROE)

ROE is often translated literally into Chinese as 交戰規則, or “rules of engagement.”

For ease of understanding, think of it as:

The operating rules for a security test.

Suppose the company has agreed to let you test its training website.

Many questions still need answers.

For example:

Until what time may you test?

May you use automated tools?

May you conduct password brute-force testing?

May you run stress tests that could crash the server?

What should you do if you unexpectedly encounter real users' personal information?

These are the kinds of questions ROE addresses.

Six matters to confirm in advance in the ROE

1. Test personnel and responsible contacts: who performs the test? Who may approve, change or stop it?

2. Test targets: which IP addresses, domains, features and accounts may be tested? Which are explicitly excluded?

3. Test window: on which date, at what starting and ending times, and in which time zone?

4. Permitted methods: which tools and techniques may be used? Which high-risk tests are prohibited?

5. Stop conditions: when personal information, service abnormalities or out-of-scope activity are encountered, which activities must stop? How should the situation be reported and testing resumed?

6. Data and report handling: how is evidence retained? Who may view it? How are reports delivered and test data handled?

These principles are not simply an invention of this lesson.

NIST Special Publication 800-115 discusses developing security assessment plans in Chapter 6, assessment execution and coordination in Chapter 7, and provides a reference ROE structure in Appendix B. NIST

It is guidance for managing tests, not a legal authorization document.

4. Worked example: Northstar's student grade system

Now let us put these concepts together.

Suppose Northstar is a company providing online teaching services.

Its system contains two test students:

Alice (Student A)

Bob (Student B)

The intended rules are:

Alice may view only her own answer data.

Bob may view only his own answer data.

The company is concerned about possible access-control issues and commissions you to conduct a security test.

Step 1: establish the ROE before testing

The following is a simplified ROE for teaching purposes.

Assume this document has been formally approved by personnel with appropriate authority.

You now know what you may and may not do.

Step 2: begin testing

Testing begins at 14:00.

You log in to the test website using Alice's account.

You then view Alice's own answers.

The system displays the expected result:

Student: Alice

Answers: A, B, C

No abnormality has been found so far.

Next, using a method permitted by the ROE, you check whether Alice's identity can read Bob's previously prepared test data.

The result:

The system actually returns Bob's answers!

What does this mean?

Technical meaning

Correct access control should produce:

Alice's account → Alice's data: allowed.

Alice's account → Bob's private data: denied.

The observed result, however, is:

Alice's account → Bob's private data: allowed.

This may indicate broken access control.

If the issue is that the system fails to check access permissions correctly for the specified data object, it may also relate to concepts such as IDOR or BOLA.

There is no need to study those vulnerability classifications in depth today. First understand that “the system is not correctly restricting which data a user may read.”

Connect this to the CIA triad in M01-01

Which security objective is primarily affected?

The answer is confidentiality.

Information Alice should not be able to see has been read by Alice.

This also shows that M01-01, M01-02 and M01-03 are not isolated pieces of knowledge.

They can be connected into a complete security-management process.

Step 3: what should you do after finding a weakness?

You are excited.

You have genuinely found a security issue.

You might think:

“Since I can read Bob's data, should I also try the data of another 100 students?”

Do not independently expand the test.

Your authorization is to verify read permissions between the designated test accounts.

It is not permission to download every student's data.

The correct approach is to follow the ROE and retain the minimum evidence necessary to demonstrate the issue.

For example:

Then notify the responsible person using the agreed method.

This approach also reflects principles used in many formal vulnerability disclosure policies: confirm the vulnerability only to the extent necessary, avoiding unnecessary data access and system disruption. U.S. Consumer Product Safety Commission

5. Three situations in which it is easy to cross a boundary

Let us continue with the Northstar example.

Situation 1: the website connects to another server

At 14:40, you discover that the test website connects to:

payment.example.test

You suspect this website has the same issue.

May you check it while you are there?

You must not simply test it.

This website is outside the original scope.

You may record the lead and ask the responsible person whether separate authorization is needed.

Key point: discovering a new target does not grant new authorization.

Situation 2: the test window has ended

At 14:59, you are about to carry out the final check.

Before you finish, the time reaches 15:00.

May you continue by saying, “I only need one more minute”?

You should not continue on your own authority.

The test window is itself part of the ROE.

Stop the unfinished test and confirm whether a valid extension has been authorized.

Situation 3: AI suggests a new tool

Suppose you ask ChatGPT:

“How can I find security vulnerabilities in this website?”

The AI suggests running a particular security tool.

May you simply follow that suggestion?

You must not run it merely because AI recommended it.

You still need to check the tool's targets, parameters, potential effects and whether the ROE permits the activity.

For example, Nmap is a common network scanning tool, but the tool itself does not determine whether a user's testing is lawful.

A tool's capabilities and your permissions are two different things.

6. Practical clarification: may anyone test a public website?

This is an easy point to misunderstand.

For example, you discover a company's website online.

Anyone can browse it, and registration is not required.

Does this mean you may scan it for vulnerabilities?

Offering a service publicly is not the same as publicly authorizing security testing.

Some organizations do establish a:

Vulnerability Disclosure Policy (VDP)

or a Bug Bounty Program.

Such policies may explicitly identify the systems open to security research, permitted methods, prohibited activities and reporting procedures.

However, the existence of a VDP does not mean that all of an organization's assets may be tested.

For example, the U.S. Department of Commerce's vulnerability disclosure policy explicitly excludes out-of-scope systems, third-party services and certain high-risk testing methods. U.S. Department of Commerce

Verification note (2026-10-27): The source paragraph is retained. The Commerce URL returned 403, so its current individual restrictions could not be verified; this is not evidence of permission. The independently verified CPSC policy excludes unlisted and third-party systems and prohibits denial-of-service tests, illustrating the same principle.

An NDA (Non-Disclosure Agreement) also differs from testing authorization.

An NDA primarily establishes confidentiality obligations. By itself, it does not mean that you have received permission to conduct security testing.

7. Turn today's knowledge into a decision process

You can use this decision framework before conducting any security test in the future.

Security testing decision flow

Want to conduct a security test on a system
                   |
                   v
    Have appropriate authorization?
                   |
          +--------+--------+
          |                 |
          No               Yes
          |                 |
          v                 v
     Do not test    Is the target in scope?
                            |
                   +--------+--------+
                   |                 |
                   No               Yes
                   |                 |
                   v                 v
            Stop and confirm   Do method and time
                                 comply with ROE?
                                      |
                             +--------+--------+
                             |                 |
                             No               Yes
                             |                 |
                             v                 v
                      Stop and confirm    Perform the test
                                               |
                                               v
                                    Has a stop condition arisen?
                                               |
                                      +--------+--------+
                                      |                 |
                                     Yes                No
                                      |                 |
                                      v                 v
                               Stop and report   Continue under
                                      |             the rules
                                      v
                             Await proper approval

Supplemental visual: a compact reading aid for the original decision tree, not a replacement for its full flow.

Two points about this process deserve attention.

First, authorization is not something to check only once at the beginning. When the target, timing or method changes, you must reconfirm whether the existing authorization still covers those activities.

Second, stopping the relevant tests does not necessarily mean permanently cancelling the entire project. Whether other tests may continue and when stopped work may resume should follow the response and approval procedures agreed in advance.

8. Essential points for the CEH exam and practical work

You do not need to memorize a long list of tools or commands for this lesson.

The most important task is to distinguish the following concepts.

Pay particular attention to this:

Authorization, scope and ROE are distinct management concepts, but their documentation may be combined in one assessment plan.

Whether conducting penetration testing, vulnerability scanning or other security assessments, first confirm the corresponding authorization and testing rules.

9. Understanding checks

Try answering in your own words before looking at the answers.

Question 1: conceptual understanding

An engineer has an administrator account for the company's internal system.

The engineer believes that being an administrator should allow them to perform any security test on that system.

What is wrong with that reasoning?

Question 2: CEH scenario

You have formal authorization to test account permissions on Website A today between 14:00 and 15:00.

At 14:50, you discover that Website A connects to Server B.

B is not on the originally approved target list.

You believe B may have a serious vulnerability.

Which action is most appropriate?

A. Because A connects to B, B is automatically included in the authorized scope and may be tested.

B. As long as no system damage is caused, test B first and report it afterward.

C. Do not conduct further testing on B. First record the lead and consult the authorization contact; obtain additional authorization if needed.

D. First scan B with an AI-recommended tool to determine whether it has a weakness, then decide whether to request authorization.

Question 3: practical judgment

Suppose you have found, in Northstar's test environment, that Alice can read Bob's fictional answers.

What evidence would be sufficient to demonstrate the issue?

Do you need to obtain the data of another 100 students?

Explain your reasoning.

10. Today's learning summary

Remember just three sentences today:

Authorization: who has the authority to approve?

Scope: what has been approved for testing?

ROE: how has testing been approved, and when must it stop?

These concepts are important foundations before moving on to CEH M02 (Footprinting), M03 (Scanning Networks), M04 (Enumeration) and even M06 (System Hacking).

Whether gathering information, scanning networks, enumerating accounts or verifying vulnerabilities, being technically able to do something never automatically makes it permitted.

Reference: NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, Chapters 6–8 and Appendix B.

Next step: answer the three questions above first. I will use your answers to assess whether you have understood today's core concepts and reinforce anything you have not yet understood, rather than immediately moving to the next lesson.

Editorial supplement: The supplied ten-section lesson is the primary text, including its invitation to answer first. Reference answers are provided below in closed disclosures. Publishing answers does not establish learner understanding, change the series schedule, or count as another concept delivery.

Reveal Question 1 reference answer: Does administrator access permit every test?

No. An administrator account provides technical capabilities, not blanket organizational authorization. Separately confirm the proper approver, targets, permitted methods and time window.

Being able to act is different from being permitted to act. Avoiding damage does not itself make an out-of-scope activity authorized.

Reveal Question 2 reference answer: May you test B because A connects to it?

Choose C. Do not test B further; record the observed lead and contact the authorization owner. Obtain appropriate new authorization and updated rules if B needs testing.

Connectivity, an expectation of no damage and an AI tool recommendation do not authorize B. The original window for A still ends at 15:00 unless validly extended.

Reveal Question 3 reference answer: How much evidence is enough?

Within the approved synthetic data, record time, environment, Alice as the acting identity, the designated Bob response, expected denial and actual permission, with the minimum reproducible evidence needed.

Do not independently retrieve another 100 students’ data. That expands access and scope beyond what is necessary to establish the observed problem. Further coverage requires appropriate approval.

The evidence establishes the specific unexpected read access, not that all records have leaked, that write access is possible or that all other accounts behave the same way.