Professional Documents
Culture Documents
Salesforce - CRM Security Audit Guide
Salesforce - CRM Security Audit Guide
W HITEPAP ER
Contents
Introduction ..................................................................................................................................... 1
Background ..................................................................................................................................... 1
Data Privacy..................................................................................................................................... 4
Profiles............................................................................................................................................................... 4
Auditing Profiles ............................................................................................................................................ 5
Field-Level Security............................................................................................................................................ 6
Field-Level Security by Profile ....................................................................................................................... 6
Field-Level Security by Object ....................................................................................................................... 7
Sharing Settings................................................................................................................................................. 7
Default Sharing Model ................................................................................................................................... 7
Sharing Rules................................................................................................................................................ 8
Roles............................................................................................................................................................. 8
Defaults and Recommendations.................................................................................................................... 8
References ..................................................................................................................................... 12
W HITEPAP ER
Introduction
The Salesforce CRM applications include settings and features that work together to protect your
data. As an information technology or information security executive responsible for data privacy,
you need to understand how salesforce.com helps to secure your data. Several features and
settings are enabled by default; others require specific actions from your Salesforce CRM
administrator. If the administrator does not change the default configuration, every user has full
access to all data.
This paper is an auditing and configuration guide to some of the most important settings within the
Salesforce application. It is intended to be a hands-on companion to the more general security
overview white paper, Salesforce CRM Security for the IT Executive. In this guide, we provide
specific recommendations for enhancing the security of your Salesforce organization.
For organizations concerned with protecting the data stored within Salesforce, we recommend
implementing the configuration changes detailed in this paper. Further details can be found in the
Security Implementation Guide
(https://na1.salesforce.com/help/doc/en/salesforce_security_impl_guide.pdf)
Background
Although this paper primarily focuses on application-specific features and configuration settings
of Salesforce CRM, salesforce.coms overall security strategy includes a combination of technical
infrastructure controls and a strong security governance framework. Our defense-in-depth strategy
includes security policies and procedures, infrastructure controls, and secure application
development and architectures.
Information security at salesforce.com is governed by a comprehensive information security
management system. Salesforce.com continues to undergo SAS/70 Type II and SysTrust audits,
and it received an ISO27001 certification from BSI in April 2008. The company performs
background checks on all employees; the entire company also completes regular security
awareness training sessions.
To ensure the highest level of data protection, salesforce.coms IT infrastructure includes a host of
enhancements. All production servers use hardened UNIX/Linux operating systems; additional
measures include centralized logging and alerting, intrusion detection, network access control,
anti-virus/anti-malware, host-based firewalls, and data loss prevention tools. The core production
servers are further protected by Juniper stateful firewalls, Cisco perimeter and core routers, and F5
load balancers. These servers are managed via bastion hosts that require two-factor authentication
to access.
The application development lifecycle was also designed with an emphasis on information
security. Every salesforce.com developer is trained on secure coding techniques, and every feature
requires a security review to be released into production. Both internal staff and third-party
security experts regularly perform security assessments.
Salesforce.com provides strong defense-in-depth strategies and technologies to protect our
customers data. We also provide application-specific features and settings to further protect your
Salesforce CRM deployment. You can ensure the ultimate security with a combination of your
own security-related configuration settings and salesforce.coms features, policies, and
technologies. The remainder of this paper focuses on the steps you can take to ensure the security
of your Salesforce CRM deployment.
Security and Compliance Related Settings
The Salesforce CRM application includes many security-related configuration settings. This
section summarizes some of the most important, including password settings, session settings, and
login and authorization settings. Consider the default settings as a baseline starting point for
security.
Note: Companies that have used Salesforce CRM for several years should be aware that previous
default settings were much less restrictive than the current defaults. Moreover, your administrators
may have modified several of the security-related parameters.
Password Settings
Password complexity and expiration settings within Salesforce CRM should be configured to
comply with your internal policies. Note that the default settings may not be appropriate for
companies with stronger security policies. These default settings also do not meet the
requirements of the Payment Card Industry Data Security Standards (PCI-DSS).
Audit and Recommendation
The available password settings include items such as expiration timers, history and complexity
restrictions, invalid lockout attempts, and lockout timers. To view password settings, click Setup
Security Controls Password Policies.
The following settings are available as of Salesforce Spring 09 and the current defaults are noted.
Our recommended settings are highlighted in bold. Note that previous versions of Salesforce
had different default settings.
Setting Name Description Options
User passwords Frequency to automatically expire passwords 30 days
expire in 60 days
90 days (default)
One Year
Never
Enforce password How many previous passwords to save to prevent password No passwords remembered
history re-use 3 passwords remembered
(default)
5 passwords remembered
Minimum password Minimum length of a password 5 characters
length 8 characters (default)
10 characters
Password complexity Should the password contain a mix of letters and numbers. If No restriction
requirement enabled, the password must contain at least one letter and Must mix alpha and numeric
one number. (default)
Password question Require the users password hint to not contain the password None
requirement Cannot contain password
(default)
Maximum invalid login How many bad logins are allowed before locking out the 3
attempts account 5
10 (default)
No Limit
Lockout effective How long should an account remain locked out 15 minutes (default)
period 30 minutes
60 minutes
Forever (must be reset by admin)
Session Settings
Several settings can be used to place restrictions on active user sessions. These include
configuring the idle session timeout, locking sessions to the IP address used at login, and requiring
secure (HTTPS) connections. Many of the default settings should be modified to improve security.
In particular, note that the default idle session timeout value is 2 hours and should be lowered for
most customers.
To view session settings, click Setup Security Controls Session Settings
Audit and Recommendation
The following settings are available as of Salesforce Spring 09 and the current defaults are noted.
Our recommended settings are highlighted in bold. Note that previous versions of Salesforce
had different default settings.
Setting Name Description Options
Timeout value Idle session time to automatically log user out of Salesforce 15 minutes
30 minutes
1 hour
2 hours (default)
4 hours
8 hours
Disable session timeout Disable the warning browser pop-up when a user is about to be Yes
warning popup logged out from the idle session timeout No (Default)
Lock sessions to the IP Force the user session to remain locked to the IP address from which Yes, if possible
address from which they the user authenticated. This setting helps prevent session hijacking No (Default)
origination but will also prevent the installation of most AppExchange packages.
Require secure connections Require HTTPS on all page requests. Yes (Default)
(https) No
Enable caching and Allow the users browser to store and auto-complete usernames or Yes (Default)
autocomplete on login page passwords after first login. No
When users attempt to log in to Salesforce CRM via the Web API or a client such as Force.com
Connect for Microsoft Outlook, the user login is verified against time-of-day restrictions and IP
address restrictions. If IP address restrictions are used, the Identity Confirmation feature, as
described here, is not used because of the enhanced protection already provided by IP address
restrictions.
If IP address restrictions are not used, Salesforce CRM checks whether the users browser or
current IP address was previously used to log in to Salesforce CRM. This check is performed by
looking for the presence of a certain cookie that is created during a successful login and by
referencing an internally stored list of IP addresses from previous successful logins by this user.
If the browser has the cookie or is using a previously known IP address, the login proceeds. If the
cookie is not present and the connection is coming from a new IP address, the user is directed to a
special screen and prompted to click a Send Activation Link button, which sends an activation
email to the address on record for the users account. This email contains a link for activating the
browser.
Data Privacy
Data privacy, or access to your data, is controlled by several features. At the core of data privacy
is your default sharing model, which consists of the default settings that control access to standard
and custom objects. These default settings can be extended with custom sharing rules, profile
settings, and role hierarchies. In addition, you can place restrictions on individual fields on a
particular record. The following sections will provide an introduction to these parameters and
highlight important considerations.
Auditing for access to data within Salesforce CRM can become very confusing since several
factors must be considered at once. Access to Salesforce CRM data is determined by a
combination of Profiles, Field-Level Security, and Sharing Settings as described below.
More details regarding auditing for data privacy can be found in the Salesforce CRM Security
Audit Guide and in the sharing cheat sheet at
https://na1.salesforce.com/help/doc/en/salesforce_sharing_cheatsheet.pdf.
Because several settings are possible to restrict access to sensitive data, you should consider the
various options and implement a consistent approach. One of the most effective strategies is to use
a combination of profiles and roles. The profiles define the classes of users and the number of
profiles should be kept as low as possible. Roles should be defined and mapped to your
organization structure so that data access is based upon management hierarchies. Finally, the
default sharing permissions should be set to private so that only authorized users can view your
data.
Profiles
A profile is similar to a role is many enterprise applications, except that each user must have one
profile and cannot have more than one profile. Every profile includes one or more permissions that
define what a user can do within Salesforce CRM, such as adding and removing users or creating
custom fields and object types. In addition to detailed permissions, a profile defines the default
access privileges to standard and custom objects, such as contacts, accounts, leads, opportunities,
and more.
Salesforce CRM defines several default profiles, referred to as standard profiles. The available
standard profiles depend on the edition of Salesforce CRM in use, and the standard profiles cannot
be modified. Reviewing standard profiles for data privacy is relatively simple since only the
System Administrator profile has full administrative access.
For larger companies, however, these standard profiles often do not provide enough fine-grained
entitlements. Organizations using Salesforce CRM Enterprise or Unlimited Editions can define
custom profiles using any combination of more than 60 individual permissions. The full list can be
viewed at Help Administration Setup User Permissions on Profiles.
For more information on profiles, see the internal help at Help Administration Setup
Managing Profiles and Chapter 2 of the Security Implementation Guide.
Auditing Profiles
Since profiles are the first step in determining data access rights, they should be reviewed closely.
If custom profiles have been used, each profile should be examined to determine which privileges
are included and which users have been assigned to the profile. If a profile is not granted certain
permission for an object, all users with this profile will be denied access. However, if a profile
does allow permission, access to the individual record must still be granted through role or sharing
privileges (See Roles and Sharing Settings below).
For example, the default profile Standard User is granted Read, Create, Edit, and Delete
permission on contacts, but only Read permission on price books. When a standard user attempts
to view a certain contact record, access to that record will be determined based on the users role
and the sharing rules defined for the organization. However, if this same user attempts to modify a
price book, the access will not be allowed because the profile prohibits edits on all price books.
To view the available profiles, click Setup Manage Users Profiles.
Auditing profiles for data privacy is a two-step process. The first is to understand all of the
profiles in use and what privileges they grant. The second step is to list the users assigned to each
profile. This section details the steps required to audit standard and custom profiles, as well as
show which users have been assigned to each profile.
Standard Profiles
The standard Salesforce profiles cannot be modified from their defaults. If no custom profiles have
been created, the auditing and review of profiles will be much simpler since all users will have one
of only a handful of static profiles. The following table shows the Standard Profiles. The System
Administrator profile should be audited closely.
Custom Profiles
If custom profiles have been defined, the permissions assigned to the custom profile should be
reviewed. Because each custom profile contains an arbitrary mix of user privileges, we
recommend keeping the number of custom profiles to a minimum. Each custom profile needs to
be carefully audited for both user membership and privileges. Since the list of privileges included
in a profile can change over time, the profile definitions need to be periodically reviewed.
Privileges Granted to Profiles
The security implications of Profiles come from the privileges granted to each profile. To view the
permissions of a profile click Setup Manage Users Profiles and select the profile. This
profile detail page lists all permissions, page layouts, login hours, and IP address restrictions. All
permissions assigned to a profile should be reviewed, but the following list includes several of the
more critical permissions to review. In particular the Modify All Data and View All Data
permissions allow write or read access to everything in your Salesforce CRM account.
Permission Description
API Enabled Grants access to Salesforce through the API.
Author Apex Can modify and deploy Apex. By default, Apex code runs with full administrative privileges. If a user
can create Apex classes, then they can view and modify all data within Salesforce through the Apex
code.
Customize Make configuration changes to the organizational settings such as password policies, custom fields,
Application workflow rules, s-controls, and more.
Download Install or uninstall packages from the AppExchange
AppExchange
packages
Edit Read Only Edit fields marked as read only for all other users in the page layout.
Fields
Manage Billing Add user licenses, manage billing and credit card information.
Manage Create, edit, and delete dashboards.
Dashboards
Manage Partners Create partner accounts and partner users.
Manage Users The ability to create or modify user accounts, including logins, sharing rules, and login restrictions.
Modify All Data This permission gives the user the ability to create, edit, or delete all data in Salesforce.
Password Never Prevent the password from expiring.
Expires
Transfer Record Transfer the ownership of accounts. The ownership of accounts affects which users can view or
modify the details of the account.
View All Data View all data owned by other users.
View All Forecasts View any users forecast regardless of the forecast role hierarchy.
View Encrypted View the value of encrypted fields. If encrypted fields are used, this permission is the only way to
Data decrypt and view the cleartext data.
View All Forecasts View any users sales forecast regardless of the user role hierarchy.
Weekly Data Export Run the weekly data export service. This will export all data.
2. The sub-section Field-Level Security shows each standard and custom object. Click the View link for
the object you want to view.
3. The next page shows whether the field is visible and/or editable by this profile.
0.
Sharing Settings
The default sharing model and sharing rules are at the core of controlling access to Salesforce
CRM data. The sharing settings define the access rights to each Salesforce CRM object and are
often confusing if they have been customized over time. In summary, sharing permissions are
based on the default permissions (the sharing model) and exception rules (the sharing rules). To
view default sharing settings and sharing rules, click Setup Security Controls Sharing
Settings.
Note: Each object type (Account, Contact, Lead, etc) can have independent sharing models and
rules.
Default Sharing Model
Each standard and custom object can be assigned a default sharing rule/model. Some of the
possible options include full read and write to all users, full read and limited write, fully private, or
other similar combinations.
When using a restrictive sharing model such as private or read-only, data access is restricted to the
record owner with two exceptions. First, a sharing rule (described below) can be used to allow
additional access. Second, a role hierarchy (described below) can be configured and then users
higher in the role (organizational chart) will automatically inherit the privileges of the record
owner.
Each standard and custom object can be assigned one of the following default options.
For example, if a contact is associated with the Acme account, then a user can only edit that contact
if he or she can also edit the Acme account.
Private Only the record owner, and users above that role in the hierarchy, can view, edit, and report on
those records.
Public Read Only All users can view and report on records but not edit them. Only the owner, and users above that
role in the hierarchy, can edit those records.
Public Read/Write All users can view, edit, and report on all records.
Public All users can view, edit, transfer, and report on all records. Only available for cases or leads.
Read/Write/Transfer
Public Full Access All users can view, edit, transfer, delete, and report on all records. Only available for campaigns.
By default, Salesforce uses hierarchies, like the role or territory hierarchy, to automatically grant
access of records to users above the record owner in the hierarchy. Professional, Enterprise,
Unlimited, and Developer Edition organizations can disable this for custom objects using the
Grant Access Using Hierarchies checkbox next to the organization-wide defaults setting. If you
deselect this checkbox next to a custom object, only the record owner and users granted access by
the organization-wide defaults receive access to the records.
The salesforce.com security team recommends using a private default sharing model and defining
an accurate role hierarchy to better protect sensitive data.
Sharing Rules
Depending on the edition of Salesforce CRM, you can set up rules to define exceptions to the
default sharing settings of most objects. The details vary slightly, depending on the object type. In
general, a sharing rule consists of three components: the owner, with whom to share, and access
permission.
If you have implemented a Private sharing model as described above, any data access exceptions
can be granted via a sharing rule. Sharing rules are used to grant exception to access restrictions
and should be kept to a minimum. Too many sharing rules become hard to understand and difficult
to audit. Moreover, once granted, it may become challenging to later remove the sharing role.
In general, a sharing rule consists of three components, the owner, who to share with, and what
access to grant. For the owner and share with, one or more of the following criteria can be
specified.
Type Description
Public Groups All public groups defined by your administrator.
Roles All roles defined for your organization. This includes all of the users in that role.
Roles and Subordinates This includes all of the users in the role plus all of the users in roles below that role.
Roles
Roles within Salesforce CRM do not completely relate to the traditional concept of a role in Role-
Based Access Control (RBAC). Instead, a role in Salesforce CRM is more closely tied to the
organizational chart and each user can only be assigned to a single role. Roles are used by the
sharing settings to control access to records.
By default, the role hierarchy is not used because the default sharing settings are Public
Read/Write (See Sharing Settings below). Once more restrictive sharing settings are enabled (such
as a private model) the roles and role hierarchies are the primary criteria used to control data
access.
To properly use role-based sharing, an accurate organization-based role hierarchy should be
defined and all users assigned to a role. You can create up to 500 unique roles for your
organization; the names of each role are fully customizable. The default sharing rules follow the
role hierarchy and users higher in the hierarchy automatically inherit the privileges of the
subordinate roles.
To view and define the role hierarchy, click Setup Manage Users Roles.
Salesforce.com recommends defining a role hierarchy that maps to your organizational structure
and enabling a private sharing model as described in the following sections. This is one of the
most effective and easiest to maintain methods of limiting access to your Salesforce data.
Defaults and Recommendations
The default settings within Salesforce CRM assign Public Read/Write permissions to nearly all
records, including leads, contacts, accounts, and custom objects. As a result, all users have full
access to every record. When different users require varying levels of data access, salesforce.com
strongly recommends defining a role hierarchy that matches your company and specifying a
private sharing model for sensitive object types. Restricting access to Salesforce CRM data
requires advance planning and testing and involves the following steps.
:: Defining a role hierarchy and assigning a role to every user.
:: Modifying the organization-wide default sharing settings for sensitive object types by setting
them to Private.
:: Defining sharing rules to provide role-based exceptions to the default settings.
Apex classes are stored as objects internally, and Salesforce provides the ability to restrict access
to run a class based on the users profile. The Security link on the Apex Classes page lists the
profiles that are allowed to run the Apex class.
Creation of Apex Classes
Apex classes can be created by any user with the Author Apex permission. By default, only the
Administrator profile has this permission. However, users can be granted this permission or
Salesforce CRM administrators can install code written by internal or external developers.
Recommendations
Because Apex classes are so powerful, review the code closely before deploying it. Developers
writing Apex should be trained secure coding practices. A brief summary of some of the more
important Apex and Visualforce security concerns can be found in the Apex and Visualforce
Security Tips article at
http://wiki.apexdevnet.com/index.php/Apex_and_Visualforce_Security_Tips.
Force.com AppExchange
The Force.com AppExchange is an on-demand application-sharing service from salesforce.com.
You can use the AppExchange to browse, install, and share apps and components stored in
packages and built for the Force.com platform. You can review apps submitted by other
salesforce.com customers, take a test drive, and install the apps. These apps work just like other
custom apps within your Salesforce CRM organization. All AppExchange applications were
checked for security flaws by salesforce.com. Salesforce.com reviews AppExchange applications
annually.
Note: Patches and version upgrades since the last security review have not been reviewed by
salesforce.com and you should review the application in the same manner you review any third-
party product.
The applications listed on the AppExchange are packaged in one of two waysnative or
composite. Native applications consist of only Salesforce CRM entities such as custom objects,
reports, workflows, Apex classes, or Visualforce pages. When native applications are installed, no
data is sent to a third-party site.
Composite applications include a combination of native features as well as connections to and/or
from a third-party data center. The details vary with each application, but data is typically shared
between Salesforce CRM and the database of the company providing the application. The
application uses the session ID of the currently authenticated user to make a Web services
connection to the Force.com API. Because of the nature of this integration, composite applications
have the same access rights as the user currently logged in.
To view a list of your currently installed applications, go to Setup View Installed Packages.
Audit Features
The Salesforce CRM application provides several types of audit logs for monitoring logins and
changes to your Salesforce CRM organization. All the audit features can be viewed by your
Salesforce CRM administrator.
User Login History
All successful and failed login attempts are recorded and saved for 180 days. The login history can
be viewed or downloaded to a CSV file by navigating to Setup Manage Users Login
History.
Setup Audit Trail
Every configuration (Setup) change is logged and archived for 180 days. The Setup Audit Trail
shows any change and who made the change. This audit log is especially helpful for organizations
with multiple administrators. To view or download the audit trail history, click Setup Security
Controls View Setup Audit Trail.
Object History Tracking
You can select certain standard and custom fields to track the change history. Each time a user
modifies one of the tracked fields, an entry is added to the History Related List on the object,
showing the time, user, and the change made. By default, no specific fields are tracked until
12