What tools or techniques can companies use to prevent penetration testers from behaving maliciously and exfiltrating data or compromising the system? I cannot imagine that the only protections companies use are contractual ones.
You're looking for a technical solution to a legal problem. This won't work.
What you worry about is primarily a legal problem. Penetration testers operate under a Non-Disclosure Agreement, which is the legal equivalent of "keep your mouth shut about anything you see here". Non-Disclosure Agreements, or NDAs for short, are what prevents a penetration tester from talking about the cool vulnerabilities they found when they tested ACME Corp. last week.
But why would a penetration tester honour a NDA? Because not doing so would basically destroy their career. If the company learns that a penetration tester disclosed internal information, they will sue the pen-tester for damages, which can be upwards of millions.
Furthermore, it'll completely destroy the reputation of the pen-tester, ensuring that nobody would ever hire them ever again. To a penetration tester, this means that the knowledge they have spent years or decades to accumulate is essentially worthless. Even if the idea seems sweet to a morally corrupt pen-tester, the punishment is magnitudes worse.
Furthermore, most pen-testers just have no interest in compromising a client. Why would they? It's in their best interest to ensure that the client is satisfied, so that they hire them again and again.
As for why you would not put in technical restrictions, there are several reasons. First, as a pentester, you feel like you are treated like a criminal. A lot of pentesters are proud of the work they do, and treating them like criminals just leaves a sour taste in their mouth. A pentester understands that a company has certain policies, but if a company goes above and beyond and escorting them with an armed guard to the toilet, just to make sure they don't look for post-it notes with passwords on them on their way back, they will feel mistrusted. This can and most likely will lower morale, and may cause a pentester to not give their absolute best.
Furthermore, absurd technical constraints can also just make things difficult for a pen-tester. For example, if their company-provided domain account gets blocked as soon as they start Wireshark or nmap, it takes time for that account to get reactivated. It prevents a pentester from launching all their tools to find vulnerabilities as effectively as possible, and wastes a lot of their time.
This is bad for both the pentester and the customer, and will likely result in a worse overall experience for both of them.
I'm asking if companies can use some tools, some techniques to avoid that penetration testers behaving maliciously can exfiltrate some data or compromise the system permanently.
You could record all the traffic behind your firewall or stay awake all night long watching Wireshark output but without technical skills it's going to be hard to make sense of the bits flying in front of you. A data loss prevention system is probably what you have in mind, but it is going to interfere with the pentest, unless this is precisely the equipment that you want to test.
The answer is due diligence. Before hiring a company check out their credentials. Ask questions, ask for sample reports too. Some outfits will do little more than run an automated scan and tick boxes on a template sheet. This is not what we want. What we want is talented pentesters who think outside the box and devise original, manual attacks based on their reconnaissance efforts (which for the most part are automated). A good pentest should be a tailor-made operation and not a cookie cutter exercise.
I wouldn't do business with a company that won't provide sample reports (curated reports of course).
My biggest worry is not dishonesty but rather lack of competence which means you pay for a useless deliverable.
So this is my first filter. A box-ticking company is in my opinion less ethical because it knowingly provides a service of questionable value. Probably better than nothing but you want value for money.
I cannot remember one single instance of a pentest company being used for criminal actions. However a few have been sued for what would amount to 'malpractice'. Example: Affinity Gaming vs Trustwave.
The contract should be clear as to what is allowed and what isn't. Make sure there are no misunderstandings and that the person hiring you has full authority. What could possibly go wrong: Iowa vs Coalfire
Surely, 'rogue penetration testers' (oxymoron) who want to break into your systems won't ask for your permission to test and then go beyond the scope of the assignment. They will just invite themselves.
Don't know if you are one of those, but some companies/government agencies require a security clearance. That raises the bar a little bit: felons are unlikely to have a clearance. There are exceptions like Mr Snowden, 0% risk doesn't exist.
If your company is involved in objectionable activity, damaging the environment, selling weapons to tyrants then you may legitimately be worried about whistle blowers. This is a conundrum - you have sensitive information and want to keep it secret, but to protect it you must allow an outsider to have access to it. You should select a provider that has experience working with companies in your field of activity and is comfortable with what you do. Perhaps your trade body or business partners can provide recommendations. Word of mouth.
If you think your company could sustain financial damage/fines in case of data exposure (accidental or otherwise), talk to your insurance company. By the way, the pentest company should have liability insurance too. This is one question to ask.
Breaches are a fact of life. Pretty much any company has been hacked at least once, or will be hacked in the future. This is something to consider. You should have a disaster recovery plan ready, regardless of whether you decide to proceed with the pentest. Which I think is a good idea: if things go wrong at least you can demonstrate that you undertook reasonable efforts to prevent a breach. A company that is found to be negligent can expect stronger sanctions in terms of: regulatory fines, lawsuits, consumer backlash, negative media exposure, shareholder revolt etc.
If you're developing products, you should have an SDLC pipeline with different environments like DTAP, where you should have penetration testers testing on the acceptance environment. It's a security best-practice to keep the environments completely seperated from production. So your acceptance environment should be a functional copy of your production environment, but it should not contain production credentials, data from your users, connections to production environments, etc.
Creating an acceptance environment for a company is often a challenge on the network and server level. If this is the case, you can make a claus saying they should stop the moment they hit a production system. If penetration testers do manage to find production credentials somewhere, or hack a production server by accident, you just act like a real breach happened - except for calling the police - and the change login credentials / monitor the server / etc.
The conceptual / contractual side has been covered in other answers, and it's very important.
However, there is also a technical side, especially in terms of "worst case impact" and limiting unnecessary access. Companies should come prepared to the pentest.
Here are some examples:
It should be possible to test system X without access to unrelated system Y.
This may sound obvious, but many companies have a single login system for employees that gives access to all systems -- in other words, the test credentials for X are also valid to access Y, Z, etc.
Instead, the company should be able to issue "limited access" tokens. When designing the credentials system, this requirement should be added even if useless at first (few employees, everyone normally trusted, ...).
Pentests should happen on a realistic environment
Again, may sound obvious but... is your testing environment holding realistic data / scripts / programs / etc.? Do you have an automatic generator for that? Are all interesting cases covered? If not, is it feasible to snapshot and anonymize the real data?
Testing on an empty shell is very unrealistic, and while you could ask the pentesters to populate a database for you they won't know all cases that you care about.
Perhaps surprisingly, your testing system should be more complete than the real one -- you should add all tricky cases that come to mind, even if you haven't really encountered them yet.
Communication lines and expectations should be established beforehand
Who should the pentesters contact in case of trouble? Are you ready to quickly restore the testing (or production!) system and bring it back up?
Do you expect to be notified of critical issues as soon as discovered? Are you going to patch the system while the test is ongoing? Do you expect persistence to be attempted? Cross-server attacks / "lateral movement"? Social engineering?
Even trickier: should pentesters read suspicious data, can they confirm the situation? ("that's testing data, continue" vs. "we didn't expect this data to be there / to be accessible, stop immediately")
What is in scope? Closely related: what is your threat model?
While you can ask pentesters to "figure it out", that's probably not what you want -- remember, the results need to be useful to you and represent your security boundaries.
It's usually best to figure this out together with the pentesters, and be ready to evolve things during the effort if necessary.
Incidentally, I believe most pentesters will happily provide advice on this matter. No one really wants to deal with the fallout of accidental damage or privacy repercussions.
The question is of course, turning in circles: if you could prevent the tester from certain access, then you would definitely want to prevent foreigners/attackers from accessing this. So your measures to keep the pentester from access are exactly those that you have in place and want to test. There should be no difference.
The only possible alternative would be to have the pentesters go after a dedicated test environment duplicated from your prod environment but w/o live data, which is of course more costly and you risk that this clone might nevertheless be different in details and dilute the results. A milder variation of this could be to cut off only most valuable IP and cilent data databases/NAS etc or attach dummy db's to your prod systems.
Your question is much more about risk treatment of your concerns, which should be covered by proper treatements as defined in Third Party Risk Management:
- perform a risk analysis identifying the actual risk potential/value; this should no only cover data leaks, but also the linked reputational damage, possible service disruptions (might they shut down your production or web presence/shop during the test?) etc.
- identify possible providers (Pentesters) and do proper due diligence / research. Your concerns are mostly about trust to the engaged party, so what you need is to build / gain trust and be sure that this trust is built on facts
- Please only use a pentester from our own jursidiction! If something happens, you need to be able to get them in court at your agreed place of jurisdiction and that evaporates if the tester has no legal entity there.
- define the (legal) boundaries of the tests to be executed
- and most importantly: define the legal consequences in your contract (this is often forgotten - people only agree what to or not to do but do not nail down what happens, if this is violated) in terms of proper liability clauses, cancellation rights, payment variations and penalty fees.
As an additional measure for the actual issue of a data leak after the pentest to be able to prove a linkage, you could add some honeypot data to your real data just for the time of the pentest. So, if there is a leak and it contains the honeypot data, you have better proof that the data leak is actually from the pentest.
You are asking the wrong question. Penetration testers test security by simulating what attackers will do. If you are more worried about pentesters stealing your data than malicious actors I would advise rethinking your security architecture.
In a secure environment, there should be “defence in depth” that has multiple security controls to provide redundancy in case one fails. The controls can be technology (like firewalls, IPS, EDR), policy (don’t use your company creds on outside system), or user training (don’t click on that phishing link). The multiple controls should be designed to catch anyone behaving maliciously. The point of pentesting is to find gaps where there aren’t multiple or any controls. Finding these gaps then allow for remediation in the form of implementing additional controls in the form of more technology, or procedures, or user awareness training.
Pentesting isn’t supposed to be adversarial. It should be a good collaboration by both the pentesters and the admin/security team.