3

How Not to Get Confused about Security

This chapter includes anti-patterns related to securing your Salesforce organization. It will start by reviewing a key anti-pattern around the shared security model that is integral to Salesforce. Then, we will look at anti-patterns that can occur when you mistake things that aren’t security for security.

We will continue to look at how not to make a mess of your sharing model and once again finish up with a review of the key points to take away.

In this chapter, we’re going to cover the following main topics:

• The Shared Belongs to Salesforce anti-pattern and how people get the shared responsibility model wrong
• How the Compliant Is Secure anti-pattern lulls you into a false sense of security and what you can do about it
• The Declarative Is Always Safe anti-pattern and why you can’t rely on declarative features to always be secure
• The Spaghetti Sharing Model anti-pattern – why it is deceptively easy to get into an overcomplicated sharing model on Salesforce and how you can prevent it from happening to your organization

After completing this chapter, you will have a good idea about how to avoid common security anti-patterns on Salesforce and what steps you can take to implement better security practices on the platform.

Getting confused about shared responsibility

Almost all SaaS and PaaS platforms use a security model called shared responsibility – that is to say, the vendor takes responsibility for certain parts of the security architecture and others remain the responsibility of the customer. In this section, we will see how misunderstanding this model can lead to issues in the Salesforce case.

Shared Belongs to Salesforce

The Shared Belongs to Salesforce anti-pattern holds that security on the Salesforce platform is always the predominant responsibility of Salesforce.

Example

SmallCo is a provider of specialty lenses for optical instruments. They sell globally and have recently adopted Salesforce Sales Cloud, order management, and B2B commerce to drive electronic commerce directly to business instead of selling exclusively via distributors.

When they did their implementation, the Salesforce platform went through a security review with James, the dedicated security professional that SmallCo has on staff. He evaluated the platform as a whole and was satisfied that the Salesforce platform, including how Salesforce secures its data centers, platform, and web application, met all the standards that SmallCo would expect.

James evaluates the shared responsibility model that Salesforce uses for security and determines that for the initial project, there shouldn’t be any need for additional security controls from SmallCo’s side. Salesforce will ensure security adequately without additional work being required by SmallCo.

After a period of successful running, SmallCo wants to extend the digital experience and online community adjacent to their web store, and also bring in a much larger number of customers to the web store itself. Mika, a Salesforce product owner at SmallCo, is given the task to run this extension project.

Because of a limited budget, Mika agrees with the implementation partner that they will extend a lot of functionality to anonymous users so that many tasks can be performed without a login. That way, SmallCo can opt for a relatively small login-based license Stock Keeping Unit (SKU).

The system goes live without issue and, as hoped, user numbers go up by more than a factor of 10. Mika and the team celebrate and, after completing the last outstanding minor improvements, start gearing up for the next project.

Just then, Mika receives a security advisory from a Salesforce consultancy that helped with SmallCo’s original Salesforce implementation. They point out that a number of new vulnerabilities have been found in Salesforce APIs used within digital experiences. These potentially allow serious exploits if there is a too-open model toward external users.

Mika is initially worried but remembers the conversation he had with James about Salesforce security prior to starting his new project. APIs sound like a core platform feature and, therefore, something Salesforce will take care of. The project is closed, and doing anything new would require finding a new budget, which is difficult. He, therefore, decides to ignore the warning.

Three weeks later, a data dump arrives at an internal SmallCo email address. It contains a data dump with all of SmallCo’s proprietary product information and lists of customers and orders. The data dump comes with a ransom demand to be paid in cryptocurrency to a specified address. Otherwise, the data will be made public.

The situation becomes frantic, and external consultants are brought in to help manage the situation. They quickly discover that some very permissive configurations have been made to help the process of making functionality available to external users. These are the likely source of the breach and were also the cause of the security advisory Mika received from the other partner.

SmallCo is very disappointed that Salesforce would leave such a glaring security hole open and raise it with their account manager, who instead points the finger back at the configuration SmallCo has made. SmallCo finally decides that the only thing to do is to pay the ransom and plug the gap.

The external consultants facilitate both of these actions and the external configuration is locked down. SmallCo has to change its license package, but at this point, it has become a small price to pay to avoid a recurrence of recent events.

On the suggestion of its external consultants, SmallCo sets up a process and some software to continuously monitor the security of its Salesforce environment. In addition, Salesforce-related personnel and James from security receive a number of educational sessions on the Salesforce security model. Mika breathes a sigh of relief and gets ready for the next project.

