Guiding Salesforce Security Priorities with the 2020 Verizon Data Breach Investigations Report

Guest post by Kevin Thompson, Security Architect at Salesforce and former author of the Verizon Data Breach Investigations Report

Every year in late spring I anxiously await the release of the Verizon Data Breach Investigations Report (DBIR) like a kid waiting to open his Christmas presents. Verizon has been producing this data-driven view into the causes and effects of data breaches for 13 years, and it has proven to be invaluable to decision makers trying to apply more science to the art of information security. Here are some things that stood out to me as being particularly relevant to my current role as a Security Architect here at Salesforce.

Malicious insiders rarely cause incidents. But …

The DBIR has consistently reported that most data breaches are caused by financially-motivated external parties to the victim organization, and that malicious insiders account for relatively few breaches. What about insiders that aren’t malicious, like an employee that emails a sensitive report to the wrong recipient or publishes it to a wide-open shared volume on the Internet?

This year’s report indicates that 22% of confirmed data breaches involved an employee’s error, and about 8% included some element of employee malice (page 7). When we look at the industry breakdown for Health Care and Public Administration where there is mandatory breach reporting, we see the combined number of error breaches and misuse breaches jump up to 35% (page 70) or 40% (page 55). In 11 of the 15 industries that Verizon examined, Miscellaneous Error was one of the top three patterns associated with confirmed breaches. And all of that is not counting phishing, which Verizon does not classify as an employee error. It’s certainly good news that few of our coworkers are bad actors working against us, but that doesn’t change the fact that about a third of security incidents involve someone that already has all the credentials they need.

Detection time has gotten better. But …

This year’s DBIR offered a ray of hope in reporting that detection time has gotten much better than what has been reported in previous years. However, this is where the composition of the sample becomes important. There are more managed security providers in the contributor pool this year who typically detect run-of-the-mill breaches very quickly and there are many more breaches that involve ransomware – which notifies the victim organization right away so the threat actor can get paid. There are also fewer point-of-sale breaches being reported which used to take a long time to detect as the threat actor would sit on the infrastructure to collect as much data as possible.

Since I’m a security architect for a cloud-based software-as-a-service company, I want to know more about discovery time for breaches involving web applications. So I went to Verizon’s VERIS Community Database of publicly-disclosed security incidents and filtered for breaches that involved a web application. Unfortunately, when it comes to publicly-disclosed breaches the data can be sparse and I found that in 2019 the sample size was too small to draw any useful inferences. However, from the 2018 data, I can say with 97% confidence that at least 32% of web application breaches are detected in months or more. Also, breaches involving insiders (whether malicious or otherwise), take much longer to detect. Last year, Verizon released their Insider Threat report, which found that between 30% and 40% of those breaches are detected in a period of years.

Applications offer tighter security. But …

This year’s report makes mention several times that authentication attacks are increasing on web applications and that one of the reasons for that trend is that more and more applications are moving from on-prem to cloud-based web applications. Yet, despite workloads moving to the cloud, cloud infrastructure was only responsible for 24% of the breaches in this year’s report (page 27). Of those breaches, nearly 60 percent involve some attack against authentication, either in the form of credential stuffing or brute force password attacking (page 74). By moving more workloads to the cloud, we have exposed fewer vulnerable services to the Internet. SaaS applications also close off many of the lateral movement vectors that hackers rely on, such as dropping malware onto the operating system. The report also found that infrastructure which is being patched AT ALL is probably also being patched quickly (page 22). So if your cloud provider is audited on their vulnerability management and they make those audit reports available to you, then you can conclude that the highest probability of success for an attacker is to go after authentication.

Detection in the cloud, however, is a bit iffy. As you move workloads into the cloud, particularly onto SaaS applications, you also need to adjust your detection logic. You need to identify new log sources and learn how to correlate that information to find unauthorized access and malicious users. That takes a fair bit of work, and unfortunately, there is often pressure to move onto the next project rather than invest in that detection. This is difficult enough in the on-prem world. After all, only about 20% of the incidents Verizon analyzed met their information quality standard.  Not all cloud providers offer the same kind of detailed logging that you would expect from on-prem solutions either. This year, one of the biggest sources of incident detection was security researchers finding cloud-based storage that had not been properly secured (page 14). Even when organizations learn that their web application has been breached in some way, it can be difficult to put together a high-quality incident report too.

How to use the Verizon Data Breach Investigations Report in your Salesforce organization

We can use the Verizon report as part of a holistic, evidence-based approach to securing our data services. A holistic approach to security has controls to identify risk and protect, detect, respond, and recover from incidents applied across multiple systems to create defense-in-depth. That’s our goal state – and the DBIR helps to inform where to prioritize our efforts. Salesforce provides a high-trust environment with excellent out-of-the-box controls for limiting access to data, and we have enhancements like Salesforce Shield and Data Mask for customers that have greater security needs.

Salesforce security controls offer protection against both external as well as internal threats. Insiders, whether malicious or not, have valid credentials, but that doesn’t mean we can’t use preventative controls to limit the damage an employee can do. We need to treat employee error as an engineering problem to be worked around. “Make fewer mistakes” is not a solution to flaws in a well-engineered system. Two-factor authentication has gradually moved from being a paranoid security enhancement to a best practice, and is now table stakes. Multi-factor authentication is now the need of the hour. You can also leverage some Salesforce AppExchange partners to make sure that you’ve got profiles and permissions set up to minimize access. For additional protection, use Transaction Security Policies to fine-tune the ability for employees to export large reports or reports with sensitive data fields. Partners are a source of potential risk too. If you’re using a third party to do development work in your partial or full-copy sandboxes you’re exposed to their errors too. Considering taking steps towards secure application lifecycle management (ALM) using a tool like Data Mask to limit their access to your customer’s personal information.

Detection and correction in the cloud are made more difficult by limited or low-fidelity logging. Data is the lifeblood of a detection and response team. High fidelity logging can be the difference between a breach notification that talks about what might have happened vs. a notification about what did happen. Salesforce offers Shield Event Monitoring as a way to get the data you need to bring your cloud detection story to the next level. A third of incidents are detected in a matter of months or years, so make sure that you’ve got a solution for long-term log archiving. If you’re just getting started, there are AppExchange partners that can jump-start your detection, and Salesforce has recently released a beta of some artificial-intelligence-based detection logic that you can have running in your Salesforce organization immediately.

To learn more about the Salesforce Security portfolio and how we can help in securing your environment, visit sfdc.co/SalesforceSecurity today.

About the Author

Kevin Thompson, CISSP, is a Principal Security Architect at Salesforce and a graduate professor of risk management. He has served on the board of directors for the Society for Information Risk Analysts and is a former author of the Verizon Data Breach Investigations Report.