Untangling Salesforce Orgs: A Deep Dive into Multi-Org Security Risks

How to navigate multi-org security pitfalls

Salesforce, while a pioneering SaaS platform, operates with a complexity that straddles the line between SaaS and PaaS. This unique architecture, centered around multiple "Orgs" (akin to instances or tenants), introduces specific security challenges compared to simpler, account-based SaaS models. This post will explore the security risks inherent in Salesforce's Multi-Org model and discuss strategies to mitigate them, ensuring robust protection across production, sandbox, and development environments.

The Salesforce Multi-Org Model: Orgs, Sandboxes, and Usernames

The Salesforce platform revolves around "Orgs," which function similarly to instances or tenants in other cloud environments. Every Salesforce customer typically has at least one Production Org, along with a collection of Sandbox Orgs (which are various levels of snapshots of the Production Org) and Development Orgs (used for testing, prototyping, or learning).

Salesforce usernames resemble email addresses, but they are distinct entities. Each user account has a unique username and a separate email address. Usernames must be globally unique across all Salesforce Orgs, not just within a single customer's deployment. This means no two users, across any Salesforce instance, can have the same username. When creating a Sandbox, the Production username is often appended with the Sandbox name (e.g. john.jones@example.com.uat). Furthermore, to separate environments, production Orgs use `login.salesforce.com` for authentication while sandbox Orgs use `test.salesforce.com`.

Essentially, each Org maintains a set of unique usernames. To avoid managing numerous email accounts, users commonly associate all their Salesforce accounts (across Production, Sandbox, and Development) with a single email address.

For typical Salesforce users, the username and email address might be the same. However, administrators, developers, and other Salesforce specialists often manage dozens of usernames across various Orgs, all linked to the same email address. This can lead to confusion and potential security challenges when managing identities and access across multiple environments.

A typical staged CI/CD (Continuous Integration/Continuous Deployment) pipeline within a Salesforce Multi-Org environment.

Developers make code changes in individual Development Orgs. These changes are then integrated and tested collaboratively in shared Sandbox Orgs at the team or project level. Before deploying to the Production Org, all changes undergo comprehensive testing in a dedicated User Acceptance Testing (UAT) Sandbox. This visual represents the flow of changes and the various Salesforce Org environments involved in the software development lifecycle.

Security Pitfalls of Salesforce Multi-Org Deployments

The Salesforce Multi-Org model, while powerful, introduces a unique set of security challenges. Understanding and addressing these risks is crucial for protecting your data and systems. Here are key security pitfalls to be aware of:

1. Accidental Changes and Human Error: With numerous Orgs, it's easy to mistakenly perform actions in the wrong environment, such as deploying changes to Production instead of a Sandbox. This increases the risk of unintended consequences and data corruption.
   
2. Sandbox Vulnerability: Sandboxes often contain sensitive production data copies. If not adequately secured, they become attractive targets. A Sandbox breach can be almost as damaging as a Production breach. As Sandboxes may not be managed and protected as stringently as the Production (monitoring, updating, access controls), a compromise of Sandboxes can be almost as bad as the compromise of Production from a confidentiality point of view. As most “normal” users don’t log into Sandboxes and also their accounts get invalidated over time, the risk of end-user compromise may not be high. But the Dev and Admin users are likely to perform riskier activities in a Sandbox than in Production – because that’s why Sandboxes were invented.
   
3. Compromised Accounts via "Login with Salesforce": Many third-party services use "Login with Salesforce." If a Dev or Sandbox Org account sharing the same email as a Production account is compromised, attackers can potentially gain access to those services, bypassing standard security measures.
   
4. Neglected and Forgotten Orgs: Over time, Dev Orgs and Sandboxes may become inactive and neglected. These "forgotten" Orgs often lack proper monitoring and maintenance, making them easy targets for exploitation.
   
5. Configuration Drift: Security and other settings can diverge across different Orgs over time. This inconsistency creates vulnerabilities and makes overall security management more complex.
   
6. Cross-Org Data Exposure: If connectors or data virtualization links exist between Orgs, a breach in one Org can lead to unauthorized access or modification of data in another. The interconnected nature of Orgs can amplify the impact of a security incident.
   
7. Increased Attack Surface: Each additional Org adds another potential entry point for attackers. Weak security in any Org can be exploited as a stepping stone to target other Orgs, though direct lateral movement within Salesforce's infrastructure doesn’t seem very common.
   