Problem

The Shared Belongs to Salesforce anti-pattern is fundamentally about whose job it is to maintain system and platform security. When you’re dealing with cloud systems, there is always a level of shared responsibility in play. That means the system or platform provider will maintain some parts of the security and you are responsible for others.

Figure 3.1 – A shared responsibility model

In Salesforce terms, Salesforce maintains infrastructure and platform security and helps you a lot with application layer security. However, when you configure or code something yourself, the responsibility for its security is ultimately on you. While I’m discussing it in the context of Salesforce, it is relevant to all SaaS and PaaS providers, although the specific boundaries defining the shared responsibility will differ.

It is, however, very easy to get confused about this boundary, and that leads to this anti-pattern. The problem that the Shared Belongs to Salesforce anti-pattern seeks to solve is the general security problem – that is to say, “How can we keep our system secure?” As we will see with the next system, it proposes to solve the problem by assuming that everything, or at least as much as possible, is the software provider’s problem, even when it isn’t.

Proposed solution

Shared Belongs to Salesforce proposes to solve the problem of system security by assuming that Salesforce as a world-leading software provider has already thought of all the issues and, therefore, will keep their platform secure. That way, you can safely ignore security as an aspect of your solution and move on with the real work of getting configurations done.

It effectively means that you don’t seriously engage with the shared responsibility model, although there are gradations of this. Most organizations, for example, will accept that they have a responsibility for the user permissions that they give the users, who access the system.

However, this might extend to how you configure your sharing model, who you give access to hit APIs or custom-coded classes, or who is allowed to run reports, which makes the situation much murkier. When it gets murky, the adopters of this anti-pattern make the easy choice that they don’t have to bother with the complexities because Salesforce will already have thought about it. That, unfortunately, is not and cannot always be true.

This anti-pattern is attractive for a number of reasons:

• You don’t have to engage seriously with complex security issues, which means you don’t need to hire or develop specialist skills
• It reduces your internal effort when doing work on Salesforce
• It gives you a story to communicate to stakeholders that you are in good hands and don’t have to worry about security
• It gives you someone to blame or hold responsible should things go wrong

While you can easily understand why people might be inclined to make their own lives easier by adopting this anti-pattern, the results are not generally optimal.

Results

Humans tend to seek to reduce cognitive load by making simplifications and taking shortcuts. Therefore, the Shared belongs to Salesforce anti-pattern is a naturally occurring phenomenon and it takes active security awareness to counter it.

It is, therefore, not surprising that the first and most serious result of this anti-pattern is a reinforcement of low-security awareness within an organization. If you aren’t aware of security issues, it is just a matter of time before something happens. This anti-pattern sets you up for something bad to happen.

Other typical negative results include the following:

• Giving everyone from end users to senior management a false sense of security about their Salesforce system, leading to even more serious fallout when an incident occurs and a lack of understanding that you actually have to do something, rather than Salesforce just fixing it for you.
• Not keeping up with the evolving security landscape on the Salesforce platform. This includes not just ignoring new security advisories as in our example, but also not looking into new security updates or features that would improve your security stance.
• Ultimately, the anti-pattern leads to an increased organization risk profile that would be intolerable to most senior managers, had they fully understood it.

It’s worth noting that you can run with this anti-pattern for years and years without discovering the negative consequences. It’s only when a security incident occurs and is discovered that has substantial enough consequences to get senior management’s attention that you really have to confront this anti-pattern.

It can, therefore, be a bit of a thankless task to point out that this anti-pattern is occurring, and you may not get anywhere initially. There are, nonetheless, things that should be done, as we’ll discuss in our next section.

Better solutions

The solutions to this anti-pattern are fairly obvious to anyone who has spent at least a bit of time with information security. First and foremost, this is about raising awareness about the security issues that are in play and getting the internal acceptance that something needs to be done about Salesforce security in an active way, rather than assuming that the vendor will take care of it.

Some of the main points include the following:

• Engaging actively with the shared responsibility model, getting a clear understanding of where the boundaries are, how to ensure your own parts are secure, and how to continuously remain vigilant about the parts that you aren’t directly responsible for but that still directly affect you.
• Investing in the required skills to perform your parts of the security task both initially and on an ongoing basis. You can build this internally or use consultants, but however you do it, the responsibility is on you to get it done.
• You need to assess new risks whenever you extend your solution in significant ways. This includes not just when you are adding new modules. Major extensions to existing functionality can also lead to new security threats being introduced.
• Fundamentally, you need to shift the mindset of your organization to one where security is seen as fundamental to organizational resilience and growth. That may be beyond what most of us as architects can accomplish. However, pushing where we can in our sphere of influence is also helpful.
• Continuously monitor your organization to evaluate Salesforce security recommendations and critical updates.

We have now completed the discussion of the first anti-pattern in this chapter and will move on to another take on the general security problem, Compliant Is Secure.

Mistaking other things for security

Security is a complex and multi-faceted domain. This complexity can be so profound in many cases that a strong temptation arises to simplify it to something more manageable. In this section, we will see two examples of how this can occur and what the negative consequences can be.

Compliant Is Secure

Compliant Is Secure holds that security for an organization can be upheld by strict adherence to one or more specified compliance regimes.

Example

Alexandra works as an architect for LifeCo, a major provider of medical devices for the continuous measurement of vital statistics. They sell devices across a number of global markets and as a consequence are subjected to a number of different regulatory regimes. It is fair to say that a big part of LifeCo’s culture is focused on meeting these regulatory requirements and maintaining compliance.

When it comes to IT security, LifeCo has also adopted a compliance-centric approach, combining ISO 27001, HIPAA, and GxP protocols in a comprehensive set of checks and controls that are documented thoroughly at the beginning of each project and audited subsequently on a yearly basis. While there are processes to maintain compliance throughout the year, LifeCo focuses most of its attention on the initial documentation and audit events.

LifeCo has adopted Salesforce for field sales and care programmes, using Sales, Service, and Health Cloud components. As part of the implementation, Alexandra worked closely with stakeholders across the business, including IT, security, legal, and the data protection office, to take Salesforce through its paces.

They performed a thorough evaluation of all the controls Salesforce has in place, both at the platform level and at the level of each individual cloud. They spent considerable time with Salesforce security representatives to understand the details of security implementation, pushing hard to get real answers to sensitive questions.

Additionally, they required comprehensive checklists and documentation from the implementation partner to ensure that all configuration work met the necessary standards. This added considerable overhead both during implementation and testing, but LifeCo was adamant that Salesforce had to meet the same standards that they apply to all internal systems.

The system documentation is finally signed off as compliant after a long period of adjustment to meet the detailed requirements. Alexandra keeps working in the Salesforce space, but mainly focuses on preparing requirements for new releases and updating technical standards unrelated to security.

Then, after 9 months, the unthinkable happens. The CEO receives a phone call from a popular news site that asks what his response is to the fact that thousands of the company’s patients’ personal information has been dumped online on a dark website. There is no doubt that the data comes from LifeCo, as it contains company proprietary information about device usage.

The CEO articulates a rushed response, but the damage is done. LifeCo suffers a major blow to its reputation and is battered in the mainstream media, social media, and the stock market. Alexandra takes a leading role in the investigation and cleanup after the incident.

The investigation is not entirely conclusive, but there is good circumstantial evidence pointing toward a disgruntled employee exporting a report file with the personal information and uploading it online. There isn’t enough evidence to bring any formal charges, however.

The root-cause analysis concludes that the incident occurred because a special procedure to give users reporting rights to patient data had been used to extend the privileges to a team of 50 people, many quite junior and relatively untrained in IT security or compliance. This had been done with the blessing of several senior managers to work around a number of management-reporting issues in the system. By exporting and manually processing the data in Excel, the team was able to compensate for certain functional shortcomings in the Salesforce implementation.

The problem is remediated, and an investigation is done to find other similar cases where a process might have been used to circumvent good practice. At audit time, Salesforce passes the audit with no serious reservations. However, in Alexandra’s mind, there still lingers a doubt that maybe they never really got to the bottom of the issue.

Problem

You might be tempted to think that the problem that Compliant Is Secure seeks to resolve is the same as for Shared Belongs to Salesforce – that is to say, what the anti-pattern seeks to resolve is the general security problem of how to keep data and systems secure. That is, however, subtly wrong.

While our last anti-pattern sought to solve security in general, Compliant Is Secure sidesteps the problem of actually being secure with the practices required to demonstrate to certain external parties that you are secure – that is to say, the documentation and checklists become the point rather than the actual security practices they are meant to encourage.

This is similar to Shared Belongs to Salesforce in so far as we reduce the complex, wicked problem of actually staying secure by replacing it with the much simpler problem of ticking all the right boxes. The strategy of reducing cognitive load by simplifying to a set of well-understood, repeatable processes, as we’ll see in the next section, is quite attractive to certain kinds of organizations.

Proposed solution

Compliant Is Secure proposes to substitute and thereby resolve the problem of keeping systems and data secure with the simpler problem of staying compliant with a set of clearly defined standards. That way, you can move forward in confidence that you have followed good practice and, therefore, are as secure as you are likely to get.

A good image to keep in mind for this anti-pattern is a checklist.

Let’s be very clear – compliance is a great thing! You should absolutely be compliant with the standards that define good practice in your industry and in general. This applies to information security, and it applies in general.

Compliance with standards can be an extremely good way to encourage good practice within your organization and embed it within its culture. What makes this scenario an anti-pattern is that compliance becomes the end goal, whereas that should, in fact, be the awareness and improvement in practice that the compliance exercise is meant to encourage.

Put another way, with information security, you should aim to use compliance as a tool to become more secure and more security-aware, not as a way to get security out of the way because you’ve ticked all the boxes. It is, however, not difficult to understand why it is attractive to organizations to focus principally on compliance:

• Compliance turns the fuzzy and wicked problem of information security into a manageable and governable one. Managers tend to like problems that are easy to understand and clearly measurable. Compliance is easy to understand; security is not.
• The processes needed to establish and maintain compliance tend to fit well with existing processes and skills, especially in companies that operate in regulated industries such as life sciences or the defense sector.
• When things go wrong, you have clear and unambiguous documentation that you have followed the rules. That helps both in terms of explaining incidents externally and protecting relevant stakeholders internally.
• You have to stay compliant anyway. For most large organizations, a certain level of compliance is mandatory and embedded in law or industry standards. Given that you have to be compliant, there is a clear temptation to make that the end goal.

The results you get from falling into this anti-pattern, however, are frequently problematic, as we’ll discuss in our next section.

Results

What you achieve with the Compliant Is Secure anti-pattern is, generally speaking, point-in-time compliance to a standard. You will be compliant at each audit point, and in between, people will follow the necessary processes that are required from them.

However, you have not instituted any deeper sense of the importance of security within the organization or given people the training and tools to engage meaningfully with it. That means that you will often find many workarounds, such as the one described in our example, where people do something that is technically compliant but completely circumvents the spirit of security that inspired the rules of the compliance standard.

You often see two patterns emerge in compliance-centric organizations:

• Drift and remediation: In this pattern, you have an ongoing drift away from the standards that have been implemented because people see compliance as a point-in-time exercise. This is corrected periodically to bring the organization back into compliance during an audit.
• Structured circumvention: In this pattern, you continuously follow the rules, but you have included within your compliance system certain ways of granting exceptions, which get exploited systematically to make the life of workers within the organization easier in one way or another. This is the pattern we saw in the preceding example.

Fundamentally, with the Compliant Is Secure anti-pattern, your organization is missing the “why” of security. They are doing certain things to check the boxes but do not engage with them beyond that exercise. That points toward the key interventions that will help with this pattern, which we’ll discuss next.

Better solutions

There is a famous book by business author Simon Sinek called Start with Why. In it, Sinek posits that the most successful organizations, Apple being the canonical example, do not start with what products they are selling, or how they make them, but with a fundamental purpose expressed in an answer to why the company exists in the first place.

While I won’t make any comments on the merits of this position relative to business in general, when it comes to information security, it is entirely correct. The reason why Compliant Is Secure is an anti-pattern is because it neglects the underlying “why” of information security.

The cure to this problem is, of course, to start from the answer to “why” – keeping information secure is not only essential to avoid threats but actually enables an organization to remain resilient and grow in a safe manner. Then, you can move on to the how and what of compliance regimes and specific controls.

That is a big mouthful for most Salesforce professionals to take on. Helpfully, there are smaller more practical things that we can also do to help:

• Continuously make other stakeholders aware that ticking boxes does not mean that the organization will remain secure
• Train people in Salesforce security and the threats that can occur despite the compliance regime
• Find champions to take on security awareness on an ongoing basis
• Advocate for ongoing monitoring of the Salesforce organization at the security level by these trained and motivated people
• Spread knowledge and awareness throughout the organization by regularly bringing up the topic at meetings and dedicated sessions

Of course, also remember that compliance is important, and you should do your part to stay compliant. Having now considered a very general security anti-pattern, we will once again focus on a specific Salesforce security anti-pattern, Declarative Is Always Safe.

Declarative Is Always Safe

Falling into the Declarative Is Always Safe anti-pattern implies having an over-optimistic attitude toward the security of declarative customization features.

Example

Rakesh is the technical lead for Salesforce at BigCo. BigCo is a long-term user of Salesforce with a big footprint across half a dozen different clouds. They expanded usage massively during the COVID-19 pandemic to facilitate a number of processes being carried out remotely.

Rakesh and his team worked with several smaller partners on the creation of these processes. Because of the time pressure involved, they built the processes using a combination of out-of-the-box features and flows, leaving out any complex requirements for a later time. The flow-based approach was recommended by the architects both from a speed-of-development and security perspective.

With the cooperation of the business, this approach proved adequate as a stopgap measure and BigCo managed the transition to remote work relatively seamlessly, partly due to this work. After the initial release, Rakesh and the team kept working on improving and elaborating the new flows, and some have evolved into complex, multi-faceted business applications with powerful features to support the business.

This includes the ability to make mass updates, creations, and deletions, the ability to call other systems via APIs, and even the ability to grant new security features to employees when they take on new roles or responsibilities in the business. There are also administrative flows that Super Users can use to manage the backend functions.

Functionally, this works well for the business, but on several occasions, mistakes by users lead to accidental record deletion. When a particularly unlucky Super User by accident deletes a large number of opportunities using an administrative flow, the CTO decides to have a partner review the flows, as he’s worried about any potential wider issues.

The partner does a review of the flows and comes back with a long list of unsafe practices used in the flows. In particular, the flows give system administrator-level access to a very large number of users that do not have the requisite training to use them. That presents not only an issue of accidental deletion, which has already happened, but also a real security issue. That includes threats both from malicious employees and from external threat agents, as some of the flows are theoretically triggerable via API updates.

The harm from the incident is easily remedied, as BigCo has an advanced backup solution in place, but the remediation of the flows takes much longer. For all future development, Rakesh works with the external partner to create a clear set of security guidelines to be followed when creating flows.

Problem

The problem that Declarative Is Always Safe seeks to solve is that of secure development or customization – that is to say, how do we keep our code and customizations from creating vulnerabilities that can be exploited to get at our data and systems?

It isn’t surprising that there is a tendency to consider low-code or no-code approaches as a cure for security headaches. Many classic and well-advertised vulnerabilities have been down to obscure coding errors, so avoiding code seems like a good idea if you want to be more secure.

Of course, low-code/no-code approaches are relatively recent phenomena, so whether this will hold well in practice is still up in the air to some extent. The reasoning is generally sound, however, as vendors such as Salesforce will spend much more time securing the low-code components they make available than you can spend on your own code.

However, as we will see when we cover the detail of the proposed solution next, this reasoning is not airtight.

Proposed solution

The proposed solution to the problem of secure development and configuration that Declarative Is Always Safe proposes is to circumvent the problem by only using declarative features – for example, custom objects, page layouts, flows, and even OmniStudio – which are assumed to be secure by default. That way, we do not have to spend much time thinking about security, and we can get our features done quicker.

This is clearly an attractive proposition to many different stakeholders:

• First, it is partially true. Low-code approaches are less likely, all things equal, than code-based ones to contain security gaps.
• Second, it simplifies development and configuration by putting clear bounds around what can be configured.
• Third, it provides the technical team with a good way to push back on business requirements that are too complex.
• Fourth, it speeds up the delivery of features by leveraging pre-built functionality that can be adapted to your particular business need.

A focus on declarative features, then, brings many benefits with it and is usually considered a good practice within the Salesforce community. However, what can make this focus – if taken too far – a security anti-pattern is the blindness to the very real threats that can be present, even in declarative solutions.

Results

The key negative result from the Declarative Is Always Safe anti-pattern, then, is blindness to security threats that may be present in your solution and a lack of awareness that such threats might even be there. This can lead to serious negative consequences, as in the previous example. The problem, however, is only getting worse day by day as Salesforce brings out new declarative features.

It is clear from the way features are being released on the Salesforce platform that Salesforce wants low-code tools such as Flow and OmniStudio to be the go-to solutioning toolkits for customization on the platform. However, the more powerful these tools become, the more likely you will be able to do something that will result in a security issue.

Let’s, for instance, consider some security problems that can happen with flows:

• General permissions such as Run Flows or the Flow User license can give a very large number of users permissions to run all flows in an organization, leading to issues such as those in our example
• If users have access to the AllFlows list view, they can then run any flow in the organization from the UI; this includes external users
• Flow execution contexts are complex to understand, and it is easy to end up running a flow in system mode by mistake, leading to a potential escalation of user rights
• Client-side validation in flows can accidentally leak information in some cases by including data in the response
• Component visibility can leak information, as the component is still included in the HTTP response
• Apex actions with wide-ranging effects may be called from flows without a clear understanding of the security implications

I recommend the article Understanding Salesforce Flows and Common Security Risks, available at https://appomni.com/resources/aolabs/understanding-salesforce-flows-and-common-security-risks/, as a good introduction to some common flow issues.

However, the wider point is that there are real security issues that happen with flows, OmniStudio, and even simpler declarative features. Therefore, we cannot rely on them to be safe by default, but we have to take due precautions, which we’ll discuss in our next section.

Better solutions

The first and most important piece of advice for avoiding this anti-pattern is to treat your declarative solutions every bit as seriously as you would your code-based ones. Tools such as flows or OmniStudio are increasingly as powerful as Apex and solve similarly complex business requirements.

That means you should follow a software development process for solutions based on these tools that are fit for purpose, just as you would for a code-based solution. Specifically, when it comes to security, you should keep the following things in mind:

• Standards and guidelines for declarative solutions should be in place as they would be if you were writing code
• Conduct risk and threat assessments at the start of the project for declarative solutions that deal with sensitive data or deploy a lot of power
• Train developers and configurators to understand the issues, and create a general awareness about what relying on declarative tools does and does not accomplish
• Keep an eye on the long-term trend toward declarative tools and update your guidelines as needed
• Monitor the external environment for issues or exploits related to declarative functionality on Salesforce

With that said, we will finish our discussion of security-related anti-patterns by taking a look at how you can really muck up your sharing model in Salesforce.

Sharing isn’t always caring

Salesforce has one of the most powerful and complicated sharing architectures known to man. This is both a blessing and a curse. In this section, however, we will focus on showing how it can go wrong and what to do to prevent it.

Spaghetti Sharing Model

A Spaghetti Sharing Model does to the security of a Salesforce organization what spaghetti code does to the maintainability of an application.

Example

GlobalCo is a conglomerate with numerous different business lines selling products across a number of B2B verticals. Most of GlobalCo’s organization is run within the business units, but IT has become a strong global function, as it has made it possible to collaborate effectively across business units using simple tools such as Slack for collaboration.

A few years back, GlobalCo adopted Salesforce Sales and Service clouds as their corporate CRM. Huan was the lead architect on that project and now sits in the global Salesforce Center of Excellence. While some subsidiaries still use other CRMs operationally, all basic data about customer transactions must make its way to Salesforce. To encourage standardization of processes and data, GlobalCo adopted a strong single organizational strategy for its Salesforce environment.

Unfortunately, while GlobalCo would like to be able to share as much data as possible globally, a number of regulations prevent it from going as far as it would like. There are a number of problems:

• Some countries require their data to be isolated from others, creating country data silos
• Competition law in a variety of jurisdictions also prevents some subsidiaries from sharing data with specific other subsidiaries to prevent collusion
• Salespeople in some jurisdictions are near-paranoid about who can see their opportunities, fearing someone else will steal them, leading to a number of extra protections being put in place
• Finally, executives in certain business units are used to keeping sensitive opportunities and customer support cases secret and only sharing among a select few, which has also been at least partially accommodated

After going live, there have been a lot of complaints that the structure GlobalCo put in place to meet these requirements was excessively rigid. There is a call for a number of exceptions from at least half a dozen countries.

Figure 3.2 – Sharing mechanisms

Huan leads the team to investigate the requirements. Initially, he thinks the problem is solvable by making minor adjustments to the organizational hierarchy and enterprise territory management. This, however, proves too simplistic, and he devises a number of additional public groups to make more refinements to the model.

Users, however, are still complaining, so Huan gets creative with the use of the account and opportunity teams. However, because the process needed would be too onerous to manage manually, the team ends up implementing a number of automations to automatically add team members to account and opportunity teams, based on certain criteria.

Even that, however, turns out to not be able to capture the full extent of the business requirements for when certain records should and shouldn’t be shared between specified business units and countries. Huan specifies an Apex-based sharing mechanism and gives it to a development team to implement.

The complete adjustment to the sharing model goes live, globally, over a weekend. Smoke testing is fine, but everyone is holding their breath as the testing of the model is difficult, and no one has been able to definitively say that all the important scenarios have been tested.

While there is no disaster, a steady trickle of access issues makes its way to the team over the week following the go-live. There are a lot of cases where either someone has access that shouldn’t have, or someone lacks access they should have.

What’s much worse, however, is that the team is finding it nearly impossible to pinpoint the errors. There are just so many moving parts that figuring out what is going wrong in specific cases becomes too complex. Every time the team thinks they have fixed one issue, it seems another two appear as a consequence.

After several frustrating weeks of trying to resolve the problem, the change management board takes a decision to roll back the changes to the sharing model and find a set of manual workarounds, until a more stable technical solution can be found.

Problem

In classical software applications, there is a well-known concept called spaghetti code. It happens when programmers work without design, practices, or the necessary experience to implement a system. Instead, they just do one thing at a time in a way that works for now with no consideration of the bigger picture.

Over time, this leads to code that resembles a portion of spaghetti on a plate. Everything is tangled up with everything else, changes to one part of the system impact other parts in seemingly random ways, and even the original writers of the code don’t really understand what is going on.

Happily, on Salesforce, we rarely see spaghetti code to this extent. It can occur, but in my experience, it is quite rare. What does occur frequently are Spaghetti Sharing Models – that is to say, sharing models that are so complicated that even their designers can’t reliably tell in a specific case why someone has or hasn’t got access to a given record.

The Spaghetti Sharing Model anti-pattern arises from an honest attempt to give a business what it wants in terms of record sharing. The problem is that for large global organizations, the level of complexity experienced in this area is so large that it is nearly impossible to get right.

In our example, we saw some of the reasons why:

• Privacy laws differ between countries and determine what can and cannot be shared
• Competition law can restrict visibility between subsidiaries
• Concerns about bonuses and commissions are extremely important to sales teams and can lead to serious concerns about data sharing
• Executives often want to keep certain data secret for a variety of business reasons, while sharing other data that is less sensitive of the same type

There are more scenarios than these, concerning, for instance, protection of sensitive health or financial data according to certain laws and standards, or internal political factors within an organization that may impact sharing requirements.

Overall, if you find yourself in an organization with this kind of requirements setup for data sharing, you are in danger of ending up in the Spaghetti Sharing Model anti-pattern, simply by trying to accommodate the requirements you are given.

Proposed solution

The Spaghetti Sharing Model anti-pattern suggests that you address sharing requirements in an incremental, iterative way, seeking as closely as possible to meet the business need.

This seems eminently sensible because of the following:

• It is exactly what we would do for most other types of requirements
• It fits with the dominant agile approaches to software development that are used by most Salesforce implementation teams
• You can nearly always achieve your goal in the short term
• It takes a long time before the complexity reaches a level to make the process go off the rails

Unfortunately, this process can break down in organizations of a certain size and complexity, resulting in the anti-pattern we are discussing, as we’ll see in the next section.

Results

The result of the Spaghetti Sharing Model is a situation where some or more of the following characteristics are present:

• Records are shared with some users without anyone fully understanding why
• Record access is missing from some users without anyone fully understanding why
• Pinpointing access issues is extremely difficult
• Making changes to the sharing model is either considered entirely off limits due to complexity
• Changes to sharing often lead to new issues that are difficult to understand and fix

It is worth reflecting on why sharing is more prone to spaghetti than other configuration areas. The answer lies mostly in the vast number of mechanisms that are available to control sharing on Salesforce and their interactions. Depending on how you count, there are more than 20 different ways to extend the sharing of objects and records in Salesforce.

The following table shows a sample of mechanisms that can be used to control sharing:

Mechanism	What it’s used for
Ownership	Access to a record owner, user, or queue
Profile	Access to an object or not at the basic level
Permission Set	Access to an object or not at the basic level
Org-Wide Default (Internal)	Default internal sharing level
Org-Wide Default (External)	Default external sharing level
Role Hierarchy	Access to subordinates’ records
Grant Access Using Hierarchies	Sharing with a role hierarchy or not
Public Groups	Sharing to a defined group of users
Ownership-Based Sharing Rule	Sharing based on a configured rule, based on record ownership
Criteria-Based Sharing Rule	Sharing based on a configured rule, based on record field values
Guest User Sharing Rule	Special sharing to the guest user
Account Teams	Sharing based on membership in an account team
Opportunity Teams	Sharing based on membership in an opportunity team
Case Teams	Sharing based on membership in a case team
Manual Sharing	Sharing records manually
Implicit Sharing	Automated sharing between parents and children for certain standard objects
Territory Hierarchy	Sharing based on configured territories and territory membership
External Account Hierarchy	Grant access based on account hierarchy
Sharing Group	Sharing records owned by portal users
Sharing Set	Sharing records to portal users based on matches between Account or Contact fields
Manager Groups	Sharing records with our management chain
Apex Sharing	Sharing programmatically

