A penetration tester does what an intruder does: looks for a way in and uses it. Computer crime laws in most countries do not ask about intentions. They ask whether the access was authorised. The whole difference between a service and an offence is a set of documents, signed by the right person before the work starts.
This article describes those documents. It is not legal advice: the law differs between countries, and your lawyers decide what applies to you.
The documents
Contract
The commercial agreement: what is done, by when, for how much, with what liability and confidentiality. The contract alone is not the authorisation. It obliges the parties to each other; it does not by itself state what may be attacked.
Authorisation letter
The statement by which the owner of the systems permits the test. It should name:
- the systems, by address, domain or another unambiguous identifier;
- the period during which testing is permitted;
- the people or the company permitted to test;
- the person who signs, and the capacity in which that person signs.
Testers carry it, literally or figuratively, for the whole engagement. When a hosting provider or a law enforcement body asks what is going on, this is the document that answers.
Rules of engagement
The technical limits: which techniques are permitted and which are excluded, the hours of testing, the request rates, what happens when a system becomes unstable, whom to call at night. NIST SP 800-115 treats the rules of engagement as a required part of planning, and PTES places them in the pre-engagement phase for the same reason: questions that are not settled before the test are settled during an incident.
Scope statement
The list of what is in and what is out. Exclusions matter as much as inclusions: the payment provider behind the checkout, the shared platform of the hosting company, the single sign-on service that belongs to the parent company.
Confidentiality and data protection
A non-disclosure agreement, signed before technical details are exchanged. Where personal data may be encountered, a data processing agreement. In the European Union this follows from Article 28 of the GDPR when the tester processes personal data on behalf of the client.
Who may sign
The authorisation is worth as much as the authority of the person who signs it.
- The owner of the system, not its user. A company cannot authorise the testing of a SaaS product it subscribes to.
- A person entitled to bind the company. A developer who orders a test of the employer’s production system without the knowledge of management has not authorised anything.
- Every owner, where there are several. A system operated by one company on the infrastructure of another may need both.
A careful provider verifies this: checks the commercial register, the ownership of the domains and confirms the order through an official channel of the company. A provider who does not ask should worry you.
Third parties
Your authorisation covers what is yours. Around it there are usually systems that are not.
Cloud providers. The large providers publish policies for the testing of resources that customers run on their platforms. At the time of writing, AWS, Microsoft Azure and Google Cloud permit customers to test their own resources without prior approval, within the rules each of them publishes; AWS also lists the services that may be tested. Denial-of-service testing is restricted by all of them. The policies change, so they are checked before every engagement and not remembered from the last one.
Hosting and managed services. Shared hosting, managed databases and content delivery networks have their own terms. Some require notice, some prohibit testing altogether.
Suppliers and partners. An integration with a partner does not extend your authorisation to the partner’s side of it. Without the partner’s written consent, testing stops at your boundary.
The usual gaps
- The test has started, the letter is still “being signed”.
- The scope lists a domain, and the application behind it moved to another address last month.
- The letter is signed by someone who had no authority to sign it.
- Production is in scope, and nobody told the operations team.
- A subsidiary in another country is tested under the authorisation of the parent.
Each of them turns an authorised test into an unauthorised one for a part of the work, and none of them is visible from the technical side.
Bug bounty is an authorisation too
A bug bounty program is an authorisation given in public: the program policy says what may be tested and how, and whoever follows it acts with the permission of the owner. A safe harbour clause adds the owner’s commitment not to pursue researchers who stay within the policy. It binds the owner only. It does not change criminal law and does not bind third parties, which is why the policy has to be followed exactly and why a system with no program is not a target.
In short
Before the first packet is sent there should be a contract, an authorisation letter signed by someone entitled to sign it, rules of engagement, a scope with its exclusions, and the consent of every third party whose systems are touched. The details of how we handle this are on the engagement page.