CAASM Use Case #6 – Finding rogue devices on privileged networks
August 16, 2024
IT entropy. It’s like toxic gas that you can’t see, taste, or smell.
But it’s gonna get you one day.
One of the sources of entropy is the HR/IT process, “Joiners, Movers, and Leavers.” Which answers the 6th question: Who causes it (and is accountable and responsible?).
In this post we answer the 5 questions and show how to use CAASM tool to find it, fix it, and shrink future entropy.
Emergent chaos where the IT landscape drifts from a “good” state to a “bad” or “unknown” state. This is also called “Configuration Drift”.
Technical debt is also a form of entropy because it is “complexity that is hard to visualize” — think of this as problems you can’t see, like bugs that have yet to surface, or vulnerabilities you are unaware of. Doesn’t matter if the backdoor is wide open, just turn the fire up?
The JML process encompasses the entire lifecycle of an employee within an organisation, from the onboarding of new hires (Joiners), to managing internal transitions (Movers) and finally handling departures (Leavers).
Poor IT practices are, in general, to blame. That means people and process.
One universal source of IT entropy is the joint HR-and-IT process of “Joiners, Movers, and Leavers”.
This is where Role Based Access Control (RBACRole-Based Access Control is the mapping of a user or API ke…) should address this, and prevent IT entropy. But do you trust RBACRole-Based Access Control is the mapping of a user or API ke…? Can you — do you? — verify that RBACRole-Based Access Control is the mapping of a user or API ke… works? Does the universal RBACRole-Based Access Control is the mapping of a user or API ke… work for every system? Does everyone use RBACRole-Based Access Control is the mapping of a user or API ke…?
Quick example of Joiners-Movers-Leavers:
Any leakage of “controls” like RBACRole-Based Access Control is the mapping of a user or API ke… –> IT Entropy.
Joiners-Movers-Leavers process is not the *only* source of IT Entropy.
Check out the 14 CAASM use cases that identify lots more sources, from shadow IT, to ephemeral devices, and unsanctioned software.
The short answer is, Yes. But why depends who you are:
You can see from this short list that finger pointing is likely, but isn’t the answer, is it? Who’s fault is it? Who will pay to fix it? Who’s job is it?
Maybe it gets “invisibled” be shrouding it in a Somebody Else’s Problem field?
The costs of unplanned IT entropy appear in order:
Because at the heart of this there’s a missing trust-but-verify process. You can fix what you can’t see. That’s where comes in.
The challenge in “seeing” IT entropy caused by the JML process is that you need to correlate information from multiple systems.
Just looking at RBACRole-Based Access Control is the mapping of a user or API ke… on the User Directory or the Identity and Access Management system isn’t enough in complex orgs.
CAASMCyber Asset Attack Surface Management (CAASM) focuses on man… fixes this in two steps:
For example, by combining your RBACRole-Based Access Control is the mapping of a user or API ke… user directory with use cases such as CAASM Use Case #10 – Maintain an Accurate User Inventory and CAASM Use Case #9 – Finding Unsanctioned Software you can find out leavers who have left unsanctioned software behind: the possibilities are endless.
Once you’ve found IT entropy — for example, that Joan is still a “sysadmin” when she’s actually left the company — then you need to enforce your policy.
First, you need a policy! In this case, it may be that Joan’s account should be disabled and that she should be removed from groups. She should also be removed from any systems — think shadow IT, think 3rd party SaaS — that aren’t working with RBACRole-Based Access Control is the mapping of a user or API ke….
Second, you can CAASMCyber Asset Attack Surface Management (CAASM) focuses on man… Enforcements to act upon the findings and do what the policy says.
The common enforcements are:
