How to be a Security Minded Admin by Chris Zullo

1. Boston World Tour 2016 How to be a Security-Minded Admin Chris Zullo Manager, Acumen Solutions | Salesforce MVP czullo@acumensolutions.com @chriszullo

2. Salesforce Org Security

3. Login IP Ranges • Limit IP addresses that users can log into Salesforce from (by profile) • Can restrict by login or on every request • Lock sessions to IP address they started on • These features ensure that if a malicious actor steals credentials they cannot use them away from your corporate networks • Working from home/road – VPN login

4. What is Two-Factor Authentication? +

5. Organizational Wide Default - OWD Determine what access and permissions users have to records they don’t own Cannot grant more access to users than they have through their object permissions For most objects, organization-wide settings can be set to: • Public Read/Write/Transfer • Public Read/Write • Public Read Only • Private Setup > Security Controls > Sharing Settings

6. Profiles • Set whether fields are visible, required, editable, or read only • Controls Tab visibility • Controls App availability • Controls Object Permissions • (Create, Read, Edit, Delete) • Setup > Manage Users > Profile What a User Can Do

7. Roles • Hierarchy Examples: • Company Size • Product-based • Territory Setup > Manage Users > Roles What a User See

8. Field Level Access Setup > Security Controls > Field Accessibility View accessibility by: 1. Object 2. Fields 3. Profiles Field Access Options: 1. Editable 2. Read-only 3. Hidden

9. Controlling Access to Records

10. Key Principles – The Human Factor • Limit the number of users with admin rights • Provide users with minimum access to do their job • Create rigorous process for user termination/deactivation • Basic security training for all users on credential/password security, phishing, and social engineering • Trailhead for ongoing, role-focused education • Effective security requires cross-org communication https://developer.salesforce.com/trailhead

11. Next Steps

12. Key Takeaways Check your Security Settings! Activate and use turnkey security features: • Enable two-factor authentication • Activate Login IP Ranges • Deactivate users in a timely manner (freeze them first!) Consider the human factor when training Salesforce users: • Password security • Emails / phishing

13. Resources & Tips • Trailhead: Data Security module • Who Sees What video series (YouTube) • Create a Salesforce Force Field for Your Users • Security Implementation Guide • ButtonClickAdmin.com • Freeze vs. Delete: You can't delete a user, but you can deactivate an account so a user can no longer log in • TIP: When object- versus record-level permissions conflict, the most restrictive settings win • TIP: Use Delegated Access to login as another user to help troubleshoot.

14. thank y u

15. Chris Zullo Triad (NC) Developer Group Leader, MVP Chris Zullo Manager, Acumen Solutions czullo@acumensolutions.com @chriszullo

16. Appendix Additional Resources

17. Organization Access By default, your active users can log in to your org from any location at any hour For increased security you can setup: • IP Ranges (Company/Org Level) Users logging in outside the range are sent an activation code to the email address on their user record Setup > Security Controls > Network Access • Login Hours Specify hours users can log into your org Setup > Manage Users > Profiles > Select Profile > Login Hours • Freeze User Accounts Setup > Manage Users > User | Select user > Click Freeze

18. Permission Sets Extending your existing Profiles • Manage Permission Sets Setup > Manage Users > Permission Sets • Assign Permission Sets Permission Sets > Manage Assignments > Add Assignments > Select User(s) > Assign

19. Sharing Rules Allows users to see/edit data they don’t own in an otherwise private setup Sharing Rules are set via your System Administrator Setup > Security Controls > Sharing Settings Manual Sharing allows record owners to give Read and Edit Permissions to Users or Users in a Public Group

20. Login IP Ranges • Recommended and available for all customers • Only access Salesforce from a designated set of IP Ranges • Two levels: • Org-level Trusted IP Ranges (permissive) • Profile-level Login IP Ranges (restrictive) Enterprise, Unlimited, Performance, Developer: Manage Users | Profiles Contact Mgr, Group, Professional: Security Controls | Session Settings For more info, search Help & Training

21. Password Security • Activate password complexity and rotation rules  Password expiration/reset every 90 days  Password length at least 8-10 characters  Password complexity – mix alpha and numeric characters • User education  No password/credential sharing  Discourage password reuse across services  Utilization of a strong password manager (example: LastPass) • Utilize two-factor authentication (2FA) and single sign-on (SSO)

