Last updated at Thu, 01 Aug 2019 14:19:31 GMT
Rapid7 was once again a proud contributor of our anonymized Managed Detection and Response 2018 incident data to the 2019 Verizon Data Breach Investigations Report (henceforth referred to as just “DBIR”). Our Rapid7 Labs research team has pored over the 78 (!) pages of insights into the overall breach and incident landscape to identify some key waypoints to help the Rapid7 community navigate through this sea of information.
Before we get to the data, it’s important to note how Verizon has leveled up the DBIR report in a couple of key ways. First, they have added views into the underlying statistical uncertainty in the data they work with. They mention this right up front as they discuss their fresh approach to the way they communicate this uncertainty in their new sloped bar charts:
When comparing two different sets of counts, the added information should help you understand the significance (or lack thereof) in any juxtaposition.
The second data-nerd exciting bit is how they’ve intelligently parsed and grouped (and/or excluded) data based on analysis context. This has increased the efficacy of the results in each section, which should help make the findings even more actionable for your organization than they have been in the past.
With that out of the way, let’s dig in!
Slow and steady gets you breached (aka ‘The detection deficit is real’)
Apart from doing your best to not have any incidents or breaches, one of the most important factors in the success of any incident response program is how quickly your responders neutralize a threat actor. We refer to the time between compromise and discovery as the “detection deficit,” and a prime goal should be to have the delta between the two be as small as possible. Note that it’s not the only goal—nor should it be the entire focus of your response plans—but it should be “up there” on any top ‘x’ list you have.
The Verizon DBIR team only provided timeline data for actual breaches, and if you keep an eye on the “n”s, you’ll see that timing data was not available for each stage across all breaches. If we just focus on compromise and discovery, it is sufficient data to make a sad discovery: The detection deficit really isn’t getting any better. Compromises still happen wicked-fast (in less than an hour, and generally minutes), and discovery still happens wicked-slow (generally in months).
This data reinforces the many headline-grabbing stories seen in 2018 in which attackers were able to linger for months (or sometimes even years) before their actions were discovered.
What can you do to move your own incident/breach “Detection Deficit” curves to the left?
1. Create a security operations/incident response team
You can also find a partner organization that can fully manage incident response for you. Believe it or not, many organizations still do not have key stakeholders assigned to this critical task and only get informed they’ve had an incident or breach once law enforcement (or another third party) informs them of such an event.
2. Develop a playbook of incident response plans that fit your organization’s threat model
Every successful sports team has made plans that they execute and adjust on the fly (since no plan 100% survives contact with an opponent) to win. Similarly, we suggest treating your IR plans as living documents that you must revisit regularly. Build an initial plan and work with your industry information-sharing cohorts to compare and improve together.
3. Invest in appropriate tooling combined with equally appropriate metrics
As noted, not all DBIR breaches have complete timeline recordings. You absolutely need this in order to learn from previous incidents and plan enhanced response for future ones. If you can’t provide your own “Detection Deficit” views for your organization’s incidents and breaches, you’re already ceding the game’s outcome to your adversaries.
The rats move to where the cheese is (aka the ‘Magic of Magecart’)
On page 18 of the 2019 Verizon DBIR report, there’s a single paragraph that you might have just skimmed over, so we’re placing a bit of emphasis on it here. The U.S. has (almost) finally moved to Europay, MasterCard, and Visa (EMV) chip-based credit card transactions, with over 60% of U.S. point-of-sale (PoS) nodes supporting chip-based transactions. PoS skimming has historically been a large component of the DBIR data and is still present, though in a diminished capacity.
Attackers still want payment card data, since they have their own playbooks full of successful steps they can take to turn digits into dollars. Rather than abandon all this coin, they’ve refocused their efforts to the server side. Figure 26 in the DBIR shows a major shift (almost to the 50% crossover point) in payment card breach volume sources to compromising web servers:
These types of attacks fall under the general category of "Magecart”," which has two primary flavors: attacks in content delivery networks and outright server compromise. The 83 breaches documented in the DBIR fall into the latter category and should be a serious wake-up call to any organization that processes payment card data on any portion of its website.
This vector is not going away anytime soon, so what can you do to help safeguard your organization?
1. Patch your systems
Forget any news you may have heard that there isn’t any point in patching. Maintain a daily inventory on the patch status of these critical servers and application components, and ensure you’ve either patched or mitigated the vulnerabilities in these systems. Not doing so would be like building a giant tower to keep enemies out but kindly installing handholds and footholds so they can make their way in with just a little effort.
2. Mind your credentials
Attackers can breach internet-facing systems in many ways, and one of their favorite paths is that of replaying stolen credentials, since you’re likely not logging on successful credential use (Pro tip: You should be). Plug any remaining credential holes you may have with a combination of judicious use of multi-factor authentication and removal of admin-level access from internet-facing interfaces.
3. Design self-defending applications
It’s time to get serious about adopting critical security headers like Content Security Policy and designing web applications modularly to enable clean and easy use of subresource integrity attributes on resources you load. While you can start with just focusing on the core pages that deal with logins and payment card transactions, you should consider adopting these two technologies holistically across all web-facing components. If you source your e-commerce applications from a third party, ensure you mandate the use of these technologies in your procurement processes.
Breaches are a (nation) state of mind (aka ‘So, um, state-affiliated attackers may, indeed, be out to get you after all’)
The 2019 Verizon DBIR report had even more contributors this year than in previous years, which both beefed up and further diversified their corpus. While I would like to say that I was pretty shocked at Figure 8 on page 7, the truth is that organizations of all shapes and sizes have seen increased levels of state-affiliated attacker activity, and this activity often ends up resulting in a successful breach:
Perhaps the most disconcerting feature of this chart is the soon-to-be convergence of organized crime and state-affiliated breach trend lines. There are many possible reasons for this, ranging from bona-fide state actors mining as many organizations as possible for any type of data they can put to use in a variety of ways, to individual actors in organized-crime syndicates and nation-state cliques sliding between these two groups or—even worse—working together.
However, scaring you with the thought of your inevitable face-off against an infinitely resourced adversary was not the only reason for including Figure 8 in this DBIR summary. I suspect many, many incompetent audit departments are going to zoom in on that “System Admin” line with utter glee and use it to double-down on draconian findings that do little more than impair the ability of security teams to focus on real threats. If you read the nearby text, you’ll see that most of these System Admin-caused breaches are actually due to errors versus (as the DBIR team put it) “rogue admin planting logic bombs.” These errors are generally server misconfigurations (something we see a great deal of in Project Heisenberg and Project Sonar) or data left out in the open on cloud services such as Amazon’s S3.
So, how do you defend yourself against this apparent new and advanced attacker landscape?
1. Focus on the fundamentals
The sad truth is that both the state-affiliated and organized-crime threat actors both have access to and use the same types of tools, such as Emotet, which we’ve talked about in our quarterly threat reports. While these are powerful tools, you also have access to equally powerful tools for defense. Research which tools align with the way your team works and organization operates so you have the best possible defense against these clever crooks.
2. Substitute 'resilient' for 'secure'
Words mean things, and most folks—including most “security” folks—roll their eyes at the word “secure.” Switch to using the word “resilient” (or “rugged”, even) and frame your team as a partner to others in helping them set up and maintain secure applications and configurations. Be a partner, and help them set up monitoring in general (slide some budget dollars their way to make even more friends), and don’t treat configuration or patching lapses as world-ending events. Just work together to figure out ways to prevent them from happening again.
3. Defend with data
Full-on attribution isn’t 100% necessary to maintain a record or have an idea of which attacker group(s) may have been involved in any incident your organization has experienced. You may be able to infer a broad level of attribution if you start adopting key frameworks such as MITRE ATT&CK and use it to compare notes—or, full datasets—with your industry threat- and incident-sharing partners. If the attackers are partnering up, it’s only fair that you do, too.
See you in 2020!
Don’t be surprised if you catch a few more glimpses into the insights the 2019 DBIR has to offer on our blog, since there are many areas to explore and take deeper dives into. You should carve out some time to digest the report—especially to extract your own industry’s view from it, then compare that with your own experiences in 2018 to see how closely your events match what the DBIR team saw in aggregate.
If you’d like some clarification on any section, the DBIR team can be reached at firstname.lastname@example.org, and the Rapid7 Labs team can provide our own set of guidance via email@example.com.