This page discusses an answer to a question concerning vulnerability assessments
What are the Risks of a Penetration Test?
Penetration testing is not without risks. This article explains some of the concerns organizations should consider.
No matter how you spin it, inviting hackers into your organization to perform a penetration test feels inherently risky. A lot of things could go wrong ,and some of those things could result in devastating impacts. We are going to try and explain the top risks of penetration testing and what you can do to minimize them. Let's look at the most common ones discussed with us.
Penetration testers are hired to break through security controls and exploit vulnerabilities. Breaking things is what we do. It should be no surprise that your number one concern is the risk that we might break something important. Talk to anyone who has experience with penetration testing, and they will have a story about something important breaking.
There are two primary factors that lead to system outages during penetration tests: recklessness and unusual or unexpected circumstances.
Some penetration testers are reckless. Most of the time, this is not a deliberate recklessness but born out of inexperience or inattentiveness. An experienced penetration tester is familiar with the systems they are testing and the tools they are using. Some of the most catastrophic outages occur with the misuse of tools. This does not mean tools are bad; Only that what they do and how they are configured must be understood. Automated attacks should also be monitored so that they can be stopped at the first sign of a problem. When a tool or exploit code is not well understood, it should first be tested in a controlled lab environment before being used on production systems.
What can you do to mitigate reckless penetration testers? Though there are a variety of certifications that a penetration tester may obtain, currently there is no recognized accreditation or license that holds them accountable as professionals. As a result, you will encounter a wide range of experience and skill. So when you consider hiring a penetration testing vendor, don't be afraid to ask about who is doing the testing. How much experience do they have? And this includes experience with IT and the applications/infrastructure being tested, NOT just security experience. If sensitive systems are in scope for testing, make sure you have established Rules of Engagement that cover procedures and communication for running exploit code or invasive tools.
Unusual or Unexpected Circumstances
Sometimes outages or breakages occur that even the most cautious of penetration testers can't avoid. An application may have software flaws that result in a Denial of Service condition. A network device may be misconfigured such that it handles some types of network traffic poorly. We have all seen these types of issues in our testing.
Unfortunately, there is no surefire way to eliminate this kind of problem. It can be reduced through best practices such as patching, change management, and thorough code reviews. Damage from this type of issue can be minimized by closely monitoring the systems being tested and being prepared to halt automated tools at the first signs of trouble. This can also be improved by ensuring the testers are experienced in how the systems being tested work.
The next significant risk to consider is that of inadvertently exposing confidential information or system access. Your penetration testers are searching for vulnerabilities and running exploits. For example, they may find a vulnerability that allows them to open up a backdoor. If they do so, but fail to protect the backdoor, a real attacker may discover and use it for malicious purposes. Another type of exposure if the tester is accessing data insecurely. For example ,they could transfer PII over an unencrypted channel.
There are a couple of things you can do to mitigate this type of issue. First: make sure you have a competent and experienced penetration testing team. If the company you hired is using junior consultants, then make certain they are being supervised by an experienced consultant. Second: be sure to have good communication with the penetration testing team. Insist on regular updates to inform you of what significant vulnerabilities were found and what systems were the targets of exploit scripts or tools.
Masking of Attacks
Another common risk of a penetration test is complacency of the organization being tested. If your Security Operations Center (SOC) disregards alerts because of an ongoing penetration test, they may be ignoring indications of a real attack. This does not mean the penetration test needs to be a secret. To the contrary, it is best for the SOC and the penetration testing team to keep a line of communication open and collaborate on the test. The results can help the SOC improve their alerting.
To help mitigate this type of problem, it is a good idea for the SOC to maintain a whitelist of the penetration tester IP addresses. They should question anything that does not originate from a whitelisted source and assume it is an attack. Error on the side of caution. It is better to interfere with the penetration test than to accidentally let a malicious attacker run free in your network. And if your penetration tester isn’t willing to perform this type of regular communication, you have the wrong pen tester.
Even when penetration testing does not cause a complete system outage, there is always the potential for it to interfere with employee productivity. For example, certain man-in-the-middle attacks may temporarily prevent users on a specific subnet from getting to the Internet. Or a DevOps team might waste time troubleshooting some odd behavior that was caused by a penetration testing script.
Some loss in productivity can be expected during a penetration test ,but there are some things that can be done to reduce it and shorten the duration of productivity loss. One of the most critical precautions is to inform teams that are most likely to be impacted that the test is going on. This will include teams such as the Security Operations Center (SOC), the network operations team, desktop support, and so on. Give those teams a channel they can use to report anything odd they are seeing during the penetration test. Also, make sure they know they CAN communicate with the testers. Often we find that IT and others will waste time troubleshooting things before talking with us because they think they are interfering or bothering us. They aren’t!
A false negative is the term used to describe a vulnerability that exists but was not detected. Most penetration testing vendors will do their best to detect all of the most critical vulnerabilities in the timeframe of the test. However, there is no guarantee that they will catch everything ,and there are many reasons why a vulnerability may be missed. Penetration tests are usually time-boxed, meaning the team will test as much as they can in the time provided by the contract. Also, there are some vulnerabilities that are just hard to detect. There are tools that do a better job of finding some vulnerabilities but not others. There may be vulnerabilities that simply have not been discovered yet (i.e. zero day). There are penetration testers who, due to a lack of skill or experience, might not recognize a vulnerability for what it is.
It is important not to assume that you are immune to a vulnerability just because it was not found. Penetration testing is a path-of-least-resistance process, not a thorough audit. To combat this, establish security best practices such as Defense in Depth and regular patching of systems. It is also a good idea to rotate penetration testing teams, either by trying different vendors or asking for variation within the same vendor.
Unfortunately, in the information security industry, there are hackers with questionable motives. They may be activists who believe they have a just cause, or they may be simply motivated by money. Either way, they are people you probably do not want to invite on to your network.
To mitigate this problem make certain to use trusted, well-known companies who only hire reliable employees. It is not uncommon to request proof of criminal background checks for the employees performing the test. Also, make sure you are aware of any subcontracted work and make sure your penetration testing vendor is only subcontracting to trusted third parties.
All of these issues can show up if you don’t educate yourself and discuss issues with your organization and chosen penetration testers.