Part 1: Identity and Access Management done right
This is part one of a two-part series discussing an innovative way to manage and enforce authorizations. This part paints the ambition of an enterprise-wide system to manage user privileges and control their access to information. It sets the stage for part two, where I paint an interesting solution to fulfil this ambition.
Setting the stage
Identity and Access Management is a core feature in information security. Every organization needs a way to first identify and then to authenticate the users of their information – be it humans, computer systems, or novel forms of artificial intelligence – to establish their permissions. Fortunately, mature standards such as OpenID Connect have emerged, to help implement single sign-on and to provide a lingua franca for the identification of those users.
An Identity is a means to identify something. You have a name, a social security number, a mobile number, any number of email addresses, each of which may be used as an identifier. Not every identifier is unique. In IT Systems, that’s often problematic, so we go to great lengths to create unique identifiers. Similarly, we try to prevent people from having multiple identities. Think of a patient at a pharmacy. If they have subscriptions from different doctors under different identities, it would be easy to miss a harmful drug-drug interaction. With a single Identity, an alert may be automatically generated. This requires a both a shared and a well-managed identity system. All this is part of Identity Management. Obviously, there are also downsides of a shared identity, but that’s outside the scope of this blog.
Authentication is about establishing authenticity. You may claim you are the person as identified by eves@dropping.it, but I need some proof before I believe it. You can share proof through something you and I both know – a password or some other kind of secret code –, something I know you have in your possession – a registered app, a phone number, an email account, a private key, a registered device, a passport –, and of course something I know of your bodily characteristics – finger, face, iris, hand palm. Obviously, this is something that needs to be managed too. Things may change (phone number), must change (password), or slowly evolve (face characteristics).
Authorization is the scope of information you are allowed to access, your level of access, and potentially the conditions of access. Conceptually, it is the simplest of the three. However, managing it effectively is often a challenge. There is so much change to keep track of, and there are often multiple systems and actors involved, making it difficult to keep authorizations always up to date. That makes Access Management an interesting capability.
In IT, typically, a principle of least privilege is implemented, granting any user no permissions unless they really need it. Additionally, access to digital resources must restricted to only those the particular user has permission to. This is often taken for granted, but authentication, identification and authorization are pretty useless unless your directories can be trusted, and your access is effectively controlled.
Digital resources are the fabric the world wide web is built from. It’s the ‘r’ in url, uri, and urn. It’s an abstract term, recognizing that a location on the web can point to any kind of digital thing – a bit of structured data, a document, a dashboard, a sensor, an algorithm, to give a few concrete examples of resources.
With the proliferation of cloud computing, especially with highly distributed cloud-native architectures, this has become more challenging than ever. Yes, zero trust is still getting more traction, but it’s also true that truly practicing it is far from straightforward. Here, the pessimistic view of the world is the generally accepted norm: assume nothing it’s secure unless proven otherwise. In this blog, I present some fresh ideas on how to rethink your access control and thus get your zero trust right.
Principles
When you design a reference architecture for Identity and Access Management, it is a good practice to start with getting alignment with your stakeholders on the purpose of the architecture. While details may vary, I see many organisations converging to these three main objectives.
- Permission granting complies to the least privilege principle.
- Permissions are always enforced as granted.
- Permission enforcement can be proven.
In other words, you make a bold promise, you keep the promise, and designated authorities can verify that you kept your promise indeed. Without exceptions.
If you think this sounds as too high bar to cross, please read on. There is a very pragmatic implementation I’m going to explain in a bit. But first, I need you to understand the proper scope.
Scope
It’s vital to establish a clear scope for any architecture, and this one is certainly no exception. Traditionally, in my experience at least, the ‘enterprise applications’ pretty much summed up the scope for Identity and Access Management. In other words, it used to focus on protecting access to enterprise resources. And with siloed applications, that worked pretty well. With enterprise integration, however, things started to become complicated – especially when systems were opened up for 3rd-party integration. Recently, there is the added complexity of distributed and mobile networks, making virtual borders in your IT-landscape increasingly permeable. How to manage access to your services, resources, digital assets, if you do not manage the users who are accessing those? Worse still, if you’re not even managing the client applications those people are using?
Most of the times, managing access to APIs is treated quite differently from managing access to applications. Often, it’s a completely separate process. And sometimes it’s even being managed in a different part of the organization. Now, if you look back at those business objectives, it’s less than obvious how to draw a line between permissions to access an application and permissions to access an API resource. It’s literally just two different types of interfaces – a user interface and an application programming interface. Moreover, an internal client application –perhaps a single page web application or a mobile app– may very well consume the same API as the external client application.
Remember, “users” can mean all kinds of identities, in this regard. I’ve already mentioned humans, computer systems and forms of artificial intelligence that are somewhere on the spectrum between system and human. With our increasingly distributed architectures, and new kinds of computing – natural language processing, self-driving cars, autonomous trading systems, robots, drones – a more holistic approach to information security is urgently needed. Separating API access control from application access control is no longer fit for purpose. Cracking that nut will unleash a significant value to your business. Being in full control of the information you are sharing will both prevent damage from information leakage and enable deep collaboration inside the organization as well as with business partners.
Helping you to select an IAM solution
Download nowOne of the largest and perhaps most embarrassing breaches of all time was the SolarWinds supply-chain attack. SolarWinds Corporation is an American company that develops software for businesses to help manage their networks, systems, and information technology infrastructure. From the hackers’ perspective, this company was an acclaimed prey item. After all, software monitoring the core of a computer network has wide access across all the vital systems of an organization.
Presumably Russian hackers succeeded in injecting malicious code providing a backdoor into its “Orion” monitor, thus infecting many of Solarwind’s 18 thousand customers at once. Including some very high-profile ones – the Pentagon, the FBI, and the National Nuclear Security Administration. Although details of the leaked information are scarce, it seems safe to assume the network monitoring software gave access to more assets than necessary for network and performance monitoring alone. Once again, trusting suppliers proved risky. The company was fined a hefty $26 million and suffers from a blemished reputation. Its market cap has roughly halved and shows no sign of recovery almost three years after the hack was revealed.
Since we cannot move back to the closed networks of the past, the only sensible scope for access management is all your digital assets and all the information flowing in and out of those assets, regardless of location, technology, or user.
Think for instance of
- Information technology, Operational Technology and Engineering Technology.
- Access by an operator, administrator, regular employee, client, supplier, business partner, authority, …
- Access via local console, Intranet, Extranet, VPN, Citrix desktop, Cloud desktop, or regular Internet.
- Data kept in Relational databases, in no-sql databases, in files and folders, or in case management or document management systems.
- Data exchanged through messages, alerts, events, emails, batch files, …
- Systems managed in the Cloud, in private datacenters, on local machines, on mobile devices, and even IoT devices living on the edge.
- Websites, mobile apps, APIs, excel sheets, dashboards, reports, …
And then think again.
Business value
I know, it sounds overly optimistic to assume such a large and diverse scope can ever be controlled in a consistent and effective way at all. It may seem impossible at least without breaking the bank and losing all your agility. But not fully knowing what you have exposed, not knowing who has access, and not knowing the risks involved is hardly an attractive proposition either. Perhaps you suppose it can only be done in a relatively small organization with a strict hierarchy. Trust me, my solution not only makes sense from a security perspective, but it also scales well to large and complex organizations.
Now, please think a minute of the potential benefits it would bring you. A single point of administration for users, applications, and their permissions. If necessary, managed as a federated web of trust. Well-managed, conforming to guidelines, and consistently enforced. And best of all, always up to date.
I think it can be done. In fact, I’ve been part of such an implementation before. Moreover, I strongly believe that only organizations that take a strong enterprise view at controlling access to their digital assets will become and remain successful in the digital age. Authorities are increasingly demanding it, customers are expecting it, and it’s safe to assume that hackers keep challenging it. So, without question, it is important. But is it urgent enough to take action now? Well, I can only remind you that you shouldn’t wait for some unfortunate event making it more urgent than you’d wish for.
