Security Specialist

Pre-work and Notes

• Grab a pen and paper. You may want to jot down notes as you read the requirements.

• Create a new Trailhead Playground for this superbadge. Using this org for any other reason might create problems when validating the challenge.

• Install the Trailhead Security superbadge managed package (package ID: 04t36000000jWht). If you have trouble installing a managed or unmanaged package or app from AppExchange, follow the steps in this article

• Although you can only create a single user in your Developer Edition org, you can create as many permissions (profiles, roles, public groups, and so on) as you need to complete this challenge. We recommend creating a user to test your various security configurations. Create a user named Samantha Cordero for this purpose.

Use Case

GenZ Capital is a startup that provides financial services for its Generation Z customers. They offer all services via social media. While their IT team is fantastic (their emoji-based support system is bleeding edge), they were less than ready to be acquired by the finserve behemoth OldGuard Finance. OldGuard has put GenZ’s systems through a thorough security audit and now changes need to be made.

As a premier Salesforce security consultant, you’ve met with the key stakeholders via social media direct message, and you have compiled a comprehensive set of security change requirements.

Standard Objects

GenZ uses the following standard objects to store all deal-related data:

• Account—Businesses that purchase financial service packages from GenZ Capital

• Contact—Prospective and existing customer contacts of GenZ Capital

• Opportunity—Deals related to GenZ Capital’s financial packages

Custom Objects

For the purpose of this superbadge, GenZ doesn’t use custom objects.

Business Requirements

This section represents the culmination of many meetings and will be the basis of your work to transform GenZ’s Salesforce org into a cloud-based version of Fort Knox.

System & Data Security Requirements

To comply with government financial regulations, GenZ must implement both data retention and encryption policies, and their acquiring company, OldGuard Finance, has strict access policies for remote workers and mobile devices. OldGuard Finance also wants GenZ to implement best practices for passwords.

You’ve explored these needs in detail with your stakeholders through a series of conversations, and you’ve come up with this short list of requirements.

• Data Retention—Data must be retained for a period of 180 days, and be reported on after the 180 days has passed. This can happen in a system outside of Salesforce.
• Security for Remote/Mobile Users—Remote workers must use VPN to access Salesforce. All mobile users must use two-factor authentication (2FA). All mobile users must be individually approved by the admin. NOTE: For ease of use, you’ve decided to manage 2FA from a single permission.
• Field-Level Security—Customer SSN and Bank Account fields on contact records must be encrypted. Any change in the Amount field on opportunity records must be recorded.
• Password Policy—Passwords must be reset every 90 days, and must have a minimum of 8 characters and include both alpha and numeric characters.

Organizational Security Requirements

You’ve investigated each role at GenZ and have come up with the following role-specific requirements:

Organizational Overview

There are three core teams in GenZ’s main sales organizational structure: Field Sales, Inside Sales, and Sales Executive. Gen Z also has individuals who have act as project managers to help implement the most complex deals.

General Record-Level Security Requirements

Configure default access to records in your org to:

• Restrict access to opportunities to the people who own them (and their managers).
• Allow access to accounts to anyone in the org, regardless of who owns them, as long as their profile allows access to Accounts in general. Note: keep default options for contacts.

Note: These general record-level security requirements can be overridden by the more specific requirements set below.

Field Sales User Requirements

Field Sales users should be able to create their own list views, but not create or manage list views for others. They should also be able to create reports and dashboards, but not create or manage report and dashboard folders. Field Sales users should have mobile access, granted by the admin on demand. They are not restricted in terms of their hours of access to Salesforce. They should also be able to read, create, and edit (but not delete) their own opportunities; and read and edit all accounts. Note: When providing access to see and edit all accounts for Field Sales, do not use the profile View All and Modify All settings.

Inside Sales User Requirements

Inside Sales users should only be able to access Salesforce from the main office (IP address 000.000.000.000), and should only be able to access Salesforce during working hours (between 8:00 AM and 6:00 PM PT, Monday-Friday). They should not have mobile access. They should be able to create reports, dashboards, and create and manage reports and dashboard folders. They should be able to create and manage list views for themselves and other people. Inside sales users can view, create, and edit all accounts and opportunities (but not delete them). Note: When providing access to see and edit all accounts and opportunities for Inside Sales, do not use the profile View All and Modify All settings.

Sales Executive User Requirements

Sales Executive users should be able to view all opportunities and accounts (regardless of other sharing settings), but not be able to create, edit, or delete any opportunities or accounts. They should be able to create reports and dashboards, but not create or manage report and dashboard folders. Sales Executive users should be able to create their own list views, but not create or manage list views for others. They should have mobile access, granted by the admin on demand, and are not restricted in terms of their hours of access to Salesforce.

Special Requirements for Users Who Are Also Project Managers

Project Manager (PM) permissions are set up differently than other user permissions because PMs all have other responsibilities within the company. For example, Carla Rodriguez’s primary job is as a Sr. Field Sales Associates, but she also works as a project manager. For this reason, you can’t use a profile to set record level permissions. You also should not use role for sharing records with project managers. PMs should be able to view all opportunities where Type = “Existing Customer - Upgrade” and Stage = “Closed Won”, but should not view any other opportunities owned by other users. Project Managers should have mobile access, granted by the admin on demand. Use the name Project Managers when naming any security property related to PMs.