Safety first: Salesforce security best practices

Picture this: one day you come to work and find out someone has attempted to compromate your salesforce data security. Or even worse , all the precious data from your  account was leaked. You might think it won’t fly with you and we strongly hope it won’t but don’t wave an idea of danger aside and ask yourself: what do you really know about salesforce security?

Just like all the data storages, Salesforce ecosystem can be subject to vulnerability. But being cloud-based storage is exempt from such a common danger as traditional storage can suffer. Moreover, cloud provides you an additional benefit of protection from physical damage caused by power or network loss. To see the overall picture of what Salesforce.com is doing to protect your data, let’s take a look at the basic Salesforce cloud security practices:

Health check

How often do you visit a doctor for check-ups routine? I bet at least once a year. Prevention is better than cure, isn’t it? Your Salesforce ecosystem is similar to a human organism and requires the similar preventive measures to maintain its health.

To begin with, I would suggest to start with Security Health Check. It aims  to eliminate the gap between salesforce.com security requirements and actual security implementation.

Go with your Security Health Check, if:

1. You have to understand your ecosystem’s overall vulnerability and stay updated with all security related processes.
2. Your business environment is changing, so the system keeps being configured: let the customers know about this.
3. Admins need to check whether  all the applications comply with the business needs.

Syntegrico recommends: Go with a Health Check Score and control your security settings with a special formula. If all of the settings  meet or exceed these requirements, the total score of health check makes 100%.

Password issues

It seems that sometimes Salesforce is too secure about how it manages users and passwords!  Default password settings make them automatically expire every 90 days so that users have to set a new unique password. But after system’s customization it’s only you to be responsible for password settings.

Syntegrico consultants suggest you to bear in mind the  following password Salesforce cloud security principles:

• Do not set the expiration date to “Never Expires” – though default values seem to be too strict, it’s no use to ease it off: define what term suits you and go with it.
• Let the users choose  their own password but set your policies straight and do not allow them to pick “12345” or “qwerty”.
• Set the Password History to remember at least three last ones.

Login security

As you know, Salesforce functionality offers you a lot of ways to secure logins. User’s profile is restricted with login hours, login IP range and org wide trusted IP ranges set by administrator.  Due to the Login History audit trail functionality, administrators can download the last six months of logins to the Force.com platform and keep track  of login attempts by user IP, API, or browser, to name a few.

If your login policies secured by all the three restrictions, mind the following scenarios:

• If user is trying to login outside of set login hours, even if the IP address is within the login Ip range, as well as trusted IP range, user access will be denied, login will be blocked.
• If user is trying to login within the set login hours, the IP range is within the login IP range but not within trusted IP range, activation to log in will be required.
• If user is trying to login within the set  login hours, the IP range is outside the login IP range but within trusted IP range, then user’s login will be blocked.

OWDs

If you still do not know about Organisation-Wide Defaults, or OWD, than, after reading this article you will probably make securing process a lot easier. OWD are set at the organization level and determine the baseline access to all the records for everyone in the org.

Role hierarchy

Role Hierarchy shows how Roles in your organization are related to each other. It comes into play when you face a challenge of setting access to an object based on your company hierarchy. A role can have one, many, or no Users, and it is the best way to make sure that every new User is assigned a Role after being added to a system. Role Hierarchy usage means that two Users at the same level will not see each other’s records if the OWD is set to Private.

!! Remember to assign Roles to each and every user added to the System – otherwise Role hierarchy won’t make any sense.

Sharing rules

What happens if you have an exception to the OWD? Sharing Rules are here for you. For example,  when sales users need to access only their Opportunities but marketing department needs to view all Closed Opportunities. In this case Sharing Rule for Public Read access should be created to allow marketing users to see all the closed records wherein OWD settings for sales can be left as Private.

Syntegrico recommends: Use the possibility of Manual Sharing for single cases, giving another User access to just one specific record without utilizing a full Sharing Rule.

Auditing

Your system seems to be running quickly and smoothly… But when was the last time you’ve checked it for security needs compliance? The number of weak points it contains will surprise you.

Salesforce Architecture could originally have inconsistent or conflicting solutions which significantly restraints Salesforce adaptability. The system could also contain unnecessary custom code or multiple integration with outsider applications that can be simply replaced with smart configuration. Once properly configured, Salesforce solution will be much easier and cheaper to upgrade and support.

Syntegrico on the guard of your security

Adhering to Salesforce security best practices, Syntegrico can boast of a range of auditing success stories. One of the recently conducted was for an insurance company. The Client constantly met Salesforce limits for storage and licensing as well as system performance problems. Therefore, the implemented system was analyzed against its compliance to the security standards of Salesforce.

The project consisted of two phases, including Salesforce technical audit and code refactoring of existing functionality according to Salesforce guidelines and best practices, and Salesforce data security model creation. After the proper auditing it turned out that the logic in the custom code ignored the access settings and security which could lead to unpredictable behavior of the system and possible data loss. The work was completed by fixing the critical issues which was confidently entrusted to our development team.

If you have read this article and still in two minds about security issues, the cause may hide in the complexity of your Salesforce instances. Syntegrico has dealt with the cases where wrong permissioning or inappropriate  engagement of the departments created reasonable delays in  successful Salesforce deployment. To avoid this, remember that the more complex your Salesforce ecosystem is, the better chances of meaningful  Salesforce security audit would be with an expert consulting partner. Contact us and check out what will work for you.