While there are plenty of legitimate reasons to justify a penetration testing program, sometimes it just doesn’t make sense from a business and ROI perspective. Find out the top reasons to justify your investment in penetration testing.
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:
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 Critical Insight. 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:
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”:
And yes, Critical Insight offers pen testing. For a free consultation, contact us today.
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.
The facts: Marriott discovered the event by identifying an encrypted database containing guest information. The database was apparently encrypted to evade detection by the data loss prevention (DLP) technology. Approximately 320M of the records included passport and other personally identifiable information. Credit card data were encrypted per the requirements of the Payment Card Industry data security standard, however, it's not outside the realm of possibility that someone is busily working on decrypting those records.
Miss 1 is poor detection and response. Technology designed to prevent security incidents is not perfect and will fail against a determined attacker. In the security industry, there’s something called, “dwell time.” It’s the time between the initial compromise and the actual detection and response. In this case, the dwell time was ridiculously long: up to four years. There was more than adequate time to detect the presence of the compromise through good monitoring combined with oversight from human investigators.
Clearly, the monitoring and/or humans failed to detect the signals of initial compromise, unauthorized network access, internal pivoting to identify the records to steal, unauthorized database access, and data exfiltration. That's a lot of failures, and once investigations are complete, my guess is that Marriott will get religion on the value of comprehensive monitoring, good investigation capabilities, and rapid response to limit the impact of security events like these.
Miss 2 is the failure to fix security holes during the acquisition of Starwood. It's likely that Marriott knew of the Starwood breach during the acquisition process, but it sounds like no additional steps were taken to comprehensively examine the network for signs of lingering hacker presence. Whether these two events are connected is, at this point, a bit of conjecture. But it's awfully suspicious, even though the Starwood incident involved fundamentally different tactics (compromised point of sale devices).
There are two lessons.
It’s not just Marriott. If you hear someone say today, “good thing I stayed at a different hotel,” you can tell them this: Marriott is not alone. Hotels have had problems with point of sale systems scraping transaction data. InterContinental Hotels Group (IHC) comes to mind. The IHC hack was identified through fraudulent transactions with stolen cardholder data. Hyatt, Kimpton, Trump, and Mandarin Oriental hotels have all been compromised and cardholder data stolen since 2015.
I send out cybersecurity news every day. If you’d like to get my daily emails, fill out the form on this page.