6

Suppose I have a penetration tester working in my data center. She is testing my systems and is probably finding some issues, allowing her to gain root access to a machine that is inside a subnet deep inside the company network.

How can I be sure, that after the job is done, this system is not permanently compromised?

The question arises: How do I monitor what a penetration tester is doing during a penetration test to ensure that there are no longtime effects on my infrastructure?

Solutions I have thought about

Nuke the machine from orbit

This would protect the machine that was inside the scope, but a skilled hacker can gain access to other servers that are in the same subnet and/or pivot from the server that she has gotten access to to another machine.

Monitor all network traffic in the subnet

Not helpful if the pen tester makes a lot of noise and if the test takes several days it is also very costly.

Virtual desktop

Set up the pen testing desktop on a virtual desktop and give the penetration tester access to this machine. Monitor what this machine is doing, inspect shell history etc.

Also extremely costly, comes close to a forensic investigation and is susceptible to errors. I can probably do the pentest myself then.

Ironclad contracts

Only work with trusted companies and trust their employees. Is this the only solution? Or is there another way to better monitor penetration tester?

Improve this question
1
  • 1
    Nuke the machine from orbit is not realistic for most data center because if the pentester have compromised some part of your network you probably don't know which one and so you will need to nuke everything from the orbit.
    – Whysmerhill
    Commented Jan 10, 2019 at 12:19

2 Answers 2

Reset to default
8

Unless absolutely necessary, do not give your pentester access to your production systems. Instead, create a dummy system with the same configuration but without any sensitive data stored in databases, etc. If you let the pentester work on the production systems, you will have to trust them. If it is absolutely necessary to allow an untrustworthy pentester to operate on production systems, at least make an off-site backup so any changes to the server can be compared to the backup.

This may not be possible if the entire network needs to be tested, or if a test system that behaves identically to the production system cannot be set up. In that case, you will need to trust them.

Generally however, a qualified pentester will be trustworthy. It is not worth it to them to compromise your computer and ruin their reputation in an industry where it's so hard to gain it back. Both you and the pentester will sign a contract specifying what they are allowed to do, what attacks are in-scope, etc. This will allow you to prove malpractice in the case that they step out of bounds (for example, if they stress test your production server against your wishes and end up effectively denying service).

Improve this answer
2
  • 4
    1. The problem with this approach: dev and test systems are never in the same state as production systems, although admins claim that they are. So a penetration test on these systems will never be as meaningful as on a production system. 2. The problem with pivoting still stands with test systems.
    – Tom K.
    Commented Jan 10, 2019 at 11:58
  • 1
    @TomK. That's true, which is why I mentioned keeping backups (or at least a list of cryptographic hashes generated with e.g. AIDE).
    – forest
    Commented Jan 10, 2019 at 12:00
1

No perfect solution for this one, I think you will need to do a mix of the three below depending of your configuration :

  1. Monitor what they do

That can be physically & logically: someone with similar skill watching what they do. You can also ask them to have a complete description of what they do and compare with the information you collected monitoring them.

Moreover you can ask that they don't bring in/out anything (don't let them bring their own laptop/tools...). In counterpart you can provide a dedicated laptop with high level of logs. But that can be highly inconvenient for the pentester as they often use specific tools.

  1. Use a dummy environment

Use a similar environment but with no sensitive data and not connected to the real/production one. This may appear as the best solution but often no doable because the dummy and production are not exactly the same and so the result will not be relevant.

You can also restrict the pentester scope to a controlled environment on which you can roll-back easily after the end of the pentest.

  1. "Trust them"

Well at some point you may need some trust on the people you hire for a pentest. So yes use ironclad contract, people that you know or that your company already work with ... In some country you have special clearance for pentester. Finally consider the pentest as a risk himself.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .