IAM Debt and Deficit

Technical debt has become a common term within the software industry. Made popular by Ward Cunningham, who developed the first wiki and was a co-author of the Manifesto for Agile Software. Technical debt was a metaphor for the long-term obligation (deferred costs) developers and software teams incur when taking shortcuts. 

"Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise."— Ward Cunningham, 1992

In "Another" 4 Pillars of IAM I covered why we need IAM. Depending on the

your organization, it could be viewed as a competitive advantage or forced cost to do business. Data without any ability to access it by humans or non-human identities, to access it would have no purpose. Companies without an IAM vision or strategy, tend to see IAM as an area to take shortcuts, many not even realizing the debt that they are accruing while thinking they saving time and effort. How many times have you being asked to grant a role with additional privileges "for now", not finalize access roles, "temporarily" use and existing "service account", "give root in development, create a local identity or credential store... etc? More concerning is when companies have strategic projects, which they want to expedite and ask IAM or security as a whole to not "disrupt them" till they get it going? This is especially true of shadow IT, mobile apps, customer apps, cloud and DevOps, and emerging technologies.

The next thing, they in production, with 100's of users and find their subject to regulatory requirements and emerge battered from their first audit. Leadership then asks the IAM team to "fix it",  thinking this is like switching on a feature, doing a simple configuration change or collect the logs centrally. Since identity and access are foundational and due to interest costs, it turns into a huge project of nearly the same costs and timelines as the original. Audit, leadership and the app team are unhappy as this derails the whole fast path strategy and goes right back into looking to go into more IAM debt by cutting costs to now bring the system into the corporate architecture and controls. The alternate is admitting failure and the waste of those resources used to "fast path" the special project, and that could cost people jobs.

To touch on the foundational nature of IAM, for those less familiar, let use a simple example. When you install an appliance, operating system or literally any software, you always need to create the first credential (often the privileged "service account" like root, admin, dba etc. If you have a PAM program, you need adaptors (tested in and deployed), privileged definitions, onboard privileged credentials, create safes, establish owners, access groups etc. If you have an identity management platform you need adapters, IBoR integration and credential management, build the roles in your role catalogue, role catalogue integration,  request management, active directory groups, service accounts,  integrate into automation, KPI, UEBA etc. I have personally never had great success retrofitting IAM to an application, as the users have what they need already - access and see anything further as unnecessary admin. Only when wanting and waiting for access are users quick to respond and this is where you can capture the required information to manage onboard the application.

IAM deficit is much like deficit programming. A very common mistake is building IAM controls for a point in time. For example, we pulled a list of users in a group last week, reviewed it and ignored changes during that week. A PAM or identity management program is a program, not a project and not built to a point in time, but as a set of controls and infrastructure that becomes core to your digital strategy. Usually, companies have a continual rotation of applications, as applications are end of life and new applications brought into the organization. Various organizations have a different level of formality and controls around introducing new applications. Each new application needs to be onboarded onto your IAM infrastructure. If your onboarding team is onboarding 3 applications a quarter, while your organization is introducing 5 applications a quarter, your IAM deficit is 2 applications or -40%. Does your IAM KPI only show how many new apps were onboarded for a period of time or does your KPI compare that to the new apps added?

When your IAM team is spending the majority of the time working on IAM debt (paying interest) and running an IAM deficit, you are losing ground.