Authorisation is everything

Accessing a computer system you have not been permitted to access is a crime in most countries. In the United States it is the Computer Fraud and Abuse Act (CFAA). In the United Kingdom it is the Computer Misuse Act. Most other countries have their own version, and the details differ: what counts as access, whether intent matters, how damage is measured, and how heavy the penalty is. The exact law is not the point for this lesson. The point is that the default state of any system that is not yours is off limits, and that a good result does not make an unauthorised test legal.

So every engagement rests on one document: written authorisation. Testers often call it the authorisation letter or, informally, the "get out of jail free" letter, because if your activity is ever questioned, it is the proof that the owner asked for it. A real authorisation names the exact systems, the dates and times, the kinds of testing allowed, the people doing it, and a signature. Keep a copy with you during the test, including a printed or offline copy, because the moment you most need it may be the moment the network is down.

Who can sign it matters as much as the signature. It has to be someone with the authority to accept the risk of the testing for those systems: the system owner or an executive who owns the business risk, not a friendly middle manager who happens to run the team. A manager saying "sure, go ahead" in a chat message is not authorisation, and it will not protect you or them. If a third party runs part of the system, as Mangrove's Partner app is run by the outside agency Lagoon Digital, the client cannot sign away permission over the agency's servers. Someone with authority over those servers has to agree too.

Scope: what you may touch, and what you may not

The scope is the fence around the engagement. It has two halves, and both matter. The in-scope list names exactly what you may test: specific applications, host names, IP address ranges, maybe a set of user roles. The out-of-scope list names what you must not touch even though it sits right next to the targets: the production database, a payments provider, the staff email system, anything belonging to another customer on shared infrastructure. Writing "out of scope: everything not listed above" is good practice, but naming the tempting neighbours explicitly stops arguments later.

Three traps catch new testers. First, third-party and cloud assets. If the client's app runs on a cloud provider, or sends traffic through a content delivery network or a payment gateway, those companies own that infrastructure. The client cannot give you permission over it, and many providers require their own notice or approval before any testing. You test the client's application, not the provider's platform. Second, data handling. The scope says what you may do with anything sensitive you find: usually, you must not copy real customer or payment data off the systems, you prove access with a redacted screenshot rather than a download, and you delete any extract when the test ends. Third, test accounts only. You use accounts the client created for the test, not a real employee's or customer's login, so you never act as a real person or touch their data.

This course gives you one scope that never changes. Every technique in every later lesson, the reconnaissance in Reconnaissance, the web attacks in the lab Partner app, the network work, the privilege escalation up to the lab directory domain, runs against a purpose-built practice environment: a sandboxed copy of the Partner app, a small practice network of store servers, and a lab directory domain. These are built to be attacked and belong to the course. They are your entire in-scope list. Real Mangrove systems, real companies, your employer, your neighbour's router and any live service on the internet are out of scope, always, with no exceptions.

Rules of engagement: how you will behave

If scope is where you may go, the rules of engagement (RoE) are how you behave once you are there. A good RoE is written to protect the client's live business and its real people, because even a test against a practice system can spill over if you are careless. The core clauses recur in almost every engagement:

• Allowed times and windows. When testing may run. Noisy or risky actions are often pushed to off-peak hours so that if something slows down, few people are affected.
• Rate limits and intensity. Caps on how hard you hit a system, so a scan does not become an accidental denial of service that takes a system down.
• No destructive tests. You demonstrate a weakness without deleting data, corrupting records or leaving the system broken. Proving you could delete a table is not the same as deleting it.
• No social engineering of real staff unless it is explicitly authorised and separately scoped. You do not phish, call or trick real employees on a whim.
• No touching real customer data. Test accounts and test data only, so no real person is affected.
• Stop conditions. The situations where you pause immediately and call your contact: a system becomes unstable, you find signs of a real prior breach, or you reach anything that looks like real sensitive data.

The RoE also sets the communication path: named emergency contacts on both sides, reachable during the test window, and how fast you must report a serious problem. Two cases deserve a planned response. If you accidentally cause an outage, you stop, call the contact, and help restore service before you carry on. And if you find evidence that a real attacker got there before you, you stop testing that system at once and follow an agreed incident path to the client's security team, because you may be standing in the middle of a live crime scene. You are a tester, not the incident responder, and trampling the evidence helps no one. Real incident handling is its own discipline, covered in the defensive course lesson on the first hour of an incident.

Engagement types, methodology and disclosure

Engagements differ in how much the tester is told up front, and the scope document should say which applies. In a black box test you start with almost nothing, like an outside attacker. In a white box test you are given source code, architecture and credentials, which finds more in the same time. A grey box test sits between, often with a normal user account. An assumed breach test skips the break-in and starts from a foothold the client grants, to answer "if one laptop is compromised, how bad does it get?" None is more correct; each answers a different question, and this course moves through several as it goes.

Professional work follows a named methodology rather than poking at random, so that coverage is consistent and the report is defensible. You should know these by name: the Penetration Testing Execution Standard (PTES), the OSSTMM, NIST SP 800-115, the OWASP Web Security Testing Guide (WSTG) for web applications, and the PCI DSS penetration testing guidance for cardholder environments. They overlap, and you cite the one you followed in the report so the reader knows what was and was not covered.

Finally, know the difference between three things people muddle. An engagement is a scoped, paid, time-boxed test under authorisation, which is this course. A bug bounty is a standing programme where a company invites anyone to report flaws under published rules, usually for a reward. Responsible disclosure is the ethic of telling the owner privately and giving them time to fix an issue before it is made public. All three share one root: you only test what you are permitted to test, and the permission's shape is different in each. Outside a scope, a bounty's rules or a clear invitation, there is no permission, and no permission means do not touch.