Salesforce event monitoring — under the hood
The underlying architecture for detecting threats, taking action and monitoring your Salesforce implementation
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
- Access incident analysis and outage periods
- Tracking configuration changes
- Viewing login attempts
- Viewing debug logs
- Viewing hourly and daily governor limits
- Viewing data and file storage usage
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.
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.
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.
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 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.
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.
4 anomalies are looked for. These 4 events are credential stuffing, session hijacking, API anomalies and report anomalies.
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.
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)
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.
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.
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.
To learn more about event monitoring try these free resources on trailhead.
Discover insights into your Salesforce org with this powerful monitoring feature.