If you've seen the news lately, you know you need strong security protections for your online systems. Join us as we teach you that access control features like IP range restrictions, identity confirmation, and two-factor authentication are absolutely critical to the protection of your Salesforce instance. Hear from Salesforce security engineers about how these protections work, threats they mitigate, and possible drawbacks. We'll also teach you some tricks to securely using Salesforce alongside these features.

1. Secure Salesforce:
Organization Access Controls
Mikel Otaegi
Principal Security Engineer
Jorge L Cáceres
Senior Platform Security Engineer

2. Safe Harbor
Safe harbor statement under the Private Securities Litigation Reform Act of 1995:
This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such
uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from
the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact
could be deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues,
or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief,
any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our
services.
The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new
functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in
our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of
any litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate,
our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new
releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization
and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of
salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form
10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings
section of the Investor Information section of our Web site.
Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently
available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based
upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-
looking statements.

3. Access Controls To Your Organization
• We will be covering high level administrator-oriented topics on
securing access to your Salesforce Organization

4. Access Controls To Your Organization
Specific features that we will cover include:
– Locking The Gates With Strong Authentication
• Password Policies
• Two Factor Authentication
• IP Restrictions
• Single Sign-On
– Keeping The Bad Guys Out With Secure Sessions
• Session Settings
• Activations
• Session Information
• Expire All Passwords
– Connected Apps
• OAuth Policies
• Session Policies
• Remote Site Settings
– Protecting Assets With Egress Control
• File Upload and Download Security
• CORS (Cross-Origin Resource Sharing)

5. Locking The Gates With Strong Authentication
PHOTO: Ryan Green

6. Who knows what the most common cause of data
breaches is?

7. Locking The Gates: Password Policies

