Org Security Fundamentals!!!...

It is no doubt that your org contains essential data which obviously you do not want to share with anyone. Ever imagined what can happen if your valuable information is leaked to the third party. They can play around with confidential information stored in your Salesforce Org. It’s always better to take precautions in advance before it gets too late. So it’s high time to take precautions and make your org safe and avoid leaking of any valuable information. What we should make sure on our end is:

1. User Access
2. Connected Apps
3. Custom Code
4. Compromised Accounts

CORE SECURITY PRINCIPLES

We should set some security principles to ensure the safety of your Org. We can opt for following strategies:

Defense In Depth: It’s always good to have multiple layers of defense, since using any one layer has potential to fail. Therefore, if we have more layers, then it’s less likely that all the providing fail at same time. This principle should always be kept in mind.

The principle of least privilege: As the word suggests, each entity should have the least number of privileges which they need to do their job. It helps to limit the damage.

FUNDAMENTAL DEFENSES

User and access management: There is always need to make sure that users who need access to org only has access.Here are different layers of access management:

Organisation Access: This deals with organization access as a whole. We should make sure that whenever a person leaves a company then he is de-provisioned. All access should be removed or taken away from him. To remove provision one can freeze user or deactivate them so org access can’t be misused.

Profiles: To remove the mess and for security purposes, we can grant access to users by their profiles. Also, we can give different permission to each object according to profiles. Field Level Security (FLS) controls the access of fields. While creating profiles assign them a particular set of roles.

To set object level permission, one should go to Quick Find Search > Profiles > Select a Profile > Object level Permission
Now you can provide read access or write access to the objects you want to give access of to that particular profile.

Sharing Default: It is a record level access.

Public vs. Private: Public refers that if someone has access to all the objects in the org. Then automatically he has access to all the records for that object. The principle is to keep access to private, i.e.; a user has access to the objects according to role hierarchy.

Internal vs. external: By internal we mean that people who have the direct login to the org and external refer to the people coming through public facing communities, portals or external chatter users. If access is set to public and we have logged in through any portal, then there are high chances of any mishap.

Health Check: What if a user has access to the objects which are required by him but has a very weak password? Ever thought??.. Yup, password plays a great role in providing security. We can protect this since Salesforce provides a way to make your org secure and safe. To perform health check: Quick Search > Health Check

Health check provides the following info:

1. Password length
2. Password history
3. Max invalid login attempts
4. Session timeouts, etc…

Health Check in a way or the other helps you to know the recommendations which Salesforce provides you in general.

Two-factor Authentication: Many times passwords have proved to be very weak links which can easily be stolen. They act as a single point of failure. They can often be guessable. Some of us have a tendency to use the same password for all the accounts which can be fatal sometimes.

One can use even Salesforce Authenticator to provide security. This app can be installed quickly. Once the user logs in, they have to provide their password and one-time security token that is displayed on the app. This authenticator is not limited to the only Salesforce.

Here are the steps to set up 2FA:

1. Create 2FA permission set
2. Assign to profiles
3. At login, users will be invited to use 2FA.

Hence, 2FA is perfect defense and proves a lot useful when it comes to providing security to the Org.

IP Whitelisting: It is a good practice to adopt. This is the next level of the defense. It is useful when we have scenarios such as where a person doesn’t have the device which provides 2FA or the security token. We can whitelist our static IP ranges in the Org. We can set it for all the profiles including API users and integrations. To whitelist IP we can go to
Setup >Network Access >Put your static IP
By doing so, whenever you log in next time it will not demand any kind of security token.

Now it’s a lot to help you, keeping your org safe and secure. Make sure always to follow best practices of defense before you get engrossed and start working. There is always someone who spies and just need that single chance to get all your information. It can be easy for him if you leave any loopholes in between. So please don’t give that single chance to anyone and take precautions before something fatal occurs. BE PROTECTIVE!!!….