Salesforce event monitoring — under the hood

The underlying architecture for detecting threats, taking action and monitoring your Salesforce implementation

Dave Norris
7 min readMar 10, 2020
Photo by Niv Singer on Unsplash

Monitoring can be defined as the ability to keep activity within your Salesforce implementations under systematic review over a period of time.

Salesforce provides a number of services to provide this systematic review as part of their base licence, including, but not limited to

There are capability gaps with the above however that may be important to your security posture and BAU operations. Some of these can be highlighted as:

  • How do I know who has viewed a record?
  • How can I see how long a report took to run?
  • How to a I block a user exporting a large number of records from a report?
  • How can I enforce two-factor authentication when a user accesses sensitive assets — like reports?

The vision for Salesforce event monitoring is to fill these gaps, and more, and provide proactive security alerts for your user base.

Salesforce event monitoring is a suite of services aimed at allowing customers to view and interpret more detailed logs about their implementation of Salesforce. It also provides the ability to take action, in real time, for a subset of those events. Three times a year Salesforce invests in these services to add and enhance their functionality as part of each major release. There is an additional charge for it.

Here is a deeper dive on how it works.

Application events captured by Salesforce (from any type of interaction) are persisted. Given the nature of the Salesforce’s multi-tenant environment the logs themselves are not much use to customers. To make these consumable for customers a number of features exist to help.

Application events are persisted to file storage

50 event types are made available to event monitoring customers by making a copy of those transactions into a standard object called EventLogFile and supporting file storage. This process is asynchronous in nature and operates in batch mode copying transactions hourly and daily. Given the vast volumes of application log captured Salesforce stores a rolling 30 days of activity. These logs contain a myriad of information useful for ascertaining who did what, when and how long it took.

50 event types are persisted into a customers Salesforce org

Transaction Security

9 event types are captured synchronously as part of transaction security. Transaction security allows customers to create security policies in Salesforce to address security risks. Given it’s a synchronous transaction it provides customers with the ability to take immediate action. The actions you take can be to block the transaction or to require two-factor authentication. You can also send an email or in-app notification to alert a person or team. For example, you can create a transaction security policy to block a user from exporting more than 1,000 records from a specific report.

9 events made available for Transaction Security Policies

Event Storage

All 50 event types are made available for 30 days. Transaction Security processes a subset of these in near real time — 18 events. These events can be streamed and stored (an administrator selects which events). These real time events are kept in scalable storage, backed by Apache HBase, for 6 months (Login and LoginVerification events for 10 years).

Real time events backed by scalable storage

Real Time Event Streaming

18 event types are also published to the Enterprise Messaging Platform, backed by Apache Kafka and other services, to be made available to subscribers. Subscribers can use CometD to subscribe to these events just like other events in Salesforce (Change Data Capture and Platform Events).

CometD is a scalable HTTP-based event routing bus that uses an AJAX push technology pattern known as Comet. It implements the Bayeux protocol.

Real time events are published to the Salesforce event bus to allow customers to stream them

Threat Detection

This streaming pattern allows for new services to be created. Internally as part of Spring ’20 release Salesforce has released a new service called Threat Detection. Threat detection can subscribe to real time events being published to the event bus and conduct analysis on the events to determine if they are a potential security event.

Threat detection subscribes to events to look for anomalies

4 anomalies are looked for. These 4 events are credential stuffing, session hijacking, API anomalies and report anomalies.

Credential Stuffing

Credential stuffing — what it is, how it’s detected and how we remediate it. *The analysis, detection and remediation is enabled for all customers. The ability to capture the event requires Event Monitoring.

Credential stuffing can be detected by researching stuffing traffic patterns and doing time bucketing analysis of those patterns over time. When this type of anomaly is detected the user will be presented with an identity challenge and be required to reset their password. The threat detection service also publishes an event to the bus.

Session Hijacking

Session hijacking — what it is, how it’s detected and how we remediate it. *The analysis, detection and remediation is enabled for all customers. The ability to capture the event requires Event Monitoring.

By fingerprinting the TLS negotiation between client and server Salesforce can detect potential malware installed on a users device. When this type of anomaly is detected the user has their session terminated and multi factor authentication is required. The threat detection service also publishes an event to the bus.

2 x Anomaly Events (Report and API)

Anomalous behaviour — the types and how they’re detected. Customers need Event Monitoring to capture these events.

Report exports are potential opportunities for data loss. Transaction security policies provide one mechanism to detect and block this activity but sometimes exporting data cannot be blocked wholesale. Users may exploit this by exporting data over time. The threat detection service can subscribe to report export events and models can be created to baseline behaviour over time. Customers can then set threshold scores based on deviation from this normal behaviour and generate anomalous events in real time that they can investigate.

Similar principles apply to the API Anomaly event. An API anomaly is any user activity that is sufficiently different from the historical activity of the same user. This is important given that data will be pushed into and out of your Salesforce Org from tools that connect via API.

Reporting and Analytics

Customers need a way to visualise and report on these logs. Some customers have existing Security Incident and Event Monitoring (SIEM) tools that aggregate security logs and some don’t.

No customer data exists in the application logs. References to 18 character Salesforce identifiers allows customers to tie back an event to a specific person or record. If a customer or third party wants to include user names or report names then they can enrich their dataset by querying for these reference tables using the standard APIs.

No Enterprise Tools

As part of event monitoring Salesforce provides its customers with 10 licences for Einstein Analytics. It also provide pre-built datasets and dashboards to visualise common use cases.

Enterprise Tools

Access to the event bus (platform events) and the EventLogFile and BigObjects (BULK, REST and SOAP) is provided to event monitoring customers. Partners have created pre-built connectors to query for application log information and make it available for reporting. Some partners, like FairWarning, have turn-key solutions ingesting and visualising data with no need for customisation. Other partners, like Splunk, have solutions that provide flexibility but require some customisation for each implementation.

The underlying components of Event Monitoring and how they work together

Summary

Detailed analysis of security, adoption and performance metrics may not be possible without event monitoring. Event monitoring is a paid for service that offers:

  • Proactive blocking through transaction security policies
  • Proactive alerting through transaction security policies
  • Anomaly detection
  • Near real time event streaming (18 events)
  • A detailed log of 50 event types providing detailed information on usage
  • Prebuilt dashboards for analysis via Einstein Analytics
  • A partner network providing extended capabilities for log analysis

Salesforce event monitoring supplements existing monitoring services to provide the most fine grained access to your Salesforce application event logs. These events are processed in batch (hourly or daily) and streamed in near real time. Reports and dashboards are available as part of the products offerings to immediately gain insights into the data. Third party services can also leverage standard APIs to access the data.

Further Reading

To learn more about event monitoring try these free resources on trailhead.

--

--

Dave Norris

Developer Advocate @ Salesforce || Interested in solving unique challenges using different cloud service providers || All opinions are mine.