Salesforce CRM Security: Are you secure?
Salesforce is a cloud-based solution that enables businesses to find more business leads, better customer outreach, helps in managing new accounts, closing deals and provides a higher level of customer support services.
It enables its customers to track their customer leads, customer activities, customer marketing and many other related activities. Salesforce also lets you generate metrics and data in the form of Dashboards.
Slack was acquired by Salesforce to make it part of its offering. You can also refer to the following article on Slack Security, that has discussed the common security pitfalls in Slack and its remediation.
Salesforce CRM market share: Salesforce is everywhere around us, it has almost 24% of the total CRM market share as compared to 5.4% of SAP with similar numbers for the likes of Oracle and Microsoft.
Imagine how many customers will be affected with any Security issues in Salesforce.?
Salesforce has already given Security a good thought and has provided various security controls & features in its CRM platform.
Let’s discuss it in our further discussion.
Different layers of Salesforce Architecture:
Salesforce Architecture Layers:
- Multi-tenant: Salesforce stores data in a single database schema and there is a single shared application service for multiple clients. This enables the developers to share the build applications with all clients via deployment in a single cloud environment.
Service Like: Sales Cloud, Marketing Cloud, Analytics Cloud, App Cloud.
2. Metadata: Salesforce uses a metadata-driven development model that enables developers to focus on building the application and store the data at different levels.
3. API: Salesforce provides a powerful source of APIs that helps in developing and customizing the Salesforce Mobile App. APIs lets you connect your apps with other apps without any hassles. Examples: Visualforce, Lightning using Apex.
Also, note that Salesforce does have offerings for SAAS, PAAS and IAAS.
Representation of Architecture by Salesforce:
I have covered a few basics of Salesforce and will now move to its security features and controls.
Salesforce Authenticate Users:Preventing unauthorized access to your organization using the following authentication mechanism.
- MFA,SSO
- Custom Login Flows: It directs the user through a process such as enforcing strong authentication or collecting user information. When users complete the login flow successfully, they’re redirected to their Salesforce org or site. If unsuccessful, the flow can log out users immediately. (source: Salesforce)
Example: Click Here - Connected Apps
Integrate Salesforce and standard protocols, such as SAML, OAuth, and OpenID Connect. - Manage User Passwords: Provides users with a unique username and password that can be configured to use several password policies like password length, complexity etc.
- Device Activation: User identity is verified on the basis of browser or device or from an IP address outside of a trusted range.
- Session Security: Set up sessions timeouts.
Shared Security Responsibility Model: Salesforce
It’s similar to the shared responsibility model that you must be familiar with for all CSPs like AWS, GCP and Azure etc.
Refer to below shared responsibility mapping for CSP and You:
CSP Responsibility: It would primarily depend on the kind of Salesforce Product.
- Uptime and Availability of Applications.
- Hardware like Storage, Networking, Database.
- Software running on hardware for virtualization.
- Availability of Regions, AZ and Edge Locations.
- Data Privacy and segregation.
- Industry Certification and Compliance
- Regulators Controls.
Customer Shared Responsibility: Have proper controls over data that is residing in Salesforce. There are multiple Security features available in Salesforce but you need to configure them properly.
- Customer data security and its sharing settings.
- IAM and Application: IAM permission setup, profile permission and the developed Salesforce application code hygiene/SAST.
- Network and Firewall Configuration.
- Enable data encryption.
- Enable Data Loss Recovery option: This lets you restore Records, fields, files and metadata.
Good! news you can sign up for free Salesforce Developer account and follow the further steps along.
Create Salesforce Developer account: https://developer.salesforce.com/signupFirst time login to Salesforce will ask for your email verification:
Salesforce Landing Screen:
Let’s get started:
Click on top right
Gearand thenSetup.
> Ahh! sales figure, this is a test account :-)
Try exploring options on the left panel and search
"security"in quick find.
Refer to following
securityoptions:
Salesforce Security Model
Salesforce “Data Security Model” can be grouped into four main categories:
- Organisational Level Security: It lets you decide on
which user,whenandfrom wherecan access your Salesforce Systems.
It utilises following settings:
- Password Policies: You can enforce password related policies like Password expiration time, length, complexity, number of invalid login attempts.
Let’s provide “Password Policy” for all users, this can be done for particular “User Profile” as well.
Search for Password Policies
Clicking on a specific user will tell you what all permission they have.
Select Profiles:
Scroll down to see Profile details:
- IP Restrictions: Users are allowed to access the Salesforce directly from specified IP ranges, for example: Office, School etc. However, if users login from outside the trusted IP range then they need to validate 2FA.
- Time Login Access: Specify and limit login access on the basis of business working hours. For example, your employees can’t login on weekends.
Before we move further it’s important to understand the three data constructs of Salesforce like Objects, Fields and Records.
Objects (Leads, opportunities, contacts), Fields and Record in Salesforce.
Example: Salesforce Objects, Fields and Records
Salesforce uses object-level, field-level, and record-level security to secure access to object, field, and individual records.
Good representation of Salesforce Security Levels:
2. Object Level Security: It is used to control data access in a way that, who can see what and this can be done by setting object permissions under Profiles and Permission Sets.
A. Profile: Enable profile based settings for what CRUD functionality can be performed by users. So, profile lets you control the access to objects.
Go to Home > Search
Profile> selectRandom ProfileandClick.
I have selectedContract Manager
Look into selected Profile > Scroll down and look for “Standard Object Permissions”
B. Permission sets: It provides the special permissions to users on top of profile permissions. In a way it extends the user’s profile permissions without changing it.
Go to Home > Search
Permission Sets> CreateNew
Provide following details:
Add Labels, API Name, assign licence and click save
After saving check the following details like, Description, Last Modified by and click on
Object Settings.
Select the Object to provide permissions, I have selected
Assets.
Click Edit and check the required permissions and Save.
3. Field Level Security: Admin can control what CRUD actions can user perform on field under the object. It is just used to restrict the ‘CRUD’ access and cannot be used to grant the access.
We can apply FLS under Home > Search
Profile> selectProfileandClick.I have selectedContract Manager
Scroll Down and look for “Field-Level Security” > “Select the Field and click View. I have selected Account in my case.
Update the required field level permissions:
4. Record Level Security: It lets you limit the record access for users in a way that they are only allowed to see a few records.
Example by Salesforce:
For example, if your user has an access to any of the account field, then logically they do have the access to both object & account field. However, you can limit the access to specific account record like “Account A” or only for “Account B” using the access control via sharing settings.You can manage record level access in following way:
Set Organization Wide Defaults(OWD) Sharing Settings > Define Hierarchy > Create Sharing RulesA. Organization Wide Defaults(OWD): Set the organization-wide sharing settings for each object. Once the new account is created there will be owner id associated for owner permission. You can utilize organization-wide sharing settings to restrict your data to private or public.
You can search for Accounts and select/create one of the existing accounts.
> Go back to Setup >>
Search for Sharing Settings
Change Account settings of Public to Private or versa from Sharing Settings.
So, under Account and Contract you can edit the permissions for Public, Private, Public Read Only and Public Read/Write.
B. Role Hierarchies: After setting up OW sharing settings, the first way to give extended access to records is via role hierarchy. It ensures that users with higher hierarchy can always access all records owned by users with lower hierarchy regardless of the OWD. Example: Our Manager can view all our timesheet records but we can only view ours.
Role Hierarchy can be setup under > User > Roles > Setup Roles
Create new role and assign the required hierarchy:
Verify Role Hierarchy:
C. Sharing Rules: Sharing rules to extend sharing access to users in public groups or roles by providing horizontal access to records across your organization.
Example: Managers can access Recruitment and Appraisal portals. Something that can be also accessed by a talent sourcing team and HR Generalist.
Get under Sharing Settings > Sharing Rules > Account Sharing Rules > Click New > Create New Sharing rule.
Try exploring both
Rule Typeoptions under Account sharing:1. Based on records owner OR Based on Criteria and then Save.
D. Manual Sharing: Lets you provide access to a particular record to a specific user.
User Sharing Settings > Scroll Down till the the End > Under Other Settings > checkmark
Manual User Record Sharing > Save > Then select the required settings.
Another good setting to explore here would be to look at Event Monitoring Settings:
Click on
Event Monitoring Settingsand exploreEvent Manager
You can enable these logs to get Stored or query event data in Salesforce objects. Salesforce big objects can store large data volumes for up to six months. So, that is why you get two kinds of log sources available in your Salesforce i.e. usual Salesforce Audit Logs and Salesforce Objects related logs.
You can also Stream these logs externally using a streaming API client.
Event Manager — Events
Click on “Credential Stuffing” for viewing its Fields and Events format.
Check Fields and Data Types:
Object: CredentialStuffingEventStoreWhat can be done on the basis of this event type trigger?
- Set alert for when Salesforce detects user login during a credential stuffing attack, this can give your details like Source IP, header etc.
You can also refer to “Salesforce Security Guide”
Salesforce Auditing Logs:
Audit logs provides you with an artifact of system usage that will be used to detect potential or real security issues.Some of the examples are as following:
- Login History: Provides logs for successful and failed login attempts in your organization for the past 6 months and you can also ingest these logs in SIEM for real time detection. See Monitor Login History.
- Record Modification Fields: Get details of the user who interacted with records, this includes the name of the user, actions performed and timestamp.
- Field History Tracking: Enable auditing for individual fields, which automatically track any changes in the values of selected fields. See Field History Tracking.
Audit Trail: Admins can view or Setup Audit Trail. You can refer to this documentation by Salesforce to get more information about the “Changes” that can be tracked. Configure File Upload and Download Security Settings
To enable better security, control file types during upload and download:
There is also a feature called Health Check in Salesforce that uses a proprietary formula to score your security setting against the Salesforce Baseline Standard or the custom baseline.
There are four risk categories that affects your Health Check score:
- High-Risk
- Medium-Risk
- Low-Risk
- Informational
Score Breakdown: Your grade is based on your score (As per Salesforce)
90% and above = Excellent +++++
80%–89% = Very Good ++++
70%–79% = Good +++
55%–69% = Poor --
54% and below = Very Poor -Security specific offering by Salesforce called “Shield”
Salesforce Shield: Provides an extended security layer on top of the available security controls by Salesforce that provides the following features. It is a huge topic, so I will just cover the basic introduction to its features.
- Event Monitoring: This feature lets you view in-depth user activity details and detect user behavior anomalies.
- Field Audit Trail: Select certain fields to be tracked and view its complete history including the changes at the object level. You can set triggers and create an audit trail with up to 10 years of interaction history.
- Platform Encryption: It provides native encryption of Salesforce data at rest across all your Salesforce apps using 256-bit AES and you can also mask a few selected data fields. It is designed to allow you to retain critical app functionalities like search, workflow etc.
- Automate security policies and run Compliance Audits.
Know more about Shield: https://shieldlearningmap.com, https://www.salesforce.com/ap/products/platform/products/shield/
Security recommendations by Salesforce:
- Enforce MFA.
- Activate IP Range restrictions.
- Set Session timeout.
- Enforce Password policies.
- Set threshold for login attempts to avoid brute force.
- Control OWD policies.
- Use Enhanced Transaction Security to monitor events.
- Have security POC or Security Champion for Salesforce Related Issues.
- Enforce platform encryption and enable key rotation.
- Ensure that data is decrypted first before destroying keys.
Security issues with Apex and other challenges:
- Structure Object Query Language (SOQL) Injections.
- Object/FLS issue by insecure sharing of custom classes.
- Field Permissions not set properly.
- Apex is used for developing Lightning components that communicate via Aura API may be exploited using vulnerabilities as it’s publicly open.
- Developers need to understand the concept of Salesforce Governor Limits. These are usage caps limits enforced by Salesforce when code is not optimised.
Example: Per Transaction Apex, Per Transaction Certified Managed Package, Lightning Platform Apex and Size-Specific Apex limits.
Bonus Section: You may hit a Bounty!
> Misconfiguration of publicly accessible Salesforce Communities: Communities or Experience are collaboration spaces designed specifically for Salesforce customers to connect with the community outside their organization.
Misconfigured community may expose sensitive information and this can be identified by simple Google dorks. <Search it yourself, I am not telling you all the secrets> :-P
Example: /s/contactsupport, /s/knowledgehub, /s/login
- Some other way you can get details are dorks like SF_USERNAME, SF_PASSWORD. (Hint)
Salesforce Security Checklist:
Subscribe to Salesforce Security Advisories:https://security.salesforce.com/security-advisories
Conclusion:
1. Pay attention and follow the security guidelines for Organization, Object, Field and Record Level Security.
2. Follow coding standards as advised by Salesforce Developer docs.
3. Use Static Code Scanners: Open Source Alternative
4. Create VDP to mitigate the exposure risk and encourage responsible disclosures.
5. Onboard logs to SIEM and have detections/Alerts.
6. Perform Salesforce Security Vulnerability Assessment and Penetration Testing.
7. Subscribe to Salesforce Security Advisories.
8. Refer to Salesforce security controls benchmark checklist by CSA.
Learning resource:
This may be overwhelming, take it slow and try to find your answers to Whys of controls and features.Feel free to reach out for any help, hope you learned something new.
~Ashishsecdev — Ashish Bansal
