IT Operations' Biggest Enemy is Human Error
The type of infrastructure your organization is leveraging (Cloud / Hybrid / On-Prem) may already be complex, or is heading in that direction. New products are added, and some tools may face deprecation as a result. These backend changes are often managed by System Administrators while Help Desk teams provide triage for internal users. Coordinating and monitoring the progress of system changes can be challenging and will lead to human error.
Perhaps human error was unknowingly planted during the planning and staging phase of your deployment effort, and moving forward with the implementation would further exasperate Help Desk personnel dealing with high volumes of unplanned traffic.
Planning & Staging: Simplifying the Effort
IT automation has come a long way over the past decade, yet the practice of planning deployment efforts still requires a good understanding of your environment’s current state.
How many products or tools does the typical System Administrator manage? A dozen or perhaps dozens? Imagine the time and resources it takes to properly scope and communicate a plan to implement a new Endpoint Detection & Response (EDR) tool for all user endpoints. To start, a CSV inventory of existing assets would need to be downloaded from your Asset Management tool, Mobile Device Management (MDM) software, and existing EDR for review.
Do all endpoints meet the technical specifications required to run the new product? Are there devices managed by your MDM that are not logged into your Asset Management tool? How much of this effort can be automated? The thought of wasting all of that time reviewing and assembling a spreadsheet to share with project stakeholders was always something that I personally dreaded. Why? Someone could treat the “official migration” spreadsheet as a checklist, and before you know it someone has marked it up beyond recognition. The spreadsheet approach also becomes outdated quickly as new workstations or entities enter or leave the environment. It is a static view of a dynamic environment, quickly becoming outdated when change management projects span longer phases or timelines.
JupiterOne addresses this by giving a more up-to-date picture of your environment as it changes in real time. By ingesting your Asset Management, MDM, and EDR data you can take advantage of JupiterOne’s Insights dashboards to map out the status of your existing environment. You can leverage out-of-the-box dashboards to visualize your data or create a custom one. Once you have a dashboard staged, all that’s left to do is share it.
Managers and team leaders can use the dashboard you have created to report status updates to upper management, and since the ingested data is refreshed periodically there is no need to manually supply that scrappy spreadsheet everyone has marked up.
Deployment & Monitoring: Alerts Go a Long Way
Now that you have a dashboard to monitor your deployment, let's talk about JupiterOne Alerts and how your team(s) could leverage this feature to identify a variety of EDR issues that may surface. During an EDR migration, we typically monitor the installation of the new and uninstallation of the old EDR. What if the deployment fails and you end up with endpoints running two different EDRs or none at all? Creating meaningful, visible, and actionable alerts within JupiterOne can drastically improve your team’s response and remediation efforts.
With JupiterOne’s Alerts feature, the results of a query used to identify endpoints missing EDR agents can broadcast a list of the affected assets in Slack to notify the appropriate stakeholders. The same alert could also be configured to automatically create a Jira Service ticket or ServiceNow Incident, or transmit an email to another ticketing system if your support tool has an automation in place to convert emails into Help Desk tickets. With one JupiterOne alert your team will be notified for visibility and a ticket generated to take action.
Simplify Alerts: Suppress Redundancies
Notification overload and fatigue can quickly lead to complacency and human error. I have witnessed first hand how a dedicated channel for alerts and feeds are dumped into a suppressed Slack channel, or filtered into a random email sub-folder labeled “IT Noise For Review” with an unread percentage well above 90%. Meet with your team as needed to discuss which alerts really matter, and establish a frequency based on severity. Informational alerts are far less important, and could instead be configured within JupiterOne as an informational dashboard to share as needed.
Using the EDR deployment example mentioned throughout this post, I can configure a single JupiterOne alert from the ingested data into a single query to determine if an endpoint agent goes inactive, becomes infected, or fails to update. One consolidated alert looks much better than several alerts stacked up, and is more likely to receive the attention of someone.
JupiterOne’s use case is not limited to security practitioners, and should be leveraged by other teams within your organization. Partner with your IT Ops teams to enhance your company’s utilization of JupiterOne.
