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:
- 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 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:
- Device
- Hardware and/or Firmware
- Software
- API
- Asset
- System
- Cloud PaaS/IaaS
- SaaS/Web Application
- Application
- Network, DNS, or IP Range
- Enterprise
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
- Vulnerability
- Web Application
- Code Review
- Wireless
- API
- Cloud
- 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
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.
Marriott Miss #1
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.
Marriott Miss #2
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).
Two Lessons
There are two lessons.
- Most importantly, monitor your network! Companies need preventive controls but that’s just not good enough anymore. Companies MUST be backed up by monitoring, investigation, confirmation, and rapid, effective response to limit the impact of security events. And, I’m not talking about now-and-then monitoring; I mean 24/7 monitoring. It’s why I started Critical Insight: so that we could staff a Security Operations Center around-the-clock and do managed detection and response (MDR) right.
- During an acquisition, it's important to evaluate the organization being acquired for security. Companies should look for the controls that are in place and the potential for compromised assets that are extant. Critical Insight has guidance on this process here. It specifically speaks to the health sector, but which is generally applicable to businesses buying businesses.
One Last Note
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.