12 January 2016

Logging Salesforce User Activity with Heroku's Logplex

If you can't already tell, I'm huge advocate of logging user activity. There's something incredibly powerful about understanding what people did in the past. I guess it harkens back to my days as a high school history teacher where I would tell everyone on the first day of class that students who fail my class are doomed to repeat it.

In my quest for understanding how salesforce customers want to log activity and measure it, there are some consistent themes I've heard:
1. the use case always drives the granularity of the data we need to capture
2. while real-time isn't always necessary, it's almost always desired
3. I really want one place to go to for log data
4. if I have access to the raw log data, I can always slice-and-dice it the way I want in my reporting app of choice

One interesting solution that I've been playing with is capturing events in Salesforce orgs and sending them over to Heroku. If you haven't heard of Heroku before, you should check it out. It's a platform for developers to effectively deploy and manage their applications. One of the great advantages of Heroku is it's great add-on platform called Elements. Whether it's cache, video processing, data storage, or monitoring, it's easy to plug Heroku apps into a great ecosystem of app providers.

Logging Salesforce user activity is pretty simple:
1. I created a polling app that runs on Heroku. In my case, I created a python script that polls Salesforce every minute to retrieve Setup Audit Trail events. But it could just as easily captured Login History, Data Leakage, Apex Limit Events, or really any object accessible via the Salesforce API.
2. The python script writes Salesforce user events to the Heroku logging system called LogPlex
3. LogPlex is integrated with a series of add-ons including Logentries, Sumologic, and PaperTrail. It can also be integrated into other back end systems like a SIEM tool or notification apps like PagerDuty

The advantages of this solution include:
  • it's near real-time (or as real time as the frequency of the polling app you create)
  • it has the ability to further integrate events from other Heroku apps that you've built
  • Heroku has a great add-on ecosystem that makes it easy to turn these events into insights



The disadvantages of this solution include:
  • Heroku's LogPlex only persists the last 1500 events and can be lossy since it was really intended to be used for logging performance trends rather than security events like escalation of privileges.
  • the polling app will count against API limits. If it polls every minute, it will cost you 1440 API calls per day.
To try this solution, check out the sample Setup Audit Trail python script on my Github Repo.

07 January 2016

Time For Your Security Health Check


As a Salesforce administrator, have you ever spent to much time researching security for your cloud applications? Ever felt frustrated trying to find the security setting you need? That's why Salesforce created the Security Health Check, available to you in Spring '16 release. 

Why we built Security Health Check

Security Health Check was built to bridge the gap with security requirements and actual implementations of security:
  • Difficulty understanding and staying up-to-date with everything security related and how it relates to your business and cloud applications.
  • Configuring security requires security understanding of the business and application environment
  • Due to changing business landscape, security requirements also keep changing and customers need information how security has been configured
  • Administrators need to validate compliance across their application portfolio
  • Identify needs for ISV or add-on security services like Salesforce Shield

Using Security Health Check

Security Health Check shows an overall score reflecting how well different security settings in your Salesforce application meet the Salesforce standard baseline. This baseline is the Salesforce recommended practice for implementing highest level of security. 

Under the hood

The typical Salesforce "org" has about 20 different security nodes in Setup. Each node consists of many different security settings. We've simplified this experience by elevating popular setting groups to the Health Check page. We evaluate each setting's security implication, its implementation, and apply proprietary risk scoring and weights to each security setting.

What’s Next for Health Check?

We are continuously expanding the scope and functionality of the Health Check on the Security roadmap. Future features include (under Safe Harbor):
  • Exposing Health Check API for ISVs and security audits
  • Adding more setting groups like Certificate and Key Management, Single Sign On and Login Access Policies
  • Viewing Health Check across multiple Salesforce applications (org’s)

Try It!


In Setup, find Security Health Check by typing "Health Check" in the Quick Find box to find it under Security Controls.
We hope you use the Health Check and that it becomes a favorite security destination for you.
Please feel free to leave your comments, suggestions and feedback below. Thank you!

05 January 2016

Using Asynchronous SOQL with Event Monitoring

Working with BigData requires re-thinking how you work on the Salesforce platform. Since you can assume that you're working with billions of records instead of thousands or even millions, common tasks like aggregate functions (e.g. SELECT count() FROM LoginEvent)  or complex queries (e.g. SELECT username FROM ApiEvent WHERE Soql LIKE '%SSN__c%)) are difficult to perform quickly. By quickly, a SOQL query needs to typically complete within two minutes or it will timeout.

The advantage of working with BigData on the Salesforce platform is that use cases involving billions of records are now achievable for a variety of use cases including:

  • long term adoption metrics
  • audit
  • performance monitoring
  • archiving

As a result, it's better to think of BigData as a data lake, where massive amounts of data can be processed at scale to meet any of the above use cases.



In a more concrete case of user login events which we now store in the Salesforce equivalent of BigData called a BigObject, it becomes important to re-think how you can work with the data at scale. This is especially important since not all capabilities that we've come to expect on the Salesforce platform, like operational reports or workflow, may be possible with a BigObject. It's a trade off of scale for limited platform capabilities.



For instance, rather than querying a BigObject like LoginEvent using a convention like synchronous SOQL via the API for use in real-time applications, it's better to use a new convention called asynchronous SOQL, currently in pilot, for extracting select use cases with analytic apps.

Asynchronous SOQL is similar to the Bulk API in the way it's job based and invoked using the API. But instead of the full CRUD capabilities with Bulk API designed primarily to work with the data off-platform, asynchronous SOQL provides a query-and-insert capability to retrieve sets of data and insert it into a structured object. Currently, this means moving data between BigObjects and custom objects on the platform.

This doesn't just mean BigObject only data but really any use cases where there is a significant amount of data including (but not inclusive of):

  • LoginHistory
  • SetupAuditTrail
  • AccountHistory (or any other field history object including Field Audit Trail)
  • Profile or PermissionSet
  • AccountShare (or any other sharing object)

For instance, you may want to create a subset set of data hourly, daily, or weekly in order to have the full transactionality of the Salesforce platform at your fingertips. Using this design pattern, we can utilize schedule and batch Apex to migrate subsets of data from a BigObject into custom objects. For instance, the ability to extract last week's worth of LoginEvents in order to report on it.



As a result, it's now possible to report on it using operational reports:



or with Wave for advanced exploratory capabilities:



or utilize workflow for generating tasks and alerts:



Asynchronous SOQL provides a new way of interacting with large sets of data on the Salesforce platform. For Event Monitoring use cases, it brings us closer to the kinds of analytic apps that enable CISOs and VPs of IT to understand the state and health of their organization.

To try this out, contact your Account Executive to have the Asynch SOQL pilot enabled in your org. Then just download the sample code and configurations in my Github asyncSOQL repository to get started with Event Monitoring use cases like Login Forensics, Data Leakage, or Apex Limit Events.