Which factors should you take into account when deciding whether users should be informed of a penetration test?

Question

Say you are conducting a penetration test of an internal network. The internal network comprises of workstations, servers and company and contractor laptops.

In an ideal world, the penetration test would just go ahead, simulating what an attacker would do given access to the local network. However, sometimes it is wise to let users know ahead of time.

Advantages include minimal disruption to business processes because users can inform their managers if the testing is likely to interrupt their work or cause other problems.

Disadvantages of informing users is that they may act differently than they would normally. For example, they may disconnect from the network, or they may disable software or enable firewalls that weren't usually active, affecting the results of the penetration test.

Which factors should you take into account when deciding whether users should be informed of a penetration test?

Answer 1

In the UK, law is a strong factor. The Human Rights Act 1998 states:

Everyone has the right to respect for his private and family life, his home and his correspondence.

So if any users that are caught up in the penetration test have an "expectation of privacy", then you are required by law to inform them prior to any testing. Note that just because they are in the UK does not mean they have an such an expectation - this would be down to the company's policies (e.g. Acceptable Use policy and Internet and Email Access policy) and contract of employment.

This page is a useful resource regarding pen testing and UK law.

Answer 2

For me the answer to this question largely revolves around the type of testing being undertaken. If you have a "proper" penetration test where the testers are simulating an attack, a decent quantity of the benefit of the test is seeing how/whether the attack is noticed and how the internal users/IT react (e.g. do they report it to the helpdesk if something odd happens, do A-V hits get investigated in a timely manner).

In this kind of circumstance, obviously, the fewer the number of people who know about the test, the more useful it is. Again obviously some people will need to know, but this should be kept to a minimum. I'd say a good hook to have is have whoever gets notified when a full security incident is raised know, so they can head off drastic actions like dropping production servers in the working day.

That said most of what gets called internal "penetration testing" isn't a full adversarial test and in those circumstances it makes sense for operational IT to know about the test, so they don't waste a load of time investigating issues which are just part of the review.

As to the legal aspects this, as ever, depends on the jurisdiction. If there's a requirement to notify end-users of any potential access to personal data, then I'd say that full pen. testing/red teaming is a pretty useless exercise as it'll never really simulate a real attack.

However in many countries users on a corporate network don't have an expectation of privacy for personal data processed, so that shouldn't be a particular concern.

Answer 3

That mainly depends on whether the user should know of the test. Of course, since you're simulating a real attack, you may or may not tell them, where comes the dilemma of things users would do. It's just that you should inform all those users for whom you are not testing the preparedness of attack. That's safe enough, because real attacks can come anytime and its a part of the test. You won't calm down or alert your system saying it's just a test, that defeats the purpose.

So, I would repeat my answer. Inform all users who are not part of your security(or even some specific ones in them if you feel disturbed). You can tell them after the test is over. In my opinion, that is best thing to do.

Answer 4

One crucial thing is to refer to the company's Information Security Policy. These policies will also decide what an employee is allowed and not allowed to do in the company with aspect of IT security. It also decides what will be the penalty if an employee breaches a security policy. So for eg: if the policy says that the company can monitor any one any time, then you can pentest without informing the end user! On the other hand if the policy says that the end users can't be monitored under any circumstance, and if you conduct a pentest then you might be in a trouble.These policies are provided to the employees when they sign the contract. So the employee cannot blame the employer later by saying that he/she was not aware of this fact.

I would highly recommend you to refer to the security policies of the company before conducting a pentest. It will help you to better understand the internal workings of a company and also it will assist you to plan your testing phase:

1. It could help you to decide when to test (Business or Non-business hours)
2. It will help you to plan your complete pentest in some aspects and to have an idea how long it will take to pentest etc..

Here is a good resource about security policies templates.

Security policies are usually created by keeping in mind the IT laws of the country to avoid any conflicts. For eg: An UK based company's security policies will be created by keeping in mind the UK IT laws.

