For years, security concerns have been the leading reason why organizations hesitated to adopt cloud services, which has also driven CASB adoption. However, a recent survey of 200 IT security professionals revealed that despite security concerns, only 35.0% of respondents thought that cloud-based systems are, as a general rule, less secure than their on-premises counterparts. 64.9% believed that the cloud is either as secure or more secure than on-premises software. Much of this trust can be attributed to the efforts leading cloud service providers like Salesforce have put towards securing their customers’ data and providing robust features that are required by enterprises.
Before getting into the 17 best practices security experts recommend for making the most of Salesforce’s built-in security, let’s first take a look at what Salesforce offers for security.
An overview of Salesforce security
Salesforce’s Trust is a customer-facing website that gives an overview of the platform’s performance as well as security issues that affect Salesforce customers. Specifically, this is where customers can find updates on phishing attacks and malware that Salesforce users must be aware of as well as remediation steps they should take to mitigate security risks.
As of today, the most recent malware impacting Salesforce users is Vawtrak, a malware variant that’s delivered by Pony (the initial downloader), which itself is delivered via phishing emails. Vawtrak steals the login credentials of a Salesforce user, then attempts to make unauthorized logins for purposes of accessing and stealing data stored in Salesforce.
Get an overview of Salesforce’s security capabilities that provide the highest level of protection for sensitive data, along with a 17-point checklist to make the most of Salesforce’s robust built-in security.
Like most malware that targets cloud services, Vawtrak doesn’t take advantage of a Salesforce vulnerability, but rather is something residing on the user’s computer and can access a host of cloud services once it knows the login credential of the service.
Salesforce and compliance
Salesforce uses the shared responsibility model for data privacy and security. With respect to regulated data such as Protected Health Information (PHI) and Personally Identifiable Information (PII), Salesforce acts as the data processor, meaning Salesforce is responsible for providing sufficient physical and technical security measures while Salesforce customers are accountable for the integrity, quality, and usage of the data, as well as the types of data being stored.
Salesforce has met the requirements of many rigorous compliance certifications including:
- ISO 27001/27018
- SOC 2
- SOC 3
- Safe Harbor
Salesforce’s Government Cloud, which includes Force.com, Sales Cloud, Service Cloud, Analytics Cloud and Chatter is also FedRAMP compliant.
In general, Salesforce contracts include clauses that prohibit Salesforce from accessing customer accounts or releasing customer data stored in their platform. There are certain exceptions to this, including when Salesforce performs technical updates to fix service outages/problems, or when legally compelled to share data with law enforcement.
Salesforce is a multi-tenant platform. This means it uses a single collection of cloud computing resources to provide its services to several tenants. This can raise security concerns around customers accidentally accessing data stored in another customer’s Salesforce instance. Salesforce solves this by giving each company a unique identifier, which then gets associated to each session that is started by a user within a company.
Salesforce Health Check
One of the most helpful tools of a Salesforce administrator is the Salesforce Health Check. This feature provides security score for certain Salesforce settings compared to a Salesforce recommended baseline settings, allowing administrators to understand how robust their configuration is from a security standpoint. The security score includes:
- Minimum password length (Salesforce recommends 8 characters)
- Maximum invalid login attempts (Salesforce recommends 3)
- Forced logout on session timeout (Salesforce recommends enabling this)
- Forced re-login after an administrator logs in as another user (Salesforce recommends enabling this)
Salesforce’s built-in security features
Salesforce administrators have several ways to protect data from both internal and external threats including auditing and access control.
Salesforce keeps track of all login attempts for the past six months, including the location of the login attempt and the IP address. Administrators can also turn on field history tracking (though with some limitations) to give visibility into field value changes and the user who performed the change.
Controlling user access to Salesforce
Salesforce has a robust system to control access and authenticate user identity that include:
Two-factor authentication – Administrators can turn on company-wide 2-factor authentication. Salesforce also lets admins create IP restrictions that would prevent access to Salesforce from untrusted IPs (or IP ranges). Admins can also set login restrictions based on the time of the day and the location from which the login attempt originates. When accessing Salesforce via an API, users are required to add a security token at the end of their password.
Custom login flows – One of the more innovative access control features of Salesforce is the ability to create custom login flows. As an example, if a user attempts to log into Salesforce from a restricted IP or during restricted hours, admins can implement a flow that would still allow the user to access Salesforce, but only after they’ve gone through several steps of authentication beyond 2-factor. In this way, an organization can meet their security requirements while also being able to perform business-critical activities within Salesforce.
Object-level permissions – Salesforce provides several layers of control over which records or the data stored in those records are visible/editable by which users or groups of users. Admins can set organization-wide sharing rules which sets the baseline minimum level of access, which can be configured separately for each object in Salesforce.
Role hierarchy – Organization-wide rules can then be extended using the role hierarchy (which itself can be turned off at the organization-wide sharing rules). Role hierarchy lets admins configure how data is visible/editable to users, their subordinates and their superiors. Role hierarchy does not determine which fields are available to users, but rather which records, reports, and dashboards can be accessed. In general, roles are a reflection of the organizations internal human resource structure, where the CEO would have the highest role in Salesforce, therefore have the broadest visibility to data (though some organizations might place the Salesforce Administrator at the highest level).
Exceptions – Some organizations need more flexibility beyond what organization-wide rules and hierarchy provides. In this case, sharing rules can be employed to further increase data access to those users who are considered an exception.
Field-level permissions – Profiles allow admins to give finer grain access or apply restrictions to individual fields within a record of an object. When creating a new field, admins are given the option to make the field read-only or read/write or completely invisible to each profile. Every user in Salesforce must be associated to only one profile.
Permission sets – Permission sets are yet another way that Salesforce allows admins to customize data access control. With permission sets, admins can create a fine-tuned set of permissions that only a subset of users need. When a user is added to a permission set, any restriction that their profile applies will be removed if the permission set allows it.
Public groups – A public group, which is a grouping of Salesforce users, can be used by Salesforce users to share content and knowledge. Users can specify, for example, which public group should be able to see a specific leads view within the lead object. There are many other uses for public groups.
Encryption – Salesforce provides what is now known as “Classic Encryption.” Admins can encrypt custom fields with 128-bit Advanced Encryption Standard (AES) using this feature, which comes out of the box. There are several limitations with this, including the fact that it only applies to custom text-fields that can’t be more than 175 characters long.
Salesforce introduced Shield in 2015 to provide customers with three additional layers of security: event monitoring, audit trails, and platform encryption.
Salesforce Shield’s event monitoring feature gives administrators and security professionals visibility into user behavior and application performance. Logs are generated and delivered the next day to customers via SOAP API and REST API. Event monitoring works best if organizations use Salesforce’s Analytics Cloud to visualize the events or a third-party tool that combines event logs from Salesforce and other services to analyze potential insider threats. Event monitoring can also be used to increase Salesforce use and drive adoption.
Though Salesforce includes a certain level of field history tracking available by default, Salesforce Shield dramatically expands tracking. Organizations can track field history going back up to 10 years across custom objects, accounts, cases, contacts, leads, and opportunities for 60 fields per object. This can be especially useful for highly regulated industries such as healthcare, financial services, and government agencies who need to maintain extended audit trails.
Platform encryption in Salesforce Shild is much more comprehensive and feature rich than Salesforce’s classic encryption. Here, organizations can encrypt data that’s at rest, including data stored in fields as well as files being uploaded to Salesforce. Salesforce employs probabilistic encryption using 256-bit AES. Though Salesforce has given the customer control over the lifecycle of managing the key, it’s still stored in Salesforce’s environment.
According to Salesforce, the following types of data stored in their cloud can be encrypted with platform encryption:
|Files and attachments||Standard fields|
|-Files attached to feeds
-Files attached to records
-Files in the Content, Libraries, and files apps
-Files managed with Salesforce File Sync
-Files attached to Chatter posts, comments, and the sidebar
|On the Account object:
-Account name, Description,
-Fax, Phone, WebsiteOn the Contact object:-Description, Email, Fax, Mailing addresses
-First, middle, last name
-Phone, Home phone, Mobile, and Other phoneOn the Case object and Comments:
-Description, Subject, Body
-Text area (long)
Salesforce security best practices
Between Salesforce’s native offerings and Salesforce Shield, the company offers many security capabilities. It’s up to the customer to make the most of these built-in capabilities, however. Here are the top best practices security experts recommend you follow:
- Turn on IP restriction for user logins to minimize the risk of unauthorized access in case of compromised accounts
- Turn on multi-factor authentication for all users to further reduce the risk of unauthorized access
- Make organization-wide sharing rules as restrictive as possible while allowing normal business functions and use role hierarchies, sharing rules, permission sets, etc., to extend access beyond the organization-wide sharing rules.
- Require secure passwords that combine uppercase letters, lowercase letters, numbers, and symbols, and require a minimum of 8 characters.
- Set a maximum incorrect login attempt to between 3 and 5 times.
- Enable obscured secret answers for password resets.
- Force re-login upon session timeout but enable session time out warning popup.
- Keep the session timeout timeframe as low as possible without annoying your Salesforce user base.
- Disable caching and autocomplete on login page.
- Expire user passwords within 90 days of creating it.
- Enforce password history so same password isn’t used until at least 5 new passwords have been used since the last time the given password was used.
- Passwords should not contain the word ‘password’.
- If using platform encryption, regularly generate a new tenant secret, which will generate a new encryption key.
- When destroying encryption keys, make sure all data encrypted with that key is decrypted first.
- Re-encrypt already encrypted data with the latest key if they’re using old keys, even if the old key is archived and not destroyed.
- Enable clickjack protection for:
- Customer Visualforce pages with standard headers
- Customer Visualforce pages with headers disabled
- Setup and non-Setup Salesforce pages
- Ensure all devices accessing Salesforce have the latest browser version, anti-malware software, and operation systems.
In addition to the data security capabilities listed above, Salesforce also provides robust access control and security for their data centers that includes:
- Around the clock human patrol and inspection
- Access control and identity verification via biometric scanning and video surveillance
- Secure data center rooms with reinforced concrete
- Buildings designed to withstand seismic activity, storms, and other natural disasters as well as temperature/humidity controls
Salesforce ensures a constant power supply to its data centers including:
- Underground electricity supply
- Backup Uninterruptible or Constant power supply
- Backup power distribution units (PDUs) Backup electricity generators
Salesforce provides both physical and digital protection to its network, including:
- Concrete protected fiber entry with high bandwidth capacity
- Backup networks
- Net-neutrality: connects to major carriers
- Use of firewalls and edge routers to minimize security risk by blocking unused protocols
- Use of internal firewalls to separate traffic between the service and the database tiers
- Advanced intrusion detection system that senses and reports abnormal events to a security event logging system that can send alerts and generate reports
- Use of outside security vendors that routinely scan Salesforce networks to alert on malicious activity that may change baseline configuration, assess applications & network vulnerabilities, and pen test and code reviews
- Use of Transport Layer Security (TSL) to ensure all users connections to Salesforce are encrypted.
- Maintenance of logs that records everything, from record creation, field updates, file uploads and the corresponding IP address and the date and time it occurred
About the Author
Categories: Cloud Security