An abridged (and unofficial) history of identity and access management

Being an “experienced” Analyst I’ve seen the evolution of a number of technologies.  One which is near and dear to my heart is identity and access management (IdM).  This blog gives a brief, unofficial history of how this technology evolved (from a certain point of view)…..

In the beginning (of IdM)…..

… there were mainframes and the IT manager looked at them and said, “This is good”.  With mainframes came the task of managing multiple workers, with different privileges, accessing the same data.  Before this computers were operated by a single user through a wired access console (usually a typewriter type device) and there wasn’t a concept of shared data.  But mainframes changed all that.  A new component of the operating system was added, user access management.  Administrators had to manage a “profile” in which workers with wired terminals were assigned certain rights to access information (Read, Write, Execute, and Delete (RWED)).  This was to ensure they accessed only the data they needed to do their jobs. 

Then came the modem (modulator/demodulator) and physical location of the worker now became important.  Not only could workers access data in the office, they could now access data from outside the boundaries of the building in “unsecure” areas, like their homes.  But the terminals only provided a “view” of the data so the administrator still had some control of what the workers could see because they still had to identify themselves at login and the data didn’t leave the mainframe’s storage.

But people weren’t content to just view the data remotely, they had to hold it in their “electronic hands” and so the PC was born.  Not only could it download the data, but it could use its own, non-mainframe, applications to manipulate the access rights to the data.  It’s about this time that administrators became really paranoid.  “What?” they said.  “You’re going to not only download my data but you’re going to change its protections remotely and then upload the data and rights to my system? But how will I know the data is still good and the proper rights are still enforced?”  Quite the quandary.  So directories where developed to manage user and data rights to ensure the protections were applied correctly and databases evolved to maintain different “views” of the data so workers couldn’t “corrupt” the enterprise data. 

But people talk.  One worker wanted the data another worker had created so PCs started sharing data between themselves on something called a Local Area Network (LAN).  Now the administrators got really busy.  Not only did they have to assign rights and privileges to the mainframe applications and data, now they had to “touch” each PC and ensure that the applications and data matched how the mainframe was configured.  But the administrators wanted to ensure they could audit and control enterprise data so they required the PCs to connect to a common “file sharing” system causing us to enter into the world of “synchronized data flows”.  The administrators sent periodic flat files of the mainframe data to the file share and the PCs sent their data back to the file share and the administrator somehow managed the relationships.  But at least it was confined to the corporate LAN and a few remote modems.

But companies talk.  They collaborated on contracts, supplied each other with materials and services and many times generated unique data.  This process required them to start joining their data between geographic locations within a company, and even beyond a single company’s information border.  Thus the Wide Area Network (WAN) came into being (eventually becoming the Internet).  But of course not every company used the same LAN technology.  There was SNA, DECnet, Appletalk, TCP/IP, OSI and others.  So not only did the administrators have to configure accounts for other people outside their domain, they had to do this for other people on different networks and work with other administrators “which they just didn’t trust”.   So the synchronization engine now became a “gateway”.  It was in effect a translator between different networks and trust mechanisms.  This provided complexity along with a logistical nightmare.  As soon as the gateway was running, the business would want another system or network added and the entire configuration of the gateway would have to be changed.  Plus, outsiders now needed access to local systems to get data so remote accounts needed to be set up and maintained (with the remote business’ promise that as personnel changed, the local administrator would be notified so they could delete the account).  Thus millions of accounts for people that no longer worked for the remote businesses began to accumulate in the conjoined enterprise directories (the beginning of good access management going bad).

By this point administrators recognized that they were spending way too much of their time managing users and access rights and not getting their regular jobs done (like backups).  They clambered for a technology that had enough intelligence to figure out that “john.doe” and “jdoe” on two different systems was the same person and also do gateway services between all the connected systems without a lot of reconfiguration.  A new technology emerged to fill this demand, “meta-directories” (the first, true IdM solution).  Meta-directories could not only emulate different operating systems and directories to reduce the integration needed to get at the source data, they had a sort of “artificial intelligence” built in that could identify existing, disjointed accounts (sometimes) of a single user, based on attributes stored at the source systems, and manage them as a single entity.  “Eureka!” the administrators said, “Now I no longer have to do complex configuration tables and I can go about doing my work.”  But there was a problem.  While the meta-directory was a friend to all systems (making a change on any of the source systems would trigger a change process that would propagate the changes to all of them), administrators found that they traded complex “data comparison” models for complex “business flow” models.  It was important that if system “A” was dependent on automatically maintaining an account based on information stored in system “B” that system “B” interact first with the meta-directory.  These “flows” became so complex and time consuming that many administrators didn’t have enough physical time in the day to complete all the flows before the next day’s processes had to begin.   

Meta-directories are still around today but they only addressed the technical aspects of maintaining accounts.  They didn’t deal with the “business-side” of accounts.  Now that companies were sharing data they wanted managers to approve “who had access to what” based on the “role” the person was assigned.  They also wanted access logs for auditors to show that the workers didn’t have access to systems they shouldn’t have. Plus they wanted the business flow models in the systems to reflect how the “actual” business operated, and not “IT’s view” of how the business operated. 