22. Phishing Education • Pervasive and effective attack vector for installing malware • Education is key to prevention • https://trust.salesforce.com - recent threats • If unsure about a Salesforce email, ask us via security@salesforce.com • Don’t open attachments that are unexpected or from unknown senders

23. User Deactivation • Deactivate users as soon as possible • Removes login access while preserving historical activity and records • Sometimes users cannot be deactivated: assign new user or reassign approval responsibility first • Know your IT department’s termination process Best practice: Freeze users first! From Setup, click Manage Users | Users. Click Edit next to a user’s name. Deselect the Active checkbox and then click Save.

24. Two-Factor Authentication (2FA) • Provides an extra layer of security beyond a password • If a user’s credentials are compromised, much harder to exploit • Require a numeric token on login • Can be received via app, SMS, email, hardware (YubiKey)

25. Step-by-Step Guidance for Admins • Try the 2FA Walkthrough created by the Salesforce Docs team • Title: “Walk Through It: Secure Logins with a Two Factor Authentication” • Shows you how to set up 2FA in an org • Only in “Classic”, but if configured, applies to users assigned the permission in Classic or Lightning Experience • 2FA Walkthrough Link

26. 2FA Setup Create a permission set titled “Two Factor Authentication” Name | Setup | Manage Users | Permission Sets | New Step 1

27. 2FA Setup Select the “Two-Factor Authentication for User Interface Logins” permission and save this permission set. Now assign this permission set to the required user by clicking: Manage Assignment | Add Assignments | Select users | Assign Step 2

28. 2FA Setup Upon the next login, users will come across the following prompt: Step 3

Editor's Notes

