76% of IT security leaders say they’ve experienced a data breach in at least one of their business systems. Needless to say, it’s important to follow proper security practices in order to protect your Salesforce Org and data from security threats. While the platform is reasonably secure on its own thanks to Salesforce Shield and built-in tools like the Security Health Check and Einstein Data Check, you’ll need your own plan in place to cover everything these native tools don’t.
To start you on the right foot, we’re taking a look at some common mistakes that put Salesforce, and the sensitive data it contains, at risk.
Giving everyone Admin access
The System Administrator profile in Salesforce has access to change the entire configuration of your Org. The Admin profile has over 100 specific permissions, giving users with it the ability to modify objects and fields, access third-party integrations, export data and more. The more people you have with such broad privileges, the more risk you are introducing into your Org.
While there is a temptation to grant Admin access to expedite support or dev projects, consider instead using a restricted permission set that allows users working on these projects to broadly view — but not export or change — data and system configurations.
Tip: Use Netwrix Strongpoint to quickly identify all users with the Admin profile, as well as ‘Phantom Admins’ who have been granted ‘Modify All’ privileges via a permission set.
Not classifying your data
To properly secure sensitive data, you need to know where it is and who owns it. Salesforce stores a lot of data, and lots of different types of data. There are no one-size-fits-all solutions for keeping it secure. That’s where data classification comes in. Data classification allows you to identify and categorize data based on risk, and build effective, appropriate policies and controls for protecting it.
Salesforce’s native data classification tool lets you categorize data based on compliance, usage, owner and sensitivity. Taking the time to assign an owner and a sensitivity level to different fields in your Org will give you a big-picture overview of where resources should be deployed, and what controls should be implemented.
Misconfiguring APIs
With the rise of cloud-based applications and the hundreds of applications businesses use, APIs are being used more than ever to connect end-to-end processes and to transfer data, usually through third-party integrations. While this type of flexibility is great, it’s hard to know what’s going on in the background — without proper system integrations, unauthorized users can easily hijack your system or open up your Salesforce Org to unknown and insecure systems.
In a busy Org with extensive customization — and, often, multiple consultants configuring the system — API security gaps are more common than you’d think. There are many ways to close these gaps, but the simplest is to make sure any data passing through an API is encrypted.
Tip: Learn more about API security here.
Going without an official security program and owner
You can’t manage security in Salesforce unless you have appropriate resources dedicated to it. Too often, there is a tendency to make decisions on an ad-hoc basis, defaulting security ownership to individual teams.
The danger of this is obvious — things can easily be missed, and responsibility for key decisions can be kicked further down the line. Instead, implement a formal security review group to own the responsibility. With a team dedicated to reviewing and identifying threats on different projects, you’ll ensure that nothing has fallen through the cracks. What’s more, this group can help your entire organization cultivate knowledge and skills that will make it easier to address problems that arise.
Tip: Salesforce offers a certification specifically focused on identity and access management in Salesforce, “designed for those who assess the architecture environment and requirements and design sound, scalable and high-performing solutions on the Force.com platform that meet the Single Sign-on (SSO) requirements.”
