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.
What is IT 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?
Where does IT Entropy come from?
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 (RBAC) should address this, and prevent IT entropy. But do you trust RBAC? Can you — do you? — verify that RBAC works? Does the universal RBAC work for every system? Does everyone use RBAC?
Quick example of Joiners-Movers-Leavers:
- Joan joins Acme Corp as a global sysadmin. Does she get access to what she needs and no more? How do you know?
- Joan leaves the sysadmin team and joins sales: are her sysadmin permissions revoked? Does she have only sales permissions? Or a mix?
- Joan leaves Acme Corp. Has she been completely removed from all IT systems? Including SaaS app subscriptions?
Any leakage of “controls” like RBAC –> 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.
Should I care about IT Entropy?
The short answer is, Yes. But why depends who you are:
- Are you accountable for IT, as a leader?
- Are you responsible for implementing the JML process as part of the HR-and-IT process team?
- Are you a team manager or individual contributor that will report any unnecessary privileges?
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:
- The cost of the problem it causes and how long that problem lasts.
- The cost to find the problem.
- The cost to fix the problem.
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.
How do I find IT Entropy cause by the JML process?
The challenge in “seeing” IT entropy caused by the JML process is that you need to correlate information from multiple systems.
Just looking at RBAC on the User Directory or the Identity and Access Management system isn’t enough in complex orgs.
CAASM fixes this in two steps:
- Connect all of your systems — devices, tools, ticketing, directories (there are 8 classes) — to CAASM (it has 1,000+ adapters) and start slurping that data.
- Use CAASM Queries (wizard of query language) to cross-query user directory/IAM with systems like VMware or a SaaS platform, including ticketing.
For example, by combining your RBAC 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.
How do I fix IT entropy?
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 RBAC.
Second, you can CAASM Enforcements to act upon the findings and do what the policy says.
The common enforcements are:
- Enable/disable users in Microsoft Active Directory
- Sending a Slack message with details to notify team members
- Creating a helpdesk ticket in ServiceNow, Jira, Zendesk, etc. to notify IT and security teams
- Adding a tag in CAASM for internal tracking purposes
- Enriching the user data with HaveIBeenPwnd to identify users in breaches, pastes and pwned passwords identified by the ‘Have I Been Pwned’ (HIBP) website.
