Ethical, Legal & Professional Boundaries in Cybersecurity

Prerequisites

• FND-K001: The CIA Triad, Security Goals & the Modern Threat Landscape

Why This Lesson Matters

Cybersecurity skills are inherently dual-use. The techniques used to find and fix vulnerabilities are identical to the techniques used to exploit them. This creates a professional obligation that does not exist in most other technical fields: you must understand exactly where the legal and ethical line is before you ever run a scan, open a network monitor, or write an exploit.

This lesson is not legal advice — always consult a lawyer for specific situations. It is, however, a professional baseline. Practitioners who act without understanding these boundaries routinely damage their own careers, expose their employers to liability, and cause real harm to organisations and individuals who never consented to being tested.

Ignorance is not a defence. "I thought I had permission" is not a defence. "The network was openly accessible" is not a defence.

1. The Core Principle: Authorisation

Everything in offensive security rests on a single question: do I have explicit, documented, in-scope authorisation to perform this action against this system right now?

If the answer is yes → proceed, carefully. If the answer is no or unclear → stop.

1.1 What counts as authorisation

Valid authorisation is: - Written and signed (email is acceptable in many jurisdictions; a formal contract is better) - Specific about scope — which systems, which techniques, which time window - Signed by someone with authority to grant it (a sysadmin's "yeah go ahead" is not sufficient; the system owner or an authorised executive must sign) - Scoped to techniques — "you can scan" ≠ "you can exploit" ≠ "you can pivot to other systems"

Invalid authorisation includes: - Verbal permission only - Permission from someone who does not own the system - A screenshot of a Slack message - "I own the company that uses this SaaS platform, therefore I can test their infrastructure" — no, you test your tenant, not the platform - Testing a client's third-party software vendor without that vendor's consent

1.2 Bug bounty programmes

Bug bounty programmes publish a scope document that defines what is in scope, what is out of scope, and what techniques are permitted. This scope document is a form of authorisation — but it has strict limits.

Common out-of-scope items in bug bounty programmes: - DoS attacks (even to prove an endpoint is vulnerable to DDoS) - Social engineering of employees - Physical access attempts - Automated scanning that exceeds defined rate limits - Systems belonging to third-party providers - Accessing or downloading data beyond minimum necessary to demonstrate impact

Violating bug bounty scope removes your legal protection, regardless of the vulnerability you found.

2. Legal Framework

2.1 Canada — Criminal Code

The primary Canadian statutes relevant to cybersecurity practitioners:

Criminal Code s. 342.1 — Unauthorized use of computer

Every person who fraudulently and without colour of right (a) obtains, directly or indirectly, any computer service; (b) by means of an electro-magnetic, acoustic, mechanical or other device, intercepts or causes to be intercepted, directly or indirectly, any function of a computer system; (c) uses or causes to be used, directly or indirectly, a computer system to commit a criminal offence; or (d) uses, possesses, traffics in or permits another person to have access to a computer password that would enable a person to commit an offence under paragraph (a), (b) or (c)...

The key phrase is "without colour of right." A signed authorisation letter is your "colour of right." Without it, even reading a file on a server you have network access to can constitute a criminal offence.

Criminal Code s. 430(1.1) — Mischief in relation to data

Covers wilful destruction, alteration, or obstruction of data and computer systems. Even a security test that accidentally causes service disruption (a crashed web server, an overloaded database) could be captured by this provision if it was not authorised.

2.2 Canada — Privacy Law

PIPEDA (Personal Information Protection and Electronic Documents Act) and Quebec's Law 25 (Bill 64) govern how personal information is collected, used, and disclosed. If during a security assessment you encounter, copy, or retain personal information:

• You have an obligation to handle it with the same care as the organisation you are testing
• You must not use it for any purpose other than demonstrating the vulnerability
• You must securely delete it at the end of the engagement
• If you discover that personal data has been breached (by someone else), Law 25 creates a 72-hour notification obligation for the organisation

2.3 United States — Computer Fraud and Abuse Act (CFAA)

The CFAA is the primary US federal computer crime statute. It prohibits accessing a protected computer "without authorization" or "exceeding authorized access." The law has been criticised for its broad language — it has been used to prosecute people for violating a website's terms of service.

Key CFAA provisions relevant to security practitioners: - 18 U.S.C. § 1030(a)(2): Obtaining information by unauthorised computer access - 18 U.S.C. § 1030(a)(5): Causing damage to a protected computer

2.4 European Union — NIS2 Directive

NIS2 (Network and Information Security Directive 2) came into force in 2024 and significantly raises the bar for cybersecurity obligations in the EU. Key obligations: - Risk management measures (technical and organisational) - Incident reporting: significant incidents within 24 hours (initial warning), 72 hours (notification), 1 month (final report) - Supply chain security - Penalties up to €10 million or 2% of global annual revenue for essential entities

2.5 Responsible Disclosure

When you discover a vulnerability — in a bug bounty programme, during authorised testing, or (more awkwardly) through legitimate research — the responsible path is coordinated disclosure:

1. Document the vulnerability thoroughly (no more access than necessary to reproduce)
2. Contact the vendor/owner through their official security contact
   ([email protected], security.txt file, HackerOne programme)
3. Provide a clear, reproducible proof of concept
4. Agree on a disclosure timeline (90 days is standard; Google Project Zero uses this)
5. Allow the vendor to patch before publishing
6. Publish after the window closes, whether or not a patch exists
   (publishing keeps users informed and creates pressure to fix)

Do not: - Demand payment for silence (this is extortion) - Exploit the vulnerability beyond what is necessary to prove it exists - Disclose the vulnerability publicly before the agreed timeline unless the vendor stops communicating - Use the vulnerability to access data that is not relevant to demonstrating the flaw

3. Professional Ethics

3.1 The Security Professional's Code

No single globally binding code exists, but several organisations have published ethical frameworks:

EC-Council Code of Ethics (governs CEH, CPENT certifications): - Keep client information confidential - Never access a computer system without permission - Disclose to appropriate parties all discovered information hazards - Respect intellectual property and privacy rights

ISC² Code of Ethics (governs CISSP, SSCP): Four mandatory canons, in priority order: 1. Protect society, the common good, necessary public trust and confidence, and the infrastructure 2. Act honorably, honestly, justly, responsibly, and legally 3. Provide diligent and competent service to principals 4. Advance and protect the profession

The priority ordering matters. If acting in the interest of your client conflicts with protecting the public, the public wins. A CISSP who discovers their client is committing fraud has an ethical obligation that overrides client confidentiality.

3.2 Conflicts of Interest

A penetration tester who discovers evidence of fraud, child exploitation material, or active attacks against third parties faces a serious conflict. The general principle: - For criminal activity: consult legal counsel before deciding whether to report - For CSAM (child sexual abuse material): report immediately; there is no professional confidentiality that overrides this - For evidence of active attacks on third parties: weigh client confidentiality against duty to warn

3.3 Scope Creep

Scope creep is when a tester goes beyond the authorised scope during an engagement — finding something interesting and following it, even if it leads outside the defined boundary.

Examples: - Testing an in-scope web application, discovering a link to an out-of-scope admin panel, and testing it anyway - Compromising an in-scope server and using it to pivot to out-of-scope internal infrastructure - Exfiltrating a sample of real production data "to prove the severity" of a finding

All of these are violations, even if the tester's intent was to demonstrate value. Stop at the boundary. Document what you found and could have done. Report it. Do not cross.

4. Practical Scenarios

Scenario 1 — The Eager Intern

A new security analyst is told to "look at the company's public web presence for vulnerabilities." They run a full Nmap scan against the company's IP range and discover a server running an unpatched version of Apache. They exploit it to obtain a shell "to prove the severity."

What went wrong: - "Public web presence" did not authorise active exploitation — only passive observation - Obtaining a shell is unauthorised access even on a company-owned server if not explicitly authorised - The correct action: document the finding, report to the manager, and wait for explicit authorisation before proceeding

Scenario 2 — The Cloud Misconfiguration

A developer is browsing a public S3 bucket that appeared in search results. The bucket belongs to a competitor and contains what appears to be proprietary pricing data. They download several files to "see if it's really sensitive."

What went wrong: - A misconfigured public bucket is not authorised access; it is unauthorised access to data the owner did not intend to make public - Downloading the files is a CFAA violation (US) and Criminal Code s. 342.1 violation (Canada) - Correct action: stop, do not download, contact the organisation via a responsible disclosure channel

Scenario 3 — The Bug Bounty Boundary

A researcher is participating in a company's bug bounty programme. They find a SQL injection that they believe could expose the entire customer database. The programme scope says "demonstrate impact without accessing user data." The researcher dumps 1,000 records to show the vulnerability is real.

What went wrong: - The scope explicitly prohibited accessing user data - Dumping records violates the scope, likely violates privacy law, and removes the researcher's safe harbour - Correct action: demonstrate the injection point by extracting database metadata (version, table names) — not row data

5. Common Mistakes

Mistake 1: "The system was left open — that means it's okay to access." No. Misconfiguration is not consent. A window left open is not an invitation to enter a house.

Mistake 2: "I found it on the internet, so it's public information." Not all publicly accessible data is data you have authorisation to access or use. Personal data has legal protections regardless of how it was exposed.

Mistake 3: "My employer told me to test it, so I'm covered." Verify that your employer has written authorisation from the system owner. If you cannot see the contract, ask. "Just trust us" is not sufficient professional protection.

Mistake 4: "I disclosed the vulnerability privately, so I can publish immediately." Coordinated disclosure requires waiting for the agreed timeline, not just sending an email. If you publish before the vendor has a reasonable opportunity to patch, you are potentially facilitating harm to users.

Mistake 5: Storing client credentials, PII, or sensitive data after an engagement. Any sensitive data captured during an engagement must be securely destroyed at engagement close. Retaining it — even on an encrypted drive — creates liability.

6. Practice Exercises

1. Read the following engagement scenario and identify every element that is missing from the authorisation:

   "A startup founder sends you a LinkedIn message: 'Hey, can you have a look at our website and tell us if it has any vulnerabilities? We really need to know before our launch next week. Here's the URL: [link]'"

2. A client asks you to "test everything." Write a scope statement that converts this into a professional, bounded authorisation document. Include: in-scope targets, out-of-scope exclusions, permitted techniques, testing window, emergency contact, and data handling requirements.

3. You are three days into a penetration test when you discover a database backup file that contains what appear to be plaintext credit card numbers. You were not authorised to test the database server — you found this file on a misconfigured web share that was in scope. Describe step-by-step what you do next.

7. Lab

Assessment mode: quiz

Scenario-based quiz: 6 situations. For each, you must decide whether the action described is (a) authorised and ethical, (b) unauthorised but arguably well-intentioned, or (c) clearly unlawful. You must also identify the specific law or ethical principle being violated or upheld.

8. Framework Alignment

9. Further Reading

• Criminal Code of Canada — s. 342.1 and s. 430(1.1): https://laws-lois.justice.gc.ca/eng/acts/C-46/
• PIPEDA — https://laws-lois.justice.gc.ca/eng/acts/P-8.6/
• Computer Fraud and Abuse Act (CFAA) — 18 U.S.C. § 1030
• ENISA Coordinated Vulnerability Disclosure — Practical guide to responsible disclosure
• Google Project Zero disclosure policy — An example of a principled 90-day disclosure framework
• HackerOne 'Hacker101' — Legal concepts for hackers — Accessible overview of relevant law for bug bounty researchers
• ISC² Code of Ethics — https://www.isc2.org/ethics

["State what constitutes valid authorisation for security testing and identify three examples of invalid authorisation", "Identify the specific provision of the Canadian Criminal Code and PIPEDA that a described security action would violate", "Apply coordinated disclosure principles to a described vulnerability discovery scenario and produce a step-by-step disclosure plan", "Evaluate a described engagement scenario and identify every ethical and legal issue it contains"]

Prerequisites → Why this matters → Core principle: authorisation (what counts, what does not) → Legal framework (Criminal Code Canada, PIPEDA, CFAA, NIS2, responsible disclosure) → Professional ethics (codes, conflicts of interest, scope creep) → Practical scenarios (3 worked examples) → Common mistakes → Practice exercises → Quiz assessment → Framework alignment → Further reading