Table 3.1

Ultimately, this vast number of mechanisms, if used injudiciously, can lead to the Spaghetti Sharing model, simply because their interaction becomes difficult for a human brain to understand.

Better solutions

As we have seen, the Spaghetti Sharing Model can occur just by people doing their job and incrementally seeking to create value for the business by meeting their requirements. That means this anti-pattern can occur without anyone doing anything wrong or making a specifically wrong decision. Someone needs to step outside of their day-to-day remit in order to spot this issue prior to it occurring.

At the risk of provoking severe retaliation from agile fundamentalists, I will suggest that if you find yourself in an organization (where there are highly complex sharing requirements), you need to stop, take a step back, and put in place an upfront design for the sharing architecture along with governance mechanisms to enforce it over time. For instance, you might introduce a principle that it is best to be parsimonious in using sharing mechanisms, and make the adoption of new types of sharing subject to approval by an architecture review board or design authority.

This concludes our presentation of security anti-patterns. We will now look at the key things to take away from the discussion.

Knowing the takeaways

In this section, we will abstract a bit from the specific patterns and instead try to pull out the wider learning points you can use in your day-to-day work as a Salesforce architect or in preparing for the CTA Review Board.

When architecting Salesforce solutions, you should be mindful of the following:

• Security is not just a technical issue; the way you frame problems and create awareness is even more important.
• It is easy to ignore complex security issues in various ways. While you may not be able to singlehandedly change this as an architect, you can be a part of raising awareness.
• Instituting sharing sessions and sending out relevant material is one good way you can help make things better.
• You can also ensure that security guidelines and practices on a technical level reflect the full threat picture.
• Do not assume that something is Salesforce’s responsibility without good evidence.
• Do not assume that because you are using a declarative feature, you cannot have a security gap.
• Find ways of monitoring the security stance of your Salesforce organizations on a regular basis and act on the intelligence.
• Make security matters a recurring discussion in governance forums where you can influence the agenda.
• Don’t build sharing models incrementally unless your requirements are very simple.
• Instead, take the pain upfront and come up with a set of mechanisms that can work in your scenario.

In preparing for the CTA Review Board, you should be mindful of the following:

• Security is embedded in a lot of areas, so even though it is a distinct domain, you should still cover security matters concisely when relevant in your solution run-through.
• Security is a complex area, so be as clear and concise as possible. It is very easy to get drawn into long discussions on security matters and you don’t have the time for that at a review board.
• Consider including some comments on security when reviewing your governance model and potential risks.
• Be parsimonious when picking security mechanisms. Fewer mechanisms are easier to explain and less likely to have interactions that lead to unforeseen consequences.
• Of course, don’t oversimplify or make assumptions that would point in the direction of not appreciating how things can go wrong in the security domain.
• Sharing is particularly easy to get wrong, so be quite careful about designing exotic sharing solutions.
• Don’t invent additional security requirements that aren’t stated in the scenario. You can easily think yourself into additional implied requirements when reading many scenarios.
• The one exception to this rule is dealing with privacy laws, such as General Data Protection Regulation (GDPR), if you have an organization in a jurisdiction where it applies.

We have now covered the material for this chapter and are ready to proceed. First, however, we will summarize what we have learned.

Summary

In this chapter, we have seen how there are many ways to compromise your security by following seemingly innocuous courses of action or failing to realize subtle distinctions in responsibilities and approaches.

These included both general security anti-patterns that affect many different platforms, such as Shared Belongs to Salesforce and Compliant Is Secure, and unique Salesforce anti-patterns such as Declarative Is Always Safe and Spaghetti Sharing Model. That underscores the particular complexity of the security domain.

When it comes to security, you have to attend both to high-level issues of organizational culture and awareness of issues, and to the minutiae of how mechanisms are designed specifically for the technology you are using. That is what makes it both frustrating and highly interesting at the same time.

Having covered the security domain, we will move on to have a look at data next.