One other example could be that some companies have a strict policies that the employees are not allowed to bring any kind of personal device. If an employee brings such kind of device then the company has full right to look into that device as long as it is in company's premises. For eg: An employee can't bring his/her own laptop or mobile phones etc. that is used for the personal use. Suppose an employee brought one such kind of device now as per the security policy the company can look into this device and the owner of the device must fully corporate! (Also: Now you have a one more device to pen test. :P

As there is no universal security policy so different companies might have different security policies. So there is no Yes/No answer to your question.

If the security policy doesn't help in some case then I would recommend to have a discussion with the owner of the company. Usually a person (or a team) with senior technical/non-technical position will be provided to you by the owner to discuss such cases depending upon the context.

Also, it is a good idea to have a contact with some senior technical/non-technical persons during the whole phase of the pentest. These persons will be assisting you in any technical/non-technical matters. Also, as they will be possessing some high positions in the company, so they will have higher authorization and they could provide you clearances in a short time. For an instance, if during the pentest unfortunately something goes terribly wrong, then you can immediately inform these contacts. You could/might have some situations during the pentest, when you have to decide something instantly. Examples of such situations could be that you forgot to plan what to do if a particular situation arises prior to conducting the pentest or a weird situation arises & you unfortunately have no backup plan. At that moment you can again discuss with the contact persons to make better decisions.

Answer 5

SilverlightFox, I feel that there are 3 main points one must keep in mind when disclosing a penetration test to personel:

1. What systems are you targeting? - The most important because depending on what is in scope, technicians for these services might need to made aware so that they can prepare and remediate any issues that arise.
2. What are the laws and policies of your environment? - make sure you are not violating any laws or company policies regarding your disclosure.
3. Who are you targeting? - You will need to make sure the users you are targeting do not know the situation and change their behavior as this will result in garbage data.

In most cases it is good to keep a need to know basis on penetration tests because you want to get a profile of the baseline security posture.

Answer 6

Speaking of isolated pentesting, compartmentalisation is your friend. It's always good if someone knows what you're up to. Could be the Board, CEO, CSO, ICT director, or any other lower management but people that are going to be pentested should not be informed if you want to observe genuine reactions.

There are some cons though, mostly if your testing is going to be aggressive. Some tests can do harm to some systems and if these systems are mission or business critical, it's good to have a contingency plan. Legal and other aspects had already been described in the other answers.

This can be a very complex decision so there is no simple answer nor there is a simple algorithm that would lead to a sane decision. It has to be decided on a per-case basis.

Answer 7

Considering the impact of an actual penetration by malicious parties (which is very high for most modern businesses), the best practice would be to do pen tests only as part of a much larger scope of action on penetration countermeasures.

For example, the first pen-test you do might be fully notified. You can then record any objections, and perhaps even track user habit changes (by doing a remote passive software audit before/after.) Carry out the pen test and record all results. You should have enough action items from these two activities to keep you busy, even if your users surreptitiously closed a bunch of holes.

Then, 6 to 12 weeks later, do the same pen test again but do not inform any users. Use your notes from the first test to identify business processes that need special attention to not disrupt. This should illustrate the rest of the issues you need to address.

If you do note a lot of discrepancies between tests one and two, you might be in need of a "threat preparedness drill" of some sort, i.e. tell the users there is an imminent threat and that they should be wary of any unfamiliar emails, network activity, etc. and gauge the response. Ultimately (getting back to the first part of your question) if you can get your users onboard with a good security posture, you will stay ahead of more threats than if you take a reactive approach and rely only on pen tests (announced or unannounced) to find the problems.

Answer 8

The factors are largely one of trust, and risk. Do you trust that people won't go and suddenly add in new security that didn't exist before?

Trust is incredibly important in security, and generally under-appreciated in the IT community. Trust between the security department and the rest of the company makes everyone's job easier. When people trust you, they're more willing to volunteer information and work with you. When they distrust you, they'll be on guard and you won't learn anything. Too often the security department creates adversarial relationships with other departments, creating tribalism and breakdowns of communications and relationships.

NOT telling your admins about a pen test will only serve to degrade trust. Pen testing can obviously affect operations, and knowing that it's happening will allow them to react far better if a pen test winds up breaking something. If they have to discover it later, you'll only breed anger, distrust, and may have any future pen tests curtailed because of the "surprise" nature of breaking critical systems.

Answer 9

Here's two factors against announcing:

A real attacker who is a user but was waiting for the most opportune moment for the attack (or not sure whether to attack at all), may just find the opportune moment in an announced pentest, when it becomes normal-ish for unusual things to happen.

People who would otherwise gleefully grant access to restricted assets to anyone who called asking, or even share their passwords, will be on their toes. If the pentest scope involves social engineering, that gets greatly distorted.