Salesforce Shield is one of the most important tools for mitigating risk in Salesforce, and includes four key components to help customers better secure their Salesforce org. One of those is Event Monitoring, which helps organizations improve data security and forensic investigations within Salesforce. Event Monitoring essentially documents and exports the raw audit log files from your Salesforce orgs. These log files are a record of user activity within your instance – also known as “events.”
By monitoring your org’s events, you can better protect your organizations’ sensitive data and identify abnormal behavior. With the nearly endless amount of activity they can provide however, (especially with larger orgs) you can imagine how the tool could quickly become overwhelming.
At Own, many of the orgs we support have hundreds to thousands of users, hundreds of objects, 10,000+ fields, and 20 or more different Shield Real Time Event Monitoring events. No admin can (or should for that matter) realistically protect every bit of information in their org. That’s why the first step in effective and efficient monitoring in Salesforce is understanding what to protect through data classification. But what should you do beyond that?
In this blog, we’ll go over some Event Monitoring Basics, explain how Own Secure can help, and provide a crawl, walk, run approach to getting the most value from Shield Event Monitoring.
Event Monitoring Basics and How Secure Can Help
The Salesforce Shield Event Monitoring license includes Real Time Event Monitoring (RTEM), which contains three key components for those interested in user activity monitoring for security purposes.
Event Big Object Storage (Forensics)
Most security policies dictate that event information be stored for at least 3-6 months to facilitate forensics efforts in the case of a breach or event. Salesforce RTEM provides a minimum of six months of storage, thereby meeting most policy requirements in this regard.
In a forensic effort, you’re likely to be most interested in events like ApiEventStream, BulkApiResultEvent, Lightning/UriEventStream, ListViewEventStream, and ReportEventStream, to rebuild or replay what happened. Consider that some or most of these objects are likely to contain millions of event records to sort through. Some events will be operations against non-sensitive data and routine, while others (in the event of an incident/breach) will be anomalous activity against sensitive data.
How does Secure help?
- With Data Classification, it’s much easier to identify and properly classify the sensitive data in an org, helping you prioritize what to address first.
- Security Insights - Objects That Should Be Monitored within Own Secure lists objects and fields containing sensitive information and their accessibility to the user community. This downloadable information provides essential filtering criteria that can be leveraged to filter down events using event fields such as “QueriedEntity”, “DisplayedFieldEntities”, and/or “ColumnHeaders”, of the events mentioned above.
Transaction Security Policies (Near Real Time Block & Notify)
Shield RTEM contains the powerful ability to stop, and/or notify, anomalous behavior in the org. Not all events can be used in RTEM, but for those that can, event fields such as “Queried Entities” again play a critical role in reducing noise / unwarranted blocking. Key events supporting Queried Entities and other essential event fields are ApiEvent, BulkApiResultEventStore (Query), ListViewEvent, and ReportEvent.
How does Secure help?
- As it does with forensics efforts, Data Classification makes it easier to identify and properly classify the sensitive data in an org.
- Armed with information from Security Insights - Objects That Should Be Monitored list, you can construct much smarter Transaction Security Policies that only “fire” when they need to, blocking or notifying potentially anomalous behavior against sensitive information only when necessary.
Event Streaming (Near Real Time Monitoring of User Activity)
Streaming events in near real-time is for active monitoring operations in a Security Operations Center (SOC). SOC personnel are commonly equipped with a Security Incident Event Management (SIEM) system that is fed logs and events from across the enterprise and include the ability to detect, analyze, and respond to security threats before they harm business operations. SIEMs include the ability to create custom rules for filtering, correlating, storing, alerting, etc. all to reduce noise and aid in bringing focus of SOC personnel to potential incidents/breaches in progress. Shield RTEM can feed the SIEM with near real-time user activity related events in support of this mission.
How does Secure help?
- Data Classification makes it much easier to identify and properly classify the sensitive data in an org.
- Security Insights - All orgs have risk hot spots. In many cases, security controls cannot be locked down to an ideal state without adversely impacting the system's ability to support the business process. Secure’s Security Insights identifies these risk hot spots and can periodically scan for them, which is important since orgs are constantly evolving. Knowing these hot spots is essential because the last layer of defense available is often user activity monitoring.
- Who Sees What lenses (Object, Record, User, Permissions) - Much like Security Insights, this feature is essential to identify where there are risk hot spots in the org security model where the control of last resort is Shield RTEM. Knowing what you need to protect against is key to understanding if you need to apply forensics, blocking, notifying, or real-time monitoring protections to reduce the risk.
- Security Insights - Objects That Should Be Monitored lists objects and fields containing sensitive information and their accessibility to the user community. This information will be invaluable in properly configuring the SIEM and allowing SOC personnel to focus on real potential incidents, rather than getting overwhelmed with noise (millions of non-critical events showing up in their consoles).
Shield Event Monitoring: A Crawl, Walk, Run Approach
If your company is new to Salesforce Shield Event Monitoring, taking the following crawl, walk, run approach (or a modified version of it) can help ensure you realize full value from your investment.
But before you do anything else, use Secure to classify your data quickly and accurately. Trying to use spreadsheets is likely to take months and often results in failure. This is NOT the step to skip, as identifying the “what to protect” is the foundation of an improved org security posture.
- Crawl: Enable storing Shield RTEM events. Since you’re already paying for the ability and the storage, you might as well take advantage of it. In the unfortunate instance you have an incident or breach, you’ll at least have the information necessary to repair and recover.
- Walk: Leverage your data classification and Security Insights -Objects That Should be Monitored to build smart Transaction Security Policies that protect your sensitive data. While in this phase, you may also consider risk hot spot information contained in Secure Security Insights and Who Sees What to build additional smart Transaction Security Policies.
- Run: Using your experience from both the classification and risk hot spot information contained in Secure, begin actively monitoring your org using a SIEM. At this point, you should be in a position to configure your monitoring operations to focus on potential incidents rather than just getting overwhelmed with noise.
The combination of Salesforce Shield Real Time Event Monitoring with Own Secure can be powerful. Together, the two solutions enable protection and awareness of anomalous behaviors that otherwise cannot be resolved using standard Salesforce security controls on their own.
To learn more, click here to see how Own can help you implement Salesforce Shield 80% faster with Own Secure.
