Ethics, Authorisation and Responsible Disclosure

Lesson plan

Level

Beginner

Time

About 65 minutes; the steps below add up to 67

The original lesson, kept word for word, states its rule first (authorisation and intent are fundamental); the guided version first shows two people trying the same windows of a house, so learners find that permission and purpose make the difference, and that permission has boundaries, before the rule is stated. The comparison is stopped deliberately: computer systems are often run by one organisation for another, so who may give permission is itself a question. Predictions precede each point where beginners go wrong: an administrator testing without asking, testing after hours, checking a suspected flaw “just once”, and publishing a flaw to warn users. The habit to build: before acting, ask who agreed to this, and what exactly they agreed.

Objectives

• Explain why permission and purpose, not the technique, separate security testing from harm
• Say who may give permission for testing, and what a written scope covers
• Explain why finding a weakness gives no permission to exploit it
• Describe the steps of responsible disclosure, and why details stay private until a fix exists
• Report a concern inside an organisation without investigating beyond your role

Before the lesson

• Open this page on your own screen and use “Open the lesson window” to open the lesson in a second window. Share only that second window.
• Learners need the People, Processes and Technology and Least Privilege lessons first.
• Be ready to say that the lesson's legal points are general education, not legal advice.
• The lesson takes about 67 minutes. To teach it in two parts, stop after “Discovering is not permission to exploit”; the second part opens with “Responsible disclosure”.
• In presentation mode every step is shown in turns: Next reveals one moment, part or answer at a time, and the instructor view names what is on screen and what comes next.

Steps

1. Introduction Opening

   On screen: the lesson’s title, module and number; Next adds its objectives and key terms, as the lesson page lists them; Next again begins the first step.

   Objectives on screen

   • Explain why permission and purpose, not the technique, separate security testing from harm
   • Say who may give permission for testing, and what a written scope covers
   • Explain why finding a weakness gives no permission to exploit it
   • Describe the steps of responsible disclosure, and why details stay private until a fix exists
   • Report a concern inside an organisation without investigating beyond your role

   Purpose: The original lesson, kept word for word, states its rule first (authorisation and intent are fundamental); the guided version first shows two people trying the same windows of a house, so learners find that permission and purpose make the difference, and that permission has boundaries, before the rule is stated. The comparison is stopped deliberately: computer systems are often run by one organisation for another, so who may give permission is itself a question. Predictions precede each point where beginners go wrong: an administrator testing without asking, testing after hours, checking a suspected flaw “just once”, and publishing a flaw to warn users. The habit to build: before acting, ask who agreed to this, and what exactly they agreed.

2. 1. The same action, two meanings Think 7 min

   Purpose: Find that permission and purpose separate the two people, and that permission has limits, before any term is used.

   Ask

   • Both try the same windows. Why is one acceptable?
   • The back window looks open, but only the front was agreed. What now?

   Responses to expect

   • “The adviser is a professional” comes up; ask what would happen if the adviser had not been asked.
   • Some would check the back window “to be helpful”. Ask who decides what is checked.
   • On screen in turns: the opening question, its answer; then the question on the back window, and its answer; where the house comparison stops.

   Discussion pause: Collect answers to the second question before revealing the explanation.

   In the lesson window

   • Think it through: Both do exactly the same thing. What makes one of them acceptable?
   • Think it through: The owner asked the adviser to check only the front of the house. From the front, the adviser can see that a back window looks open. What should the adviser do?

3. 2. Why ethics comes first Explain 5 min

   Purpose: State the principle and separate reasoning about attacks from carrying them out.

   Ask

   • Is sketching an attack on paper acceptable?

   Responses to expect

   • Some think any attack planning is wrong. Ask whether anything was tried against a real system.
   • On screen in turns: the opening; then what thinking like an attacker means; the check question on the apprentice’s sketch, and its answer.

   If the explanation does not land: A locksmith teaching a class how locks fail is teaching; the same locksmith opening a stranger’s door is breaking in. The knowledge is the same; permission and purpose differ.

   In the lesson window

   • Check your understanding: An apprentice sketches, on paper, how an attacker might reach their employer’s customer database, to suggest where a control could stop it. Is that acceptable?

