We’ve heard repeatedly from customers that to really leverage the data Jamf Protect gathers within your SIEMs, additional information would be helpful that has never been available through the existing API.
Without further ado, let’s take a quick tour of the API changes coming to Jamf Protect very soon.
Why are there 2 streams of collected data?
If you look at the data Jamf Protect provides, there are two streams today: Alerts and Logs.
A number of you have rightfully asked why? Especially when the data is collected into a SIEM where it is cross-referenced against other events.
Well, as of early October, the Logging stream is going to be considered deprecated and will be removed altogether in the future. All of the information that flowed through the Logging endpoint is now going to come through the Alertsendpoint. Additionally, the alert field has been renamed JSON.
“But, how do I tell what’s an alert and what’s informational?”, you ask. Let’s address that.
How important is this anyway?
As data flows into a SIEM, one thing that’s critical for any broad analysis is to be clear about which data is important and what is purely informational. The informational events are rarely something that would be flagged on its own but may be used to augment a security event or to raise an alert in conjunction with other data already in the SIEM.
To make that simpler, the Alerts stream will now include a Severity property that will indicate whether a data point indicates something Informational, Low, Medium, or of High severity. There will also be opportunities to define your own values for this property.
Is there some way to tell if Protect did something about an alert?
When it comes to single panes of glass like a SIEM, it’s easy to see all the data collected. However, to accommodate some of the changes above, we are removing a few values from the Actions property in Jamf Protect’s Alerts stream. Specifically, Jamf Protect will no longer use the following values:
- ‘Log’: with the above changes, these events are now Informational alerts
- ‘Alert’ or ‘Reported’: these are replaced with the concept of severity above.
What if we want to leverage the API for other integrations?
If you use the API to query alerts, logs, etc., one of the more common questions we get is “How do I tell what’s new?” And for that, let me introduce you to the Status property for the Alerts endpoint.
The Status property for every new detection, informational event and so forth will, by default, be labeled New. When an event was Blocked, the Status property will automatically be set to Auto-Resolved.
To query alerts you can use the list alerts API which can optionally accept a filter to limit which alerts are returned. By specifying a filter of severity being equal to Informational you would effectively receive the same information you get from the Logging stream today.
Do I have to make any changes in my API usage?
We urge you to move away from using the Logging API endpoint and transition that to the Alerts as soon as possible. While the old APIs will continue to work, they will shortly be removed.
Depending on how or if you use the Jamf Protect APIs today, you may have to make changes to your usage.
As a reminder, the Logging endpoint for the API is going to be deprecated in early October and will be removed in the future.
Happy Threat Hunting!
Secure your network against threats while maintaining compliance with security policies.
by Category:
Have market trends, Apple updates and Jamf news delivered directly to your inbox.
To learn more about how we collect, use, disclose, transfer, and store your information, please visit our Privacy Policy.