Identity Access Management (IAM)
I just read a recent article about IAM (Identity Access Management) projects, and the level of complication that can ensue when trying to plan and implement a project of the scale and scope that a comprehensive IAM project entails.
The theme of the article is that AD (Active Directory), in many enterprises, is the identity store of choice; the idea being that if you could align your enterprise to use a single account, there is an economy of scale, reducing the number of places where access and permissions would need to be managed.
Lack of Active Directory Optimization
This is a common theme today and we have seen this idea presented many times and in many places but not always in such a positive light. A number of system security conscious organizations are looking to avoid this very model. Learn more…
The Anatomy of an Attack
Modern attacks on an enterprise rarely begin on the servers, either at the edge of an enterprise nor (especially) deep in the center where the most valuable data and resources are maintained. Gone is the day of the over-vulnerable IIS (Internet Information Service) server, at the edge of the network that could become a gateway to the center.
Today most attacks are against a different edge. The users. A common initial breach is through phishing attacks and drive-by-downloads. A breach at a desktop or laptop may expose some sensitive data, but it will rarely give up the crown jewels of an enterprise.
Instead, these initial compromises are used to gain a foothold to penetrate other systems, so that the attacker can work their way in to the organizations infrastructure.
This is where one problem of centralization can surface; if an attacker can move through the Windows domain, gathering credentials, and access to systems, eventually the goal is to find the account of a person who is authorized to get access to those ‘crown jewels’. The attack might start with a regular ‘user’, but the goal is to for the attacker to ‘become’ and administrator by hopscotching across systems and through accounts.
The Problem With One ID for Everything
There are a number of products in the marketplace that purport to ease the burden of identity access management by consolidating everything in the AD account. It becomes that case that authenticating to AD grants access to not only the Domain, but the Unix/Linux estate as well. To make things ‘easier’ they propose to use Single Sign-On, in the form of Kerberos, to grant access from an authenticated Windows account to the Unix and Linux systems that often are running the most critical applications or hosting the most sensitive and important data.
Just imagine a compromised account that can SSO (Single Sign On) in to your most guarded systems.
Combined Account Access is Not Recommended
Windows is not bad, and AD in general is a good thing, but just like we impose a separation of duties on employees so that too much responsibility does not fall in to the hands of one person, some believe that placing too much trust in a single account is just not such a good thing.
Mark Lambiase, CTO, Fox Technologies, Inc.
You may also be interested in: Best Practices for Unix/Linux Privileged Identity and Access Management
FoxT Access Management & Governance solutions complement your existing technologies by adding granular control and enforcement of authentication and authorization policies for both privileged and end users. www.foxt.com/boks