8. Locking The Gates: Password Policies
1. Weak And Stolen Credentials, a.k.a. Passwords
Hacking remains the single biggest cause of attacks don't depend on finding vulnerabilities in
the application or network protocol to tunnel through. For years, experts have warned about
the risks of relying on weak credentials to restrict who has access to the data, and this is still
a problem.
About 76% of network intrusions involved weak credentials, according to Verizon's data
breach report. Authentication-based attacks, which includes guessing passwords, cracking
using specific tools or trying out passwords from other sites on the target system, factored
into about four of every five breaches that was classified as a hacking incident in 2012,
Verizon says.
(http://twimgs.com/darkreading/attacks-breaches/S6980513breachcauses.pdf)

9. Who knows what the most common used password is in
America?

10. Locking The Gates: Password Policies

11. Locking The Gates: Two Factor Authentication
Stolen passwords played a role in 48% of the data breaches that involved hacking, Verizon
found. This could have been accomplished by using stolen password lists from previous data
breaches, keylogging malware or phishing attacks.
If that number isn't eye-popping enough, Verizon estimated that 80% of data breaches would
have been stopped or forced to change tactics if a "suitable replacement" (such as multifactor
authentication) to passwords had been used.

12. Locking The Gates: Two Factor Authentication
What is Two Factor Authentication?
Two factor authentication is using more than one of the following to login or process a
transaction
• Something you know (account details or passwords)
• Something you have (tokens or mobile phones)
• Something you are (biometrics)

13. Locking The Gates: Two Factor Authentication
Two Factor Authentication With Salesforce
• Two Factor Authentication introduces the ability to use an App to generate OTPs
• Policies may be set to force two-factor authentication on login
• Session Level policies allow you to block specific actions, or “step-up” authentication

14. Locking The Gates: Two Factor Authentication

15. Locking The Gates: Two Factor Authentication

16. Locking The Gates: Two Factor Authentication

17. Locking The Gates: Two Factor Authentication

18. Locking The Gates: Two Factor Authentication

19. Locking The Gates: Two Factor Authentication

20. Locking The Gates: IP Restrictions
Trusted Login IP Ranges
The salesforce platform allows administrators to define IP ranges that are trusted. Users who
login from defined IP ranges are trusted and the login operation proceeds normally. It is
important to understand that this only covers login operations. If a user already has a valid
session id, they could make requests from IPs not in the trusted range unless you have
specified the option to lock sessions to originating IP which we will cover later.
There are two ways Trusted IP ranges can be defined, and each has unique security features:
– Organization level Trusted Login IP ranges
– Profile level Trusted Login IP ranges

21. Locking The Gates: IP Restrictions
Organization Level Trusted Login IP Ranges
Administrators define a list of IP addresses from which users can login without receiving a
login challenge for verification of their identity, such as a code sent to their mobile phone.
The main security behavior here is that login is not completely blocked. If the user
succesfully completes the login challenge, they can proceed.
The requirements and behavior is different based on entry point of login: UI/Browser, or API.
UI/browser login: As defined above. User must go through a login challenge if coming
from an IP outside the Organization Trusted range. After a succesful challenge, the user's
client browser is now trusted and can login from any ip address without being challenged.
This is accomplished with a unique cookie set on the client's browser. If the client's browser
cookie is cleared, a login challenge will be required on login from an IP outside the Trusted
range. This in effect turns the Trusted Login IP range into a type of Trusted client feature.

22. Locking The Gates: IP Restrictions
Organization Level Trusted Login IP Ranges
API login: In order to login from an IP outside the Organization Trusted range, the user must
provide a security token appended to their password. Users can obtain their security token
by changing their password or resetting their security token via the Salesforce user interface.
Unlike the UI login, API login always requires the security token.

23. Locking The Gates: IP Restrictions

24. Locking The Gates: IP Restrictions
Profile Level Trusted Login IP Ranges
• Administrators define a list of IP addresses from which users can log in.
• This list is defined per profile.
• The main security feature is that login is completely blocked if coming from an untrusted
IP.

25. Locking The Gates: IP Restrictions

26. Locking The Gates: Single Sign-On
Single Sign-On Options With Salesforce
• Delegated Authentication (not available by default, must submit a support case)
• SAML Federated Authentication

27. Locking The Gates: Single Sign-On
SAML Federated Authentication
● Federated authentication is a form of authentication (commonly referred to as single
sign-on or SSO) that allows the portability of identity information to multiple services
without the need for redundant identity management in each service.
● This type of authentication is advantageous for the user because they can remember one
password and gain access to many resources.
● This type of authentication is also advantageous from a management perspective
because it centralizes identity information and can provide a single location to disable
access.

28. Locking The Gates: Single Sign-On
Understanding SAML
● In Salesforce, federated authentication employs SAML (Security Assertion Markup Language) which
provides a secure, XML-based solution for exchanging user security information between two parties.
o There are 2 versions of SAML supported by Salesforce, 1.1 and 2.0. Version 2.0 is the default because it
includes many more features and allows for multiple configurations within Salesforce.
● The SAML assertion is the message sent by the identity service that the recipient uses for
authentication. It provides several strong security features:
o All the details of the authentication request are contained in the SAML assertion.

29. Locking The Gates: Single Sign-On

30. Locking The Gates: Single Sign-On

31. Keeping The Bad Guys Out With Secured Sessions
Picture licensed under a Creative Commons Attribution Share-Alike 3.0 License

32. Keeping The Bad Guys Out: Introduction
Introduction
Administrator functions to maintain secure sessions
● Session Settings Set the session security and session expiration timeout for your
organization.
● Activations Maintain the list of IP addresses representing the device IP addresses that
have been activated by a user.
● Session Management The View information about or delete active user sessions.
● Expire All Passwords Use to expire the passwords for all of the users in your

33. Keeping The Bad Guys Out: Session Settings

34. Keeping The Bad Guys Out: Activations

35. Keeping The Bad Guys Out: Session Management

36. Keeping The Bad Guys Out: Expire All Passwords

37. Connected Apps: Introduction
• A connected app integrates an application with Salesforce using APIs.
• The administrators can set various security policies and have explicit control over who may use the
connected app.
• Two deployment modes:
– The app is created and used in the same organization.
– The app is created in one organization and installed on other organizations.

38. Connected Apps: Basic Information
• The administrators can set various security policies and have explicit control over who may use the
connected app:
• Via the connected app configuration, administrators can install the connected app, enable SAML, use
profiles, permission sets, and IP range restrictions to control which users can access the application
• Connected apps use SAML and OAuth to authenticate, provide Single Sign-On, and provide tokens
for use with Salesforce APIs.
• Connected apps can be added to managed packages, only.

39. Connected Apps: OAuth Basics
Supported OAuth flows:
● Web Server flow
● User-Agent flow
● JWT Bearer Token Flow
● SAML Bearer Assertion Flow
● SAML Assertion Flow
● Username and Password

40. OAuth Policies
Make sure to always follow the principle of least privilege while defining this scope. Only provide the minimum
access required for the application use case.

41. OAuth Policies

42. OAuth Permissions

43. Connected Apps: Session Policies

44. Remote Site Settings

45. Secure Salesforce at Dreamforce 2015
​ 10 DevZone Talks and 2 Lighting Zone Talks covering all aspects of
Security on the Salesforce Platform
​ Visit our booth in the DevZone with any security questions
​ Check out the schedule and details at http://bit.ly/DF15Sec
​ Admin-related security questions?
​ Join us for coffee in the Admin Zone Security Cafe

46. Secure Salesforce – Thursday Morning
​ Org Access Controls
​ Jorge Caceres and Mikel Otaegi
​ 9:30am in Moscone West 2007
​ Secret Storage in your Salesforce Instance
​ Kyle Tobener and Ian Goldsmith
​ 9:30am in Moscone West 2011
​ External App Integration
​ Astha Singhal and Chris Vinecombe
​ 12:00pm in Moscone West 2010

47. Secure Salesforce – Thursday Afternoon
​ Hardened Apps with the Mobile SDK
​ Martin Vigo and Maxwell Feldman
​ 2:30pm in Moscone West 2008
​ Code Scanning with Checkmarx
​ Robert Sussland and Gideon Kreiner
​ 3:30pm in Moscone West 2011
​ Lightning Components Best Practices
​ Robert Sussland and Sergey Gorbaty
​ 4:45pm in Moscone West 2007
​ Common Secure Coding Mistakes
​ Rachel Black and Alejandro Raigon Munoz
​ 5:00pm in Moscone West 2006

48. Secure Salesforce – Friday
​ Chimera: External Integration Security
​ Tim Bach and Travis Safford
​ 10:00am in Moscone West 2009

49. Q&A

51. Additional Resources
• Secure Coding Guidelines -
https://developer.salesforce.com/page/Secure_Coding_Storing_Secrets
• Intro to Managed Packages - https://developer.salesforce.com/page/An_Introduction_to_Packaging
• Salesforce StackExchange - http://salesforce.stackexchange.com/questions/tagged/security
• Developer.Salesforce.com Security Forum - https://developer.salesforce.com/forums (full link hidden)
• Security Office Hours (Partners) - http://security.force.com/security/contact/ohours
• Security Implementation Guide - https://developer.salesforce.com/././securityImplGuide/ (full link hidden)

52. Additional Security Features For Access Control

53. Locking The Gates: Single Sign-On
Delegated Authentication
Delegated authentication is a form of authentication that forwards the username and
password from Salesforce via web-service callout to an admin specified endpoint that can
verify and authenticate the user.
● To build the external webservice, a WSDL is available in the Salesforce setup menu. Navigate to Setup -
> Build -> Develop -> Api and click “Delegated Authentication WSDL”
● Users are enabled for delegated authentication via the “Single Sign-On Enabled” profile permission.

54. Locking The Gates: Single Sign-On

55. Keeping The Bad Guys Out: Activations

56. Locking The Gates: Single Sign-On

57. Connected Apps: Session Policies
Features that use session level security:
– Reports and dashboard in Salesforce1 Reporting
– Connected apps.
You can specify an action to take if the session used to access the resource is not High Assurance.
• Block — Blocks access to the resource by showing an insufficient privileges error.
• Raise session level — Redirects the user to log in based on the login method associated with
High Assurance security level. When the user completes the login flow successfully, the user
can access the resource. For reports and dashboards, you can apply this action when users
access reports or dashboards, or just when they export and print reports.

58. Remote Site Settings
Before any Visualforce page, Apex callout, or JavaScript code using XmlHttpRequest in an s-control or
custom button can call an external site, that site must be registered in the Remote Site Settings page, or
the call will fail.
For security reasons, Salesforce restricts the outbound ports:
● 80: This port only accepts HTTP connections.
● 443: This port only accepts HTTPS connections.
● 1024–66535 (inclusive): These ports accept HTTP or HTTPS connections.

59. File Upload and Download Security
• Helps you control how various file types are handled during upload and download.
• Specify what happens when users attempt to download specific file types.
• Download (Recommended): The file is always downloaded.
• Execute in Browser: The file is displayed and executed automatically when accessed in a browser or
through an HTTP request.
• Hybrid: Attachment and document records execute in the browser. Salesforce CRM and Chatter files
are downloaded.

60. File Upload and Download Security

61. Egress Controls: CORS
• To allow code (such as JavaScript) running in a Web browser to communicate with Salesforce from a
specific origin, whitelist the origin.
• If a browser that supports CORS makes a request to an origin in the Salesforce CORS whitelist,
Salesforce returns the origin in the Access-Control-Allow-Origin HTTP header.
• For example, https://*.example.com adds all the subdomains of example.com to the whitelist.