Transaction Security is a framework that amps up Salesforce Event Monitoring capabilities
Would you like to extend your monitoring efforts on the Salesforce platform from a detect only capability to prevent capability? Transaction security is the feature that enables you to monitor a subset of Salesforce events, spot potential troublesome behaviour based on the rules you create and provides for the ability to take proactive action in real-time.
I've probably binge-watched all of the espionage and spy thriller movies on Netflix and Prime. Everyone at some point in their lives must've thought of becoming a detective or a spy as they appeal to be quite cool jobs. There is one key ingredient that differentiates the two. Detectives examine the evidence to solve something that has already happened. Spies or secret agents, on the contrary, gather information to mitigate the risk of something bad happening. Salesforce event monitoring is like looking in the rear-view mirror and spotting objects or events in the past (Credit to @Mike Burnside for describing it in a way that sticks). However, the transaction security feature makes this detective a good spy with the capability to spot potential trouble and mitigate the risk by blocking an event.
Salesforce offers some essential monitoring services as a part of your base platform license. These include reviewing user login history, tracking configuration changes, tracking governor limits, etc. Salesforce event monitoring offers significant enhancement to the essential monitoring service. Some examples include the capability to monitor:
Thanks to the advancements in the analytics space, we're all embracing security automation and orchestration capabilities like never before. Improved visibility is allowing us to automate a response based on the gathered insights like never before. Transaction security is the feature that enhances the event monitoring capability multi-folds, allowing automated actions in real-time based on the policy defined. You start creating a transaction security policy by identifying a transaction or an event to watch for. You then designate an action that is triggered when the event occurs.?
Let's take an example. You allow your employees and partner ecosystem to view reports and export data. To align with your organisation security policy, you want to ensure that
(a) your employees cannot export large amounts of data from reports, i.e. cap this to 100 records, and
领英推荐
(b) you don't want your partners to export data from reports that contain sensitive information, i.e. Intellectual Property or client lists (Credit to @Doug Merrett for describing most businesses as mainly IP and their client list at the core in his podcast with @Ben Duncombe recently). The event type in this use case is a report event. The potential actions available to you when the policy is triggered are:
These examples are an excellent starting point to evaluate how best you use transaction security capabilities to bolster your monitoring efforts. I'd highly encourage you to review the following resources on the subject:
Cyber Security Leader | Board Director | Collaboration, Inclusion and Diversity Advocate | ?? Speaker & Storyteller
3 年Dean Clarke Lindsey Duff Mark Gabriel Glenda Thomson Michael Niall Clyde Fernandez Asmaa Zahid Amanda Hall Lisa Han Chetan Sansare Dave Norris Divya Khosla Ruchika Arora
Cyber Security Leader | Board Director | Collaboration, Inclusion and Diversity Advocate | ?? Speaker & Storyteller
3 年Big shout out to Mike Burnside, Doug Merrett, Amr Ibrahim and Gaurav Sinha for your inputs on the early draft that led to this article.
Cyber Security Leader | Board Director | Collaboration, Inclusion and Diversity Advocate | ?? Speaker & Storyteller
3 年Nathan Talbett, Judy Fang, The examples in this article were the same use cases we discussed this morning. I'd appreciate feedback on the content. Thanks!
Jay: Is transaction security events integration with SIEM on SF roadmap?