Several months ago in “Why IT teams should be using JupiterOne,” we discussed the complexity that accompanies software deployments for endpoints and one (of many) ways to simplify the process by leveraging JupiterOne. The data points for this topic were pretty straightforward: add the integration for the product you are deploying, create Insights Dashboard widgets to measure deployment progress, and leverage alerts to determine where deployments have failed.

In this article, I’ll analyze some of the lessons learned since that earlier article and look at our recent Automox Patch Management deployment. 

The widgets we created to track the EDR rollout simply told us how many endpoints had SentinelOne installed, and we used that list to compare the total number of active endpoints registered with our Addigy MDM integration. Many questions came to mind after the completing the deployments:

• Is there a better way to monitor the success of a software installation from the JupiterOne app itself?
• Which devices are compliant versus non-compliant and how can we measure historical trends? 
• How can I make my IT-related integrations more purposeful? 

The Automox rollout - Taking deployments to the next level 

In The Cyber Defense Matrix there’s a chapter dedicated to “Improving Situational Awareness” that covers the concepts of visibility, perception, and comprehension; this resonates with the very questions I asked myself with respect to which data points truly matter to teams responsible for deploying software. We took these concepts and applied them to our most recent deployment of the Automox Patch Management solution. For this deployment scenario, we are adjusting our approach for distributing software while leveraging JupiterOne as our ultimate source of truth.

Faulty visibility 

“To perceive something, we have to be able to see it. Oftentimes, we do not have the visibility that we need.” - Sounil Yu, The Cyber Defense Matrix

The original Insights Dashboard widget we created months ago for the SentinelOne rollout fell short of its purposefulness in terms of value for a couple of reasons. First, the numeric data on the widget only updates when the integration responsible for providing the latest data ingestion completes. Our SentinelOne integration is configured to ingest new data every four hours.

The data does not convey how many endpoints are missing the SentinelOne agent, nor does it provide data pertaining to agent performance. Second, the widget consists of a single J1QL managed question that fails to provide historical context for results that were reported yesterday, last week, or even last month. The number doesn’t reveal whether end user compliance with SentinelOne is improving, stagnant, or getting worse over time. 

Data without visibility is useless, so how did we avoid the same mistakes during the Automox rollout?

Faulty perception

“Just because we see something does not mean that we are consciously aware of it.” -  Sounil Yu, The Cyber Defense Matrix

Taking data at face value does not provide real context into the actual data we need to be consciously aware of. An Insights Dashboard widget that only provides numerical data to show how many endpoints have Automox installed is simply not enough, as it does not represent the true count for how many Automox agents are installed … and of those, which ones are active versus inactive. By adding a saved question that queries both active and inactive devices we can see how these agents are reporting back. 

The slightly improved query still doesn’t provide much more context if we don’t have data capturing historical trends, so this is where enabling daily trend data collection for your managed questions comes into play. This feature can be toggled on simply by editing a saved question (screenshot below.)

With daily trend data collection enabled, you now have better visibility into the Automox active versus inactive question; this is especially useful for tracking endpoints that have gone offline for an extended period of time. The graph below shows us which devices are active (green) versus those that are inactive (blue). From the time we initiated User Acceptance Testing (UAT) in mid-February until we kicked off the Automox agent rollout on February 28, we were able to measure our installation progress.

While the Automox Device Active Status graph was useful in measuring our Automox deployment progress, there are still outstanding questions that need to be addressed. We need better comprehension of the data we’re capturing from the Automox integration to better illustrate how Automox is really performing.

Faulty comprehension

“Even if we can see it and perceive it, we might not comprehend what we are looking at” - Sounil Yu, The Cyber Defense Matrix

Labeling is a very powerful tool when using JupiterOne. Questions should be labeled along with the data points you are looking to capture for your team members. In the example below, we want to know what we’re looking for in a managed question to define how those answers should be displayed when executed.

Active Device Query: “FIND automox_device with lastRefreshedOn >= date.now -7 days as a RETURN a.displayName as UpdatedDevice”

Inactive Device Query: “FIND automox_device with lastRefreshedOn < date.now -7 days as a RETURN a.displayName as OutdatedDevice”

In this instance we set the Automox agent inactivity threshold to a week, yet of all the active endpoints, which devices are actually receiving scheduled patches from Automox? We have a question for that!

Compliant Device Query: “FIND automox_device WITH compliance=true AS a RETURN a.displayName AS CompliantDevices”

Non-Compliant Device Query: “FIND automox_device WITH compliance=false AS a RETURN a.displayName AS NonCompliantDevices”

The “compliant” API property for the Automox integration is a defined set of rules and conditions that determines whether a device is compliant. When we create this question with daily trend data collection enabled it becomes much easier to identify how our endpoints are faring once Automox is installed. To graph the question above, simply create it, run it, and click the “add trend chart to insights” icon. You will be given the opportunity to choose which dashboard the new widget should be sent to.

Helping IT teams with more effective patch management

The Compliant vs Non-Compliant Automox Devices widget is a great tool for monitoring patch management issues within your environment. During the UAT phase of the Automox rollout we didn’t have too many endpoints categorized as non-compliant, yet when we initiated the software deployment to our production environment, our non-compliant device list started to trend in the wrong direction. The spike in non-compliant devices reporting to JupiterOne indicates one or multiple issues with these endpoints.

The age-old question famously asked by your Help Desk team, “Have you tried restarting your machine?” most certainly applies here. As with most software products that are installed on a given device, a reboot is almost always needed in order for endpoint agents to function properly. This is a common step required for installing management tools since there are backend processes required to be on and running in order for the product to work effectively. 

If a non-compliant device has already restarted there could be an issue with the app’s OS-level permissions to run at the OS level, or perhaps a particular product in need of patching has a built-in self-updating mechanism that may not play nice with a patch management system (cough, Zoom, cough). If that is the case, excluding that software may resolve a compliance issue. 

With the non-compliant device data in hand, I can begin remediation efforts and track my progress thanks to the capture and retention of historical data for my JupiterOne managed question.  

Parting words - JupiterOne isn’t just for security teams

As you saw in this post, JupiterOne’s use cases are not limited to security practitioners and should be leveraged by other teams within your organization. Partner with your IT Ops teams today to enhance your company’s utilization of JupiterOne, which could not only improve security, but also improve the management of your IT systems, resulting in a better user experience.