Cloud for Good
Search
Close this search box.

Security vs Convenience: Securing Your Salesforce Org

One of my colleagues recently received an email from salesforce.com asking her to download a file.  Only the email wasn’t from salesforce.com; it was a phishing attack.  The email contained malicious code designed to access her data.  This event caused me to think about Salesforce related security and how we, the users and administrators, can be the weakest link in an otherwise secure system.

When implementing Salesforce, we rightly focus on designing the system; what data do we need to input and the reports and dashboards we want as output.  But have you thought about how your decisions regarding Salesforce’s security features can dramatically affect the overall security of your data.  Kelly Hardebeck recently posted a great article about “Why a System Administrator Profile Is Not For Everyone,” so I am not going to talk about user permissions and visibility. Instead, I want to discuss controlling how your users log in to Salesforce.

Passwords
First, let’s talk passwords.  No one likes passwords and we especially dislike changing passwords even more, but they are a necessary evil.  You have the ability to set the complexity of your users’ passwords.   Simple passwords that never expire will make your users happy but do nothing for your security.  Remember that since Salesforce can be accessed via a web browser, you want to make it difficult for someone to guess your passwords.  Review your Password Policies and don’t take the easy way out.  I recommend the following:

I can be persuaded to let passwords expire in 90 instead of 60 days but I am a firm believer that after too many failed login attempts a user gets locked out until an admin resets their password.  Temporary lockouts just give patient hackers more attempts to gain access to your data.  My experience suggests that if they can’t remember their password in 5 attempts, users won’t remember it after a 15 minute break.   With the new Salesforce mobile app, admins can unlock actual users and reset their password from their smartphone.  Don’t forget to train your users to use the “Forget Your Password” link before they get locked out.

The permission “Password Never Expires” should only be assigned in the most exceptional circumstances.

IP Ranges and Login Hours
If you have inside staff that should only be using Salesforce when they are in the office, consider setting login IP ranges and login hours on their profiles so they can only log in from your network during office hours. Make sure your ISP is providing you with a static IP before restricting login ranges.

If a user tries to login from an IP range that is not listed in the Network Access section, Salesforce will require the user to confirm their identity and activate their computer. DON’T deactivate this feature.  I’ve seen some road warriors complain about this feature but Salesforce.com has made this less obtrusive than when first implemented.  Users can decide if they receive the activation code in an email or a text to their mobile phone.  This is a key security feature and the one minute delay that a user may encounter when logging in from a hotel is a small price to pay for your data security.

Controlling Your User Licenses
If your organization assigns email addresses to your staff, activate the Winter 14 feature “Restricting User Email Domains” to prevent users from adding a personal email address to their user profile.  This will ensure that password reset emails and other Salesforce messages will be only sent to your organization’s authorized email addresses.

Monitor your users’ login rates and deactivate users who are not logging in.

Create a workflow rule and field update on the user object that will automatically deactivate temporary users based on the value of a custom date field.  I have also found it helpful to add a custom textbox to the user object and populate it with the reason someone has access to Salesforce.  Sometimes a user’s profile and role do not provide enough explanation and in larger organizations or ones with high staff turnover, you need a reminder of who a person is and why they deserve access.

Make sure your Salesforce admin is included in your organization’s employee termination processes.  Deactivating a user two weeks after they leave is never a good idea.

If you have any third party applications or integrations that require access via a user license, create a special license as an “Integration User” and configure a custom profile with only the permissions  required by the integrated application(s).

Phishing Trips
As an administrator, visit the trust.salesforce.com  site and notify staff of potential phishing attacks.  Salesforce.com won’t send users emails asking them to download files.  If you or your users receive a suspicious email check the site and contact your AE.

Security Trumps Convenience
It would be great if we lived in a world without door locks, PIN’s and passwords but we don’t.  So, when you are configuring your Salesforce Org and deciding which records and fields your employees can see in Salesforce, spend some time making sure that only your employees will be able see your Salesforce data.