How to remediate – Salesforce.com Compliance Checks

1. Introduction

Salesforce.com Compliance Checks assesses whether your Salesforce instance meets defined security policies. This is important because non-compliance can lead to data breaches and regulatory fines. Systems usually affected are any organisation using the Salesforce platform, particularly those handling sensitive customer or financial information. Likely impact on confidentiality, integrity, and availability is medium due to potential for unauthorised access or modification of data.

2. Technical Explanation

This check uses supplied credentials to verify configuration settings against a given policy. Exploitation involves an attacker gaining access to Salesforce with valid credentials and then identifying misconfigurations that violate security standards. There are no known CVEs associated with this compliance check itself, as it is a verification process rather than a direct vulnerability. An example of exploitation would be an administrator failing to enforce multi-factor authentication, allowing account takeover.

• Root cause: Incorrect or missing configuration settings within the Salesforce platform.
• Exploit mechanism: An attacker with valid credentials identifies and exploits misconfigurations.
• Scope: All Salesforce instances using supplied credentials for policy verification.

3. Detection and Assessment

Confirming vulnerability involves checking current Salesforce configurations against a known good standard. A quick check is to review user permission sets.

• Quick checks: Use the Salesforce Setup menu to view User Permission Sets and Profiles. Look for overly permissive settings.
• Scanning: No common scanners directly address this compliance check, as it requires policy-specific configuration analysis.
• Logs and evidence: Review Salesforce setup audit logs for changes to permission sets, profiles, and security settings.

4. Solution / Remediation Steps

Fixing this issue requires reviewing and correcting Salesforce configurations against a defined security policy.

4.1 Preparation

• Dependencies: Access to Salesforce with System Administrator privileges is needed. Roll back plan: Restore from backup if issues occur.
• Change window: A standard change window may be appropriate, depending on the scope of changes. Approval from a security team lead is recommended for significant configuration updates.

4.2 Implementation

1. Step 1: Review each User Permission Set and Profile to ensure least privilege access.
2. Step 2: Enforce Multi-Factor Authentication (MFA) for all users, especially administrators.
3. Step 3: Configure Salesforce security settings according to your organisation’s policy (e.g., session timeouts, IP restrictions).
4. Step 4: Regularly review and update permission sets and profiles as user roles change.

4.3 Config or Code Example

Before

//Example: Profile with "Modify All Data" permission enabled

After

//Example: Profile with only necessary object permissions enabled, removing "Modify All Data"

4.4 Security Practices Relevant to This Vulnerability

List only practices that directly address this vulnerability type. Use neutral wording and examples instead of fixed advice.

• Practice 1: Least privilege access reduces the impact if an account is compromised.
• Practice 3: Multi-Factor Authentication adds a second layer of protection against unauthorised access.

4.5 Automation (Optional)

If suitable, provide a small script or infrastructure code that applies the fix at scale.

5. Verification / Validation

Confirming the fix involves re-running the compliance check and verifying all settings meet policy requirements. A smoke test is to log in as a standard user.

• Post-fix check: Re-run the Salesforce Compliance Check script; it should report no violations.
• Re-test: Review User Permission Sets and Profiles again to confirm changes are still valid.
• Smoke test: Log in as a standard user and verify access is limited to necessary data and functions.
• Monitoring: Monitor the Salesforce setup audit logs for unexpected changes to permission sets or security settings.

6. Preventive Measures and Monitoring

Suggest only measures that are relevant to the vulnerability type.

• Baselines: Update your Salesforce security baseline document with specific configuration requirements.
• Pipelines: Integrate a static analysis tool into your development pipeline to check for overly permissive permission sets during code deployment.

7. Risks, Side Effects, and Roll Back

List known risks or service impacts from the change.

• Risk or side effect 2: Incorrect configuration changes could lock out users; have a roll back plan in place.
• Roll back: Restore the Salesforce configuration from the pre-change backup.

8. References and Resources

Link only to sources that match this exact vulnerability.

• Vendor advisory or bulletin: [https://help.salesforce.com/s/articleView?id=sf.security_best_practices.htm&type=5](https://help.salesforce.com/s/articleView?id=sf.security_best_practices.htm&type=5)
• NVD or CVE entry: Not applicable – this is a compliance check, not a specific vulnerability.
• Product or platform documentation relevant to the fix: [https://help.salesforce.com/s/articleView?id=sf.security_settings.htm&type=5](https://help.salesforce.com/s/articleView?id=sf.security_settings.htm&type=5)