Transaction Security Policies Address Security Issues

Transaction Security is a framework that intercepts real-time Salesforce events and applies appropriate actions and notifications based on security policies you create. Transaction Security monitors events according to the policies that you set up. These policies are applied against events in your org and specify actions to take when certain event combinations occur. When a policy is triggered, you can have an action taken and receive an optional notification. This feature is available in both Lightning Experience and Salesforce Classic.

User Permissions Needed
To create, edit, and manage transaction security policies:

“Author Apex”

AND

“Customize Application”

Available in: Enterprise, Performance, Unlimited, and Developer Editions.

Note

Note

Customers are required to purchase Salesforce Shield or Salesforce Shield Event Monitoring add-on subscriptions to use this feature. For pricing details, contact your Salesforce account executive.

The real-time actions that can be taken are:
  • Notify a Salesforce admin that the policy was triggered
  • Block the operation
  • Require the use of two-factor authentication
  • Require the end of a current login session
Transaction Security includes predefined policies to limit concurrent login sessions and to block excessive data downloads done through APIs. Both example policies come with a corresponding Apex implementation class. An administrator can edit the Apex classes and enable the policies immediately.

For example, you modify the Concurrent Sessions Limiting policy to notify you via email when the policy is triggered. You also update the policy’s Apex implementation to limit users to three sessions instead of the default five sessions. (That’s easier than it may sound.) Later, a user with three login sessions tries to create a fourth. The policy requires the user to end one of the existing sessions before starting the new session. At the same time, you are notified that the policy was triggered.

Here’s another example, showing the user interface and how to create a policy to block use of a specific browser. Screen to create a new Transaction Security policy.

In this example we’ve asked Transaction Security to generate the policy code. Here’s the generated code with some added comments:
global class BlockAccessByBrowserPolicyCondition implements TxnSecurity.PolicyCondition {
  public boolean evaluate(TxnSecurity.Event e) {
    // We get the login history from the event, and then the browser from the login history.
    LoginHistory eObj = [SELECT Browser FROM LoginHistory
                         WHERE Id = :e.data.get('LoginHistoryId')];
    if(eObj.Browser == 'Navigator') { // Navigator is the browser we’re blocking.
     return true;
    }
    return false; 
  }
}
You can modify the generated Apex to perform additional tasks, such as block when there’s a specific platform and browser combination. Here’s the modified code, again with comments added:
global class BlockAccessByBrowserPolicyCondition implements TxnSecurity.PolicyCondition {
  public boolean evaluate(TxnSecurity.Event e) {
    if (event.resourceType == 'LoginHistory') {  // Let's make sure we have a login event.
      // We still get the login history from the event...
      LoginHistory eObj =[SELECT Platform, Browser FROM LoginHistory
                          WHERE Id =: e.data.get('LoginHistoryId')];
      String platform = eObj.Platform;  // We retrieve the platform
      String browser = eObj.Browser;    // as well as the browser.
      if (platform == 'Mac OSX' && browser.startsWith('Navigator')) {
        return true;  // Now we're blocking Navigator on Mac OSX.
      }
    }
    return false;
  }
}

Along with all the Apex features, you can also use external web services when implementing policies. This ability gives you great flexibility without having to write extra code. And in case there’s a conflict in policy actions, Transaction Security resolves actions with the same event type in the following order: The Block action is taken before Two-Factor Authentication, and both of those actions are taken before Ending a Session.

Many other examples are available in the online help. The following is a partial list.
  • Requiring high-assurance login sessions when accessing confidential data
  • Blocking access from specific locations or IP addresses
  • Limiting the posting rate on Chatter
  • Restricting platform and browser access to specific types
  • Blocking users with vulnerable or outdated systems