Legal issues may throw sand in the wheels of penetration testing machine. Luckily, all of them are solvable.

 

Penetration testing is widely referred to as ethical hacking, and not by chance. Although the procedure happens on the mutual consent of the customer and the penetration testing provider, a range of US state laws still consider it hacking. They all have a common ground: whoever makes illegal unauthorized use of computer systems commits a crime.

 

But the very idea of pentesting is an attempt to get the unauthorized access to the customer’s system. So, the question is how to make it legal in the eye of the law. To achieve this, both a customer and a provider should pay special attention to legal issues in penetration testing. Let’s discuss the most typical ones.

 

Different states have different security regulations. Imagine that the customer is a Texan company that wants to test the network of their Kansas branch, and the pentester will work from their own office in Colorado. The question is, which legislation should be applied to the pentester’s actions?

 

The customer and the penetration testing provider should both remember to clear this issue out before signing the contract. Practice shows that there is no universal rule here. The parties can agree on any of the legislations in question.

 

The “Get out of jail free” statement is a document that the customer should give to the pentester to prove that penetration testing is permitted, and that the customer is authorized to give this permission. There is no unified get-out-of-jail-free form to fill in, but usually it begins with the explanation of reasons for testing followed by the pentester’s and the customer’s names and signatures.

 

Sometimes, additional permissions or restrictions are required. A vivid example is penetration testing in a cloud environment. In this case, the customer’s authorization is not enough. The cloud service provider should permit penetration testing as well. They will act as the main controlling body ensuring that the test covers only the area of network that belongs to the customer.

 

High on the agenda, regardless of the penetration testing type, is the necessity to specify the scope of work. This includes the amount of networks, the range of IP addresses within one network, subnets and computers. It’s important for the customer to decide not only what should be tested, but also what should not be.

 

Look at the two cases of what happens when this issue isn’t clarified. We replaced the actual names of companies with Customer Tom Ltd. and Customer Jerry Ltd.

 

Case #1: Customer Tom Ltd. had gone through penetration testing, and shortly after that the company got hacked. They made a claim on the penetration testing provider for the quality of the services. The customer was certified by the pentester for meeting certain security standards, when, in fact, they didn’t.

 

It turned out that Tom Ltd. didn’t include in the scope of work several systems that were hooked to the internet after penetration testing had already begun. As a result, those systems were left unattended and became a target for hackers.

 

Case #2: Customer Jerry Ltd. is a mobile operator that also provides mobile TV services through a third-party organization. This organization contributes all the necessary hardware and software, while Jerry Ltd. provides its domain name. During the penetration testing of Jerry Ltd’s network, pentesters hacked a server of the third-party organization, because they didn’t know that the network is a shared resource. Shortly, the affected organization filed a lawsuit against both the customer and the penetration testing provider.

 

Lesson learned: no work scope – no business.

 

Cloud customers who decided to go with penetration testing have to be especially accurate about the cloud environment area to be tested. The scope of penetration testing will differ depending on the deployment model (Infrastructure as a Service, Platform as a Service or Software as a Service). IaaS, for example, will allow much deeper penetration testing than SaaS.

 

Following on the topic of third parties in penetration testing, let’s consider the situation: after a testing procedure the pentester has discovered some vulnerabilities that may affect a third party because the networks of the third party and the customer are interconnected. Should the pentester warn this third party or remain silent? This is one of the ethical issues in penetration testing, and it has no straightforward way out. Any further spread of information concerning a particular penetration testing project should be endorsed by the customer.

 

Legal issues is something that penetration testing providers and customers deal with in every project. If disregarded, they may render penetration testing ineffective or damage the customer’s and the pentesting provider’s reputations. The list of legal issues described above includes the cases which are easily solvable if addressed in time. Keep them in mind to conduct penetration testing by letter of the law.