Consider it this way. In addition to the personal computers we have at home and the computers large and small at work, there are also millions upon millions of smaller processing devices– computers in automobiles, on manufacturing assembly lines, in advanced medical equipment, modern electric, gas, and water meters. Everywhere you look there are small computers performing specialized functions across many industries. Increasingly, those processors are being networked, and in some cases even finding their way onto the Internet, either intentionally or unintentionally. This is where things can really start to get interesting, and not in a good way.

You have no doubt seen stories in the media about the hacking of critical infrastructure systems. One of the most notorious occurred in 2010 with the Stuxnet virus, which attacked specific technology from a specific vendor involved in (among other things) the nuclear power industry. In this case, it seemed likely that the incident was part of industrial espionage on the part of nation-states, but it highlighted the issues regarding the myriad of critical computing going on throughout our infrastructure.

One of the biggest problems however has been to separate the fear and near-hysteric tone of some of these reports from the real issues facing various industries today with operational technology. What exactly do we know for sure about operational technology security, and upon what can we commonly agree? Well, let’s see:

1- Operational technology security is a real and serious issue. The proliferation of processors and their supporting firmware, operating system, and application environments have been deployed in many cases without considering basic principles of secure development. The means to secure these environments as a “layer” of data and systems protection has also not been a high priority for many industries, resulting in areas of weakness throughout the networks of systems;

2- Operational technology security is actually larger in terms of devices, systems, and code than information technology. Think about it– for every computer we have, there are hundreds of smaller processing devices (networked and not networked) throughout the world. These processors, embedded in so many different systems, constitute the largest deployment of information systems in the world. As these devices become more ‘intelligent’ and grow in complexity and function, the ‘attack surface’ for those devices grows;

3- We are becoming increasingly dependent upon operational technology to run our industries, our transportation, and our utilities. If key critical infrastructure within those industries remains in a compromised state, the risk for those enterprises goes up, and the likelihood of compromised systems also goes up over time;

4- There are lessons that have been learned in the ‘traditional’ computer security world that can be applied to the operational technology world, as long as the differences between operational and information technology are recognized and accommodated. While some of the practices and processes by which we began to successfully address computer security are applicable, there will be entirely new approaches necessary for some operational technology security needs.

There are no doubt other common facts upon which we can agree about operational technology security. The first step in doing something about the problem is to be aware that it exists, and to take practical and pragmatic steps to mitigate the risk to our critical infrastructure before, during, and after deployment of said infrastructure. In the days ahead, we will write more about this to contribute to that awareness. Gartner has existing research in this area and there is more to come.

The Summit, and others like it in the IAM industry, actually serve as an important peer forum, and we at Gartner like to think that we are part of that forum. It is an opportunity for people of like mission and mind to come together to discuss how they do it, what has worked, and not worked for them, and to ask the questions that we at Gartner most need to hear. By doing so, all of us gain a common sense of purpose. We begin to see a shape, a pattern to IAM, and what it means to peers in this particular and peculiar business. By pooling our knowlege together, we make the experience hopefully meet real expectations.

Ah, I forgot to mention the theme of the Summit, didn’t I? It is “IAM Reality Check: Solutions and Practices for Successful Business”. Or as it is known internally by some: “Get Real, IAM!”. Perhaps you sometimes feel that analysts at Gartner are chartered with a “crystal ball” to try and predict future trends and analyze leading-edge technology and process. I don’t blame you, sometimes we sound that way. But we have another charter as well to clients. It is the charter of bringing proven practices to light. Gartner must serve as a distiller of all of the hard work you have done and package it in ways that allow others to minimize the continual rediscovery of how NOT to plan, build, or operate IAM.

So you could consider our 6th Annual IAM Summit as a way for ALL of us to listen to one another, to learn from one another. Sure, I know that sounds a bit pretentious given you’re paying to be at the event, but it is my sincere hope that Gartner’s contribution to the discussion at a minimum is as much about how much we’ve learned and can learn from your experiences, and how much we can help your future IAM experience be as productive as possible.

I think that’s enough rambling for now. I’m beginning to sound too much like a commercial. I hope to see some of you here at the Summit. Safe travels.

