Salesforce Security For Admins, Devs, Architects, And Consultants: The Ultimate Guide

Cyber attacks are popping up in headlines, and keeping your data secure should be top of mind for Salesforce professionals.

Whether you’re an Admin safeguarding data access, a Developer writing code, an Architect focusing on delivering solutions, or a Consultant advising clients on best practices, getting to grips with the fundamental tenets of Salesforce security is non-negotiable. 

The Salesforce platform provides various features to support data protection, but there is always a human element to security too – so less technical roles don’t get off lightly when it comes to responsibility. 

Let’s take a look at what Salesforce professionals need to know about doing their part to avoid catastrophe – and some common pitfalls to avoid. 

Security for Salesforce Admins

Admins need to stay up-to-date with the latest policies, methodologies, and tools to keep information safe. The three most critical components of a comprehensive protection protocol are understanding, protecting, and monitoring your data. 

Understanding your data is the first and most important step in developing your organization’s data protection protocols. 

Personally identifiable information (PII) is any data which can be used to identify a specific individual. It is often protected by regulatory frameworks, like GDPR. 

The storage of PII might require your organization to develop a data protection and management framework which is compliant with the relevant regulation. PII examples include:

• First name and last name 
• Email address
• Phone number
• Governmental IDs (i.e. Social Security Number, National Insurance Number, Tax Id, etc.)

All personal data should be handled with care, but some personal data needs special care because of its sensitive nature. 

PII is any data which can be used to identify a unique person. But sensitive personal data is any personal data which can be used to cause harm to or discrimination against that person, which can include:

• Race or ethnicity
• Religion or spiritual beliefs
• Political beliefs
• Genetic or biometric data
• Sexual orientation and/or gender identity 
• Health status

Sensitive data might also take the form of financial information such as credit card numbers or account passwords. 

Now let’s take a look at compliance. Data security is paramount for all organizations which manage constituent data, but data compliance becomes even more critical and complicated in highly regulated industries like healthcare and finance. 

It is of the utmost importance that your team liaises with a data security architect who understands compliance and regulation for your industry – if it is highly regulated. 

Even in less or unregulated industries, admins should get to grips with the key tenets of regulatory frameworks which protect constituent data, including:

• Consent for clear usage
• Data minimization
• Data accuracy
• Limited retention
• Data integrity and confidentiality 
• Data subject rights
• Breach notifications
• Accountability and governance

The list above is not exhaustive or specific to a certain policy, but it outlines the intention behind most data protection regulations. 

To read about how Admins can protect and monitor their data, check out Caitlin Graaf’s article for Salesforce Ben: Understanding Salesforce Data Security: An Admin’s Guidebook

Security for Salesforce Developers

Developers are perhaps at the frontline of Salesforce security, but they should know it isn’t just their responsibility to make sure disaster is avoided. 

Tristan Lombard, Dev and Engineering Community Builder, told Salesforce Ben about a DevSecOps report showing that as many as 48% of developers do not have the proper time for security.

And Matt Meyers, Salesforce CTA and Founder & CEO EzProtect, told Salesforce Ben that it is still everyone’s responsibility to make sure everything is secure. 

Here’s some of his tips on how to do that. 

Firstly, devs should get up to speed with Salesforce’s Shared Responsibility Model, which is, essentially, the idea that a Salesforce org is something that both the customer and Salesforce itself have a responsibility to protect.

Our recent Salesforce Ben surveys indicated a low understanding of the Shared Responsibility Model among developers (45%) and admins (26-27%). 

E-commerce sites make for attractive cyber attack targets. Salesforce uses and makes available the following tools and practices to help strengthen customers’ security: 

Secondly, devs should consider learning more “soft” skills – and using them to more effectively handle hard conversations which need to be had. 

Matt mentioned an incident where a developer sent a block of code and a line of text saying, ‘Here, I fixed the issue’, to business executives who have no idea what they’re looking at. Learning those business and communication skills – or cooperating more with Salesforce Admins who might have built these skills up a little more – can help the developer immensely.

Thirdly, it’s best to make use of AI tools, because bad actors are already doing so. 

Developers should “think like a hacker” and create “anti-personas” – similar to personas which businesses create to represent customers or users, but in this case representing nefarious people who are trying to access the system. 

Marla Hay, Vice President of Product Management for Security, Privacy, and Data Protection at Salesforce, says that while security concerns are not new for developers, they are becoming much more acute and scaling because of automation around data and tasks generated by AI. 

