Salesforce Security - Admins, Do Your Share

Your data is valuable to you and your prospects and customers. We put together some tips for improving your Salesforce security practices.

Salesforce-Security-Admins-Do-Your-Share.png

Let’s face it, 2014 has been a bad year for corporate security. Sony Pictures, Home Depot, Target and JPMorgan Chase are just the most prominent names of companies that became victims of cyber criminality. They found themselves in a PR nightmare due to data breaches. Also, Salesforce security went under attack by the Dyre Malware going after Salesforce credentials. This means: it can hit your company too. So, why not start the year with a Salesforce security sanity check of your Salesforce org? Here are some tips that come with no costs, but might significantly improve your Salesforce security.

1st Salesforce Security Tip - Keep Them Out

This is about making it as hard as possible for intruders to get access to your Salesforce org.

One effective feature on Salesforce security is to require users to activate their computer if they have never logged in from a particular computer before. This works by either sending the user a verification code via email or text message (or, using a one time code generator app a user must install on their mobile phone). Even though the email option is the most convenient for the user, it is the least secure. Reason being, users tend to re-use their passwords across multiple systems. This means that as soon as a hacker steals a user’s email username/password, they can conveniently log into Salesforce and cause even more damage. So, what can you do?

  1. Make it clear to everyone that re-using passwords is against your security policy.
  2. Avoid email verification and use the text message verification instead. This is most important for system admin accounts.
  3. If you have an SSO system in place, make sure users can only log in via the SSO. Leaving them the option to alternatively use their Salesforce username/password defeats one of the major Salesforce security gains of your SSO system.
  4. If a group of users are desk-only workers (e.g. call center agents) implement login restrictions (e.g. only computers in a certain IP range can log in). This is pointless if you include your open WiFi - go figure.

2nd Salesforce Security Tip - Lock Them Out

One of my pet peeves is admins forgetting to de-activate Salesforce user accounts of users that have left the company. Assume they are now working for your competitor and still have insight into all the deals you are working on (including contacts, pricing and activity history). Shocking idea, isn’t it? All of the above measures apply for this scenario but I’d like to add these:

  1. Make sure user passwords expire at least after 90 days. The shorter the expiration period, the better - yet, the less your users will like you.
  2. Don’t forget your sandbox! The so called “Full Sandboxes” typically contain all your customer data. To make things worse, the passwords of your users are the same and the username can easily be guessed. Therefore always make sure only people that really use the sandbox have active accounts in your sandbox after you refresh it.

3rd Salesforce Security Tip - Assume Breach

My key takeaway of the the assume breach paradigm is that you should always ask yourself “What would happen if a hacker gets access to my Salesforce org?”. Besides the data that is exposed to the intruder, it certainly depends if the intruder got access with sys-admin privileges (see below) or just as a standard user. This implies that you must keep the permissions of your standard users as tight as possible. You may want to ask yourself these questions:

  • Do they have Modify All or View All permissions on any objects? If so, it defeats the point of your sharing settings.
  • Do they really need access to all these objects? E.g. does a demand rep really need access to post-sales objects such as the contract object?
  • Are your users mindful of what they store in Salesforce. E.g. storing credit card numbers in a notes fields is grossly negligent and your users should know that.
  • Do they really need API Enabled? See my blog post about OAuth to understand why this matters.

Minimize Super Users

Definitely the worst thing that can happen is that an intruder can log in as a sys admin. In that case, all of your Salesforce security measures will fall like dominos. This is implied by the ability to create new users, install apps, deploy code and log in as another user. Thus ask yourself:

Do all the users that are system admins really need the full set of privileges?

I have seen companies give sys-admin privileges to underpaid data quality temp workers. Instead, they could have created a new profile for them with just the permissions they really need.

Did you hire consultants and gave them sys-admin access?

Remember that consultants deal with many Salesforce orgs and they will have their own way of managing all their credentials (and they might have to share it with their co-workers). The methods I have seen range from memorizing it (good) or using a Chrome extension (bad), to a shared Google doc (very bad). All this puts your org at risk. The only legitimate way I can think of is them using a password safe, which I think is a fair requirement from you as a customer. Also, don’t forget to de-activate their account after your engagement with them is over.

Did you install a 3rd party app that wants you to create a Salesforce user account to to give the 3rd party access to your org?

Marketo is a good example where you have to do this, but at least the permissions are very restrictive, according to the Marketo install guide. If an app wants you to give it admin permissions, you should ask the provider why they think this is necessary - because it really shouldn’t be.

Last but not least: Who deactivates the sys-admin account of users that leave the company - including your own?

The tips above can’t replace a thorough risk assessment and enforcing security policies and procedures. But I hope this is at least food for thought.