I’m not here to bash IAM product or service vendors. That isn’t my job. As an analyst, I’m supposed to— well, analyze. I try to look at the historical record and make some conclusions about what has happened and some guesses as to what will happen. If my view of reality isn’t rosy or satisfying, it is because of what we find as researchers during analysis, not because we have something against the IAM market response to customer need. For IAM, the reality is that we have made some progress. It has been in fits and starts, with notable successes and failures, but in general we’ve progressed from a necessary evil to playing an important role in securing an enterprise and its business assets.

The reality is that our vision of IAM as a ‘gatekeeper’ has been somewhat realized. We know how to establish an access architecture and technology set that does a good job at determining whether or not someone has the initial right/privilege/permission/entitlement/claim/fill-in-the-blank to enter our IT/business kingdom and letting them in if they have it. The kingdom, anyway. Going further with those entitlements to allow entry into specific, mission-critical areas (e.g. sensitive business information, key applications) remains problematic, and allowing a lot of different players (e.g. partners, suppliers, third-parties, other strangers) into our kingdom is still a work in progress (e.g. federation), but we’re getting there.

The reality of administering the identities themselves and governing that process is still problematic. It’s just plain hard, actually, because we’re trying to define an identity for use in the business lexicon, directly, not through the IT translator. We’re actually inviting and engaging the business in direct participation in the creation, maintenance, retirement, reporting, tracking of identities for which they are personally responsible. In many respects, that scares them. It was better when most of that nasty, administrative stuff was hidden from them (more on that later). But unfortunately, with great power comes great responsibility. As the individual business user becomes more engaged in matters related to sensitive data integrity or customer data privacy or managing different forms of risk throughout their business processes, they keep running into the pesky IAM problem. The reality of IAM is that it is a pain for everyone, equally: whether the business user comes from the human resources group, the supply chain department, the customer relationship management division, all of them have IAM to worry about in some capacity. It is the horizontal commonality in a vertical world.

Work continues on taking IAM to the next stage, where formal, structured methodologies, processes, and organizational requirements are identified and employed where required in maturing enterprises. Identity and access governance (IAG), that step closer to structure, methodology, process, and organization, is heating up now, joining the ‘toolkit’ for IAM. A reality check there reveals that IAG is like Thursday’s child: it has far to go. But it comes closest in the IAM realm to addressing the business user directly, and that’s a good thing. We’ll watch closely to see what transpires.

Gartner’s annual IAM Summit in San Diego, CA 14-16 November, 2011 will have as the summit theme “IAM Reality Check: Solutions and Practices for Successful Business”. I think there all of us (you, analysts, vendors, and others) can compare notes as ‘gatekeeper veterans’ to see what has been the reality of your experiences to date, and ponder your roles for tomorrow. We could use a reality check about now, I think.

When I think about the reasons for IAM’s existence, there are 3 words that keep coming to my mind: control, observe, and inform. Let me tell you what I think they mean in the context of IAM.

Control: from the time I first started looking at IAM as an analyst, a large part of the technology, process, and skill sets involved the control of access– to networks, platforms, applications, data, and services. This concept of control is integral to IAM, and is the original reason why IAM first started looking like a discipline rather than just a loose collection of technologies to address tactical needs. Whether it is controlling access, controlling the creation and life cycle of identities, or controlling privacy (primarily through controlling access), deploying and managing access control is fundamental to your IAM project;

Observe: to control access or anything else in IAM, you have to know what is going on. You have to collect information about the control event itself, logging information about it for later analysis and use. You have to observe the changes in identity data that occur as day-to-day administration touches the data, monitoring process and workflow to ensure timely completion of IAM activities. In IAM, logging and monitoring are key functions in enabling observation.

Inform: it isn’t enough only to collect information through and for observation– you have to use that information. In IAM, compliance with policy and regulation require that reporting is provided from the control and observation of identities and access. It is necessary to inform key stakeholders and participants in IAM on what exactly is happening, whether the purpose is to improve the IAM process itself, or to inform the business with key identity-indexed knowledge to make good decisions.

Control, observe, and inform. Keep these themes in mind when you’re striving to create an optimum IAM experience in your organization. That way you will be able to see the entire forest, rather than just the trees.

————————————————————————————-

