Configuration and Setup - Data Security

Question 1

Organization restrictions

Answer 1

For your whole org, you can maintain a list of authorized users, set password policies, and limit logins to certain hours and locations.

Question 2

Object level data

Answer 2

Access to object-level data is the simplest thing to control. By setting permissions on a particular type of object, you can prevent a group of users from creating, viewing, editing, or deleting any records of that object. For example, you can use object permissions to ensure that interviewers can view positions and job applications but not edit or delete them. You can use profiles to manage the objects that users can access and the permissions they have for each object. You can also use permission sets and permission set groups to extend access and permissions without modifying users’ profiles.

Question 3

Fields restrictions

Answer 3

You can restrict access to certain fields, even if a user has access to the object. For example, you can make the salary field in a position object invisible to interviewers but visible to hiring managers and recruiters.

Question 4

Records-level access

Answer 4

You can allow particular users to view an object, but then restrict the individual object records they’re allowed to see. For example, an interviewer can see and edit her own reviews, but not the reviews of other interviewers. You can manage record-level access in these four ways.

Organization-wide defaults
Role hierarchies
Sharing rules
Manual sharing

Question 5

Records: Organization-wide defaults

Answer 5

specify the default level of access users have to each others’ records. You use org-wide sharing settings to lock down your data to the most restrictive level, and then use the other record-level security and sharing tools to selectively give access to other users.

Question 6

Records: Role hierarchies

Answer 6

give access for users higher in the hierarchy to all records owned by users below them in the hierarchy. Role hierarchies don’t have to match your organization chart exactly. Instead, each role in the hierarchy should represent a level of data access that a user or group of users needs.

Question 7

Records: Sharing rules

Answer 7

are automatic exceptions to organization-wide defaults for particular groups of users, so they can get to records they don’t own or can’t normally see. Sharing rules, like role hierarchies, are only used to give additional users access to records. They can’t be stricter than your organization-wide default settings.

Question 8

Records: Manual sharing

Answer 8

allows owners of particular records to share them with other users. Although manual sharing isn’t automated like org-wide sharing settings, role hierarchies, or sharing rules, it can be useful in some situations, such as when a recruiter going on vacation needs to temporarily assign ownership of a job application to someone else.

Question 9

Login Hours

Answer 9

Profile level: Can restrict hours for users to log in
Days & hours can be set for users to log into the organization; they will be denied if attempted outside the allotted days/hours
The same error message that appears when the username or password is incorrect appears when a user is denied access
‘Clear all times’ can be clicked to allow users to log in at any time
By setting ‘Start Time’ to 12AM and ‘End Time’ to ‘End of Day, it will prohibit users from logging in on a specific day

Question 10

Network Settings

Answer 10

Org Access (Highest level):Without verifying their identity, users can login on specified trusted IP ranges set within the network access settings

Question 11

Record Modification Fields

Answer 11

All objects include fields to store the name of the user who created the record and who last modified the record. This provides some basic auditing information.

Question 12

Login History

Answer 12

You can review a list of successful and failed login attempts for the past six months

Question 13

Field History Tracking

Answer 13

You can turn on auditing to automatically track changes in the values of individual fields. Although field-level auditing is available for all custom objects, only some standard objects allow it.

Question 14

Setup Audit Trail

Answer 14

The Setup Audit Trail logs when modifications are made to your organization’s configuration.

Question 15

Password policies

Answer 15

Set password and login policies, such as specifying an amount of time before all users’ passwords expire and the level of complexity required for passwords.

Question 16

User password expiration

Answer 16

Expire the passwords for all the users in your org, except for users with “Password Never Expires” permission.

Question 17

User password resets

Answer 17

Reset the password for specified users.

Question 18

Login attempts and lockout periods

Answer 18

If a user is locked out due to too many failed login attempts, you can unlock the person’s access.

Question 19

Identity provider

Answer 19

is a trusted service that enables users to access other websites and services without logging in again.

Question 20

Single sign-on (SSO)

Answer 20

enables a person to log in once and access other apps and services without logging in again.

Question 21

Social sign-on

Answer 21

enables a person to log in to an app using the credentials established with a social account like Google. That app accepts the Google credentials, and the user doesn’t have to create another account and password.

Question 22

Service provider

Answer 22

is a website or service that hosts apps and accepts identity from an identity provider.

Question 23

Protocol

Answer 23

specifies the set of rules that enable systems to exchange information. Generally, the term protocol and standard are used interchangeably.

Question 24

Privileged credentials

Answer 24

are a subset of credentials (such as passwords) that provide elevated access and permissions across accounts, applications, and systems.

Question 25

Privileged passwords

Answer 25

can be associated with humans, applications, service accounts, and more.

Question 26

Privileged access management (PAM)

Answer 26

Manages a way to store secrets, such as passwords and cryptographic keys (a word, number, or phrase that works in combination with an algorithm to encrypt [or scramble] plaintext)

An important factor of PAM implementation is to make sure you have well-defined use cases and user profiles.

Use these to assign levels of access for service account management, discovery functions, asset and vulnerability management and analytics, and more.

If your organization does not have the resources to maintain security staff who are trained to install, configure, and manage these solutions, consider using a managed service provider (MSP) who can perform these functions for you.

Question 27

Privileged Account Password Policy

Answer 27

To protect your systems your organization should develop and enforce a clear policy for privileged account passwords and to socialize it with all relevant parties who use and manage these accounts.

It’s a good idea for organizations to develop privileged account password policies for both accounts accessed by people, and accounts accessed by other systems. These policies should include the mandatory use of long passphrases and multi-factor authentication (MFA) for human accounts.

Passwords rotation standards can ensure the systematic rotation of passwords for every account, system, networked hardware device, application, and service. Your rotation standards should include automatic notification to stakeholders when it’s time to update passwords.

Question 28

principle of least privilege (POLP)

Answer 28

he principle of least privilege is an IT security design principle that restricts access rights and program privileges to only those necessary for the required job. It’s the difference between having a key that works on every door, and one that only opens certain rooms.

One aspect of implementing least privilege is that you remove full local administrator access to system endpoints

Question 29

k

Answer 29

k