Penetration testing has achieved buzzword status! Paying a professional to attempt to compromise your network, applications, or other digital properties is a straightforward concept that seems valuable.
No matter what you call it—be it pen-test, pentest, or pen test—there are only a handful of sufficiently compelling reasons to actually conduct a penetration test. Being prepared to generate meaningful results is as important as running a “pen test” in the first place.
Therefore, the question is not do you really need a penetration test, but when do you really need a pentest?
Don’t Believe Everything You Hear
A few months back, I met a new client declaring something I commonly hear on first-time meetings.
“I was told I need to conduct a pentest,” he said.
“What kind of pentest do you need?” I asked.
“Not sure – but I need to run one soon,” the client noted.
“May I ask who told you that?” I replied, expecting the answer I’ve heard a hundred times.
“AAA Pentest Co. told me last month that it was imperative we run a pen test soon,” he explained.
I told him he has a lot of things to do before it’s worth spending the money for a pentest.
Unfortunately, as it was in this client’s case, they heard the, “you need to run a pentest” directive from the last security company they called that specializes in (not surprisingly) penetration testing. Sometimes, clients call me after hearing from a sysadmin that they need a pentest.
No matter the environment, I tell clients that there are seven reasons to initiate a pentest.
7 Triggers for Penetration Testing
The appropriate triggers for penetration testing include, but are not limited to:
- Compliance or audit mandate
- Reaching milestones in a software development or system implementation process
- Production deployment of IT, Application, and Security infrastructure
- Completion of or on reaching milestones within security remediation projects
- Major changes that affect the security of an application, system, network, or process
- A part of a vulnerability and risk management program
- Recovery from a security incident
If you have not recently triggered one of the above events for technical testing, you likely do not need a penetration test—at least not right now. It’s much more likely that you need to conduct a baseline assessment of your people, processes, and technology first.
What to Do Before a Pentest
To prepare for future penetration tests, you should consider a network vulnerability scan either in parallel with the security baseline, or shortly thereafter if you’ve never used a vulnerability management program. For example, if you know your patching practices are inadequate, you won’t get value out of a pentest until you commit resources to address the patching problem first. A vulnerability scan is an essential tool in understanding which systems need patching, updating or reconfiguring to make them more secure.
Once you’ve addressed the patching problem, run another vulnerability scan to see what you missed—and you will miss many issues on your first pass. Fix those findings and repeat the process. You’ll have still more findings. It is at this moment that you’ll realize the necessity of regular vulnerability scans. When I consult with various companies, I find that many need a continuous vulnerability identification (CVI) solution. That consistent finding is one of the reasons I made sure we would offer our CVI service when I helped create CI Security. Learn more about our CVI services.
Don’t Waste Time & Money on the Wrong Penetration Test
Back to penetration testing. When I hear, “I need a pentest,” and the company has listed one of the triggers mentioned above, we need to agree upon the type of testing for the engagement.
Testing any of the following systems requires utilizing differing approaches, methodologies, tools, tactics, and techniques:
- Hardware and/or Firmware
- Cloud PaaS/IaaS
- SaaS/Web Application
- Network, DNS, or IP Range
And, once we determine which systems to test, then we need to determine which of the following approaches to use, all of which can be casually referred to as “Penetration Testing”:
- Automated Scans (with or without human verification of results)
- Security Scanning and Testing Tools
- Web Application
- Code Review
- Operational Technology (passive scanners)
- Security scanning and testing tools with human verification
- Security Scanning and Testing Tools
- Network/System Penetration testing (Black/Grey/White Box)
- Web application security and penetration testing
- Wireless testing
- Password strength
- Social Engineering/Fraud – Digital, Telephony, Physical
- Device Security testing
tl;dr: Do Your Homework Before Penetration Testing
For your colleagues that may respond tl;dr, tell them this: We can save time and money by waiting until the time is right to conduct penetration testing.
If you’re just starting to mature your security program, let’s start there. After you have addressed the big problems, we can spend our time on deep meaningful penetration testing. Then, we’ll pentest, app test, social engineer, ethical hack/crack, reverse engineer, red team/purple team, or otherwise security test whatever you need tested, for sure.
Finally, note that one very good reason for conducting penetration testing is to justify requests for additional controls—not the least of which are improvements to monitoring, detection, and response. If a small compromise is not detected and quickly remediated, the impact may spiral out of control and result in the unwanted outcomes of records disclosure, theft and extortion, or disruption of critical services. Determining how well your monitoring “sees” the beaconing signal created by a penetration test goes a long way to communicating how well you’ll respond when the real deal hits—because, eventually, it will.