8. Phishing and Social Engineering Risks: Users with access to non-production Orgs can be targeted in phishing attacks. Attackers might use typosquatting or lookalike "My Domains" to trick users. Emails from any Salesforce Org are likely to bypass spam filters, increasing the effectiveness of these attacks.
   
9. Password Reuse Vulnerabilities: If users reuse passwords across multiple Orgs, a compromise in a Dev or Sandbox Org can have serious implications for Production. Should be noted that passwords are reused by default when creating or refreshing a sandbox. Password leaks can occur e.g. via phishing, or when integration credentials are inadvertently committed to public repositories like GitHub.
   
10. Trailhead "Hands-on Orgs" Risks: If a user's Trailhead account is compromised, an attacker may gain access to all connected Salesforce Orgs, potentially enabling lateral movement and further compromise.
    
11. Environment Hub Risks: Environment hub is used to spin up development Orgs, but you can also map users between the Orgs and set up SSO mapping. This can potentially lead to lateral movement opportunities for the attackers.

By understanding these risks, organizations can develop effective mitigation strategies to protect their Salesforce Multi-Org environments.

Strategies for Securing Your Salesforce Multi-Org Environment

Protecting a Salesforce Multi-Org deployment requires a proactive, layered approach. Here are key strategies to mitigate the inherent security risks:

• Establish Unified Security Policies: Implement and rigorously enforce consistent security policies across all Orgs (Production, Sandboxes, Development). This includes password policies, access controls, and data handling procedures.
  
• Fortify Sandbox Security:
  • Anonymize or mask sensitive data in Sandboxes.
  • Establish a regular Sandbox refresh schedule, but be mindful of data exposure during these refreshes.
  • Implement strict, role-based access controls.
  • Deactivate unnecessary user accounts in Sandboxes and Dev Orgs.
  • Use unique passwords in Sandboxes and Dev Orgs. Do not use the same password in two different Orgs in general.
  • Decommission unused or outdated Sandboxes and Dev Orgs promptly.
    
• Enforce Strong Access Management:
  • Adhere to the principle of least privilege for all users across all Orgs. This includes basing permissions on purpose-built permissions set versus profiles as well as using sharing features to prevent access to records the user doesn’t have a business need to access.
  • Mandate Multi-Factor Authentication (MFA) for all user accounts. Including Sandbox and Development Org accounts.
  • Implement centralized user management solutions for streamlined provisioning and deprovisioning.
    
• Automate Security and Monitoring:
  • Utilize automation tools and scripts to deploy and maintain security configurations consistently.
  • Implement continuous monitoring for suspicious activities and configuration drifts.
    
• Maintain System Integrity:
  • Ensure timely application of security patches and updates to all Salesforce Orgs.
  • Conduct regular security audits and vulnerability assessments.
    
• Educate and Empower Users:
  • Provide comprehensive security training to all users, emphasizing the interconnectedness of Org security.
  • Reinforce the importance of strong passwords and MFA, even in non-production environments.
  • Educate users on recognizing and reporting phishing attempts, including those targeting Salesforce Orgs.

By implementing these strategies, organizations can significantly reduce the risks associated with Salesforce Multi-Org deployments.

How can Valo help?

Valo stands out in the Salesforce ecosystem as a comprehensive, truly multi-org security solution. Unlike many tools that focus solely on Production Orgs, Valo provides unified monitoring and management across your entire Salesforce landscape — Production, Sandboxes, and Development Orgs alike.

With Valo, you gain:

• Holistic Visibility: A single view to monitor all your Salesforce environments, ensuring no Org is left vulnerable.
• AI-Powered Insights: Intelligent detection of anomalous behaviors and potential security risks specific to multi-org deployments.
• Proactive Threat Detection: Real-time alerts on security issues, allowing you to address them before they escalate.
• Simplified Management: Streamlined security management across all Orgs, reducing complexity and saving valuable time.

Valo empowers you to secure your entire Salesforce ecosystem, not just isolated parts of it.

About Mika

Mika Ståhlberg is the CTO and Co-founder of Valo, bringing 25 years of experience in cybersecurity and R&D to the role. Previously, Mika led security initiatives at Ouraring and served as CTO at F-Secure. He is a Salesforce Certified Integration Architect with extensive experience in leadership and hands-on technology work. Mika is passionate about building usable products that effectively solve customer problems.

Outside of work, Mika enjoys snowboarding, music, and exploring history.

• 

  Mika Stahlberg