By Andrew Walls

Active Directory is everywhere. This is both a testimonial to the success of Microsoft’s product management strategy and a challenge for any enterprise that wants to build a unified AD environment. Consolidation of AD forests and domains is the single most frequent topic raised in inquiry concerning Active Directory. Commercial organizations, governments and educational organizations are all looking for a more efficient approach to managing AD and providing AD services to their internal clients. The complexity of some AD environments is staggering. Many commercial organizations are operating >10 Forests with multiple domains in each forest and a complex network of trust relationships. Quite a number of governments are operating >50 forests with who knows how many domains. To date, the most complex environment I have encountered is at a global organization with 138 forests operating on every major release of AD since Windows NT.

There are good reasons for this infestation of AD. When AD was first released, it was seen as an extension of Windows Workgroups and was implemented as a departmental, localized solution. As the years have gone by, AD has become an enterprise solution but many organizations are still managing it as a departmental solution. This legacy architecture keeps a lot of AD administrators employed and enables departments to act as a separate fiefdom within the overall enterprise. Although this local autonomy has some benefit, the complexity produced by multiple, unique AD implementations can prevent, or drastically increase the cost of, deployments of new, enterprise wide software and work processes.

The allure of a single AD forest with a simple domain design is not fool’s gold. There are real benefits to be found in a consolidated AD environment. A shared AD infrastructure enables user mobility, common user provisioning processes, consolidated reporting, unified management of machines, etc. The reasons for consolidation are clear, but there are significant barriers to success.

1. Politics- Let’s face it, the big problem with AD consolidation is political. No one likes to give up local control of users and machines to a centralized bureaucracy. From a technical perspective, a consolidated AD model is clearly a more elegant approach to AD management. From the perspective of local versus centralized control, the best model is not so clear.
2. Cost justification- It is very hard to write a business case for an AD consolidation project. Does consolidation reduce costs? Maybe, but probably not by much. You might be able to produce minor reductions in license costs but, consolidation rarely results in AD administrators being laid off. On the other hand, the actual consolidation project can cost a considerable amount. I have reviewed AD consolidation proposals from systems integrators that range in price from ~$200k to over $5million. The benefits derived from consolidation tend to be qualitative rather than quantitative. User portability, shared GAL (Global Address List) and consolidated reporting enhance productivity, but can you measure that enhancement in dollars?
3. Complexity- An AD consolidation has to unite and rationalize the ID formats, password policy objects, user groups, group policy objects, schema designs and application integration methods that have grown and spread through all of the existing AD environments. At times, this can feel like spring cleaning at the Aegean stables. Of course, if you miss something, users will not be able to log in, or find their fileshares, or access applications. No pressure.

How do you avoid all of this? You fight proliferation of AD at every turn and realize that consolidation is not a onetime event. The optimal design for AD is a single domain within a single forest. Any deviation from this approach should be justified on the basis of operational requirements that a unified model cannot possibly support (I have yet to see such a requirement except for deployment of AD in an internet-facing DMZ). There is no avoiding the pain of consolidation when your existing environment is already fragmented, but once you build the core AD environment, you should not have to repeat that pain.  Many clients that experience regular mergers and acquisitions have established defined processes with time lines for integrating new subsidiaries into the collective (Resistance is futile! Your AD will be absorbed within six months of merge date). 

It is never too early to start on consolidation. The pain of consolidation increases the longer you wait to grapple with the situation. Take the bull by the horns and develop a strategy for consolidation now (full consolidation can take years to complete in very complex environments) and get started on implementation right away. While you are consolidating the existing AD environments do not allow any new domains or forests to be created!

With IAI, that isn’t our point. Oh, of course we’d like to sell more research, but Gartner and other firms also seek to be advocates for clients. That not only helps us because you’re more likely to buy from us if our advice is good, but it also helps you, the client. IAI is not about technology. It was never our intention to imply that in presentations or research. IAI should actually be the result of a culture change within IT and the enterprise. It should be the output of a shift in the way work is done, the way decisions are made, the way we actually USE what we know in IAM to best effect. It should be the goal that we strive for in IAM, the prerequisite to do effective access control, the means by which we can make (for example) better HR, project management, and risk  decisions, the measurable and real proof that accountability and transparency are occurring.

IAI can be the result of a change in mindset of what we do with the information at hand. Believe me, it won’t be the first time that enterprise have tried to tackle this– good intelligence is hard to find, difficult to create, and still harder to maintain as a discipline. It can involve speaking to people you’ve never spoken to before, using tools that you never knew were available, acquiring skills that aren’t in your usual training agenda. Building a center of excellence around IAI actually means becoming part of an enterprise security intelligence program. And THAT subsequently means becoming part of a business intelligence program. I think you can see the pattern.

Some of the clients I have spoken to have said “well that sounds great, but I just want to provision a new employee. I don’t have time for all of this fancy analytics stuff.” What is ironic is those same clients staff up, train, and organize to do the basics like provisioning, build and deliver the reports necessary for operations and compliance, and establish the relationships with the business to ensure the results of provisioning are felt. Whether they know it or not, they’re already involved in all of the same steps that, with just a little more effort, can expand the intelligence they have to work with to get provisioning done, and then some. Again, it is a change in mindset on how we use what we have to do what we do better.

So what am I saying here? Just that this isn’t yet another round of renaming reporting and dashboarding, moving around people, process, and technology like pieces on a chessboard. This can be the “real deal” if we understand that the end result is intelligence to make our identity-based decisions (IT or business) better.

First, is IAM a set of products with owners? If so, what are the responsibilities these owners have in insuring that management of identity and access actually happens? Or do they just “own” the products, much like an enterprise application owner would. Personally, I don’t believe IAM is a set of products, but let’s assume for the purposes of this discussion that it is. In many enterprises, IT would be the owners (what a shock). In this sense, to own might mean to manage the versions and releases of the products, the software presence on the server or servers, the customization that occurred to get the software to run, the databases and directories needed, and the SLA that outlined the expectations of the software’s performance and availability. I’m sure I’m forgetting other things being an owner might entail, but you have the gist of it. You notice, however, that this describes managing the products, not the elements it is chartered to deliver.

All of that is managing the products, not really managing identities and access. Let’s try a different lens to view IAM. Perhaps IAM is a set of processes in an enterprise that delivers the right kind of access to the right applications for the right people at the right time– a lot of “rights”, as it were. In that sense, there may some kind of access process to be owned by someone, as well as an administration process. Again, guess who probably gets that responsibility? Yep– IT, though some administration of identity might actually be done by some other parties like HR.

Now there is this idea of an intelligence process too, where you can use information from the access and administration experience, properly analyzed and formatted, to make different kinds of IT AND business decisions. Compliance reporting is an example of this. When that happens, who is doing the managing of identity and access? if consumers of identity and access intelligence need those identities to change or those accesses to be modified as a result of what the intelligence tells them, they are actually beginning to manage, as it were.

What’s the point of this rambling? I would like you to consider what the management of identity and access really means, and who is really doing the management. I want you to separate ownership of products and resources from the actual management experience (as many of you have). I want you to take up a different lens to view the act of managing identity and truly see that, in a process, there are many managers. There may actually be process owners that will manage not only the process itself, but the inputs and outputs from that process. There may be intelligence consumers that will manage the identities because they know now how they’re being used, and what they’re being used for, and under what circumstances. And of course, there will be custodians that will manage the repositories or raw and refined identity information, from directories to entitlement catalogs, to ensure that the use of identity to perform access is an effective, secure experience. Managers are also stakeholders in the success of IAM, particularly when those managers are also the consumers of IAM.

So the next time you have a discussion about identity and access management, spend some time thinking about how many managers can you fit into the picture and who they really are.

2010 certainly saw some changes in the market landscape, with a number of acquisitions specific to identity and access. I expect more this year, even one or two large and significant ones. I also believe the acquisitions will start quickly– after all, year-end is an artificial demarcation point for many enterprises, and won’t slow them down. Digesting the existing acquisitions will consume a lot of energy in 2011– there is likely to be some “mid-course” corrections in the earlier 2010 acquisitions as the new owners come to terms with the reality of integration and the results of sales training on the new products.

The administration side of IAM will come into its own in 2011. Provisioning and access certification grew in 2010 and will grow more, though I think provisioning is starting to undergo architectural transformations as it matures, becoming less of a focus after this year than some of the higher-order features and “business-adjacent” components of IAM (such as certification, analytics, etc.). The intelligence derived from identity access and administration will become more valuable (for the business anyway) than the functions of access and administration. Different faces and different audiences will see and hear about IAM this year, and will participate more in decisions affecting products and services.

And speaking of services– I continue to have hope for the entrepreneurs that believe there is a viable alternative means of delivering IAM, through software as a service, in cloud computing environments and/or for cloud-based services. 2011 is a big pioneer year, i.e. those customers brave enough to cross the new prairie without ending up face down and sprouting arrows, those willing to upgrade or extend existing IAM with IAM as a service, or those that have never used IAM formally but are ready to make a move without mortgaging their homes. It began in 2010, but will continue in 2011. Acquisitions in 2011 will also reflect the evolving view of who will own such services, whether traditional IAM product vendors, traditional IT service providers, or someone new. There will be some surprise owners before 2011 is done.

We should also watch for government-driven changes in IAM in 2011, from industry-specific regulatory changes to the need for the IAM industry to address public-sector concerns of cost, availability, and function. Higher education and state/local governments (internationally) are particularly interested in broadening the field of options in IAM to the point where the more traditional monolithic IAM projects costing great sums of money are becoming increasingly hard to justify. Health care and energy/utility industries are also bringing added focus to the maturation of products and services tailored for them. Some IAM acquisitions and feature changes introduced in 2010 reflect this focus and trend.

2011 will be the year that more mature IAM users will rethink the role of IAM in their enterprise, relegating functions of IAM to a broader IT and information security architecture and design and beginnning the process of “inclusion”, i.e. absorbing IAM functions and responsibilities into IT rather than treating them separately from IT in general and information security in particular. This is a program maturity phase that optimizes IAM capability and has it assume its earned role in IT and the business.

Wait a minute. I thought I said that I was no good at prediction. Forget everything written here. After all– who can predict the future?  Happy New Year, or as the curse goes: may you live in interesting times.

First, I’m struck by the level and intensity of interest in the acquisition itself. While Novell has been in the industry for many years (founded in 1979!), its revenues and relative size seem out of proportion to the level of speculation and analysis that I’ve seen in the past 24 hours. Of course, being an analyst that has covered Novell for almost a decade, perhaps I’m too close to this. But so are many others, ranging from ISV channel watchers to Linux pundits, from analysts in email/collaboration to systems resource management. As a result, there’s a lot to read today, each from many different perspectives. Finding your way to a broad view of Novell becomes increasingly difficult– we seem to view the company as the sum of its parts rather than a whole. And therein may lie one of the swan songs of the company. While Novell executives were striving to weave these separate stories together into a business view of “intelligent workload management”, it remained difficult to give up the legacy, tactical solution messages that had served them well in the past.

Novell underwent a series of transformations in its lifetime, and in doing so entered many facets of IT through acquisition and development. The company essentially remade itself several times in an attempt to remain relevant to the market. In doing so, it amassed an impressive array of patents across many different IT infrastructure disciplines, in operating systems, security, storage, and networking, to name a few. Of the stories about the acquisition, this one is particularly intriguing. I can understand the goal of Attachmate in acquiring and utilizing mature and established solutions. I can also understand their desire to avail themselves of Novell’s cloud strategy and efforts to grow the systems resource management space. But it’s the patent deal that I find truly interesting.

There is much speculation occurring at present in exactly what is in the 800+ patents that the consortium of companies CPTN Holdings will purchase. Of course, CPTN Holdings didn’t exist before November 2010, so you have to wonder who knew what and when they knew it (baby boomers, do you remember this phrase?). The role of Microsoft in this is becoming more interesting as this sale develops. Time (and SEC filings) will provide a clearer answer. It makes open source and Linux users of all stripes nervous, though, until we know more. It is disconcerting to see the volatility of open source support increasing after the acquisition of Sun Microsystems by Oracle, and now this acquisition. While one tries to remain optimistic, my cynical view of markets tends to prepare for the worst instead of hoping for the best.

In the midst of all of this of course is the identity and access management impact. I see challenges for Quest Software ahead, since they often go head-to-head with Attachmate-NetIQ for Microsoft centric administration customers. I see some relief for the “Big Three” in IAM now, CA, IBM Tivoli, and Oracle, now that a spoiler in many ways may be out for a bit during the ‘absorption’ phase of acquisition. I see advantages for smaller and more nimble players such as Courion, as well as obvious beneficiaries like Microsoft. What will be interesting to see in the days ahead is the impact this has on Novell partners: Verizon in cloud security, VMWare in virtuatization, SAP in IAM, and Deloitte in IAM consulting and system integration. One would expect Attachmate not to shoot the goose that lays golden eggs, but you never know.

And there remains the unspoken question on whether the sales are over.

Other than that, it is pretty quiet going into the holiday period. Remember, there’s till more days left in the year for more acquisition excitement in the IAM industry.

Gartner is preparing an Event note on this topic that will consolidate the analysis of literally dozens of analysts that have covered and do cover Novell and Attachmate as a whole. It should be released within weeks. In the meantime, Novell customers should be calm and not take hasty action. Be prepared to make your feelings known to Attachmate on a variety of topics, not the least of which is ongoing maintenance and support contracts for existing Novell deployments. This was a problem area in the Oracle-Sun acquisition, and it is often a sore point in most acquisitions. Observe the split of Novell among Attachmate divisions carefully to determine the impact on roadmaps you may have that combined Novell solutions in the past. Stay tuned for more speculation and analysis in the days ahead.

And buckle your seatbelts.

Happy Thanksgiving!

Attachmate’s acquisition of Novell for $2.2B signals the end to an era. Novell represents one of the original key players in the network operating system and identity management period from the early 1990s until today. In fact, one could make an interesting case that the company made Microsoft what it is today through the early market battle between Novell NetWare and Microsoft Windows Server. We all know how that battle ended, but in the long run Windows Server was a better product because of it.

Novell had significant and continued influence on many vendors, ranging from the identity and access management to the Linux market, from email to virtualization, and of course security. In most of those cases the company made a good to excellent showing of technology and was quick to improve upon it and in some cases to outpace its competitors both in terms of vision and architecture.

But not in execution.

Each time there were innovations to be parleyed into market share, the execution failed to materialize. There were a number of causes: timing, marketing, acquisition missteps, and others. It often seemed to be the wrong place at the wrong time, or experienced a confluence of bad partners and bad economies. When it seemed that they might be able to recover from these ‘curses’, another would take its place.

But what remained consistent throughout most of Novell’s existence was by and large the technical quality of most of its products. In spite of considerable turnover throughout the ranks of the company over the past decade, product quality and innovation remained consistent. That could not be said of the legendary Novell customer support, which suffered over the past years following the Cambridge Technology Partner acquisition and subsequent divestiture. While a services partnership change was the right thing to do, execution again led to some problems with that support.

Many decisions will lie ahead for Attachmate, including product positioning and branding, management restructuring, possible division sales. It will be a period of transition for the Novell employee and the Novell faithful.

What is clear is that the breadth and number of customers ensures that many of the products will live on in an Attachmate universe– if they stay there. For IAM, a world-class directory, provisioning, access management, and SIEM portfolio (among other elements) will continue for its customers, though you may expect some delays in feature updates while organization, product engineering and product management concerns within Attachmate are worked out. Of course, I thought that way with many of Sun’s solutions until they were acquired by Oracle. But this is not an aquisition that has such broad product overlaps. It affords Novell products a greater chance at survival.

The final irony of the announcement is that CPTN Holdings is a consortium of technology companies organized by Microsoft! So $450 million of Novell IP is likely to make its way through CPTN to Microsoft. It isn’t yet clear what that IP is, but it will be revealed in the days ahead. If that isn’t ironic enough, Attachmate is backed by private equity firms Francisco Partners, Golden Gate Capital and Thoma Bravo. Attachmate’s offer of $6.10 per share followed the $5.75 a share offer earlier in the year by investment firm Elliott Management Corporation, one of Novell’s largest shareholders. Novell rejected that offer then, but as part of this deal, Elliott is to become an equity shareholder in Attachmate. One way or another, Elliott participated in the final phases of Novell’s acquisition.