The Problem with I&AM (Identity & Access Management)
By Gehan Dabare, Director for Identity & Access, Bank of Tokyo-Mitsubishi
It has ALWAYS been important to have a handle on who has access to what resources. If you don't know who has access and who is who - how can you prevent bad things from happening? Managing who has access to resources is the foundation of any cybersecurity program. In the post Enron world the need to provide assurance of the control became important. This need to evidence that your controls are in place that they are designed correctly and that they are executed well is the difference.
Many companies realize they need to get a grip on I&AM when they get an audit finding or a significant deficiency in their SOX report. They actually begin to pay attention when there are a few repeat findings or when they see that I&AM is impacting the grades of quite a few audits. Maybe even a failed SSAE16 report (or two)—which can impact revenue. Or, in the worst case, god forbid when there is a security event where an external actor has gained access to company resources.
Thousands of people are working on this problem and billions of dollars are spent every year on it. Everyone has the problem (even if they don’t realize they do) and everyone thinks it’s a tech problem to solve. Many companies start out thinking it’s a problem that can be solved relatively easily using the same people that have solved technology problems before. Most companies realize this is not the case.
"Managing who has access to resources is the foundation of any cybersecurity program"
Identity & Access is a business risk that technology has to help resolve. Think of a world where there were no computers, (yes Millennials that happened!) people still ran businesses everything from the corner store to multinational companies like the East India Company. People took precautions to safeguard the important resources of their business including the books and records of the firm. The business owned the risk and the business managed the risk. The introduction of computers has not changed anything, the business still owns the risk and needs to manage the risk – since most business people do not understand the complexities of the tools they use they need the help of technologists to help understand, resolve and manage the risk. That does not make I&AM a technology problem, it remains a business risk.
The nature of the I&AM problem that makes people underestimate the scope and cost of getting to green are:
1. Legacy: If you have old applications that work just fine for your business needs and they were designed by your great grand uncle Esteban in 1962 in Fortran and he didn’t worry about access management because it was just him and his cousin Eddie that ran the business. And you still use that app – and you deem it key to your business and it, say, touches your books and records – guess what? – you have to do access management on it. Think of all the mainframes and all the code running on those mainframes and all the datasets that the code has access to and how almost no one remembers whyall the decisions along the way were made.
2. Diversity: Business processes use applications written in any language, on any platform, using any database – if they are key to your business process – it’s in scope. Yes including that cool hipster app on your iPhone and the not so cool one that runs on a VT100 terminal emulator with a green screen.
3. Layers: The first time most people try to solve the I&AM problem they happily focus on the application. “Look all my application access is sorted! – all good, done and dusted”. “Audit finding? What!? How!?” Oh yeah assurance is about access – not about the application layer access. In addition to who can access the App, we have to provide assurance on: Which support people can access the operating system on the server that the application runs on? Who has access to the database the app users to store its data?
4. Dependency: In many cases Identity & Access depends on already established technologies, processes, inventories etc. – things like corporate directories, inventories of applications, people, servers etc. When you attempt to fix I&AM you uncover all that is broken (or nonexistent) in all the systems you depend on – this does not make you a very popular person. :)
5.Complexity: Once you figure out what resources you need to have assurance on, what downstream resources they rely on and what IT resources, information sources you need to be able to manage all this and you develop the best most elegant sci-fi like system – you still need to implement it! And most importantly keep it running day after day everyday and detect when any of this very complex system you designed fails to deliver. One day my dream will be real: “Alexa! who has access to the general ledger?”
6.Cost: Money may not buy you happiness but it will buy you solutions and if you hire intelligent people (who are not cheap) then with time you will have assurance. Solving your I&AM problem will cost more money than you anticipate and more money even than your technology partners are brave enough to tell you it will cost.
That in a very generic sense is the true nature of the I&AM problem. In this article, I have not dealt with the specifics and all the components that go into I&AM: AuthN, AuthZ, Cert, Privileged Access and all the other cool sexy stuff. I am very aware I have not suggested a solution – other than maybe spend lots of money and hire good people which is obvious. I will detail my approach to solving the problem in another article. I wanted to start with the problem statement – acceptance is the first step. Did I state the high level problem correctly? What did I miss? Do you disagree with the problem statement? Would love to hear from you.