A Primer on Forensic Investigation of Salesforce Security Incidents

I am increasingly asked by customers how to investigate potential security incidents in their Salesforce environments. Common questions are: What did a specific user do during that time? and What data was impacted? Every organization and incident is unique, and the answer to these questions depends on the specific situation, but there is some general guidance I can provide.

Three key sources of information for investigating a security incident in Salesforce environments are activity logs, user permissions, and backup data. 

The default logs available in a Salesforce org are useful for detecting unusual logins and investigating important changes captured in the Setup Audit Trail. Shield Event Monitoring is an add-on product that provides enhanced visibility into activities, including API calls, report exports, and file downloads. For customers using B2C Commerce Cloud, there are additional logs useful for security monitoring.

When investigating a security incident, an initial concern is whether the user had access to sensitive data and could make significant changes in the Salesforce org. Determining a user’s access and permissions in Salesforce can be challenging, particularly given the combination of Profiles, Permission Sets / Groups, Sharing Rules and Role Hierarchies. You can find the information in multiple places or quickly see everything in a single view using Who Sees What (WsW) Explorer.

Figure: Security Center WsW Explorer used to get a quick and comprehensive overview of which Objects and Fields a user has permission to access alter, and export, with sensitive fields denoted with a red icon.

When the principle of least privilege is followed to restrict user access and permissions, this helps limit the impact of a security incident. Conversely, if an initial impact assessment reveals that a user had broad access to sensitive data and could make significant changes in the Salesforce org, then more in depth analysis can be performed to determine specifically what was accessed and altered.

Most forensic investigations of Salesforce security incidents involve finding pertinent information in large volumes of logs. Knowing what logs are available and what details they contain help you form an effective log analysis strategy. Event Monitoring has three sources of enhanced logging that can be useful for identifying and investigating Salesforce security incidents:

• Real Time Event Monitoring (RTEM) that can be streamed for active security monitoring, and stored for up to six months to enable querying. RTEM includes specialized Threat Detection events that employ statistical and machine learning methods to alert on unusual activities.
• Event Log Objects (ELO) provides low-latency logs with many, but not all, events currently represented in the ELF. This low-latency log source can be queried via Salesforce Platform APIs.
• Event Log Files (ELF) in CSV format that support security, performance, user adoption, and general observability, but not near-realtime/low-latency.

At a minimum, you should be monitoring Threat Detection events for known anomalies, with the caveat that these still require investigation to determine whether they are actually malicious. The anomaly events trigger when any user activity is sufficiently different from the historical activity of the same user, so there will be false positive alerts under certain conditions. Threat Detection events can be viewed within an individual Salesforce org, or across all of your orgs and sandboxes using the centralized dashboard in Security Center (see How To Simplify Security, Response, and Compliance in Salesforce).

Routine monitoring of logs helps develop familiarity with typical activities in your Salesforce environment, making it easier to identify deviations, including external attacks and insider threats. Salesforce Analytics Studio can be used to create dashboards for monitoring threats and investigating incidents, and this is made even easier with being able to query ELO. For instance, you can filter the Threat & Access dashboards to focus on a specific user, answering the question “What did a specific user do during that time?” and obtaining details needed to develop a timeline of events. 

Figure: Analytics Studio Threats & Access dashboards using data in ELO. Specifying a user and time refocuses these dashboards on the logs relevant to the question “What did a specific user do during that time?”

When the dashboard displays activities that warrant further investigation, you can quickly pivot to the source data in ELO to investigate the logs in more detail. For example, an unusual increase in API activities for a given user account or connected app deserves further attention.

Figure: Analytics Studio dashboard showing API access by client (left) and source ELO data (right)

When an incident involves data exfiltration, the forensic investigation delves deeper into logs to reconstruct what happened and what data was taken. When analyzing Event Monitoring, be aware that some log sources can have additional fields for the same event. For example, ELF ReportExport has 16 fields, ELO ReportEventLog has 25 fields, RTEM ReportEventStream has 37 fields. When data is exfiltrated via API, the RTEM APIEventStream specifies which records and fields that were queried; ELF and ELO do not have these details. A sanitized sample entry from the realtime API ApiEventStream focusing on DataLoader shows the query and downloaded records in bold. 

Log details can be important for creating incident timelines, performing scope assessment, determining root cause, notifying affected customers, and reporting to stakeholders or regulators. Forensic findings from log analysis can also help eradicate unauthorized access, inform future mitigations, and pursue legal remedies.

Field History Tracking is useful for determining whether certain fields were altered by the user during the incident, and backups are invaluable for ensuring data integrity and returning damaged data to a known good state.

Enhanced Transaction Security is a feature available for some RTEM events that can be configured with specific policy rules that trigger a response when violated. Any report containing sensitive fields can be blocked from being downloaded by policy, as shown below. These automated responses configured in Transaction Security Policies (TSP) can include blocking ‌the activity, sending an alert, and requiring MFA. TSP can also be combined and can trigger a workflow that automates follow-up actions in real-time, such as creating a case and sending a Slack security notification.

Figure: Transaction Security Policies that trigger automated actions when specific real-time events occur

Consider a situation in which a Guest User Anomaly alert triggers a TSP to block unauthorized access to data in your org via a customer portal. This type of access via Digital Experience Sites creates distinctive AuraRequest events that show the IP address of the system being used to gain unauthorized access, which can be used to search logs for related activities. Determining what data was accessible requires a review of permissions for guest user accounts and which objects have external org wide defaults set to public read/write. Such undesirable data exposure can be prevented by restricting Guest User permissions in Salesforce Digital Experience portals.

Organizations that prepare proactively for security incidents impacting mission-critical Salesforce data are in a better position to detect, investigate, and neutralize problems more quickly. Addressing these incidents promptly and effectively reduces the downtime and cost, and can prevent the problems from escalating.

Related Resources: