With Salesforce handling more and more sensitive data, you can respond to the increased risk surface in one of two ways:
Working with organizations both large and small, Ed Ponte witnessed many companies take the latter stance—a path he doesn’t recommend.
Now the Product Manager for OwnBackup’s Secure for Salesforce, Ed builds the product that solves the problems he saw. He’s a vocal advocate for keeping data secure within Salesforce orgs and minimizing exposure through risk assessment.
On an episode of the Beyond Backup podcast, Ed discusses Salesforce Shield best practices, how to navigate managing multiple SaaS applications, and the power of risk assessment.
With years of risk assessment under his belt, Ed says that he’s seen one key theme most often: a lack of awareness of the risks present in SaaS applications.
CISOs and other infosec leaders need to manage many elements to keep their enterprises safe. With all that they oversee, it’s understandable that they hope SaaS vendors keep security tighter than they actually do.
But the shared responsibility model for data security is, in fact, shared: While SaaS vendors handle the security of the infrastructure, data security is left in the hands of the data owners. This means that when infosec teams rely on SaaS applications to protect their data in the cloud, they leave themselves horribly exposed.
Ed explains that this lack of risk awareness is the root of many other problems. “Everything else flows from that lack of awareness, lack of inspection, and lack of governance because you’re not aware there’s a potential problem out there,” he says.
In this day and age, this lack of awareness might seem surprising. And although a high-level understanding of the risk inherent in SaaS applications may be increasing, many organizations still aren’t taking the steps to eliminate security gaps altogether.
Ed has seen many clients with robust policies in place that correctly reflect the business’s risk environment. But they were only implementing these policies on their legacy applications—not on cloud applications like Salesforce.
What’s more, many administrators and developers might be aware of authentication policies while still committing violations. (Ed calls this “not locking the front door to the application as well as you could.”) These violations can stem from a limited understanding of how different Salesforce features expose sensitive data to unnecessary risks.
In response to these security gaps, the power of risk assessment lies in educating the infosec and admin teams and bringing them together under a shared language. Working toward a common goal of data security requires taking admins out of Salesforce jargon and infosec teams from the world of SaaS features to a unified understanding of risk.
For organizations looking to protect their most sensitive data, Salesforce Shield is essential. Its core features—such as Platform Encryption, Event Monitoring, and Field Audit Trail—provide a strong foundation for holding up your end of the shared responsibility model.
But implementation is no easy feat. That’s why it’s critical to start by classifying your data. Whichever Shield applications you implement first, you need to begin by understanding what (and where) sensitive information is in your organization.
Not only does the classification process shape your understanding of the concentrations of risk, but it enables you to implement Shield in the first place.
Before you set up Platform Encryption, you need to know which fields are sensitive: They’ll be your targets for encryption. Likewise, those sensitive fields are the fields that you’ll track through Field Audit Trail. Event Monitoring will show you entities or objects you should monitor because they have sensitive fields.
But you need to classify your data before you can implement any of these valuable tools for your organization.
Implementing Salesforce Shield and its applications is an undertaking—but Ed cautions against viewing implementation as a one-and-done project. “You don’t just flip a switch and you’re protected.”
He points out that organizations add new fields all the time, leading to the presence of new sensitive data—and this reality demands processes to continually revisit these applications. Implementation of Salesforce Shield is a project, but a security program is essential to manage Shield and keep it protecting your organization over time.
This maintenance looks like encrypting new fields, rotating keys for encryption, and updating monitoring capabilities to track new fields that support new business processes. These ongoing adjustments help you stay protected amidst always-shifting risks.
In a world that runs on SaaS, protecting your data rarely involves just one environment. It typically calls for data security in multiple SaaS environments from Microsoft Dynamics to ServiceNow.
Ed offers these words of wisdom about not just securing data across multiple SaaS applications but staying resilient in the face of risk.
Team members at every level of an organization operate with limited resources. That’s why infosec teams partnering with the admin teams for the SaaS applications is critical.
These teams need to work together to balance their differing strengths and expertise. Infosec teams know how to secure applications, and they understand policies and compliance needs. Admin teams know how the application supports the business, which helps to shape understanding of the risk of the application.
Bringing together the collective knowledge of these groups provides the foundation for a robust security program that protects the sensitive data of at-risk SaaS applications.
Knowing the risk level of each application lets security teams invest their team in areas of greatest need. “Not all [Salesforce] orgs are risky,” Ed points out. “There’s some stuff that you don’t need to spend time on, even if you had resources.”
Interview admin teams to understand the risk profile of each SaaS application. For example, is the application supporting a process that handles sensitive data: mergers and acquisitions, healthcare data, or Personally Identifiable Information (PII)?
Look for data involved in the business process (and being brought into the organization) that need protecting. Along the way, you’ll also find fields that don’t need to (or can’t) be protected.
By assessing risk, you can detect which applications are a high priority for protection because they put the business at risk and which ones don’t demand your time and attention.
Shield offers field-level encryption, not tenant-level or database encryption. And because encryption happens per field, a field’s use in sorting, filtering views, or reporting can break things in the Salesforce org.
What’s more, not every data type is supported for encryption. So Shield encryption can be a major undertaking to understand which fields can’t be encrypted and the business impact of those that can. (And if you have 1,000 or more fields, this can be an overwhelming and time-consuming endeavor.)
Luckily, data protection tools (like OwnBackup’s Platform Encryption Analyzer) can help automate checking these fields to ensure encryption goes as smoothly as possible.
Attempting a look into the future, Ed foresees that the awareness of risk will continue to increase. But unfortunately, simply surfacing risk information (while a step in the right direction) isn’t inherently actionable.
“The next big challenge to solve is going to be identifying and communicating what the risk of any given control state or setting mismatch is,” Ed explains. “If you have 100 things to fix, you probably only have the bandwidth to fix 10.”
His guidance shines a bright light on the need for risk assessment. If you only have enough time to put out some of the data security fires in your organization, you’d better be sure they’re the biggest and most urgent ones.
At the end of the day, the best way to enhance your organization’s security posture is by identifying and assessing risk and taking critical steps to protect your data.