W H IT E P A P E R

W HITEPAP ER

Salesforce CRM Security Audit

Guide
W HITEPAP ER

Contents
Introduction ..................................................................................................................................... 1

Background ..................................................................................................................................... 1

Security and Compliance Related Settings................................................................................... 1

Password Settings ............................................................................................................................................. 2
Audit and Recommendation .......................................................................................................................... 2
Session Settings ................................................................................................................................................ 2
Audit and Recommendation .......................................................................................................................... 2
Login and Authentication Settings ...................................................................................................................... 3
Time of Day Restrictions................................................................................................................................ 3
IP Address Restrictions.................................................................................................................................. 3
Single Sign-On Options ................................................................................................................................. 3
Identity Confirmation...................................................................................................................................... 3

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

Apex and Visualforce ...................................................................................................................... 9

Apex and Data Privacy....................................................................................................................................... 9
Apex Security Controls....................................................................................................................................... 9
Triggers ......................................................................................................................................................... 9
Classes ......................................................................................................................................................... 9
Creation of Apex Classes ................................................................................................................................. 10
Recommendations ........................................................................................................................................... 10

Force.com AppExchange ............................................................................................................. 10

Audit Features ............................................................................................................................... 10

User Login History....................................................................................................................................... 10
Setup Audit Trail .......................................................................................................................................... 10
Object History Tracking ............................................................................................................................... 10

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.

Salesforce CRM Security Audit Guide

W HITEPAP ER

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)

Salesforce CRM Security Audit Guide

W HITEPAP ER

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

Login and Authentication Settings

By default, all users are allowed to login to Salesforce from any IP address at any time of day,
subject to the restrictions of the Identity Confirmation feature described below. It is possible to
restrict user login access to specific work hours and/or defined ranges of IP addresses. These
restrictions are defined based on user Profiles (see Profiles below).
Time of Day Restrictions
User logins can be restricted to specific times of the day. These settings are defined for each
profile and no organization-wide settings can be configured. To view the time of day restrictions,
edit the Login Hours related list for each profile at Setup Manage Users Profiles
IP Address Restrictions
User logins can be restricted to specific IP addresses or ranges of IP addresses. IP range
restrictions can be configured for the entire organization or for each particular profile. You can set
multiple ranges of allowed IP addresses, but the total number of IP addresses in the allowed lists
can be no more than 33,554,432. Salesforce.com Information Security strongly recommends using
IP Address Restrictions to ensure that your users are coming from your trusted corporate
network(s).
To view or set restrictions for the entire company, click Setup Security Controls Network
Access.
You can also set different IP range restrictions for each profile at Setup Manage Users
Profiles.
Single Sign-On Options
In addition to the standard username and password authentication, Salesforce CRM supports two
types of single sign-on. To improve user account management, salesforce.com recommends
enabling one of the following options:
:: Delegated Authentication When delegated authentication is enabled, Salesforce CRM
makes a Web services call to your organization to authenticate your users, rather than using
the native Salesforce CRM passwords.
:: Federated Authentication Federated authentication directs Salesforce CRM to use the
Security Assertion Markup Language (SAML) for user authentication.
Single Sign-On should be used if possible. If a user leaves your company, you administrator will
be required to disable their Salesforce CRM account manually. If you are using a single sign-on
method, once the user is removed from your central authentication server, their access to
Salesforce will be immediately revoked.
To configure single sign-on using SAML, click Setup Security Controls Single Sign-On
Settings.
Identity Confirmation
The Identity Confirmation feature was developed in part to provide a defense against phishing
attacks and/or stolen user credentials. This feature is enabled for all organizations. It cannot be
disabled.

Salesforce CRM Security Audit Guide

W HITEPAP ER

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.

Salesforce CRM Security Audit Guide

W HITEPAP ER

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.

Profile Name Available Permissions

System Can configure and customize the application. Has access to all functionality that does not require an
Administrator additional license. For example, administrators cannot manage campaigns unless they also have a
Marketing User license. Can manage price books and products. Can edit any quota, override
forecasts, and view any forecast.
Standard User Can create and edit most major types of records, run reports, and view the organization's setup.
Can view, but not manage, campaigns. Can create, but not review, solutions. Can edit personal
quota and override forecasts.
Partner User Can lonely login via a PRM Portal
Marketing User Can manage campaigns, import leads, create letterheads, create HTML email templates, manage
public documents, and update campaign history via the import wizards. Also has access to the
same functionality as the Standard User.
Contract Manager Can create, edit, activate, and approve contracts. This profile can also delete contracts as long as
they are not activated. Can edit personal quota and override forecasts.
Read Only Can view the organization's setup, run and export reports, and view, but not edit, other records.

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.

Salesforce CRM Security Audit Guide

W HITEPAP ER

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.

Users Assigned to Profiles