Read more about how Developers can avoid disaster in the below article: How Salesforce Developers Can Avoid a Security Disaster

Security for Salesforce Architects

Salesforce security is having something of a reputational problem – not because the platform is insecure – but because many organizations simply don’t know how to secure it properly. 

Salesforce-related breaches have been in the news this year and we see a similar pattern emerging. 

Technology Engagement Manager and Architect at Banham Patent Locks, Beech Horn, told Salesforce Ben what we’re seeing is security teams not understanding Salesforce, and more Salesforce teams not understanding security. 

“You don’t know what you don’t know,” Beech says. “Security teams can’t speak the language of Salesforce… and teams only realize once an extortion email lands and the data is already leaked.”

Let’s take a look at some of Beech’s top tips for Salesforce Architects. 

Firstly, companies lack people who understand both Salesforce and security. Experienced security teams do not understand the way Salesforce, MuleSoft, Slack, Marketing, or Commerce operate, while teams who are experienced with those products typically only know some security, but don’t possess the wealth of experience of a security professional.

With a lack of hybrid skillset and proper visibility, the ecosystem needs to close the gap between Salesforce professionals and security professionals before attackers do – or architecture will always have holes. 

Secondly, when companies try to audit Salesforce security, they can miss the parts that matter most, as tools, documentation, and visibility simply don’t keep up with threats.

Blind spots repeatedly expose companies without them realizing it. One such blind spot is the belief that Salesforce’s native tooling already provides strong coverage. You can buy the feature, but that does not mean you’re protected. 

According to Beech, there are also risks organizations can’t see – which is where hackers have been operating most effectively over the past few years.

Next is the concept of “zero trust”, and the principle of “least privilege”. A lot of organizations try to uphold these ideals, but not many successfully implement them in a way that doesn’t collapse under pressure.

Businesses don’t want to slow down workflows for the sake of a vague security threat in the distant future, and if a new feature creates friction for users, the security can be altered or completely removed.

If security proves to be a hassle, then staff can end up not reporting suspicions to IT to avoid additional bother, and people may share shortcuts, quietly disabling some controls, or even forming their own private channels. 

The solution, according to Beech, is to stop treating least privilege as an access-restriction exercise and start treating it more like a user experience design problem.

To read more about how Architects can get to grips with security, read Thomas Morgan’s article: How Hackers Are Exploiting Salesforce and Why Architects Must Act

Security for Salesforce Consultants 

If a business can’t make sure its users and customers will have their data protected in the org, everything can quickly fall apart. 

Salesforce Consultant at IBM, Richard Tuharsky, told Salesforce Ben that  security in Salesforce is a shared responsibility – not just a “checkbox for IT”. 

Salesforce Technology Systems Consultant, Andrew Day, says that data breaches can be a stark reminder of how pertinent appropriate security measures are, and consultants should not just wait for one to occur to take action. 

Whether it’s clients, customers, or stakeholders, it is evident from speaking to the Salesforce Consultant community that there are still many considerations they wish these parties would keep in mind. 

Umar Rafi and Muhammad Zohaib, Salesforce Consultants, say that they tell clients good security is less about being restrictive and more about being thoughtful.

For instance, instead of turning admins or users into “heroes” with too much access, adhering to the principle of least-privilege keeps orgs safer and far easier to maintain. Minimal profiles and expiring permission sets might feel slower at first, but they stop messy access sprawl which can be a nightmare to untangle later on down the line.

Consultants are often first in line to navigate a client’s org, helping with setup, rollout, and adoption, so the pressure to deliver something functional, scalable, and safe is weighty. 

It’s generally a good idea to approach security from relevant angles, utilizing everything from MFA to a strong password policy. If someone does not need to read into the information, they don’t need to see the information. 

Don’t skimp on appropriate monitoring. When security measures are put into place, the job is not finished. They need to be monitored..”

To find out more about Salesforce security for consultants, read Sasha’s article below: What Salesforce Consultants Really Think About Security

Final Thoughts

Whether you’re a complete newbie or a Salesforce MVP, everyone can benefit from brushing up on those essential security elements.

As we’ve stressed throughout this article, security is everyone’s responsibility, and doing your part means everything will keep running smoothly.

The post Salesforce Security for Admins, Devs, Architects, and Consultants: The Ultimate Guide appeared first on Salesforce Ben.