CAASM Use Case #6 – Finding rogue devices on privileged networks

CAASM Use Case #6 – Finding rogue devices on privileged networks

Welcome back, cybersecurity party guardians! 💂‍♂️

We’re diving into the sixth instalment of our Cybersecurity Observability use cases series.

Today, we’re hunting for the despicable underbelly of our seemingly-pristine digital world: those dirty, pesky rogue devices on privileged networks.

Imagine this: Your network is running as smooth as a dinner party, everything seems secure. Then your CISO drops this bombshell:

"Remember that NASA JPL hack? It was all because of a rogue Raspberry Pi. That couldn't happen to us...could it? How do we know we don't have our own ticking time bomb?" (Chief Information Security Officer)

Some vendors define rogue devices as “just plain malicious in nature,” this strict definition omits devices like the rogue Raspberry Pi that allowed criminals to access NASA JPL systems.

So for the purposes of this article, we’re talking about devices on privileged networks that are not supposed to be there and may be used for malicious intent.

Gulp! It’s like realizing there might be a wolf in sheep’s clothing among your flock.

Let calm commence.

This is where CAASM (Cyber Asset Attack Surface Management) and cybersecurity observability become your digital shepherd’s crook.

Gain Complete Visibility of Your Cybersecurity Assets with the SJULTRA CAASM free trial.

Table of Contents

Time to mention the unmentionables: rogue devices on your network.

“What are you on about, Steve? What is even a rogue device?”

Imagine you have a VIP party. You’re the host. Everything is going great. But then you spot someone dishevelled and behaving weird in a dark corner. It’s like that uninvited guest at a VIP party.

  • On a privileged network (VIP party)
  • Not expected to be there (uninvited)
  • Potentially up to no good (might steal the silver)

These could be anything from a hacker’s carefully planted device to an employee’s personal gadget connected where it shouldn’t be. They’re the “known unknowns” that make security pros reach for the antacids.

Steve, I'm busy managing my known knowns and unknowns... are you asking me to look for unknown unknowns? (YES)

Enter SJULTRA's Cybersecurity Observability Service

This is where SJULTRA’s CAASM services, powered by Axonius, becomes your digital bouncer.

It’s like giving your security team x-ray glasses and a guest list for your network.

Axonius pulls data from multiple sources:

  • Network/Infrastructure Data
  • Directory Services (like Active Directory or Azure AD)
  • Configuration Management Tools (like SCCM)
  • Virtualization Tools
  • Vulnerability scanner consoles

By correlating this data, Axonius can spot the devices that are crashing your network party. It’s like finding Waldo, if Waldo was a potential security breach!

Book your free CAASM trial now

Get visibility on all 14 cybersecurity observability use cases in less than 30 days with SJULTRA.

Let's get querying

Once we’ve got Axonius set up (remember, SJULTRA offers a free 30-day trial), we can start hunting those sneaky rogue devices.

Want to find devices on a privileged network that don’t belong? Here’s how we do it… starting with a question:

Show me all devices on our Fortigate network that aren't in our VM environment, aren't in Active Directory, aren't in Hyper-V, aren't managed by Jamf Pro, and have been seen in the last four days."

The longer the question… the longer the query… which is why the Axonius query wizard is helpful…

sjultra axonius query use case 6 finding rogue devices

But us hardcore Axonius users love a bit of (AQL) — why? Because we can document it, repeat it consistently, and iterate on it… and automate it…. (Did I mention the SJULTRA Free Trial where we do this for you/show you?)

				
					(adapters_data.fortigate_adapter.id == ({"$exists":true,"$ne":""})) and not (adapters_data.esx_adapter.id == ({"$exists":true,"$ne":""})) and not (adapters_data.active_directory_adapter.id == ({"$exists":true,"$ne":""})) and not (adapters_data.hyper_v_adapter.id == ({"$exists":true,"$ne":""})) and not (adapters_data.jamf_adapter.id == ({"$exists":true,"$ne":""})) and specific_data.data.last_seen >= date("NOW - 4d")
				
			

This query finds all unmanaged devices without security agents or management solutions.

Here’s an example of the returned results:

sjultra axonius results use case 6 finding rogue devices

So now we know all rogue devices on any Fortigate network.

But what about a guest network? 

Let’s first say it in English “pseudocode”:

The following Axonius Query Language (AQL) statement is looking for specific devices or assets in a network inventory system. Here’s a breakdown of what it’s doing in simple English:

  1. It’s looking for devices that:
    • Have a Fortigate adapter ID
    • Do NOT have an ESX adapter ID
    • Do NOT have an Active Directory adapter ID
    • Do NOT have a Hyper-V adapter ID
    • Do NOT have a Jamf adapter ID
  2. The devices must have been seen in the last 4 days.
  3. For the Fortigate adapter, it’s excluding any interfaces that have “guest” in their name (case-insensitive).

In essence, this query is trying to find devices that are:

 

  • Managed by Fortigate (a firewall/security solution)
  • Not managed by certain virtualization platforms (ESX, Hyper-V)
  • Not part of Active Directory
  • Not managed by Jamf (an Apple device management solution)
  • Recently active (within the last 4 days)
  • Not on guest networks

 

 

				
					(adapters_data.fortigate_adapter.id == ({"$exists":true,"$ne":""})) and not (adapters_data.esx_adapter.id == ({"$exists":true,"$ne":""})) and not (adapters_data.active_directory_adapter.id == ({"$exists":true,"$ne":""})) and not (adapters_data.hyper_v_adapter.id == ({"$exists":true,"$ne":""})) and not (adapters_data.jamf_adapter.id == ({"$exists":true,"$ne":""})) and specific_data.data.last_seen >= date("NOW - 4d") and not adapters_data.fortigate_adapter.interface == regex("guest", "i")
				
			

We've found the unscanned devices - now what?

Great, we’ve uncovered these hidden cloud instances. What’s next? This is where the “action” part of our cybersecurity observability comes in. With Axonius, we’ve got four aces up our sleeves:

  1. Notify: Send alerts via email, Slack, Syslog, or CSV (because who doesn’t love another alert about cloud security?)
  2. Create Incident: Generate tickets in systems like ServiceNow, Jira, or Zendesk
  3. Enrich Device or User Data: Use tools like Shodan, Censys, or Portnox to show what’s publicly known about the instance
  4. Update VA Coverage: Automatically add the cloud instance to the next scheduled vulnerability assessment scan

Summary

And there you have it, network party planners! 🥳

That’s how we turn the sneaky threat of rogue devices into a manageable, observable process.

It’s not just about finding unexpected guests; it’s about making sure we know everyone at our digital soirée.

Remember, this is just 6 out of 14 standard use cases we help our customers with as part of our CAASM Concierge service. And guess what? You can get it for free with our SJULTRA Axonius CAASM Free Trial.

In the world of cybersecurity, an uninvited guest can ruin the whole party. But with the right tools and a bit of observability magic, we can keep your network exclusive and secure.

Stay vigilant, keep querying, and may all your network parties be invite-only!

Axonius documentation and Videos

Read the Axonius documentation: Find Rogue Devices on Privileged Networks.