What’s the point of establishing a baseline if you don’t intend to track your progress? When organizations only run an initial pen test, they are only getting half the picture.
A pen test is used to give a business a baseline idea of how well their systems would stack up against hackers who wanted to exploit vulnerabilities. Once the results are delivered, it’s up to the team to implement those changes. And then –
And then, what? Are things safer now? Did their work of the past few weeks make a difference? Are there new holes that came from patching the old ones? All of those questions (and more) emphasize the importance of rerunning a pen test after remediation efforts are made. Read on to learn all the reasons to retest.
1. Verifying that Remediation Efforts Were Even Implemented
The most basic reason to retest is to make sure plans for remediation were ever turned into action.
“The first principle of communication,” noted scholar and consultant Philip Clampitt said, “is ‘message sent’ often does not equal ‘message received.’” This is true when any two human parties communicate, and the cybersecurity realm is no exception.
A pen testing team – whether in-house or third-party– will do its best to relay the results, delivering reports and noting priorities. Pen testing personnel are typically not the same as those in charge of implementing changes. Additionally, not all pen testing teams are created equally, and neither are all SOCs. Reports may not be as detailed or other miscommunications may lead to recommended changes going overlooked.
Also, on the client side, employees may not have followed through with making the necessary changes. This includes updating passwords, auditing permissions, and reporting all application additions to IT (we’re coming for you, Shadow IT).
Retesting is a second chance to highlight high priority security weaknesses and make sure you’re on the right track towards remediation.
2. Determining Whether Remediation Efforts Were Effective
Post-pen test, a security team can be a flurry of activity as team members try to efficiently make the necessary fixes. Sometimes something gets rushed and a typo stalls things out. Or perhaps a task is given to someone with a slightly different skillset. It’s well known that cybersecurity resources are perpetually limited. It’s understandable that things happen.
Also, patches may be incompatible. It’s no good unless you test it again to make sure that vulnerability is really shored up the right way. And workarounds may not be effective. What works in theory may not work under stressors, and there’s no better way to find out than to put it to the test. Or rather, the retest.
3. Uncovering New Issues Caused by Remediation Efforts
Remember the story where the boy sticks his finger in the wall and saves his town from a flood? Well in reality, patching can be more like a game of Whack-a-Mole or a five-hour brain surgery. If you don’t do it right the first time, you could cause a host of other problems to pop up.
Sometimes flaws in the patch can be a whole new (exploitable) vulnerability. Or applying the patch in the wrong way can cause a good patch to go bad (or open up problem spots elsewhere). Alternately, a new security control intended to fix the issue may end up getting misconfigured upon deployment. Unfortunately, any change, even those intended to eliminate weaknesses, can end up becoming a problem and of itself.
When fixing the problem, you have to not only get in there and do the “dirty work” but ensure everything around it stays immaculately clean. It’s a tough job, and one not everyone gets right on the first try. Rather than obsessing over perfectionism, it makes more sense to just have the same team check your work again. Or even a different one.
Simplifying Retesting Efforts
The upside to a retest is that it doesn’t take nearly as much effort as the original testing initiative. When the network was tested the first time, practitioners had a broader scope—exploring the outcomes of exploitation in order to better prioritize risk. The second time around doesn’t require exploration. They know the vulnerabilities they found and which ones are most crucial. Their path of attack is already mapped out—they remember how they got there, and what the weak spots were the first time. They can (more) quickly and easily navigate back to those spots and do a quick check to see if the issues have been addressed.
Retesting with Pen Testing Solutions or Services
Pen testing is a process, not an event. And it never, ever ends. The day an organization stops assessing their security is the day they should start making a recovery plan for any number of successful attacks
Companies that stay on their toes and make pen testing a habitual part of their overall security strategy have not only the benefit of finding out what went wrong once, but the status of their security posture at all times. It’s the difference between always knowing your grade and not finding out your midterm scores until you’ve failed the class.
It’s never too late: When thinking about offensive security, organizations can start now to develop relationships with external pen testers who can help them get on the right track. Fortra offers ways for teams to pen test in-house or services to do it for them.
With Core Impact, even less experienced teams can conduct high-level, automated penetration tests with ease using a certified exploit library and allows teams to easily retest network and web assets that have previously been identified as vulnerable. By storing previously run tests, the Remediation Validator can efficiently deploy a retest, generating a report that compares new results with that of the original test.
Or rely on Fortra’s team of specialized offensive security experts to make the job easier. When you take advantage of our managed pen testing services, you’ll get experienced pen testers that leverage commercial-grade tools to assess your system, leaving no stone unturned.
So, when it comes to vetting for vulnerabilities, remember: Test early, test often, and always (always) retest.