4. 3. Permission and scope Predict 14 min

   Purpose: Establish written permission from someone entitled to give it, separate it from account access, and show that scope includes systems and time.

   Ask

   • Sam has full administrator access. May Sam test the servers without asking?
   • 18:30, one more check: allowed?
   • Does a clean report prove the systems are secure?

   Responses to expect

   • Many say Sam may, because Sam runs the servers. Ask who agreed to a test.
   • The timeframe is often forgotten; point to the agreed hours.
   • Diagram: reveal the boundaries one at a time, from everything reachable inwards, and ask what each boundary adds before showing the next.
   • On screen in turns: the opening question, its answer; then the two meanings of authorisation; the question on the after-hours check, and its answer; scope as boundaries, starting with everything you could reach; the second boundary: who controls the systems; the third boundary: what was agreed in writing; the innermost area: what the test actually does; the out-of-scope link, up to the unexpected server; what the tester does next, and why; what a clean report does not show; the check question on the clean report, and its answer.

   Misconceptions to challenge

   • A learner may believe: “If I can reach it, I am allowed to test it.” Respond: Reach gives no permission. Agreement in writing, from someone entitled to give it, does.
   • A learner may believe: “Permission for one system covers anything connected to it.” Respond: Only the agreed scope is covered; the out-of-scope link example shows the right response.

   If the explanation does not land: Return to the house: the agreement named the front windows, on one evening.

   In the lesson window

   • Think it through: Sam is an IT administrator with full access to the company’s servers. One evening, without asking anyone, Sam runs a tool that searches them for weaknesses. Is that authorised testing?
   • Think it through: A tester agreed to test a company’s network from 09:00 to 17:00 on Monday. At 18:30 they think of one more check. May they run it?
   • Check your understanding: A penetration test finds no serious weaknesses. A manager says the systems are now proven secure. What is the best response?

5. 4. Discovering is not permission to exploit Predict 9 min

   Purpose: Apply the bank-door principle: finding a weakness gives no permission to use it, and the same holds for search tools.

   Ask

   • May you change the order number once, just to check?

   Responses to expect

   • “Only to confirm it” is the common answer; it still means opening another customer's data.
   • On screen in turns: the opening; then the two paths after finding a weakness, with the starting point only; the path of reporting it; the path of exploiting it; tools that reveal exposed systems; the question on checking another customer’s order, and its answer; the online-shop order, handled step by step.

   Misconceptions to challenge

   • A learner may believe: “I was only checking, not causing harm.” Respond: Good intentions do not replace permission, and looking at another person's data is itself the harm.

   Discussion pause: Show only the starting point of the two-path diagram and ask the class what they would do, before revealing either path.

   In the lesson window

   • Think it through: On a shop’s order page you notice that changing the number in the address might show someone else’s order. Is it acceptable to try once, just to check before reporting it?

6. 5. Responsible disclosure Predict 8 min

   Purpose: Teach the steps of responsible disclosure, bug bounty scope, and why payment must never be demanded.

   Ask

   • Would posting the flaw publicly be the best way to warn users?
   • Does a bug bounty for the website cover the email server?

   Responses to expect

   • Some favour publishing to protect users; ask who else reads the post before a fix exists.
   • Diagram: step through the four stages and ask, at each, what would go wrong if it were skipped.
   • On screen in turns: the opening question, its answer; then the name for reporting carefully, and its stages; the diagram’s stages one at a time; bug bounties, and never asking for payment; the check question on the bug bounty’s scope, and its answer.

   Misconceptions to challenge

   • A learner may believe: “Responsible disclosure means publishing the details straight away.” Respond: Report privately first; publish, if at all, once a fix exists.

   In the lesson window

   • Think it through: You find a serious flaw in a popular app. Posting the details publicly would warn every user at once. Is that the best first step?
   • Check your understanding: An organisation runs a bug bounty programme for its main website. A researcher notices the organisation’s staff email server nearby. May they test it?

