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.
“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.
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)
This is where SJULTRA’s CAASM services, becomes your digital bouncer.
It’s like giving your security team x-ray glasses and a guest list for your network.
CAASMCyber Asset Attack Surface Management (CAASM) focuses on man… More pulls data from multiple sources:
By correlating this data, CAASMCyber Asset Attack Surface Management (CAASM) focuses on man… More can spot the devices that are crashing your network party. It’s like finding Waldo, if Waldo was a potential security breach!
Once we have CAASMCyber Asset Attack Surface Management (CAASM) focuses on man… More configured (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."
But us hardcore CAASMCyber Asset Attack Surface Management (CAASM) focuses on man… More 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:
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 CAASMCyber Asset Attack Surface Management (CAASM) focuses on man… More 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:
In essence, this query is trying to find devices that are:
(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")
Great, we’ve uncovered these hidden cloud instances. What’s next? This is where the “action” part of our cybersecurity observability comes in. We’ve got four aces up our sleeves:
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 CAASMCyber Asset Attack Surface Management (CAASM) focuses on man… More Concierge service. And guess what? You can get it for free with our SJULTRA 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!
Read the documentation: Find Rogue Devices on Privileged Networks.
