Table of contents<\/h3>\n\n\n\n- Salesforce Security Breach Risks<\/a><\/li>
- Primary Salesforce Data Security Best Practices<\/a><\/li>
- How to Run a Security Health Check for Salesforce Instances<\/a><\/li>
- 20 More Tips for Greater Data Security in Salesforce Organizations<\/a><\/li>
- Final Words<\/a><\/li><\/ul>\n\n\n\n
Only in August 2022, IT Governance alone identified 112 security incidents that resulted in 97M compromised records<\/a>. The number of data breaches continues to grow yearly as more businesses go online, more employees work remotely, and bad guys become more inventive. Companies failing to implement sufficient cybersecurity protocols and safeguards risk facing severe consequences, such as revenue loss, non-compliance fines, legal fees, and loss of trust.<\/p>\n\n\n\nSalesforce, one of the biggest and most popular CRM platforms, stores not only gigabytes of customer data but also its customers\u2019 vital prospect lists, pricing and discounting details, sales pipelines, and often sensitive information. Understanding the potentially fatal impact of a successful Salesforce cyber-attack or careless actions by internal players, the SaaS provider takes great pains to keep its platform secure.<\/p>\n\n\n\n
Read on to learn what Salesforce security best practices make it one of the safest CRM solutions and how admins and developers can ensure maximum data security. But let\u2019s start with an overview of risks and threats specific to the CRM platform.<\/p>\n\n\n\n
<\/a>Salesforce Security Breach Risks<\/h2>\n\n\n\nUnfortunately, some Salesforce security vulnerabilities are rooted in the platform\u2019s advantages. <\/p>\n\n\n\n
For example: <\/p>\n\n\n\n
- Easy integration with multiple services via APIs<\/strong><\/li><\/ul>\n\n\n\n
Not every third-party app you connect to Salesforce may be as safe as Salesforce itself. Integrated apps can potentially create unsecured doors into your instance and introduce new security risks. APIs can make your Salesforce org vulnerable to:<\/p>\n\n\n\n
- DDoS attacks<\/li>
- code injections<\/li>
- fraudulent logins<\/li>
- unsecured cardholder information<\/li>
- replay attacks<\/li>
- exposed data in URI keys<\/li><\/ul>\n\n\n\n
If a connected app is compromised, it could expose your internal Salesforce data. Granting access to a shady or unsecured API may lead to hacks, data breaches, and compliance issues.<\/p>\n\n\n\n
- Empowered users<\/strong><\/li><\/ul>\n\n\n\n
Virtually any Salesforce user can be a lesser or greater insider threat based on their level of access to information housed on the cloud platform and ability to make changes. <\/p>\n\n\n\n
For example, employees may share or extract sensitive data inadvertently or intentionally. An enabled “export” permission makes it easy for unscrupulous employees to steal information like leads or customer lists.<\/p>\n\n\n\n
More and more CRM users that work remotely access Salesforce on personal devices, creating additional risks. <\/p>\n\n\n\n
Common insider threats to Salesforce data include:<\/p>\n\n\n\n
- departing employees who may take valuable or sensitive information with them<\/li>
- insiders who want to harm a company\u2019s reputation by leaking data<\/li>
- negligent insiders whose errors can expose a company to security threats<\/li>
- privileged users that enjoy more access rights than their duties require and can make configuration changes affecting data security<\/li>
- unauthorized persons obtaining a user\u2019s credentials and other account information<\/li><\/ul>\n\n\n\n
- Salesforce being configurable, customizable, and open<\/strong><\/li><\/ul>\n\n\n\n
Misconfiguration is one of the biggest risks to cloud environments. Salesforce org security is often neglected in favor of configuration changes. Countless permission possibilities make it easy to leave valuable data exposed. Teams that don\u2019t know the ropes of the many Salesforce configurations risk missing critical gaps.<\/p>\n\n\n\n
Contractors are among external users that are granted access to SF. According to the 2021 SaaS Risk Report by Varonis<\/a>, 75% of contractor identities remain active after they leave.<\/p>\n\n\n\nSalesforce opening its functionality for developers and social communities also opens up possibilities for security incidents. <\/p>\n\n\n\n
Outsider attacks are a persistent threat too. For example, one Salesforce data breach affected over 200,000 customers of Hanna Andersson, a children\u2019s clothing company. Salesforce handled the customers\u2019 personal and payment information when they engaged in a sale.<\/p>\n\n\n\n
From September 16 through November 11, 2019, the Salesforce network suffered a malware infiltration. Hackers were able to scrape consumer data, including credit card information and personal identifiers, from about 10,000 consumers. The hackers sold the data on the dark web and retained access to the database for several months before law enforcement found it out.<\/p>\n\n\n\n
In 2020, a California resident filed a federal class action lawsuit against Salesforce and Hanna Andersson for negligence, declaratory relief, and violations under the California Unfair Competition Law. The complaint claimed that both companies failed to protect private data, failed to detect the data breach, employed inadequate security practices, and did not warn consumers about their deficient practices.<\/p>\n\n\n\n
In 2021, Salesforce and Hanna Andersson agreed to pay $400,000 to resolve the lawsuit and offered identity theft protection services to the affected customers. Salesforce focused heavily on integrating monitoring systems to catch breaches early on.<\/p>\n\n\n\n
Handling situations like these over two decades, Salesforce has amassed a vast knowledge of bad practices. Salesforce Trust<\/a> provides a transparent and real-time view of its security measures and updates on attacks that can affect its customers. The company has also developed a robust data security model and a comprehensive set of controls to secure each Salesforce org. <\/p>\n\n\n\nPrimary Salesforce Data Security Best Practices<\/h2>\n\n\n\n
The primary cybersecurity best practices implemented by Salesforce include:<\/p>\n\n\n\n
1. Multi-factor authentication (MFA)<\/h3>\n\n\n\n
Salesforce requires all customers to use MFA when accessing Salesforce products. Users must confirm their identity with an authentication app on a mobile phone or a security key. MFA makes phishing attacks useless: if the bad guys obtain a user\u2019s credentials, they will not be able to use them without the user\u2019s smartphone, for example.<\/p>\n\n\n\n
![\"\"](\"https:\/\/alternative-spaces.com\/blog\/wp-content\/uploads\/2022\/10\/70-1024x513.webp\")
<\/figure><\/div>\n\n\n\n2. Authentication data security<\/h3>\n\n\n\n
Every time a user enters their username and password, the platform creates a session cookie for them. Instead of storing the credentials data in it, Salesforce uses encoded session IDs. If somebody intercepts cookies from a user\u2019s browser, they won\u2019t be able to access the user\u2019s authentication data. The default session timeout, two hours of inactivity, also contributes to security.<\/p>\n\n\n\n
3. Event monitoring<\/h3>\n\n\n\n
An automatic system within Salesforce promptly notifies customers of potentially dangerous actions of its users, such as weak passwords or insecure settings, and suspicious processes involving their data. The change logging feature can track multiple event types and allows admins to view, filter, and download event logs through the Event Log File Browser. If something goes wrong, the platform will alarm both the customer and Salesforce cybersecurity personnel to fix the problem.<\/p>\n\n\n\n
4. A comprehensive and flexible data-sharing model<\/h3>\n\n\n\n
Salesforce customers typically have dozens or hundreds of employees with different responsibilities. The multi-layered data security model in Salesforce enables administrators and app developers to manage these employees\u2019 access to information from an org perspective down to an individual record. This means not only a better user experience but also error reduction and greater safety: if a user\u2019s account is compromised, intruders won\u2019t go further than information open to that user.<\/p>\n\n\n\n
The three key constructs related to data in Salesforce include:<\/p>\n\n\n\n
- Objects<\/strong> similar to tables in databases, such as Projects, Accounts, Portfolios, Resources, Files, Tasks, Reports, etc.<\/li>
- Fields<\/strong> correlating with a table’s columns, e.g., Project name, Description, Status, Start date, Finish date, etc.<\/li>
- Records <\/strong>that correspond to rows of data inside a table.<\/li><\/ol>\n\n\n\n
Salesforce secures access to these data sets on three levels:<\/p>\n\n\n\n
Layer 1: Object-level security<\/strong><\/p>\n\n\n\nTwo configurations help manage object-level access: Profiles and Permission Sets. Each user is assigned a profile, where the admin (the person with principal administrative rights in the organization) allows minimum access to data needed for a particular job role and configures things like login IP restrictions. Admin can grant further access and abilities to the user through multiple permission sets.<\/p>\n\n\n\n
For example, the admin may allow a salesperson to see only a specific object they work with, while their manager will have the right to view all objects and create new ones. The admin can issue and take away these permissions from users at any level at any time. <\/p>\n\n\n\n
Layer 2: Field-level security<\/strong><\/p>\n\n\n\nProfiles and permission sets also control field-level access. Admins can provide read and write permissions for individual fields within an object. When an admin hides a field from a user, it means the user will not be able to access it. A field hidden with field-level security will not be accessible through any entry points, including APIs.<\/p>\n\n\n\n
Layer 3: Record-level security, aka Salesforce sharing model or record sharing<\/strong><\/p>\n\n\n\nThere are five ways for users to share records and access other users\u2019 records. After configuring org-wide defaults to lock down their data, they can use other record-level security tools to open records to selected users as needed.<\/p>\n\n\n\n
![\"\"](\"https:\/\/alternative-spaces.com\/blog\/wp-content\/uploads\/2022\/10\/68-1024x723.webp\")
<\/figure><\/div>\n\n\n\nThe record-level security tools include:<\/p>\n\n\n\n
1) Organization-wide sharing defaults (OWD). <\/strong>Every record has a field called \u201cOwnerId\u201d that refers to a real user, usually the person who created the record and has full create, read, update, and delete access to it. OWD control the default behavior of users regarding access to a record they don\u2019t own. OWD must be either public read-only or private to create sharing rules.<\/p>\n\n\n\n2) Role hierarchies.<\/strong> Different job roles have different record access requirements. Users with a higher role usually need and can access records to which users in lower roles have access. To use this upward sharing rule, an administrator has to add a user to a higher role and then grant access.<\/p>\n\n\n\n3) Sharing rules. <\/strong>If users need to share records they own laterally, e.g., with their teammates, sharing rules apply that extend sharing access to groups, roles, or individuals. They enable record sharing laterally and in an ad-hoc fashion via public groups:<\/p>\n\n\n\na) Ownership-based sharing rules<\/strong> let admins share records based on role, role-and-subordinate, and public group ownership. These rules allow for exceptions to OWD and the role hierarchy that give a user access to records they don\u2019t hold. Owner-based sharing rules are limited to 300 per organization.<\/p>\n\n\n\nb) Criteria-based sharing rules<\/strong> open access to a record based on the value of a field in it, irrespective of who owns the record. If one or multiple criteria are met, records are shared with an eligible individual or group. An organization can have up to 50 such rules.<\/p>\n\n\n\nc)Guest user sharing rule<\/strong> that grants access to records to an unauthenticated user using sharing settings is seldom used because it is not recommended to expose data to such users. <\/p>\n\n\n\n4) Manual sharing.<\/strong> If a record\u2019s OWD is private or public read-only, end-users can share it with others manually. This permission is available through the Sharing button on the record details page. If the ownership of a shared record changes, all users whom the original owner had granted access will lose it. <\/p>\n\n\n\n5) Apex managed sharing. <\/strong>In cases when records can\u2019t be shared via UI or settings, developers can write Apex code to do so programmatically. It can be used only when a record\u2019s OWD is set as private or public read-only.<\/p>\n\n\n\n5. Data encryption<\/h3>\n\n\n\n
Two types of encryption are available \u2014 for standard and premium subscriptions \u2014 allowing to encrypt most data stored on the platform. Salesforce provides encryption whenever data travels to and from the platform. The encrypted connection prevents Salesforce data from being exposed when you export it.<\/p>\n\n\n\n
6. Data storage and backup<\/h3>\n\n\n\n
Salesforce stores user data using multiple active clusters. The database is hosted on carrier-class storage that may need only a few minutes of downtime per year. If one data center goes offline or a server breaks, all data will still be accessible. Moreover, data can be backed up weekly or monthly for greater security.<\/p>\n\n\n\n
![\"\"](\"https:\/\/alternative-spaces.com\/blog\/wp-content\/uploads\/2022\/10\/69-1024x723.webp\")
<\/figure><\/div>\n\n\n\nThe best practices for Salesforce security are not implemented only on the CRM\u2019s side. Customers need to keep the shared responsibility in mind: Salesforce secures the cloud platform, but once a company inputs its data, it\u2019s up to them to protect it with an extra layer of security beyond what Salesforce provides.<\/p>\n\n\n\n
Administrators can activate and adjust many tools, settings, and parameters to make their instances more secure. Here are Salesforce security tips to help minimize external threats and breaches caused by employee error or malicious intent. <\/p>\n\n\n\n
If we were to rank the methods, our first advice would be: start with your Salesforce Health Check<\/strong>.<\/p>\n\n\n\n<\/a>How to Run a Security Health Check for Salesforce Instances<\/h2>\n\n\n\nThe Salesforce Security Health Check tool lets administrators thoroughly assess their instance\u2019s well-being by scanning the settings that ensure its safety. Having identified possible risks and vulnerabilities, the admin can fix the issues and even improve their instance\u2019s security with one click, all from one page.<\/p>\n\n\n\n
You can start Health Check by searching for it in the Quick Find box of your Setup page or heading over to Security > Health Check.<\/p>\n\n\n\n
Next, in the Baseline dropdown, choose the Salesforce Baseline Standard or a custom Baseline. This means you can run the check either against the settings for different risk levels recommended by Salesforce or against a customized Baseline. In the latter case, Security Health Check allows adding up to five custom Baselines to make the check as rigorous as needed or make the settings less restrictive than the Baseline selected.<\/p>\n\n\n\n
For example, if your healthcare organization handles sensitive data and Personally Identifiable Information, you can add a custom Baseline about GDPR standards<\/a>.<\/p>\n\n\n\nYou can create a custom Baseline as follows:<\/p>\n\n\n\n
1. Click on \u201cExport Baseline\u201d in the Baseline Controls Menu.<\/p>\n\n\n\n
2. Use a text editor to edit the exported XML file. When making adjustments in the risk categories, make sure not to add or delete risk categories, names, and even quotation marks: it would lead to import failure. Some specific setting values cannot be modified, and moving a security setting to the Informational category means removing it from the Health Check score calculation.<\/p>\n\n\n\n
3. Click on \u201cImport Baseline\u201d in the Baseline Controls Menu to save and import the XML file. <\/p>\n\n\n\n
4. Enter your custom Baseline\u2019s name in the dialog box that opens.<\/p>\n\n\n\n
5. Assign your custom Baseline a unique API name without any spaces or special characters.<\/p>\n\n\n\n
6. Set the new custom Baseline as the default Baseline for your Salesforce security review, if you want. It will appear in the dropdown once the import is completed.<\/p>\n\n\n\n
So, after you click on the Baseline dropdown and select the desired Baseline, Security Health Check would run the scan, produce a health score, and give recommendations on addressing weaknesses.<\/p>\n\n\n\n
The tool uses a proprietary formula to assess the compliance of your instance\u2019s security settings with Salesforce Baseline Standard or a customized Baseline. Your org\u2019s health can be scored through the following percentages:<\/p>\n\n\n\n
- \u2266 54% \u2014 very poor<\/li>
- 55%-59% \u2014 poor<\/li>
- 70%-79% \u2014 good<\/li>
- 80%-89% \u2014 very good<\/li>
- 90%-100% \u2014 excellent<\/li><\/ul>\n\n\n\n
The more restrictive your settings, the higher the score will be.<\/p>\n\n\n\n
![\"\"](\"https:\/\/alternative-spaces.com\/blog\/wp-content\/uploads\/2022\/10\/71-1024x607.webp\")
<\/figure><\/div>\n\n\n\nSecurity Health Check divides any discovered vulnerabilities into four classes: high-risk, medium-risk, low-risk, and Informational Security Settings. Within each section, settings to review will also be categorized as \u201cCritical,\u201d \u201cWarning,\u201d and \u201cCompliant.\u201d This will give you a prioritized checklist of items to review and fix.<\/p>\n\n\n\n
For example, Salesforce Baseline Standard limits invalid login attempts to three. If your instance\u2019s settings allow more, Health Check will flag a high-risk vulnerability, advise you to mitigate the risk, and create a shortcut for the necessary modification.<\/p>\n\n\n\n
Other settings Health Check might flag include:<\/p>\n\n\n\n
- minimum password complexity<\/li>
- forced logouts on session timeouts<\/li>
- forced re-logins after an administrator logs in as another user<\/li>
- clickjack protection<\/li>
- locking sessions to the IP address from which they originated<\/li><\/ul>\n\n\n\n
The types of recommendations include:<\/p>\n\n\n\n
- Password Policies<\/li>
- Session Settings<\/li>
- Network Access<\/li><\/ul>\n\n\n\n
Click on \u201cFix Risks\u201d to start adjusting your settings.<\/p>\n\n\n\n
![\"\"](\"https:\/\/alternative-spaces.com\/blog\/wp-content\/uploads\/2022\/10\/72-1024x532.webp\")
<\/figure><\/div>\n\n\n\nOccasionally, you wouldn\u2019t want to adjust your settings to match Salesforce\u2019s recommendations. For example, Salesforce recommends disabling the option to log in as another user. However, if you often do it when troubleshooting issues, you would want it enabled.<\/p>\n\n\n\n
Just like humans periodically undergo health checkups even when there are no perceptible risks, admins should undertake a security health check for Salesforce instances on a regular schedule, e.g., monthly or quarterly. Salesforce regularly updates its Baseline Standard to adapt to new threats and changes in best practices, and the platform itself is updated three times per year. Industry standards also change, and so do your organization\u2019s security requirements.<\/p>\n\n\n\n
<\/a>20 More Tips for Greater Data Security in Salesforce Organizations<\/h2>\n\n\n\n1. Identify your Salesforce security responsibilities, vulnerabilities, and misconfigurations<\/strong><\/p>\n\n\n\nUnderstanding what data you have in the CRM system and identifying misconfigurations are essential to strengthening your org\u2019s security. It\u2019s also crucial to understand which security tasks are handled by Salesforce and which are your security team\u2019s responsibility. <\/p>\n\n\n\n
It may help to review your internal processes to see if you can adjust a process to meet Salesforce standards instead of overly customizing the CRM platform to fit your processes. For example, Alternative-spaces specialists can help you identify and fix misconfigurations, incorrect permissions, data exposures in your Salesforce environment, and other potential issues with Salesforce data security.<\/p>\n\n\n\n
Suppose you feel that the Salesforce Security Health Check is insufficient for your needs and that your company\u2019s security policy requires more robust customizable capabilities. In that case, you may reinforce your security strategy with third-party solutions. For example, OwnBackup Secure allows automation of the remediation of identified misconfigurations with detailed action plans and real-time alerts.<\/p>\n\n\n\n
2. Be super-cautious with permissions<\/strong><\/p>\n\n\n\nSometimes, admins initially provide users with broad access to objects and fields and later try to hide some data by limiting fields\u2019 visibility for individual profiles. However, hiding a field does not cancel a user\u2019s underlying access. They may still access the information by creating a report or through a data export. Integrated apps may also view info within hidden fields.<\/p>\n\n\n\n
The recommended approach is to control access by granting permissions to objects and fields to specific profiles or users. Follow the principle of least privilege: users, including APIs, should have access only to the bare minimum of information necessary to do their job.<\/p>\n\n\n\n
Allow users the least privilege level and selectively grant higher privileges as needed on a case-to-case basis. Refrain from using the permissions to \u201cview all\u201d or \u201cmodify all\u201d within profiles. Be extra careful with \u201cexport\u201d permissions. <\/p>\n\n\n\n
Keep the number of ownership-based sharing rules to 100 per object and the number of criteria-sharing rules to 50 per object.<\/p>\n\n\n\n
Ensure that your Salesforce security team can audit privileged users and is notified when changes are made. <\/p>\n\n\n\n
Don\u2019t forget about external users. Any org that runs a community should review its external sharing and security model, including that of guest users, and take extra care to lockdown records, objects, and permissions. Audit your configuration and check whether authenticated and unauthenticated community users can access only what you want them to. If possible, enforce authenticated access on your communities.<\/p>\n\n\n\n
Admins should review and revalidate permissions over time, including inactive accounts. For example, they must properly offboard contractors once the cooperation is over.<\/p>\n\n\n\n
3. Install apps for specific profiles<\/strong><\/p>\n\n\n\nWhen installing an app or package, you can select to \u201cInstall for Admins Only,\u201d \u201cInstall for Specific Profiles,\u201d or \u201cInstall for All Users\u201d (i.e. opening access to Salesforce for partners, vendors, contractors, and everyone else in your Salesforce environment).<\/p>\n\n\n\n
Once access is granted, you would have to remove users\u2019 permissions manually when needed. The more secure approach is to install the app only for specific profiles with the default \u201cno access\u201d for all users and then add additional profiles and users whenever necessary.<\/p>\n\n\n\n
4. Secure data within packages during installation<\/strong><\/p>\n\n\n\nWhen installing packages, users can select from several settings: \u201cManaged\u201d or \u201cUnmanaged,\u201d and \u201cPublic\u201d or \u201cProtected.\u201d<\/p>\n\n\n\n
The \u201cManaged\u201d option allows creating a unique \u201cCustom Namespace\u201d for your package to store any components, Visualforce pages, classes, or credentials belonging to the package. The \u201cUnmanaged\u201d setting keeps those items in the default or local Namespace.<\/p>\n\n\n\n
The \u201cPublic\u201d setting provides access to the data within the package to any user. The \u201cProtected\u201d setting limits access to the users and components within the Namespace.<\/p>\n\n\n\n
The optimal method is to set the package to \u201cManaged\u201d and \u201cProtected.\u201d<\/p>\n\n\n\n
5. Secure your APIs<\/strong><\/p>\n\n\n\nBefore giving access to any API you connect to Salesforce, look into its security model. This applies to any third-party integrations, such as marketing automation, computer telephony integrations, data enrichment tools, and even your own custom API work. <\/p>\n\n\n\n
Treat any API that accesses your Salesforce instance like any other user. The admin must be able to control what it can and can\u2019t do. You may create a dedicated integration user \u2014 a Salesforce license not used by any human but intended solely for that API with its own profile and permission sets. Then you can enable permissions for specific roles and enforce them as \u201cAPI only,\u201d ensuring the integration can\u2019t access your instance in any other way and view or modify data it shouldn\u2019t.<\/p>\n\n\n\n
Assign them only \u201cread\u201d access, unless otherwise is necessary, and enforce the same password-level policies and location-specific restrictions as for other roles in your Salesforce org. It makes sense to require more robust passwords for integration users: at least 20 random characters, including upper- and lowercase letters, digits, and special symbols.<\/p>\n\n\n\n
You can also restrict the API\u2019s access to your Salesforce instance so that it can log in only from its own partner or vendor\u2019s servers. <\/p>\n\n\n\n
When configuring integrations, developers often use unencrypted HTTP for testing and troubleshooting. When insecure HTTP is not disabled, sensitive information can be exposed to outsiders. Other parties may read and store records within the unencrypted API calls, including login credentials or an OAuth token. None of your integrations should have \u201cDisable Protocol Security\u201d selected. You can configure this setting under Setup > Remote Site Settings > select Details for a specific endpoint.<\/p>\n\n\n\n
You also need to log the integration users\u2019 behavior, conduct regular audits, review them periodically, and revoke access to dormant apps.<\/p>\n\n\n\n
6. Enable App Allowlisting<\/strong><\/p>\n\n\n\nUsers may also create vulnerabilities by giving solutions access to SF. Suppose an employee allows a messenger access to Salesforce to receive notifications about Opportunities, unaware that this violates the organization\u2019s GDPR or HIPAA compliance.<\/a> It could take days to months to spot this issue and fix it.<\/p>\n\n\n\nEnable App Allowlisting in the org to prevent such situations. It lets admins specify to which apps users can and cannot grant access. They can manage user authorization at the org-wide level (all users) or for specific users and apply the same limitations to new users.<\/p>\n\n\n\n
To enable App Allowlisting in your org, the admin must submit a case or call Salesforce. After it has enabled the feature, the admin can assign specific profiles and permission sets access to specific apps:<\/p>\n\n\n\n
- Under \u201cManage Connected Apps,\u201d click \u201cEdit\u201d next to the app in question.<\/li>
- Next, under OAuth policies > Permitted Users, select \u201cAdmin-approved users are pre-authorized.\u201d<\/li>
- Under \u201cManage Connected Apps,\u201d if they click on the app\u2019s label to bring up the Connected App Detail, the admin may assign Profiles and Permission Sets to access the app.<\/li><\/ol>\n\n\n\n
7. Use Salesforce Shield<\/strong><\/p>\n\n\n\nSuppose you need to go beyond the standard security measures provided by Salesforce and bolster your business-critical app. It\u2019s especially relevant in the financial and healthcare domains, with additional layers of security to comply with privacy policy, regulatory requirements, and contractual obligations. In that case, you may strengthen organization-level access with Salesforce Shield. <\/p>\n\n\n\n
The instrument includes three main features:<\/p>\n\n\n\n
- Shield platform encryption<\/strong><\/li><\/ul>\n\n\n\n
With Shield, admins and developers can encrypt fields in standard and custom objects and unstructured content, such as files of any size, using an advanced HSM-based key derivation system. Shield\u2019s encryption supports search, validation rules, and workflows without intervening with the functionalities.<\/p>\n\n\n\n
- Event monitoring<\/strong><\/li><\/ul>\n\n\n\n
Shield brings richer functionality to event monitoring for large companies or those needing more complex auditing. Shield\u2019s event monitoring gives a more granular overview of user behavior and app performance. Admins can see the history of all their user logins, including the login methods used, and see all interactions, including who is accessing what, where, and when. <\/p>\n\n\n\n
- Field Audit Trail<\/strong><\/li><\/ul>\n\n\n\n
Field Audit Trail helps realize stringent audit requirements for a Salesforce org by tracking standard and custom objects. Admins can see the state and value of data going back up to 10 years across objects, accounts, cases, contacts, leads, and opportunities. They can select specific fields for field history tracking that will record the date, time, and who made the change to a particular field. Retaining archived history data helps organizations comply with industry regulations related to audit capability and data retention. Admins can also set triggers to receive notifications when somebody deletes specific data.<\/p>\n\n\n\n
Salesforce Shield also allows many Salesforce security policies to be automated.<\/p>\n\n\n\n
8. Perform regular backups<\/strong><\/p>\n\n\n\nRegular backups are necessary for protecting critical data and metadata and a quick and hassle-free recovery, should your data be compromised. <\/p>\n\n\n\n
For example, automated daily backups will ensure that employees can resume work with the most current data quickly after an incident.<\/p>\n\n\n\n
Salesforce\u2019s Enterprise, Performance, and Unlimited editions limit backups to once per week. This may be insufficient for some businesses. A third-party backup and recovery solution, such as Coupler.io, elastic.io, or SpinOne, may provide real-time incident alerts, pinpoint compromised data, and help restore your system after an incident.<\/p>\n\n\n\n
9. Invest in change monitoring tools<\/strong><\/p>\n\n\n\nIt\u2019s essential to track what users are doing with data and receive alerts if their actions are potentially harmful. When Salesforce environments are modified, it\u2019s also important to consider how these changes are documented and verified. It may be reasonable to invest in tools that can manage and monitor all users accessing data and all modifications to avoid misconfiguration.<\/p>\n\n\n\n
For example, DatAdvantage Cloud monitors access and activity, issues alarms on suspicious behavior, and identifies security posture issues or misconfigurations. SpinOne allows versioning to recover from previous snapshots and full reversion of your multiple Salesforce environments into earlier versions for data and metadata in several clicks. AppOmni can help you review the level of access of all your users from a single page.<\/p>\n\n\n\n
10. Implement password best practices<\/strong><\/p>\n\n\n\nSalesforce\u2019s default minimum for passwords is 8 symbols, but security experts now recommend at least 15. Salesforce offers six levels of complexity to choose from.<\/p>\n\n\n\n
Salesforce does not prevent users from adding their actual password to their security question, so make sure to enable the Cannot Contain Password setting. Also, disable caching and autocomplete on your Salesforce login page.<\/p>\n\n\n\n
The default password expiration setting is 90 days. If you opt for a shorter period, you need to turn on Salesforce\u2019s Enforce password history setting to prevent users from reusing passwords.<\/p>\n\n\n\n
11. Set trusted IP ranges<\/strong><\/p>\n\n\n\nAdmins can allow users to access their org instance only from the corporate network or VPN and prevent access from specific IP ranges. A trusted IP range includes safe or familiar IP addresses from which Salesforce users can log in. A company\u2019s trusted IP range usually includes office locations and other private networks that employees normally access. <\/p>\n\n\n\n
![\"\"](\"https:\/\/alternative-spaces.com\/blog\/wp-content\/uploads\/2022\/10\/73.webp\")
<\/figure><\/div>\n\n\n\nTo configure the trusted IP range feature, find Network Access in Setup and click on \u201cNew\u201d to create a new trusted IP range. In case of multiple trusted IP ranges, add informative descriptions to specify which range applies to which use case.<\/p>\n\n\n\n
Once a trusted IP range is set up, users who access Salesforce outside of that range are required to verify their identity. Login will require a security token \u2014 an alphanumeric key often used in conjunction with a user\u2019s password. <\/p>\n\n\n\n
For example, to access Salesforce via API, they need to append their security token to the end of their password. With MFA enabled, they will need to enter the password and then their security token. If it is unavailable, they must use the Salesforce authenticator app to generate a new one and send it to their email box. If a user uses a device outside your IP range, they will not be able to reset their security token.<\/p>\n\n\n\n
Admins can also define hours for usage and session-specific settings for logged-in users.<\/p>\n\n\n\n
12. Enable custom login flows<\/strong><\/p>\n\n\n\nAuthorized users occasionally may need to access your instance under unusual conditions, but it shouldn\u2019t create security risks for your business. Use custom login flows to put additional authentication steps in place for login attempts that seem suspicious. <\/p>\n\n\n\n
For example, suppose a user tries to log in from a restricted IP or out of regular working hours. You can set a flow to be triggered that would ask the user a secret question, notify an admin so they can validate or reject the login attempt, or require other actions for extra security.<\/p>\n\n\n\n
13. Track login history<\/strong><\/p>\n\n\n\nSalesforce provides a standard feature for tracking login history called \u201cNew Login Location Report.\u201d <\/p>\n\n\n\n
For example, suppose a salesperson is using an application like WorkBench, Browser, Data Loader, etc., to export leads. This could signal that they plan to quit and take leads and other confidential information with them.<\/p>\n\n\n\n
14. Pay special attention to data encryption<\/strong><\/p>\n\n\n\nMake sure to use platform encryption when a new tenant secret is generated. Also, make sure to destroy old encryption keys after data decryption.<\/p>\n\n\n\n
15. Use Salesforce Sandbox <\/strong><\/p>\n\n\n\nUse Sandbox for safer and simpler verification of untested or untrustworthy code. In an isolated test environment that mirrors production environments, you can experiment with different variables and test system changes before they go live. This will help you remove threats before they become a problem and prevent potentially malicious code from infiltrating your system.<\/p>\n\n\n\n
Some admins tend to delay installing security updates because they might impact the end-users\u2019 experience. Testing these updates in Sandbox will help you deploy these changes more confidently and timely.<\/p>\n\n\n\n
16. Stay updated<\/strong><\/p>\n\n\n\nMake sure that all devices accessing Salesforce should have the latest version of the OS, browser, and anti-malware software.<\/p>\n\n\n\n
As more users tend to work remotely, tightening Salesforce default user access settings and requirements may be reasonable.<\/p>\n\n\n\n
17. Implement a virus scanner<\/strong><\/p>\n\n\n\nUnsecured devices, communities, sites, attachment uploads, email-to-case, and other areas of entry create multiple Salesforce security vulnerabilities, whereas the platform doesn\u2019t have a native virus scanner solution in place. A third-party virus scanner app, such as EZProtect and its alternatives, may provide extra security.<\/p>\n\n\n\n
![\"\"](\"https:\/\/alternative-spaces.com\/blog\/wp-content\/uploads\/2022\/10\/Salesforce-Security-Best-Practices-and-Tips-1-1024x723.webp\")
<\/figure><\/div>\n\n\n\n18. Turn on Clickjack protection<\/strong><\/p>\n\n\n\nHackers can use clickjacking, i.e. luring a user into clicking a malicious link or button, to access and modify Salesforce instance data. Salesforce safeguards standard pages against clickjacking, but it never hurts to enable clickjack protection in your Session Settings to enhance the protection of customer Visualforce pages and setup and non-setup Salesforce pages.<\/p>\n\n\n\n
19. Implement Salesforce app development best practices<\/strong><\/p>\n\n\n\nSalesforce security guide empowers app developers to secure the apps and improve the cybersecurity of customers\u2019 databases on the platform. Some of the threats that require special attention are:<\/p>\n\n\n\n
1) Cross-site scripting (XSS).<\/strong> XSS attacks occur when malicious HTML or client-side scripting is provided to a web application, enabling attackers to take control of a web app user\u2019s session and execute malicious code. Some likely targets include bulletin boards or user comment-style websites, news, or email archives. Salesforce\u2019s Visualforce developer guide provides guidelines to restrict such scenarios during app development.<\/p>\n\n\n\n2) Cross-site request forgery (CSRF). <\/strong>A cyber criminal\u2019s web page contains an URL created with malicious intent. If a user logged into a valid web page visits the attacker’s web page, the URL is retrieved to perform the actions planned by the attacker. Visualforce guidelines for CSRF can help developers safeguard their code in these scenarios.<\/p>\n\n\n\n3) SOQL Injection.<\/strong> Bad guys can modify unvalidated user input in queries in the Salesforce database query language for malicious purposes. To secure code against SOQL attacks, developers should implement the defense mechanisms explained in Visualforce guidelines for SOQL Injection.<\/p>\n\n\n\n20. Educate your employees <\/strong><\/p>\n\n\n\nEven the FBI lists employee education as a way for businesses to protect themselves from cyber-attacks. <\/p>\n\n\n\n
Ensure employees\u2019 education on company policies regarding data usage, threats, and vulnerabilities. Share your organization\u2019s Salesforce security rules and action plan with all employees and other users, if applicable, to ensure that everyone understands how to use Salesforce safely.<\/p>\n\n\n\n
Employees must know how to spot a red flag, how to report abnormal activities within the organization, when they should inform managers, etc. Check when you last held employee training aimed at phishing prevention. Make sure the employees are updated regularly: remote employees often delay updating their software, devices, and best practices.<\/p>\n\n\n\n
<\/a>Final Words<\/h2>\n\n\n\nSalesforce is a robust and secure CRM platform with mandatory MFA, advanced encryption, a comprehensive and flexible data sharing model, and a notification system. However, it is up to each organization to evaluate its data management, put varied Salesforce security best practices in place, implement policies and technology that go above and beyond Salesforce\u2019s innate security controls when needed, and continuously update and monitor security systems.<\/p>\n\n\n\n
Unfortunately, IT and security teams are often overwhelmed with multiple competing priorities. That, combined with the complexity of Salesforce permission configurations, could jeopardize a company\u2019s data, customers\u2019 information, or other sensitive information, putting its business processes, reputation, and profitability at risk. <\/p>\n\n\n\n
We hope you found this article helpful and will be able to apply some tips to increase the security of your company\u2019s data. If you have questions, need a Salesforce security review, or want experienced developers to create a secure custom Salesforce application for you, please don\u2019t hesitate to contact Alternative-spaces!<\/p>\n\n\n\n
Our company has been developing products that run on the Salesforce platform for six years, the services including:<\/p>\n\n\n\n
- Application solution architecture<\/li>
- Full-cycle Salesforce app development<\/li>
- Salesforce migration<\/li>
- Post-release maintenance<\/li>
- Improving existing Salesforce applications<\/li>
- Salesforce consulting<\/li><\/ul>\n\n\n\n
Content created by our partner, Onix-systems.<\/p>\n","protected":false},"excerpt":{"rendered":"
If you are contemplating developing a customized solution that runs on Salesforce but don\u2019t know if it\u2019s secure enough, this article is for you. If you already have a Salesforce solution, you may still find it helpful: administrators and developers can adjust some settings better, use extra tools, and learn new tricks to enhance data security […]<\/p>\n","protected":false},"author":4,"featured_media":4439,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-4438","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/posts\/4438","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/comments?post=4438"}],"version-history":[{"count":2,"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/posts\/4438\/revisions"}],"predecessor-version":[{"id":4449,"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/posts\/4438\/revisions\/4449"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/media\/4439"}],"wp:attachment":[{"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/media?parent=4438"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/categories?post=4438"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/tags?post=4438"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Only in August 2022, IT Governance alone identified 112 security incidents that resulted in 97M compromised records<\/a>. The number of data breaches continues to grow yearly as more businesses go online, more employees work remotely, and bad guys become more inventive. Companies failing to implement sufficient cybersecurity protocols and safeguards risk facing severe consequences, such as revenue loss, non-compliance fines, legal fees, and loss of trust.<\/p>\n\n\n\n Salesforce, one of the biggest and most popular CRM platforms, stores not only gigabytes of customer data but also its customers\u2019 vital prospect lists, pricing and discounting details, sales pipelines, and often sensitive information. Understanding the potentially fatal impact of a successful Salesforce cyber-attack or careless actions by internal players, the SaaS provider takes great pains to keep its platform secure.<\/p>\n\n\n\n Read on to learn what Salesforce security best practices make it one of the safest CRM solutions and how admins and developers can ensure maximum data security. But let\u2019s start with an overview of risks and threats specific to the CRM platform.<\/p>\n\n\n\n Unfortunately, some Salesforce security vulnerabilities are rooted in the platform\u2019s advantages. <\/p>\n\n\n\n For example: <\/p>\n\n\n\n Not every third-party app you connect to Salesforce may be as safe as Salesforce itself. Integrated apps can potentially create unsecured doors into your instance and introduce new security risks. APIs can make your Salesforce org vulnerable to:<\/p>\n\n\n\n If a connected app is compromised, it could expose your internal Salesforce data. Granting access to a shady or unsecured API may lead to hacks, data breaches, and compliance issues.<\/p>\n\n\n\n Virtually any Salesforce user can be a lesser or greater insider threat based on their level of access to information housed on the cloud platform and ability to make changes. <\/p>\n\n\n\n For example, employees may share or extract sensitive data inadvertently or intentionally. An enabled “export” permission makes it easy for unscrupulous employees to steal information like leads or customer lists.<\/p>\n\n\n\n More and more CRM users that work remotely access Salesforce on personal devices, creating additional risks. <\/p>\n\n\n\n Common insider threats to Salesforce data include:<\/p>\n\n\n\n Misconfiguration is one of the biggest risks to cloud environments. Salesforce org security is often neglected in favor of configuration changes. Countless permission possibilities make it easy to leave valuable data exposed. Teams that don\u2019t know the ropes of the many Salesforce configurations risk missing critical gaps.<\/p>\n\n\n\n Contractors are among external users that are granted access to SF. According to the 2021 SaaS Risk Report by Varonis<\/a>, 75% of contractor identities remain active after they leave.<\/p>\n\n\n\n Salesforce opening its functionality for developers and social communities also opens up possibilities for security incidents. <\/p>\n\n\n\n Outsider attacks are a persistent threat too. For example, one Salesforce data breach affected over 200,000 customers of Hanna Andersson, a children\u2019s clothing company. Salesforce handled the customers\u2019 personal and payment information when they engaged in a sale.<\/p>\n\n\n\n From September 16 through November 11, 2019, the Salesforce network suffered a malware infiltration. Hackers were able to scrape consumer data, including credit card information and personal identifiers, from about 10,000 consumers. The hackers sold the data on the dark web and retained access to the database for several months before law enforcement found it out.<\/p>\n\n\n\n In 2020, a California resident filed a federal class action lawsuit against Salesforce and Hanna Andersson for negligence, declaratory relief, and violations under the California Unfair Competition Law. The complaint claimed that both companies failed to protect private data, failed to detect the data breach, employed inadequate security practices, and did not warn consumers about their deficient practices.<\/p>\n\n\n\n In 2021, Salesforce and Hanna Andersson agreed to pay $400,000 to resolve the lawsuit and offered identity theft protection services to the affected customers. Salesforce focused heavily on integrating monitoring systems to catch breaches early on.<\/p>\n\n\n\n Handling situations like these over two decades, Salesforce has amassed a vast knowledge of bad practices. Salesforce Trust<\/a> provides a transparent and real-time view of its security measures and updates on attacks that can affect its customers. The company has also developed a robust data security model and a comprehensive set of controls to secure each Salesforce org. <\/p>\n\n\n\n The primary cybersecurity best practices implemented by Salesforce include:<\/p>\n\n\n\n Salesforce requires all customers to use MFA when accessing Salesforce products. Users must confirm their identity with an authentication app on a mobile phone or a security key. MFA makes phishing attacks useless: if the bad guys obtain a user\u2019s credentials, they will not be able to use them without the user\u2019s smartphone, for example.<\/p>\n\n\n\n Every time a user enters their username and password, the platform creates a session cookie for them. Instead of storing the credentials data in it, Salesforce uses encoded session IDs. If somebody intercepts cookies from a user\u2019s browser, they won\u2019t be able to access the user\u2019s authentication data. The default session timeout, two hours of inactivity, also contributes to security.<\/p>\n\n\n\n An automatic system within Salesforce promptly notifies customers of potentially dangerous actions of its users, such as weak passwords or insecure settings, and suspicious processes involving their data. The change logging feature can track multiple event types and allows admins to view, filter, and download event logs through the Event Log File Browser. If something goes wrong, the platform will alarm both the customer and Salesforce cybersecurity personnel to fix the problem.<\/p>\n\n\n\n Salesforce customers typically have dozens or hundreds of employees with different responsibilities. The multi-layered data security model in Salesforce enables administrators and app developers to manage these employees\u2019 access to information from an org perspective down to an individual record. This means not only a better user experience but also error reduction and greater safety: if a user\u2019s account is compromised, intruders won\u2019t go further than information open to that user.<\/p>\n\n\n\n The three key constructs related to data in Salesforce include:<\/p>\n\n\n\n Salesforce secures access to these data sets on three levels:<\/p>\n\n\n\n Layer 1: Object-level security<\/strong><\/p>\n\n\n\n Two configurations help manage object-level access: Profiles and Permission Sets. Each user is assigned a profile, where the admin (the person with principal administrative rights in the organization) allows minimum access to data needed for a particular job role and configures things like login IP restrictions. Admin can grant further access and abilities to the user through multiple permission sets.<\/p>\n\n\n\n For example, the admin may allow a salesperson to see only a specific object they work with, while their manager will have the right to view all objects and create new ones. The admin can issue and take away these permissions from users at any level at any time. <\/p>\n\n\n\n Layer 2: Field-level security<\/strong><\/p>\n\n\n\n Profiles and permission sets also control field-level access. Admins can provide read and write permissions for individual fields within an object. When an admin hides a field from a user, it means the user will not be able to access it. A field hidden with field-level security will not be accessible through any entry points, including APIs.<\/p>\n\n\n\n Layer 3: Record-level security, aka Salesforce sharing model or record sharing<\/strong><\/p>\n\n\n\n There are five ways for users to share records and access other users\u2019 records. After configuring org-wide defaults to lock down their data, they can use other record-level security tools to open records to selected users as needed.<\/p>\n\n\n\n The record-level security tools include:<\/p>\n\n\n\n 1) Organization-wide sharing defaults (OWD). <\/strong>Every record has a field called \u201cOwnerId\u201d that refers to a real user, usually the person who created the record and has full create, read, update, and delete access to it. OWD control the default behavior of users regarding access to a record they don\u2019t own. OWD must be either public read-only or private to create sharing rules.<\/p>\n\n\n\n 2) Role hierarchies.<\/strong> Different job roles have different record access requirements. Users with a higher role usually need and can access records to which users in lower roles have access. To use this upward sharing rule, an administrator has to add a user to a higher role and then grant access.<\/p>\n\n\n\n 3) Sharing rules. <\/strong>If users need to share records they own laterally, e.g., with their teammates, sharing rules apply that extend sharing access to groups, roles, or individuals. They enable record sharing laterally and in an ad-hoc fashion via public groups:<\/p>\n\n\n\n a) Ownership-based sharing rules<\/strong> let admins share records based on role, role-and-subordinate, and public group ownership. These rules allow for exceptions to OWD and the role hierarchy that give a user access to records they don\u2019t hold. Owner-based sharing rules are limited to 300 per organization.<\/p>\n\n\n\n b) Criteria-based sharing rules<\/strong> open access to a record based on the value of a field in it, irrespective of who owns the record. If one or multiple criteria are met, records are shared with an eligible individual or group. An organization can have up to 50 such rules.<\/p>\n\n\n\n c)Guest user sharing rule<\/strong> that grants access to records to an unauthenticated user using sharing settings is seldom used because it is not recommended to expose data to such users. <\/p>\n\n\n\n 4) Manual sharing.<\/strong> If a record\u2019s OWD is private or public read-only, end-users can share it with others manually. This permission is available through the Sharing button on the record details page. If the ownership of a shared record changes, all users whom the original owner had granted access will lose it. <\/p>\n\n\n\n 5) Apex managed sharing. <\/strong>In cases when records can\u2019t be shared via UI or settings, developers can write Apex code to do so programmatically. It can be used only when a record\u2019s OWD is set as private or public read-only.<\/p>\n\n\n\n Two types of encryption are available \u2014 for standard and premium subscriptions \u2014 allowing to encrypt most data stored on the platform. Salesforce provides encryption whenever data travels to and from the platform. The encrypted connection prevents Salesforce data from being exposed when you export it.<\/p>\n\n\n\n Salesforce stores user data using multiple active clusters. The database is hosted on carrier-class storage that may need only a few minutes of downtime per year. If one data center goes offline or a server breaks, all data will still be accessible. Moreover, data can be backed up weekly or monthly for greater security.<\/p>\n\n\n\n The best practices for Salesforce security are not implemented only on the CRM\u2019s side. Customers need to keep the shared responsibility in mind: Salesforce secures the cloud platform, but once a company inputs its data, it\u2019s up to them to protect it with an extra layer of security beyond what Salesforce provides.<\/p>\n\n\n\n Administrators can activate and adjust many tools, settings, and parameters to make their instances more secure. Here are Salesforce security tips to help minimize external threats and breaches caused by employee error or malicious intent. <\/p>\n\n\n\n If we were to rank the methods, our first advice would be: start with your Salesforce Health Check<\/strong>.<\/p>\n\n\n\n The Salesforce Security Health Check tool lets administrators thoroughly assess their instance\u2019s well-being by scanning the settings that ensure its safety. Having identified possible risks and vulnerabilities, the admin can fix the issues and even improve their instance\u2019s security with one click, all from one page.<\/p>\n\n\n\n You can start Health Check by searching for it in the Quick Find box of your Setup page or heading over to Security > Health Check.<\/p>\n\n\n\n Next, in the Baseline dropdown, choose the Salesforce Baseline Standard or a custom Baseline. This means you can run the check either against the settings for different risk levels recommended by Salesforce or against a customized Baseline. In the latter case, Security Health Check allows adding up to five custom Baselines to make the check as rigorous as needed or make the settings less restrictive than the Baseline selected.<\/p>\n\n\n\n For example, if your healthcare organization handles sensitive data and Personally Identifiable Information, you can add a custom Baseline about GDPR standards<\/a>.<\/p>\n\n\n\n You can create a custom Baseline as follows:<\/p>\n\n\n\n 1. Click on \u201cExport Baseline\u201d in the Baseline Controls Menu.<\/p>\n\n\n\n 2. Use a text editor to edit the exported XML file. When making adjustments in the risk categories, make sure not to add or delete risk categories, names, and even quotation marks: it would lead to import failure. Some specific setting values cannot be modified, and moving a security setting to the Informational category means removing it from the Health Check score calculation.<\/p>\n\n\n\n 3. Click on \u201cImport Baseline\u201d in the Baseline Controls Menu to save and import the XML file. <\/p>\n\n\n\n 4. Enter your custom Baseline\u2019s name in the dialog box that opens.<\/p>\n\n\n\n 5. Assign your custom Baseline a unique API name without any spaces or special characters.<\/p>\n\n\n\n 6. Set the new custom Baseline as the default Baseline for your Salesforce security review, if you want. It will appear in the dropdown once the import is completed.<\/p>\n\n\n\n So, after you click on the Baseline dropdown and select the desired Baseline, Security Health Check would run the scan, produce a health score, and give recommendations on addressing weaknesses.<\/p>\n\n\n\n The tool uses a proprietary formula to assess the compliance of your instance\u2019s security settings with Salesforce Baseline Standard or a customized Baseline. Your org\u2019s health can be scored through the following percentages:<\/p>\n\n\n\n The more restrictive your settings, the higher the score will be.<\/p>\n\n\n\n Security Health Check divides any discovered vulnerabilities into four classes: high-risk, medium-risk, low-risk, and Informational Security Settings. Within each section, settings to review will also be categorized as \u201cCritical,\u201d \u201cWarning,\u201d and \u201cCompliant.\u201d This will give you a prioritized checklist of items to review and fix.<\/p>\n\n\n\n For example, Salesforce Baseline Standard limits invalid login attempts to three. If your instance\u2019s settings allow more, Health Check will flag a high-risk vulnerability, advise you to mitigate the risk, and create a shortcut for the necessary modification.<\/p>\n\n\n\n Other settings Health Check might flag include:<\/p>\n\n\n\n The types of recommendations include:<\/p>\n\n\n\n Click on \u201cFix Risks\u201d to start adjusting your settings.<\/p>\n\n\n\n Occasionally, you wouldn\u2019t want to adjust your settings to match Salesforce\u2019s recommendations. For example, Salesforce recommends disabling the option to log in as another user. However, if you often do it when troubleshooting issues, you would want it enabled.<\/p>\n\n\n\n Just like humans periodically undergo health checkups even when there are no perceptible risks, admins should undertake a security health check for Salesforce instances on a regular schedule, e.g., monthly or quarterly. Salesforce regularly updates its Baseline Standard to adapt to new threats and changes in best practices, and the platform itself is updated three times per year. Industry standards also change, and so do your organization\u2019s security requirements.<\/p>\n\n\n\n 1. Identify your Salesforce security responsibilities, vulnerabilities, and misconfigurations<\/strong><\/p>\n\n\n\n Understanding what data you have in the CRM system and identifying misconfigurations are essential to strengthening your org\u2019s security. It\u2019s also crucial to understand which security tasks are handled by Salesforce and which are your security team\u2019s responsibility. <\/p>\n\n\n\n It may help to review your internal processes to see if you can adjust a process to meet Salesforce standards instead of overly customizing the CRM platform to fit your processes. For example, Alternative-spaces specialists can help you identify and fix misconfigurations, incorrect permissions, data exposures in your Salesforce environment, and other potential issues with Salesforce data security.<\/p>\n\n\n\n Suppose you feel that the Salesforce Security Health Check is insufficient for your needs and that your company\u2019s security policy requires more robust customizable capabilities. In that case, you may reinforce your security strategy with third-party solutions. For example, OwnBackup Secure allows automation of the remediation of identified misconfigurations with detailed action plans and real-time alerts.<\/p>\n\n\n\n 2. Be super-cautious with permissions<\/strong><\/p>\n\n\n\n Sometimes, admins initially provide users with broad access to objects and fields and later try to hide some data by limiting fields\u2019 visibility for individual profiles. However, hiding a field does not cancel a user\u2019s underlying access. They may still access the information by creating a report or through a data export. Integrated apps may also view info within hidden fields.<\/p>\n\n\n\n The recommended approach is to control access by granting permissions to objects and fields to specific profiles or users. Follow the principle of least privilege: users, including APIs, should have access only to the bare minimum of information necessary to do their job.<\/p>\n\n\n\n Allow users the least privilege level and selectively grant higher privileges as needed on a case-to-case basis. Refrain from using the permissions to \u201cview all\u201d or \u201cmodify all\u201d within profiles. Be extra careful with \u201cexport\u201d permissions. <\/p>\n\n\n\n Keep the number of ownership-based sharing rules to 100 per object and the number of criteria-sharing rules to 50 per object.<\/p>\n\n\n\n Ensure that your Salesforce security team can audit privileged users and is notified when changes are made. <\/p>\n\n\n\n Don\u2019t forget about external users. Any org that runs a community should review its external sharing and security model, including that of guest users, and take extra care to lockdown records, objects, and permissions. Audit your configuration and check whether authenticated and unauthenticated community users can access only what you want them to. If possible, enforce authenticated access on your communities.<\/p>\n\n\n\n Admins should review and revalidate permissions over time, including inactive accounts. For example, they must properly offboard contractors once the cooperation is over.<\/p>\n\n\n\n 3. Install apps for specific profiles<\/strong><\/p>\n\n\n\n When installing an app or package, you can select to \u201cInstall for Admins Only,\u201d \u201cInstall for Specific Profiles,\u201d or \u201cInstall for All Users\u201d (i.e. opening access to Salesforce for partners, vendors, contractors, and everyone else in your Salesforce environment).<\/p>\n\n\n\n Once access is granted, you would have to remove users\u2019 permissions manually when needed. The more secure approach is to install the app only for specific profiles with the default \u201cno access\u201d for all users and then add additional profiles and users whenever necessary.<\/p>\n\n\n\n 4. Secure data within packages during installation<\/strong><\/p>\n\n\n\n When installing packages, users can select from several settings: \u201cManaged\u201d or \u201cUnmanaged,\u201d and \u201cPublic\u201d or \u201cProtected.\u201d<\/p>\n\n\n\n The \u201cManaged\u201d option allows creating a unique \u201cCustom Namespace\u201d for your package to store any components, Visualforce pages, classes, or credentials belonging to the package. The \u201cUnmanaged\u201d setting keeps those items in the default or local Namespace.<\/p>\n\n\n\n The \u201cPublic\u201d setting provides access to the data within the package to any user. The \u201cProtected\u201d setting limits access to the users and components within the Namespace.<\/p>\n\n\n\n The optimal method is to set the package to \u201cManaged\u201d and \u201cProtected.\u201d<\/p>\n\n\n\n 5. Secure your APIs<\/strong><\/p>\n\n\n\n Before giving access to any API you connect to Salesforce, look into its security model. This applies to any third-party integrations, such as marketing automation, computer telephony integrations, data enrichment tools, and even your own custom API work. <\/p>\n\n\n\n Treat any API that accesses your Salesforce instance like any other user. The admin must be able to control what it can and can\u2019t do. You may create a dedicated integration user \u2014 a Salesforce license not used by any human but intended solely for that API with its own profile and permission sets. Then you can enable permissions for specific roles and enforce them as \u201cAPI only,\u201d ensuring the integration can\u2019t access your instance in any other way and view or modify data it shouldn\u2019t.<\/p>\n\n\n\n Assign them only \u201cread\u201d access, unless otherwise is necessary, and enforce the same password-level policies and location-specific restrictions as for other roles in your Salesforce org. It makes sense to require more robust passwords for integration users: at least 20 random characters, including upper- and lowercase letters, digits, and special symbols.<\/p>\n\n\n\n You can also restrict the API\u2019s access to your Salesforce instance so that it can log in only from its own partner or vendor\u2019s servers. <\/p>\n\n\n\n When configuring integrations, developers often use unencrypted HTTP for testing and troubleshooting. When insecure HTTP is not disabled, sensitive information can be exposed to outsiders. Other parties may read and store records within the unencrypted API calls, including login credentials or an OAuth token. None of your integrations should have \u201cDisable Protocol Security\u201d selected. You can configure this setting under Setup > Remote Site Settings > select Details for a specific endpoint.<\/p>\n\n\n\n You also need to log the integration users\u2019 behavior, conduct regular audits, review them periodically, and revoke access to dormant apps.<\/p>\n\n\n\n 6. Enable App Allowlisting<\/strong><\/p>\n\n\n\n Users may also create vulnerabilities by giving solutions access to SF. Suppose an employee allows a messenger access to Salesforce to receive notifications about Opportunities, unaware that this violates the organization\u2019s GDPR or HIPAA compliance.<\/a> It could take days to months to spot this issue and fix it.<\/p>\n\n\n\n Enable App Allowlisting in the org to prevent such situations. It lets admins specify to which apps users can and cannot grant access. They can manage user authorization at the org-wide level (all users) or for specific users and apply the same limitations to new users.<\/p>\n\n\n\n To enable App Allowlisting in your org, the admin must submit a case or call Salesforce. After it has enabled the feature, the admin can assign specific profiles and permission sets access to specific apps:<\/p>\n\n\n\n 7. Use Salesforce Shield<\/strong><\/p>\n\n\n\n Suppose you need to go beyond the standard security measures provided by Salesforce and bolster your business-critical app. It\u2019s especially relevant in the financial and healthcare domains, with additional layers of security to comply with privacy policy, regulatory requirements, and contractual obligations. In that case, you may strengthen organization-level access with Salesforce Shield. <\/p>\n\n\n\n The instrument includes three main features:<\/p>\n\n\n\n With Shield, admins and developers can encrypt fields in standard and custom objects and unstructured content, such as files of any size, using an advanced HSM-based key derivation system. Shield\u2019s encryption supports search, validation rules, and workflows without intervening with the functionalities.<\/p>\n\n\n\n Shield brings richer functionality to event monitoring for large companies or those needing more complex auditing. Shield\u2019s event monitoring gives a more granular overview of user behavior and app performance. Admins can see the history of all their user logins, including the login methods used, and see all interactions, including who is accessing what, where, and when. <\/p>\n\n\n\n Field Audit Trail helps realize stringent audit requirements for a Salesforce org by tracking standard and custom objects. Admins can see the state and value of data going back up to 10 years across objects, accounts, cases, contacts, leads, and opportunities. They can select specific fields for field history tracking that will record the date, time, and who made the change to a particular field. Retaining archived history data helps organizations comply with industry regulations related to audit capability and data retention. Admins can also set triggers to receive notifications when somebody deletes specific data.<\/p>\n\n\n\n Salesforce Shield also allows many Salesforce security policies to be automated.<\/p>\n\n\n\n 8. Perform regular backups<\/strong><\/p>\n\n\n\n Regular backups are necessary for protecting critical data and metadata and a quick and hassle-free recovery, should your data be compromised. <\/p>\n\n\n\n For example, automated daily backups will ensure that employees can resume work with the most current data quickly after an incident.<\/p>\n\n\n\n Salesforce\u2019s Enterprise, Performance, and Unlimited editions limit backups to once per week. This may be insufficient for some businesses. A third-party backup and recovery solution, such as Coupler.io, elastic.io, or SpinOne, may provide real-time incident alerts, pinpoint compromised data, and help restore your system after an incident.<\/p>\n\n\n\n 9. Invest in change monitoring tools<\/strong><\/p>\n\n\n\n It\u2019s essential to track what users are doing with data and receive alerts if their actions are potentially harmful. When Salesforce environments are modified, it\u2019s also important to consider how these changes are documented and verified. It may be reasonable to invest in tools that can manage and monitor all users accessing data and all modifications to avoid misconfiguration.<\/p>\n\n\n\n For example, DatAdvantage Cloud monitors access and activity, issues alarms on suspicious behavior, and identifies security posture issues or misconfigurations. SpinOne allows versioning to recover from previous snapshots and full reversion of your multiple Salesforce environments into earlier versions for data and metadata in several clicks. AppOmni can help you review the level of access of all your users from a single page.<\/p>\n\n\n\n 10. Implement password best practices<\/strong><\/p>\n\n\n\n Salesforce\u2019s default minimum for passwords is 8 symbols, but security experts now recommend at least 15. Salesforce offers six levels of complexity to choose from.<\/p>\n\n\n\n Salesforce does not prevent users from adding their actual password to their security question, so make sure to enable the Cannot Contain Password setting. Also, disable caching and autocomplete on your Salesforce login page.<\/p>\n\n\n\n The default password expiration setting is 90 days. If you opt for a shorter period, you need to turn on Salesforce\u2019s Enforce password history setting to prevent users from reusing passwords.<\/p>\n\n\n\n 11. Set trusted IP ranges<\/strong><\/p>\n\n\n\n Admins can allow users to access their org instance only from the corporate network or VPN and prevent access from specific IP ranges. A trusted IP range includes safe or familiar IP addresses from which Salesforce users can log in. A company\u2019s trusted IP range usually includes office locations and other private networks that employees normally access. <\/p>\n\n\n\n To configure the trusted IP range feature, find Network Access in Setup and click on \u201cNew\u201d to create a new trusted IP range. In case of multiple trusted IP ranges, add informative descriptions to specify which range applies to which use case.<\/p>\n\n\n\n Once a trusted IP range is set up, users who access Salesforce outside of that range are required to verify their identity. Login will require a security token \u2014 an alphanumeric key often used in conjunction with a user\u2019s password. <\/p>\n\n\n\n For example, to access Salesforce via API, they need to append their security token to the end of their password. With MFA enabled, they will need to enter the password and then their security token. If it is unavailable, they must use the Salesforce authenticator app to generate a new one and send it to their email box. If a user uses a device outside your IP range, they will not be able to reset their security token.<\/p>\n\n\n\n Admins can also define hours for usage and session-specific settings for logged-in users.<\/p>\n\n\n\n 12. Enable custom login flows<\/strong><\/p>\n\n\n\n Authorized users occasionally may need to access your instance under unusual conditions, but it shouldn\u2019t create security risks for your business. Use custom login flows to put additional authentication steps in place for login attempts that seem suspicious. <\/p>\n\n\n\n For example, suppose a user tries to log in from a restricted IP or out of regular working hours. You can set a flow to be triggered that would ask the user a secret question, notify an admin so they can validate or reject the login attempt, or require other actions for extra security.<\/p>\n\n\n\n 13. Track login history<\/strong><\/p>\n\n\n\n Salesforce provides a standard feature for tracking login history called \u201cNew Login Location Report.\u201d <\/p>\n\n\n\n For example, suppose a salesperson is using an application like WorkBench, Browser, Data Loader, etc., to export leads. This could signal that they plan to quit and take leads and other confidential information with them.<\/p>\n\n\n\n 14. Pay special attention to data encryption<\/strong><\/p>\n\n\n\n Make sure to use platform encryption when a new tenant secret is generated. Also, make sure to destroy old encryption keys after data decryption.<\/p>\n\n\n\n 15. Use Salesforce Sandbox <\/strong><\/p>\n\n\n\n Use Sandbox for safer and simpler verification of untested or untrustworthy code. In an isolated test environment that mirrors production environments, you can experiment with different variables and test system changes before they go live. This will help you remove threats before they become a problem and prevent potentially malicious code from infiltrating your system.<\/p>\n\n\n\n Some admins tend to delay installing security updates because they might impact the end-users\u2019 experience. Testing these updates in Sandbox will help you deploy these changes more confidently and timely.<\/p>\n\n\n\n 16. Stay updated<\/strong><\/p>\n\n\n\n Make sure that all devices accessing Salesforce should have the latest version of the OS, browser, and anti-malware software.<\/p>\n\n\n\n As more users tend to work remotely, tightening Salesforce default user access settings and requirements may be reasonable.<\/p>\n\n\n\n 17. Implement a virus scanner<\/strong><\/p>\n\n\n\n Unsecured devices, communities, sites, attachment uploads, email-to-case, and other areas of entry create multiple Salesforce security vulnerabilities, whereas the platform doesn\u2019t have a native virus scanner solution in place. A third-party virus scanner app, such as EZProtect and its alternatives, may provide extra security.<\/p>\n\n\n\n 18. Turn on Clickjack protection<\/strong><\/p>\n\n\n\n Hackers can use clickjacking, i.e. luring a user into clicking a malicious link or button, to access and modify Salesforce instance data. Salesforce safeguards standard pages against clickjacking, but it never hurts to enable clickjack protection in your Session Settings to enhance the protection of customer Visualforce pages and setup and non-setup Salesforce pages.<\/p>\n\n\n\n 19. Implement Salesforce app development best practices<\/strong><\/p>\n\n\n\n Salesforce security guide empowers app developers to secure the apps and improve the cybersecurity of customers\u2019 databases on the platform. Some of the threats that require special attention are:<\/p>\n\n\n\n 1) Cross-site scripting (XSS).<\/strong> XSS attacks occur when malicious HTML or client-side scripting is provided to a web application, enabling attackers to take control of a web app user\u2019s session and execute malicious code. Some likely targets include bulletin boards or user comment-style websites, news, or email archives. Salesforce\u2019s Visualforce developer guide provides guidelines to restrict such scenarios during app development.<\/p>\n\n\n\n 2) Cross-site request forgery (CSRF). <\/strong>A cyber criminal\u2019s web page contains an URL created with malicious intent. If a user logged into a valid web page visits the attacker’s web page, the URL is retrieved to perform the actions planned by the attacker. Visualforce guidelines for CSRF can help developers safeguard their code in these scenarios.<\/p>\n\n\n\n 3) SOQL Injection.<\/strong> Bad guys can modify unvalidated user input in queries in the Salesforce database query language for malicious purposes. To secure code against SOQL attacks, developers should implement the defense mechanisms explained in Visualforce guidelines for SOQL Injection.<\/p>\n\n\n\n 20. Educate your employees <\/strong><\/p>\n\n\n\n Even the FBI lists employee education as a way for businesses to protect themselves from cyber-attacks. <\/p>\n\n\n\n Ensure employees\u2019 education on company policies regarding data usage, threats, and vulnerabilities. Share your organization\u2019s Salesforce security rules and action plan with all employees and other users, if applicable, to ensure that everyone understands how to use Salesforce safely.<\/p>\n\n\n\n Employees must know how to spot a red flag, how to report abnormal activities within the organization, when they should inform managers, etc. Check when you last held employee training aimed at phishing prevention. Make sure the employees are updated regularly: remote employees often delay updating their software, devices, and best practices.<\/p>\n\n\n\n Salesforce is a robust and secure CRM platform with mandatory MFA, advanced encryption, a comprehensive and flexible data sharing model, and a notification system. However, it is up to each organization to evaluate its data management, put varied Salesforce security best practices in place, implement policies and technology that go above and beyond Salesforce\u2019s innate security controls when needed, and continuously update and monitor security systems.<\/p>\n\n\n\n Unfortunately, IT and security teams are often overwhelmed with multiple competing priorities. That, combined with the complexity of Salesforce permission configurations, could jeopardize a company\u2019s data, customers\u2019 information, or other sensitive information, putting its business processes, reputation, and profitability at risk. <\/p>\n\n\n\n We hope you found this article helpful and will be able to apply some tips to increase the security of your company\u2019s data. If you have questions, need a Salesforce security review, or want experienced developers to create a secure custom Salesforce application for you, please don\u2019t hesitate to contact Alternative-spaces!<\/p>\n\n\n\n Our company has been developing products that run on the Salesforce platform for six years, the services including:<\/p>\n\n\n\n Content created by our partner, Onix-systems.<\/p>\n","protected":false},"excerpt":{"rendered":" If you are contemplating developing a customized solution that runs on Salesforce but don\u2019t know if it\u2019s secure enough, this article is for you. If you already have a Salesforce solution, you may still find it helpful: administrators and developers can adjust some settings better, use extra tools, and learn new tricks to enhance data security […]<\/p>\n","protected":false},"author":4,"featured_media":4439,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-4438","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/posts\/4438","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/comments?post=4438"}],"version-history":[{"count":2,"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/posts\/4438\/revisions"}],"predecessor-version":[{"id":4449,"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/posts\/4438\/revisions\/4449"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/media\/4439"}],"wp:attachment":[{"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/media?parent=4438"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/categories?post=4438"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alternative-spaces.com\/blog\/wp-json\/wp\/v2\/tags?post=4438"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}<\/a>Salesforce Security Breach Risks<\/h2>\n\n\n\n
Primary Salesforce Data Security Best Practices<\/h2>\n\n\n\n
1. Multi-factor authentication (MFA)<\/h3>\n\n\n\n
<\/figure><\/div>\n\n\n\n2. Authentication data security<\/h3>\n\n\n\n
3. Event monitoring<\/h3>\n\n\n\n
4. A comprehensive and flexible data-sharing model<\/h3>\n\n\n\n
<\/figure><\/div>\n\n\n\n5. Data encryption<\/h3>\n\n\n\n
6. Data storage and backup<\/h3>\n\n\n\n
<\/figure><\/div>\n\n\n\n<\/a>How to Run a Security Health Check for Salesforce Instances<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n\n<\/figure><\/div>\n\n\n\n<\/a>20 More Tips for Greater Data Security in Salesforce Organizations<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n\n<\/figure><\/div>\n\n\n\n<\/a>Final Words<\/h2>\n\n\n\n