W H IT E P A P E R. Salesforce CRM Security Audit Guide

Transcription

1 W HITEPAPER Salesforce CRM Security Audit Guide

2 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 Recommendations Force.com AppExchange...10 Audit Features...10 User Login History Setup Audit Trail Object History Tracking References...12

3 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 ( Background Although this paper primarily focuses on application-specific features and configuration settings of Salesforce CRM, salesforce.com s 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 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.com s 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.com s 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.

4 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 expire in Enforce password history Minimum password length Password complexity requirement Password question requirement Maximum invalid login attempts Lockout effective period Frequency to automatically expire passwords How many previous passwords to save to prevent password re-use Minimum length of a password Should the password contain a mix of letters and numbers. If enabled, the password must contain at least one letter and one number. Require the user s password hint to not contain the password How many bad logins are allowed before locking out the account How long should an account remain locked out 30 days 60 days 90 days (default) One Year Never No passwords remembered 3 passwords remembered (default) 5 passwords remembered 5 characters 8 characters (default) 10 characters No restriction Must mix alpha and numeric (default) None Cannot contain password (default) (default) No Limit 15 minutes (default) 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)

5 Disable session timeout warning popup Lock sessions to the IP address from which they origination Require secure connections (https) Enable caching and autocomplete on login page Disable the warning browser pop-up when a user is about to be logged out from the idle session timeout Force the user session to remain locked to the IP address from which the user authenticated. This setting helps prevent session hijacking but will also prevent the installation of most AppExchange packages. Require HTTPS on all page requests. Allow the user s browser to store and auto-complete usernames or passwords after first login. 4 hours 8 hours Yes No (Default) Yes, if possible No (Default) Yes (Default) No Yes (Default) 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.

6 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 user s 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 to the address on record for the user s account. This 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 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.

7 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 user s 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 System Administrator Standard User Partner User Marketing User Contract Manager Read Only Available Permissions Can configure and customize the application. Has access to all functionality that does not require an 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. 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. Can lonely login via a PRM Portal Can manage campaigns, import leads, create letterheads, create HTML templates, manage public documents, and update campaign history via the import wizards. Also has access to the same functionality as the Standard User. 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. 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.

8 Permission API Enabled Author Apex Customize Application Download AppExchange packages Edit Read Only Fields Manage Billing Manage Dashboards Manage Partners Manage Users Modify All Data Password Never Expires Transfer Record View All Data View All Forecasts View Encrypted Data View All Forecasts Weekly Data Export Description Grants access to Salesforce through the API. 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. Make configuration changes to the organizational settings such as password policies, custom fields, workflow rules, s-controls, and more. Install or uninstall packages from the AppExchange Edit fields marked as read only for all other users in the page layout. Add user licenses, manage billing and credit card information. Create, edit, and delete dashboards. Create partner accounts and partner users. The ability to create or modify user accounts, including logins, sharing rules, and login restrictions. This permission gives the user the ability to create, edit, or delete all data in Salesforce. Prevent the password from expiring. Transfer the ownership of accounts. The ownership of accounts affects which users can view or modify the details of the account. View all data owned by other users. View any user s forecast regardless of the forecast role hierarchy. View the value of encrypted fields. If encrypted fields are used, this permission is the only way to decrypt and view the cleartext data. View any user s sales forecast regardless of the user role hierarchy. 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 address is a field of the Contact object. Every field in every object can be assigned unique access privileges based on the user s profile. For example, the 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.

9 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 Controlled by Parent Private Public Read Only Public Read/Write Public Read/Write/Transfer Public Full Access Description 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. Only the record owner, and users above that role in the hierarchy, can view, edit, and report on those records. 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. All users can view, edit, and report on all records. All users can view, edit, transfer, and report on all records. Only available for cases or leads. 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.

10 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 Public Groups Roles Roles and Subordinates Description All public groups defined by your administrator. All roles defined for your organization. This includes all of the users in that role. 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 Full Access Read/Write Read Only Private Description 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. User can view and edit the record, and add associated records, notes, and attachments to it. User can view the record, and add associated records to it. They cannot edit the record or add notes or attachments. 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

11 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 user s 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, let s 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 user s 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 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.

12 Apex classes are stored as objects internally, and Salesforce provides the ability to restrict access to run a class based on the user s 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 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 thirdparty product. The applications listed on the AppExchange are packaged in one of two ways native 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

13 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

14 activated by the administrator. To enable history tracking on an object, click Setup Customize [object type] Fields Set History Tracking. References :: Sharing Cheat Sheet: :: Secure Coding Tips: For More Information Contact your account executive to learn how we can help you accelerate your CRM success. 12