Application security, DevOps, DevSecOps, Identity, Sales and marketing

Salesforce security in a shared-responsibility world: Catching misconfigurations and drift before they become breaches

(Adobe Stock)

In a recent SC Media webcast, host Adrian Sanabria spoke with Justin Hazard, Principal Security Architect at AutoRABIT, about how to manage and secure Salesforce instances and make sure that minor misconfigurations and misunderstandings don't develop into major breaches.

Sanabria and Hazard gave an overview of Salesforce's evolution from a customer-relationship-management system to a comprehensive cloud platform. Hazard pointed out that Salesforce is now used for a variety of sensitive business functions beyond sales, including handling patient data and credit-card information.

"It was one of the very first SaaS platforms that we saw come out of the early 2000s," observed Sanabria. "And it's really evolved into a much bigger beast than it was in the in the early days."

That led to a discussion of the security risks that can arise as organizations expand their Salesforce implementations far beyond Salesforce's core uses, leading to greater complexity and broader attack surfaces.

A major topic of discussion was how to manage security as Salesforce environments grow. Hazard and Sanabria both noted that in many organizations, what began as a well-defined CRM has grown to become a central repository for sensitive data, leading to situations in which incremental features and customizations may accumulate risk.

Seemingly minor mistakes, like over-permissioned accounts or unclear visibility into which users have access to sensitive data, can result in critical vulnerabilities. Administrators or security teams may not be aware of these flaws until a data breach or a regulatory audit brings the vulnerabilities to light.

The security experts also discussed parallels with past security issues in on-premises environments and public cloud platforms, emphasizing that similar mistakes in permissioning, privilege creep, and third-party-vendor management have reemerged in the Salesforce ecosystem.

"We run into very similar situations that we ran into in the 2010s with Active Directory and things of that nature," said Hazard. "I work with a lot of developers that know Salesforce inside and out. They want to be security-conscious, and they want to do the right things as it relates to security. But they don't really understand some of the nuances that come into play when it's security-related. It's not what they've lived in and grown up in."

Several recent breaches were examined, highlighting the risks from subcontractor accounts with excessive access, the lack of effective multi-factor authentication (MFA), and the critical importance of visibility and rigorous auditing processes within complex enterprise environments.

Hazard and Sanabria also went over the additional risks that might be introduced by third-party applications as well as internal developers. Salesforce's extensive marketplace and ecosystem, with thousands of applications, can introduce further complexity and risk, while internal customizations and integrations may create unseen dependencies.

Attackers increasingly target users and admins with high privileges, exploiting the ability to install OAuth-connected apps and other attack vectors, making security hygiene and process discipline even more vital.

Protecting non-production environments such as sandboxes and development areas is a significant challenge, Hazard said. Attackers will target weakly secured dev and QA environments, especially if production data is copied there without adequate masking or access controls.

Inadequate processes around environment migration, defunct environments left online, and a lack of meaningful follow-ups after security exceptions or risk acceptances can quickly undo even the best security posture established in production, he added.

Generative AI and agentic AI tools are emerging risk factors, Hazard said. The "chatty" nature of AI agents may inadvertently expose sensitive data if not tightly restricted, and he urged robust policy enforcement, comprehensive logging, and sticking to the principle of least privilege.

Finally, Hazard and Sanabria discussed AutoRABIT's tools for Salesforce backup, CI/CD, code scanning, and permission visualization, underlining the importance of a layered defense, continuous process improvement, and inter-team collaboration to secure complex cloud environments like Salesforce.

Practical advice for security leaders:

  • Establish a formal, regular review-and-audit process for Salesforce permissions, profiles, and third-party integrations, ensuring that overprivileged accounts and unused application connections are quickly identified and remediated.
  • Create and enforce clear policies and processes for managing security exceptions and temporary changes in Salesforce, with robust documentation, defined timelines for reversion, and explicit follow-up responsibilities.
  • Secure non-production environments (dev, QA, sandboxes) in Salesforce development to the same standard as production environments, and use best practices including data masking, access controls, and prompt decommissioning of unused environments to prevent non-production environments from becoming attack vectors.
Paul Wagenseil

Paul Wagenseil is a custom content strategist for CyberRisk Alliance, leading creation of content developed from CRA research and aligned to the most critical topics of interest for the cybersecurity community. He previously held editor roles focused on the security market at Tom’s Guide, Laptop Magazine, TechNewsDaily.com and SecurityNewsDaily.com.

You can skip this ad in 5 seconds