In this blog series, Onapsis Research Labs will introduce you to the different types of audit capabilities that Salesforce has, analyze them, and see how they complement each other.
Having proper auditing capabilities (and reviewing the results) is key to maintaining a high level of security. Without it, organizations are blind to what is happening in their most critical systems and processes. Proper auditing helps to quickly detect unusual behavior that is often an indicator of misuse or worse... signal compromise.
In this series, I plan to cover the following topics:
- Login History
- Setup Audit Trail
- Event Monitoring
- Real-Time Event Monitoring
Note: Salesforce provides another interesting feature called “Field History Tracking” which tracks changes in selected fields. Although important and very useful, I won’t be covering it in this series.
Salesforce Login History
Login History is one of the most common logging facilities. You can find it under the “Settings” → “Login History” menu. It allows Salesforce Security Administrators to review and keep track of login attempts that are made to the organization’s Salesforce instance. By default, you can obtain different information about a login attempt, including username, date and time, IP address, and whether the login was successful or not. If you need additional data, you can create a custom view and add fields such as country of login origin and the HTTP method used.
The Login History stores up to six months of login information that you can download as a CSV file or compressed. (Note: If your company has a retention policy requiring that login attempts be stored for a longer time frame, you will need to manually download and store them.) Login History is included without having to pay for any add-ons, a big difference compared to other useful tools such as the “Event Monitoring” add-on.
Login History Limitations
An interesting behavior worth mentioning is that Login History does not capture login attempts by users that do not exist in the organization. When analyzing the information provided, take into consideration how long user sessions last before reaching the timeout. It could happen that you look for a login event on a certain day, but if your organization has configured long periods of inactivity (12 or 24 hours, for example), user sessions could span two days and you therefore will not find a login event for the day in question.
Another corner case not covered by the Login History is the “Login-As” feature. This feature allows Salesforce Administrators to log in as another user, useful to reproduce bugs or troubleshoot missing permissions. If your organization has this feature enabled and a Salesforce Administrator logs in as another user, it won’t be logged in the Login History as this login works using a different mechanism than the traditional login. If you need to review logins performed through this method, you can use the “Setup Audit Trail”. We’ll cover it in a future blog post.
Login History Use Cases
The Login History can be very useful to detect different attacks or adherence to compliance policies, for example:
- Password guessing attempts (a large number of invalid logins affecting one or more accounts)
- Credentials stolen or account sharing (multiple logins of the same account from different IP addresses)
- Compliance with login policies (usage of specific login methods)
If you need to perform complex searches, you can access the Login History using SOQL queries. A simple example is shown below:
Another option is to consume the Login History through SOAP API calls, but given its complexity, I’ll save this for the next blog post.
As you can see, you can consume information from Salesforce’s Login History feature to keep track of who is logging in to your organization and from where — and act accordingly. In the next blog post, I’ll continue analyzing other alternatives that complement Login History and help us to keep our organization secure. Stay tuned!