In order to respond to these demands, the IdM vendors updated their meta-directory solutions to be based on business-flows (generally starting with HR) and created a new technology – “provisioning systems”.  These systems, the big brother of meta-directories were the first “business-driven identity management systems”.  But they came with a price (and not just the fact that they were generally 10 times the cost of meta-directories), the business now understood how to configure the technology; the worst nightmare of the administrators.  The businesses now could give business process flows and controls and have them defined in the software with no translation to “techno-speak” necessary.  While a good thing, in many cases the initial deployments of provisioning systems failed before they ever got off the ground. This was mainly due to arguments, disagreements and misunderstandings of how the business processes worked.  The problem was no longer how to connect to a source system and what data it held, but understanding the process of “how” workers were given permission to access a system and how it was determined they no longer needed access.  “Life-cycle management” became the key and continues to plague provisioning systems today.

But IdM didn’t end here.  Now that IdM was no longer a mysterious black box to business people, they were putting more and more demands on the IT department to have other control mechanisms put in place.  Today we see rash of other technologies based on their demands.  We now have “federated systems” so the workers no longer have to remember lots of logins and passwords to get access to data on other systems.  There are “reporting/audit tools” creating “server farms” of log data for analysis and reporting.  “Web Access Management (WAM) tools and portals” are providing a single sign-on to gain access to multiple systems, or the inverse, “virtual directories” bringing the information of many systems to one.  We have “rules and roles engines” for determining the responsibilities and roles workers are playing in near real time to ensure they get access to only that data that they need for their job. Plus, we have many other products to help business managers with compliance, risk, data loss, monitoring and the other control functions.  This has ultimately led to making the business managers, not the administrators, the owners of identity and access management (God help us all!). 

Yep, we’ve come a long way since the mainframe and wired terminals, some may say not in the right direction. But whatever your belief, IdM has come into its own and is here to stay.  Stay tuned, like they say in the Midwest (where I grew up), “Don’t like the weather, give it five minutes and it’ll change.” 

………..to be continued

r

The “Pearl Harbor Syndrome” (Inaugural Post)

 

Welcome to my personal blogging site on IT Security and Identity Management (separated in many organizations, but one in the minds of people tasked with the protection of information). 

As I open this blog looking at the state of protection in the world, I realize that with the downturn economy we’re creating an information landscape that as a “native Hawaiian” (yes, I was born there) is very familiar, Hawaii, 1941.  Back then the U.S. had brought its Pacific Fleet to Hawaii and ordered a military buildup in the Philippines in the hope of discouraging Japanese aggression in the Far East.  By showing the size and force of the U.S. military, the President had hoped that Japan would see that they had no way of winning against such a formidable foe.  If you think about it, this is exactly what many organizations are doing today to protect against information loss.  They’re following what I call the “Pearl Harbor Syndrome”, building up a suite of S/W and H/W solutions (i.e. Data Loss Protection (DLP) tools; building “hacker-proof” websites, portals and network channels; encrypting e-mails; provisioning tools to manage the life-cycle of employee responsibilities and privileges; etc.) in hopes of deterring people from conducting malicious activities against them.

But are all these technologies a deterrent to the “enemies” of the organization not to attack?  Not really.  The Japanese attacked with three objectives:

1)      Destroy American fleet units, thereby preventing the Pacific Fleet from interfering with Japanese conquest.

2)      Buy time for Japan to consolidate her position and increase her naval strength.

3)      Be a blow against American morale, which might discourage the U.S. into entering a war in the Pacific.

Today’s “enemies” have similar objectives

1)      Disable the security boundaries of an organization so they won’t interfere with their activities.

2)      Create “back doors” in the security technologies so they have time to infiltrate the corporate systems looking for valuable information.

3)      Attack the morale of the organization’s clients to weaken the company’s reputation, cause revenue loss, and keep the organization in a state of recovery.

So what mistakes did the U.S. do that you can learn from as you look at your “battleships” of protection? First, the lines of communication must be established.  The U.S. had people on the ground that saw the attack planes flying toward Pearl Harbor but didn’t have a way to get that information to the right people in a timely way.  And even when the information was given, the military was too arrogant to believe it because it didn’t come from their “official” sources.  I don’t know how many times I worked with an organization where I never saw a business person, a client, or an end user.  By partnering with the people who own, manage and use the information you want to protect, and providing a two-way communication channel with them, IT and security staff can have a tremendous number of eyes and ears to detect problems and attacks before they succeed. 

Knowing your weaknesses and strengths is important. The U.S. saw their battleships as the best deterrent technology available.  But the Japanese knew they were just large metal targets when confined within the harbor and exploited this with relatively simple, low cost mechanisms.  Having multi-million dollars of deterrent technologies without the proper environment and support needed will allow outsiders to exploit their weaknesses as well.  It takes time AND EFFORT to take advantage of all the protections these technologies provide.

Finally, put in place the contingency plans for an attack in now, not after they occur.  Too many organizations have found themselves in an unenviable position of having to deal with an attack without the tools in place to begin the forensic phase that follows.  Leaving yourself helpless also allows the attackers time to consolidate their position and increase their strength to do further damage.  In addition, government disclosure laws are forcing organizations to have formal plans so don’t wait.  In a recent conference I attended a presenter from the FBI suggested a “take a local FBI agent out to lunch” meeting where you can get to know the law enforcement officer and where they can get you started understanding what you can do to work with them.

Unfortunately the U.S. lost a lot of good people in the attack on Dec. 7, 1941 but they learned a lot of valuable lessons that day.  Hopefully you can learn from their mistakes and not have a “… date which will live in infamy” of the day your organization had a successful attack against it.

r