There are several layers of access and control that determine “who sees what” and who “can do what” in a Salesforce org. Those of you at larger companies with multiple Salesforce orgs need to separately configure these controls in each org. First, lets talk about Org Wide Default, or OWD: OWD determines the access and permissions users have to records they don’t own. The admin can’t grant more access to users than they have through their object permissions. [LEADER: OWD is configured at setup>security controls>sharing settings] Profiles are set up based on what you want a user to be able to DO. By using profiles, you can set whether fields are visible, required, editable or read only. Profiles also control tab visibility, app visibility and standard object permissions, also knows as CRED (create, read, edit, delete). [LEADER: Profiles are configured at setup>manage users> profile] Roles govern what a user can SEE. Role hierarchy is used to control how your org reports on and accesses data. Examples are hierarchy based on company size, product or territory. [LEADER: Roles are configured at setup>manage users>roles]. Field level security allows you to restrict access to specific fields on a profile by profile basis. The fields that users see on detail and edit pages are a combination of page layouts and field-level security settings. The most restrictive field access settings of the two always apply. For example, if a field is required in the page layout and read-only in the field-level security settings, the field-level security overrides the page layout and the field will be read-only for the user.
One of the key features that Salesforce highly recommends all customers enable are Login IP Ranges. First, the basics: An IP address (Internet Protocol address) refers to a numerical identifier for each device on a network that communicates with other devices over the Internet. The IP address serves both as an “address” that shows the location of particular device, and also as an identifier of the device when it interfaces with the host network. So think of an IP like the address of your house. Login IP range restrictions limit unauthorized access to Salesforce by requiring users to login to Salesforce from designated IP addresses—typically your corporate network or VPN. By using Login IP Ranges, admins can define a range of permitted IP addresses to control access. Those who try to login to Salesforce from outside the designated IP addresses will not be granted access. What this feature does is ensure that if a malicious actor steals login credentials via a phishing or other attack, that they cannot use them away from your corporate network.
One of the most important things you can do to enhance the security of your Salesforce org is to implement two factor authentication (2FA). 2FA requires a second level of authentication for every user login. You can also require 2FA when a user meets certain criteria, like attempting to view reports or access a connected app. Two factor authentication is often described as “something you know plus something you have”. Typically this entails requiring users to enter a time-based token as a second form of authentication, once the user enters their password. This second form of authentication may be a token generated via an app on the user’s phone, through SMS, email or a hardware-based token that the user inserts into their computer. 2FA provides an extra layer of security that goes beyond the user’s credentials. So even if those credentials are compromised, the account may still be protected. Salesforce makes it easy to set up 2FA for your Salesforce orgs through Salesforce Authenticator, which you can configure right from Setup. You can also use similar solutions from other security vendors to secure your orgs.
Organization-wide defaults—specify the default level of access users have to each others’ records. OWD can further restrict permissions on records a user does not own. Determine what access and permissions users have to records they don’t own OWD cannot grant more access to users than they have through their object permissions Public Read/Write/Transfer – allows non-owners to read/edit/and change ownership. This public ability to transfer ownership only applies to Leads and Cases. For all other objects, only the owner or someone above them in the role hierarchy can transfer ownership. Public Read/Write – users can view and edit records they don’t own, but they can’t transfer ownership. Public Read Only – users can view records they don’t own, but they can’t edit those records or transfer ownership Private – this is the most restrictive setting. Users cannot see records they do not own.
Custom App Settings, administrators can make visible or default a selected App. This is an example of what apps are available from the App Selector, on the UI. The power of Profiles…there are several administrative functions related to the User that can be managed via the PROFILE, for example: Profiles give access to the OBJECT and Roles give access to the Records, a profile controls what a user can do in the system. Users assigned to a Profile have the permissions (CRED) and page layouts listed below. Administrators can change a user's profile by editing that user's personal information.If your organization uses Record Types, use the Edit links in the Record Type Settings section below to make one or more record types available to users with this profile. If enhanced profile list views are enabled for your organization, you can change permissions for multiple profiles from the list view. Enhanced Profile List Views Enables enhanced list views and inline editing on the profiles list page. With inline editing in enhanced profile list views, you can manage multiple profiles at once.
It is mandatory to have a PROFILE but not a ROLE User ROLES Do not need to match your organizations HR Role They are not meant to be organizational hierarchy, they can be This layer determines which records users have access to. The Role Hierarchy extends access to records when you have set the default sharing settings to anything more restrictive than Public Read/Write. Role hierarchies—allow you to ensure a manager will always have access to the same records as his or her subordinates. Each role in the hierarchy represents a level of data access that a user or group of users needs. You can use the Role Hierarchy to open access back up, giving users visibility to the records of users below them in the hierarchy The role hierarchy will only open up access; it cannot restrict record access to less than what is granted through the org-wide defaults
Use page layouts to set whether fields are visible, required, editable, or read only. You can further control access by using record types which can allow you to display certain picklist values depending on your business needs You can use field level security to prevent access to specific fields on a profile by profile basis. You can further restrict users' access to fields by setting whether those fields are visible, editable, or read only. For example, individual fields which are confidential, can and should be hidden FLS - In order to be absolutely sure that a user can't access a particular field, it's important to use the field-level security page for a given object to restrict access to the field. There are simply no other shortcuts that will provide the same level of protection for a particular field. - Trailhead Controlling Access to Fields module
Let’s take a quick look at the structure of access to records Organization-Wide Defaults (OWD) is your baseline for permissions on standard and custom objects Roles opens access from the top-down Sharing Rules opens access further using criteria-based rules Manual Sharing is user driven, not criteria-based
There are a few more key principles that can help augment the layers of security at your company. First, limit the number of users with admin rights, and check periodically to make sure that, the same individuals need to have admin permissions. This can change over time. A key principle of security in general is to provide users with the minimum access they need to do their job. There is no need, for example, for a business analyst to see billing information for customers. For those of you who haven’t checked out Trailhead yet, we highly encourage you to check out this fun and engaging educational tool available for self-paced training. There is a Data Security module that will give you hands-on for some of the things we reviewed today. And last, cross-org communication is critical to security, not only between org admins, but also with your IT and security departments. Some key things you can talk about with IT: How can you partner to improve security awareness of Salesforce users How can you better understand company security policies and integrate into your administration of Salesforce, including password policies Creating a process for notifying you when a user should be deactivated What are the most common IP addresses that employees log in from As foreign as it may seem to some, there is a lot to gain from building a relationship with your IT and Security departments.
The most important thing you can do when you get back to the office is review the security settings in each of your orgs. If there are other admins at your company who aren’t here today, we’d encourage you to talk to them and share what you learned in this session. Would anyone in the room like to share what they plan to do from a security perspective when they get back to the office, based on what you learned today? Activating and using the turnkey security features in Salesforce is the best way to get started in bolstering the security of your implementation. But security settings aren’t something you set once and walk away from – there is some maintenance required as your company grows and changes and your users come and go. And no one security feature can prevent all malicious actors, so it’s best to implement multiple features at both the org level, profile level and even for sensitive fields and reports. There are additional capabilities available like encryption and monitoring capabilities, but the features we discussed today are a great start. And don’t under-estimate the role of the individual user in keeping your data secure. Educate, educate, educate. Talk to your colleagues about creative ways they have worked with their users to make them more aware and motivated to do their part to keep data secure.
This is a list of suggested resources to help you take next steps on all of the things we talked about today. Don’t forget about Dreamforce session recordings, which are a great learning resource and almost always include a demo so you can see step-by-step how to configure some of the settings we talked about today. In particular, the Salesforce Trust team ran a whole series of sessions called “Secure Salesforce” that get a step deeper into the technology that we didn’t have time to cover today. The Salesforce Trust and Compliance teams have recently begun a webinar series with each release that focuses specifically on what’s new in security and compliance. Salesforce product managers and experts walk through new features, and there is open Q&A at the end. Finally, Trailhead and Help & Training are always available for self-help.
IP Ranges (Company/Org Level) Users logging in outside the range are sent an activation code to the email address on their user record Setup > Security Controls > Network Access Login Hours Specify hours users can log into your org Setup > Manage Users > Profiles > Select Profile > Login Hours Freeze User Accounts Setup > Manage Users > User | Select user > Click Freeze Image credit: Pixabay https://pixabay.com/en/silhouettes-hierarchy-human-man-439150/
Profile vs. Permission Set: The key difference between the two is that users can have only one profile, but they can have many permission sets. This means you can use profiles to grant the minimum permissions and settings that all users of a particular type need, then use permission sets to grant additional permissions, without changing anyone’s profiles. The combination of profiles and permission sets gives you a great deal of flexibility in specifying object-level access. Balanced use of Profiles and Permission Sets is important. Too many of either can complicate security for your org. Manage Permission Sets Setup > Manage Users > Permission Sets Assign Permission Sets Permission Sets > Manage Assignments > Add Assignments > Select User(s) > Assign
Sharing rules allow users to see/edit data they don’t own in an otherwise private setup Can be shared by owner or criteria based sharing They can be used to extend access to users in roles, public groups, or territories. Sharing rules can never be stricter than your organization-wide default settings. The platform provides the following record-level security and sharing tools. Sharing rules—enable you to make automatic exceptions to organization-wide defaults for particular groups of users, to give them access to records they don’t own or can’t normally see. Manual sharing—allows record owners to give read and edit permissions to users who might not have access to the record any other way. For example, use sharing rules to extend sharing access to users in roles, public groups, or territories Owner or Criteria Based Sharing Can never be stricter than your organization-wide default settings
Salesforce has two levels of granularity that can be used when applying login IP range restrictions. The first is at the Org level. Org level Trusted IP Ranges require users to log in from designated IP addresses - typically your corporate network or VPN. These are IP addresses from which users can log in to Salesforce without getting a login challenge, where they have to enter a code send to their mobile device or email address before they can successfully log in. The second level of granularity is profile-based login IP range restrictions. For Enterprise, Performance, Unlimited, Developer, and Database.com editions, you can set the Login IP Range addresses from which users can log in on an individual profile. Users outside of the Login IP Range set on a profile cannot access your Salesforce organization. And if you are using Contact Manager, Group, and Professional Editions, you can set the Login IP Range in Setup, Security Controls | Session Settings. Since this feature can be a little more complex to implement, you can check Help & Training for more detailed information, or work with your IT department to help you identify appropriate IP ranges and to help you set this up. If your company has VPN and/or Single Sign On (SSO), we recommend talking to your IT department about how login IP ranges can work in your environment.
First, some critical things to know about passwords. Strong password security is an important first step in protecting your Salesforce accounts. Salesforce recommends these best practices: Password expiration – Salesforce recommends no more than 90 days to force users to reset their passwords Password length – Salesforce suggestions minimum password length of 8-10 characters Password complexity – Require users to include a mix of alpha and numeric characters in their Salesforce password. In addition, remind users to never reuse passwords on multiple accounts, or they risk compromise of more than one of their accounts. Last, users need to understand that they must never share passwords with anyone, either online or in person -- this includes their Salesforce password. Hackers know that people reuse passwords and will take a hacked password and try it on other sites. A study of the 2011 PlayStation Network hack showed that 33% of users had the same password for two unrelated sites, Sony and Gawker. Odds are that some of these reused passwords may have been used for more sensitive accounts, such as email and bank accounts. Password reuse is low-hanging fruit for hackers. Because hackers can circumvent passwords, Salesforce also recommends using additional technologies like two factor authentication and single-sign-on to provide extra layers of protection to your orgs.
Salesforce highly recommends phishing education for all Salesforce users. Most cyber attacks use malware (malicious software) to infect a computer with malicious code designed to steal passwords, data, or disrupt an entire computer/network. Fortunately, you don’t need to be a security expert to help stop malware. Some simple recommendations you can make to your Salesforce users: Teach users to not be fooled by phishing, and to not click links or open attachments in suspicious emails. One of the most effective cyber attack techniques is tricking someone to click a link or open an attachment that installs malware. These are called phishing e-mails because they lure you into opening an email by using the Bugs in Human hardware techniques we discussed earlier. Phishing email can say something intriguing, useful, or appear to be a legitimate message from a real company (package delivery, payroll, IRS, social networking, etc.). If you aren’t sure, try Googling the subject of the email and see if any other sources have reported it to be a phishing attempt. Another simple rule with big impact is to instruct users to never open emails from unknown sources. Hackers want people to click on their link so that they can infect the user’s computer. Similarly, teach users that emails received from an unknown source should be evaluated based on the source and whether it makes sense. If not, it may be malicious. The sender's address should always be verified and and any links to URLs can be hovered over to validate them. For example, if the link says it’s from Salesforce, then hovering over the link should show a URL ending in ".salesforce.com” or “exacttarget.com”. If you or any of your users are unsure about whether a Salesforce email is legitimate, forward the email to security@salesforce.com, and you will hear back from someone on the Salesforce Trust team very quickly. You can also check trust.salesforce.com for a listing of recent email threats that the Trust team is aware of.
These days people change jobs more than ever. And this means that your Salesforce users are constantly changing and shifting - people leave the company and new users are added all the time. When the user no longer works for the company, security is in your hands. Get that user deactivated as soon as possible so they can no longer use their Salesforce credentials! The best practice is to freeze a user as your first step in deactivation. Freezing a user will lock their credentials while you work on deactivating the user across your company’s implementation. Freezing a user is also quick and easy to do: Just log into the User Record and click the box “Freeze”. You may have wondered at some point why a user can’t be deleted from Salesforce. Think of it this way - every user creates records with everything they do in Salesforce, whether they are posting in Chatter, updating a Contact or closing an Opportunity. If a user was to be deleted, it would mean that many of the records created by that user could be orphaned. Orphaned records still exist in Salesforce, but they are not associated with an object or other records, and can only be accessed by the original owner. Deactivating a user, on the other hand, allows the many records and linkages between records to remain, even without an active user associated with them. You may see this occur when you try to deactivate a user, and you get a pop-up message that says “You cannot deactivate this user”. For example, this occurs when a user is a Default Lead Owner, and someone must be assigned a default for your organization. All you need to do is change the Default Lead Owner, and then you can proceed to deactivate the user. There can be one little kink in this whole thing. The information that a user is leaving may not make it’s way over to your desk...and if it does, it may not be in a timely fashion. Creating a rigorous process of notification with IT or your HR department is extremely helpful. Some companies are required to create this process for compliance reasons, but for many others, the Admin can be in the dark unless the lines of communication are open.
Salesforce recommends requiring 2FA each time your users login to Salesforce. By a show of hands, how many of you have 2FA enabled for your orgs? Some companies are concerned about the inconvenience this extra step can create for users. One approach is to set up 2FA for certain profiles, like for admins (who have a high level of permissions) or users who have access to sensitive data, like billing details. Salesforce Authenticator is a free feature, but for a small cost, some customers use a hardware-based token that the user adds to their computer and simply touches to generate the unique code. This can also decrease any inconvenience. 2FA can be enabled through permissions or profile settings. Users add the mobile authenticator app, Salesforce Authenticator, to their mobile device by downloading from the iTunes App Store or Google Play. [LEADER – if participants in your user group would like to see Setup screenshots for 2FA setup, we have provided slides after the Thank You slide at the end that you can use.]
If you would like a step-by-step walkthrough of setup for two factor authentication, a great resource is available through Salesforce Docs. You can jot down this link or go to Help & Training and search for “Two Factor Authentication”. You will find a link in the Help & Training article that will lead you to the walk through. 2FA Walkthrough link (hyperlink also in the slide above): sforce.co/1VWwmpB

How to be a Security Minded Admin by Chris Zullo

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to How to be a Security Minded Admin by Chris Zullo

Similar to How to be a Security Minded Admin by Chris Zullo (20)

More from Salesforce Admins

More from Salesforce Admins (20)

Recently uploaded

Recently uploaded (20)

How to be a Security Minded Admin by Chris Zullo

Editor's Notes