Close Security Gaps

Learning Objectives

After completing this unit, you’ll be able to:

• Prioritize tech debt activities.
  
• Explain the principle of least privilege for Salesforce security.
  
• Standardize secure user access.
  

Face Technical Debt Head-On

For new and seasoned Salesforce admins alike, tech debt can seem daunting. Pile on faulty automation, excess permissions, incomplete customizations, and more—and things can feel very messy. It can be difficult to figure out where to start, so let’s break down the types of technical debt at AW Computing and how to prioritize fixing the issues.

Prioritize by Risk

“If we let this issue remain, will it be annoying, or will it eventually break the org or damage our business?” That’s a good question to ask. It helps you organize the issues in order of what should be tackled first.

As you dig deeper into the AW Computing environment, you find that when Salesforce was first deployed in-house, it was done without clear governance. Speed and growth were top priorities. But without clearly defined policies for Salesforce maintenance and development, some issues occurred.

• A “lite” case view was deployed for leadership and mistakenly for some segments of the services team. This brought confusion and a slew of requests to add additional fields so that everyone on the services team had access to the information they needed.
  
• Duplicate fields were released into production that capture the same or similar data. Some team members capture data in standard fields, some in custom, duplicate fields. There are even fields labeled “test” and “Noah’s notes”.
  
• Permissions were given to members of the executive team that opened up the environment to further deployment and security risks. As the organization grew, it became mighty tempting for those with privileged access to deploy “quick fix” fields and duplicates as mentioned above.
  
• Automations were built that have since gone unsupported and are causing system bloat. They all use older features like Process Builder, and you question why they were implemented in the first place.
  

To say the least, AW Computing’s Salesforce org is in dire need of cleanup. But instead of thinking about it in terms of messy versus clean, you start thinking about it in terms of risk.

Make It Make Sense

When you reframe tech debt in terms of risk level, you give yourself the ability to organize and prioritize. You can evaluate the challenges and break them down into workable chunks. And if you’re collaborating with a team or reporting to leadership, reframing it this way helps you guide the conversation and point out what’s important and why.

There’s no wrong way to organize the issues that arise from tech debt, and no org or business is the same. It might make sense to categorize priorities using a 1–5 score, with 1 being the lowest priority and 5 being the highest. And there’s no limit to the considerations that you can add. Level of effort, time, and capacity can also help give you a clear view of where to start and guide your plan of action.

Live by the Principle of Least Privilege

Based on your research and evaluation, the permissions issue is the one that you need to tackle first. It’s a big security risk, and it threatens to cause even more tech debt in the future. So you get to work closing the security gap.

It’s important to follow the principle of least privilege—give users the least amount of access to data and functionality that they need to get their job done. This is important to minimize security risks and protect against any accidental user errors.

For AW Computing, members of the leadership team were given excess permissions via a custom profile. Here’s what should have happened during the deployment instead.

• Give the services org minimum access via a standard profile.
  
• Use permission sets to give additional access by increment based on the user’s job.
  

Following this best practice, even if members of the leadership team had additional access via permission sets, it would have been easier to catch the issue early on as AW Computing’s Salesforce practice matured.

Standardize and Secure Access

First things first, you ensure all using a standard profile that limits access.

1. Select and select Setup.
   
2. In the Quick Find box, search for and select Users.
   
3. Select the name of the user whose profile you wish to change.
   
4. Select Edit.
   
5. From the Profile dropdown, select the correct profile.
   
6. Select Save.
   

Repeat this for all users on the leadership team…. But you don’t stop there.

Delete the Custom Profile

The custom profile has no use anymore (and it gives people excess permissions). And now that you’ve assigned all users the standard profile, it’s time to delete the old one.

1. From Setup, in the Quick Find box, search for and select Profiles.
   
2. Select Del next to the custom profile. (Note that you can’t delete a profile that’s in use, so be sure that no users are assigned the profile.)
   
3. Select OK in the modal to confirm you want to delete the offending profile.
   

You did it! You’ve boosted security for the AW Computing org by standardizing profiles and ensuring the team has the appropriate access to cases. Your next priority is dealing with the duplicate and excess case fields.

Resources

• Salesforce Admins: Tech Debt: What It Is and Why You Should Care