To view a list of the users assigned to each profile, first navigate to Setup Manage Users
Profiles and select the profile. Next click the button that says View Users to see a list of users
assigned to this profile.
Privileges Granted to Users
There is currently no direct way to retrieve a list of which privileges are granted to which users.
However, Salesforce security built a Security Health Check application that you can install from
the App Exchange to get this information. The Security Health Check will review your security
settings, provide a numeric score and give recommendations for improvement, and provide a
listing of which users have been granted which privileges.
Field-Level Security
Field-level security provides granular control over specific fields related to Salesforce CRM
objects. For example, the email address is a field of the Contact object. Every field in every object
can be assigned unique access privileges based on the users profile. For example, the email
address of a contact could be restricted to read-only for one profile, not visible for another profile,
and fully editable by yet a third profile.
Field-level security rules should be reviewed periodically since they potentially override other
types of data access settings.
In general, setting field-level security will make auditing and controlling your data complicated.
Field-level security should be used strategically to protect sensitive elements. For example, you
may save certain sensitive information about each contact that only members of an executive team
can access. In that case, you would create a special profile for those users and set field-level
security for that Contact field so that only members of your new Profile could view the data.
To set and view field-level security, use one of two options.
Field-Level Security by Profile
To view field-level security on a particular profile:
1. Click Setup Manage Users Profiles and select the desired profile.

Salesforce CRM Security Audit Guide

W HITEPAP ER

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.

Field-Level Security by Object

To view field-level security for a particular object type:
1. Click Setup Customize, choose a tab, and click Fields.
2. Select the field you want to modify.
3. Click Set Field-Level Security.

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.

Sharing Access Description

Controlled by Parent A user can perform an action (such as view, edit, or delete) on a contact based on whether he or
she can perform that same action on the record associated with it.

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.

Salesforce CRM Security Audit Guide

W HITEPAP ER

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.

The possible access levels to grant are:

Access Level Description

Full Access User can view, edit, delete, and transfer the record. User can
also extend sharing access to other users; however, the user
cannot grant Full Access to other users.
Read/Write User can view and edit the record, and add associated
records, notes, and attachments to it.
Read Only User can view the record, and add associated records to it.
They cannot edit the record or add notes or attachments.
Private User cannot access the record in any way.

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

Salesforce CRM Security Audit Guide

W HITEPAP ER

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 and Visualforce

(Apex and Visualforce are only available in Force.com Developer Edition and the Salesforce
CRM Enterprise and Unlimited Editions.)
Apex is a programming language developers can use to create custom business logic or complete
applications on Force.com platform server. Visualforce is a tag-based markup language (similar to
HTML and JSP) to give developers a more powerful way to build applications and customize the
Salesforce CRM user interface.
A very typical use of Apex and Visualforce will be to create a customized Visualforce page that is
supported by Apex code written by your developers. This powerful ability to customize Salesforce
CRM also presents potential security risks that should be monitored. First, Apex and Visualforce
pages can have many of the same security vulnerabilities as any web application might have and
should be reviewed in the same way other internal web applications are reviewed. Second, Apex
code can bypass all of the data privacy restrictions previously discussed in this paper.
Apex and Data Privacy
Apex classes are essentially custom code segments you can use to modify almost any data,
business logic, or even outbound Web services and HTTP requests. One of the most important
features of Apex is that, by default, it runs with full system privileges. That means that the users
profile-based permissions, field-level security, and sharing rules are not taken into account during
script execution. Security must be enforced by the author of the Apex Code.
For example, lets say a developer creates an Apex class that searches for and modifies contact
records, and assigns that Apex class to a Visualforce page. A standard user with limited access to
contacts uses this page to search for a contact. Even if the users profile and sharing settings do not
normally allow the user to see the contact, the Apex class running with system privileges will
retrieve the record and allow the user to take any action that the class has been written to perform.
For more information on Apex access controls, see the Data Access Control section of the Apex
and Visualforce Security Tips article at
http://wiki.apexdevnet.com/index.php/Apex_and_Visualforce_Security_Tips.
Apex Security Controls
Apex can be used on the platform in two different forms.
Triggers
A trigger is an Apex script that executes before or after specific data manipulation language
(DML) events occur, such as before object records are inserted into the database, or after records
have been deleted. Triggers are stored as metadata in Salesforce at Setup Customize [object
type] Triggers. Triggers do not have any additional security controls and are always run
regardless of the user currently logged in.
Classes
A class is a template or blueprint from which Apex objects are created. Classes consist of other
classes, user-defined methods, variables and custom business logic. All classes currently deployed
can be viewed at Setup Develop Apex Classes.

Salesforce CRM Security Audit Guide

W HITEPAP ER

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

Salesforce CRM Security Audit Guide

W HITEPAP ER

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

Salesforce CRM Security Audit Guide

 activated by the administrator. To enable history tracking on an object, click Setup Customize
[object type] Fields Set History Tracking.
References
:: Sharing Cheat Sheet:
https://na1.salesforce.com/help/doc/en/salesforce_sharing_cheatsheet.pdf.
:: Secure Coding Tips:
http://wiki.apexdevnet.com/index.php/Apex_and_Visualforce_Security_Tips.

For More Information

Contact your account executive
to learn how we can help you
accelerate your CRM success.

12