7. 6. Reporting concerns inside an organisation Check 5 min

   Purpose: Bring the principles home: report concerns in your own organisation without investigating beyond your role.

   Ask

   • Should you open a few payroll files before reporting?

   Responses to expect

   • Some want evidence first. A note of what was seen, and where, is enough.
   • On screen in turns: the opening question, its answer; then what to do about the open folder.

   If the explanation does not land: Compare noticing a fire door wedged open at work: you report it to the person responsible; you do not test whether the alarm works by setting it off.

   In the lesson window

   • Think it through: You notice that a folder of payroll documents seems to be open to all staff. Should you open a few files to see how bad it is before reporting?

8. 7. Legal and professional considerations Explain 6 min

   Purpose: Summarise the law, data protection and professional conduct as general education.

   Ask

   • Nothing was changed. Is the access still an offence?

   Responses to expect

   • Many assume no damage means no offence. Permission is what the law turns on.
   • On screen in turns: the opening; then the law, data protection and professional conduct; the check question on access “only to show it”, and its answer.

   Misconceptions to challenge

   • A learner may believe: “If nothing is damaged, no offence is committed.” Respond: Under the Computer Misuse Act 1990, unauthorised access can itself be an offence. Permission, not the absence of damage, makes access lawful.

   In the lesson window

   • Check your understanding: Someone accesses a company’s server without permission, to show that it is insecure, and changes nothing. In UK law, what matters most?

9. 8. Apply it in a new situation Apply 4 min

   Purpose: Set up independent application, ideally on a later day.

   Ask

   • Who will try these now, and who later in the week?

   Responses to expect

   • The charity question checks who is entitled to give permission; the chatbot question checks policy before sharing data.
   • On screen in turns: the opening question, its answer; then the question on the customer spreadsheet and a chatbot, and its answer.

   In the lesson window

   • Apply it: A friend who works for a small charity asks you to “have a go” at breaking into its website as a favour, to see whether it is secure. What should happen first?
   • Apply it: A colleague wants to paste a spreadsheet of customer complaints, with names and addresses, into a public AI chatbot to summarise it. What should happen first?

10. 9. Check your understanding Check 6 min

    Purpose: Check the lesson against the approved revision-bank questions.

    Ask

    • Answer individually, then compare before revealing.

    Responses to expect

    • The shared-platform question links back to the second boundary in the scope diagram.
    • On screen in turns: the opening; then the revision questions one at a time, each followed by its answer; where to practise next.

11. 10. What to remember Consolidate 3 min

    Purpose: Summarise the five points and the misunderstandings.

    Ask

    • Without looking: what two questions do you ask before testing anything?

    Responses to expect

    • Who agreed to it, and is it inside what they agreed?
    • On screen in turns: the opening; then the summary; the key terms; the common misunderstandings.

12. Lesson recap Closing

    On screen: the lesson’s objectives again; Next adds the closing question, which asks the class to explain each one in their own words without looking back. It says nothing about what anyone has learnt: use the answers to decide what to revisit.

    Points to listen for

    • The difference between testing and harm lies in who agreed and why, not in the technique.
    • Written agreement, from someone with authority over the system, bounded by systems and time.
    • Managing a system and being allowed to test it are different things.
    • A discovered weakness is reported privately, never tried.
    • In your own organisation, report what you saw and let others investigate.

Consolidation

• The difference between testing and harm lies in who agreed and why, not in the technique.
• Written agreement, from someone with authority over the system, bounded by systems and time.
• Managing a system and being allowed to test it are different things.
• A discovered weakness is reported privately, never tried.
• In your own organisation, report what you saw and let others investigate.