Guest post by Arastun "Russ" Efendiyev. Arastun is Lead Solution Engineer for the Salesforce Platform based in Greater Boston Area. He works with many Salesforce Shield and Event Monitoring customers and is one of the leading experts for Salesforce Event Monitoring and Transaction Security. You can connect with Russ on LinkedIn and follow him on Twitter.
10 Event Monitoring Gifts for the Holidays
Holidays are around the corner, and odds are that you’re finding yourself with a shopping list for all the gifts. But don’t forget reward yourself! If you have Event Monitoring, here are Ten Best Practices you can take advantage of - put them on your list!
For those of you unaware of Event Monitoring, here is a quick cheat-sheet to get you up to speed.
Here are the Ten Best Practices.
- Sit Down and Define what you want to track. Have a Monday morning meeting about it. Take the Event Monitoring reference API doc that provides a list of all things you can track for each event. Ask yourself “What would the ideal dashboard look like?” Use the API doc to help you understand all the data points you can track. Maybe some of them exist outside of Event Logs (i.e., metadata/config changes) – that’s okay, throw them onto the dashboard. Too often I see folks zero in on the technology and encounter a ‘technology-first, business-second’ dilemma. Reverse it! Just bring some good donuts to the meeting.
- Offload. The logs are retained in Salesforce for 30 days. Then they leave. Set up a process to export them on an archive of your choice. A large use-case of Event Monitoring is doing a retroactive forensic analysis on an individual or individuals that left the company. Let’s say the individual took down top Contacts in a report export and went to a competitor. They did it 4 months ago. You have to be prepared to be able to mine that data. Set up automation – such as using shell scripts provided here and running a scheduled cron job to grab data, or scheduled to run this python script provided here. A SIEM tool can help with this and eventually have data reside after it leaves Salesforce in 30 days. This is especially helpful as various SIEM tools excel at log-aggregation and ingestion, which comes from Event Monitoring files. Contact us and we can provide some SIEM vendors that have hot-pluggable adapters for Event Monitoring, if you want an out-of-the-box experience.
- Compliance vs Productivity. It’s definitely something we all live and breathe, especially in Financial Services, where I see a lot of companies try to walk this very fine and very important line. Use a security model that’s too strict and your end users don’t use the system, while security that’s too lax comes with more threats. Let’s use the same example. So you’re still worried about someone leaving for a competitor and taking all your reports? Okay, remove their privilege to Export Reports and their decommission Connected App Data Loader access. Problem solved, right? Whoops. Too bad you just prevented the user from working on various things they’d need to do in Excel with the exported data. No worries here – Transaction Security, a feature of Event Monitoring that can alert/block on events in real time, can help. It lets you provide a granular scope on certain types of records and how their export will happen. Maybe we only block anyone who exports an entire contact list, or over 100 contacts. Or, even more lax, maybe we let them do it but email an alert saying they’ve done it. Or, only email or block if they did it in off hours for over 100 contacts. Or email if they did it in off hours, their profile was Standard User, and their User object had a Suspicious__c checkbox boolean flag turned on. You can get really flexible here and get much closer to the business, while letting the end users be productive
- Keep up with our roadmap! We release 3X per year. Obligatory Forward-Facing statement / #Safeharbor here. We have product managers mapped to Event Monitoring functionality, the Transaction Security aspect of it, and even our Wave Admin Analytics for Event Monitoring visualization. Take a look at a recent Winter ’17 example of some things we put in Transaction Security. To broaden picture: we executed on Transaction Security and Wave Admin Analytics – and those are undergoing iterations. Part of it is feedback from YOU! What are the use-cases that are important to you? Continue to share wiith us and we’re open to putting them in our roadmap.
- Data can come from elsewhere. Event Monitoring is the end-all-be-all. What about your authentication history? Your metadata/configuration changes? Your data & field history changes? Easy to overlook. Don’t forget them for your next audit. As per its name Event Monitoring provides insights on events, while data/metadata changes are a great complement. Wear your fancy audit shoes, seamlessly crunch out reports on all of these things, and give them to the auditors.
- Join your friend objects. Okay, so you have your logs. Let’s take a look at that example of ours – a user extracting a report. They collect information on User ID of 00530000009M943. Good start, but we need to make sense out of it. Well, we have User Object. Plug that into your reporting solution on Event Monitoring, whether it’s a SIEM or our Wave App, for 30 days worth of retention. If I’m looking at a report, Report ID is captured, which can be joined against the Report table to give it a name (versus an ID). We now find out that it was John Smith that looked at a Top Contacts report. And if I want to get a Profile mapping to it, I know that Profile is tied to User via User’s ProfileId. The Wave Admin Analytics is effective here since we’ve brought over some of these friendly objects!
- QA Buddy. Not everyone has a QA team and/or QA automation, like Selenium, within their enterprise. When you test your Authorization model, Login-As is a great feature (which is trackable on Event Monitoring, by the way). It lets you impersonate an end-user so you can validate that they can or can’t see functionality, especially data. Who can or can’t see data, create it, edit/update it, etc. Login-As is a QA process, whether it’s you doing it or another individual checking your work. Here’s where your thoughtful effort on Profiles, Permission Sets, Criteria Based Sharing Rules, Apex Managed Sharing Rules, Org Wide Defaults, Role Hierarchy, etc. is put to the test. Those are very important controls – we don’t want the wrong individual within the org to see wrong data, let alone act on it. With event monitoring, you have a true validation of the controls you put in place. You can assert that John Smith never saw a Case filed by Bob Jones for Payroll to validate Bob’s paycheck amount reflects the hours worked. Or, you finally saw that John was able to look at John’s payroll case. So you know your controls need to be changed. This is true automation to validate your controls.
- Insights into Usage. As per above example of John looking at Cases, you may find this insight beneficial beyond security validation. Let’s say that you want to see how much your Sales team, that John Smith is part of, is looking at customer-only Cases – you’re trying to understand if they are able to help the customer and/or even find new product line opportunities. Event monitoring can help track both use cases, being your QA Buddy for the authorization model and seeing how much functionality is being utilized. A Sales individual can look up a Case and give the customer a call. If they don’t have Salesforce integrated to Telephony, there may not be anything tied to that record, but the log will remain that John Smith went on a customer-field case eight times in two days!
- Trailhead! We have released various Trailhead modules to get hands-on with this and we run a checker to see if you got your work right or wrong in your Developer org, an account where you can test this. Here are some Trailhead modules: Transaction Security Trailhead & Event Monitoring Trailhead. There are many other modules that have Security – feel free to search for them in Trailhead depending on your security area of interest.
- Optimize where it matters. So you saw your complex Visualforce page, that utilizes Angular and is backed by sophisticated Apex Controller, encounter a slower render/request time. You spent 14 hours fixing it. Success! Actually, the behavior witnessed was close enough to average request time. Remember, this was based off your perception of a slower request time. The kicker is that there are two other Visualforce pages that are behaving a good standard deviation out of the ordinary. Perhaps we should’ve chased after those! This is where Event Monitoring can go beyond security – it can help you justify which change requests/projects to allocate your time to. The next kicker is: You encountered slowness on your fancy Visualforce page that was behind or close to average request time… but did you know that you and your peer administrator/developer were the only ones using and testing it? Event Monitoring can tell you how much of your functionality is being used. So perhaps it’s those other two Visualforce page that have been utilized by a lot of users in the past few days that need tweaking!
Happy holidays. Leave your comments below or tweet and discuss with the #salesforcehacker hashtag! Many thanks also for Mike Jacobsen for his contribution on this blog.