Some two weeks ago I’ve been at the EMC EMEA Analyst Summit in France. In one of the session Chuck Hollis, VP Global Marketing CTO of EMC Corporation (what a title, isn’t it?) made a very good comment when of the presenters talked about the needs for

• agility and speed
• service level fulfillment and improvement
• cost optimization

of IT when providing services. He pointed out that IT looks at this typically in the order of cost – service level – agility, while business looks at agility – service level – cost. I really like that.

You might argue that business always is talking about IT being too expensive. Yes, they do. But there are reasons for that. On reason is that business still frequently doesn’t really has an answer on the “what’s in for me?” question. If business doesn’t see a value (and supporting the need for agility, e.g. enabling business to become better, is sort of the big theme behind the business value) it looks at costs. No surprise at all. However, if IT provides what business really wants, then the discussion is much less about cost.

With other words: IT has to understand what business really needs. Look at the business services they want, at the business value, and how IT supports agility and speed. Ensure the service levels. And then try to do it at optimized cost.

Honestly: That isn’t a groundbreaking insight. Many of us are talking about this since years. But do we act accordingly? Not always. Always having in mind that the order better should be agility – service level – cost than the other way round might help us to become better in Business/IT alignment.

Trust is a fundamental concept of today’s IT. Security is based on trust.

We have (or better: had, after DigiNotar?) trust that a web server which has a valid SSL certificate is the server it claims to be.

We had trust that RSA SecurID tokens are secure (whích they still are to some degree, but a lower than before).

We have trust that our authentication in the Active Directory is done in a secure way.

We trust the identity provider when using identity federation.

However, especially the first two examples raise the question whether the concept of trust still is a foundation to build on. On the other hand: Are there any alternatives?

I think we will further need to build on trust as a concept. There is no real alternative. However, we need to be much more careful regarding this concept and add to other approaches:

• Mistrust
• Risk

Mistrust means that we shouldn’t take things for granted. We might challenge “facts” – e.g. authentication decisions and so on. In fact, mistrust is not really new. We might check the URLs behind links which are suspicious – are they really pointing to eBay, PayPal or whomever they claim to do? We add additional tiers of authentication or stronger authentication mechanisms for sensitive interactions and transactions. But in the light of what happens these days, with more cyber-attacks and even the well-secured, experienced ones like RSA becoming victims of successful attacks, mistrust becomes more important.

That is related to the concept of risk. Risk relates to

• interactions and transactions performed and the information assets affected
• the level of mistrust and the “objective”, factual security risks

This relation is fundamental. We need to understand what could happen to our information assets (and the real assets behind them). And we need to understand how much mistrust we need. Based on that we can define what we need beyond the trust we might have today.

Technically, this leads to the need for flexibility and versatility. It’s not about a specific type of solution, it is about the ability to combine multiple technologies (for authentication, fraud detection,…) depending on the risks and the level of mistrust. The bad news however is: Mistrust will increase, trust will decrease, which will make it more complex to achieve an acceptable level of security for specific risks. And some of the concepts – like SSL – are obviously not sufficient by themselves to address today’s and the future’s security challenge. However: SSL++, e.g. SSL plus other approaches, might suit our needs. And approaches like the ones of convergence.io might help us as well in better rating the risks and applying the concept not only of trust but as well of mistrust. And, despite the mistrust we might feel for rating agencies in the finance world, having rating agencies for organizations like CAs we have to trust might be another approach.

Today Microsoft announced that they have acquired technology assets from BHOLD, a dutch vendor of Access Governance technology. Microsoft thus now owns technology which has been missing in their IAM portfolio until now. Microsoft thus enters the Access Governance market. Whether that will happen through enhancements of their existing FIM 2010 product or by adding another product based on the BHOLD technology hasn’t been announced yet. Anyhow, the deal will change the Access Governance market, particularly regarding the offerings which are targeted to complement Microsoft FIM.

KuppingerCole will follow up on this news and provide further information as soon as it is available. Overall, this acquisitions proves that Microsoft continues investing in the broader IAM space and thus rates this market segment as important to their customers. For existing BHOLD customers, the acquisition provides new opportunities given that they are working with a much bigger vendor now. However, the impact on existing customers can be rated first when the Microsoft roadmap is unveiled. In general we recommend existing BHOLD customers to stay calm until more information is available. For customers investing or planning to invest into FIM 2010, the acquisition is definitely good news because it means that FIM will grow beyond the somewhat technical approach into a more business-oriented solution over time. However, without the roadmap being unveiled it is hard to predict when Microsoft customers really will benefit.

I understand the reason behind – but it is still contradictory. People expect IT vendors to quickly inform them about security issues. And people then blame them for the security issues. OK, if there are security issues which affect someone, he has some reason to blame the company responsible for these. Nevertheless, some more fairness would help in achieving even more openness. If you have to admit a security issue and you fix it, then this is obviously better than just trying to hide what has happened.

Let’s take some examples. Microsoft has been bashed for years for not doing even to secure its products. They have built a sophisticated system for patching and informing the public. They are very open regarding security weaknesses. But they are still blamed for being insecure. Apple is much more reluctant in its openness regarding security issues. But they aren’t blamed as much as Microsoft. Fair or unfair? I personally prefer the Microsoft approach – Microsoft has been amongst the first to provide a patch for the DigiNotar case. It took Apple much longer.

The DigiNotar case is my second example. Today the news of bankruptcy spread the news, after DigiNotar had to admit that their root CA (Certificate Authority) became hacked. The bad thing is that it looks like DigiNotar knew about that way before. They didn’t inform the public. Good or bad? I opt for bad – they severly increased the security risks in the entire Internet.

RSA Security is another example. They informed the public about the hack of the RSA SecurID seeds. They informed their customers. And they got blamed. I believe that the RSA approach is far better than the DigiNotar approach. Customers were informed and thus able to react. RSA spend a lot of money for helping customers to address their issues.

We can blame all, Microsoft, Apple, DigiNotar, RSA, and all the others not mentioned for security bugs. I remember a professor of informatics calculating back in the 1960′s that starting with a defined (relatively low) number of lines of code there is no chance to avoid bugs. Thus, security bugs in code and security weaknesses in IT environments are somewhat “natural”. And, by the way, it’s always a question of how much you invest in attacks to succeed. There is no absolute security. RSA did a lot to secure the seeds, knowing that they are the biggest risk (and every RSA SecurID customer could and should have known of that “single point of failure”). DigiNotar, from what I’ve heard, didn’t do as much. Microsoft has invested massively in improving security, but still is on a long-year journey for better code and so on.

At least, it is a difficult balance. Openness can’t be an excuse for security issues. But openness is better than fuzzing around or hiding security issues. Openness allows the customers to evaluate their risks and to act. And risks are better than uncertainty, which is the result of not being open around security issues. You can avoid risks – but it’s hard to deal with uncertainty.

Today, the next story about banks failing in managing trading risks hit the news. It remains unclear what allowed the trader to execute unauthorized (and thus most likely illegal) transactions which lead to that loss. However, the Risk Management of UBS obviously failed. By the way: UBS had to annouce that just the day the swiss parlament started a debate about new regulations for the finance industry.

It will be interesting to hear about why that could happen. Did some people co-operate? Did the risk management system specifically for that types of transactions fail? Or has it been an Access Management problem like at SocGen some time ago, where the trader was able to control himself? Whatever the reason is, the incident proves that there is still a long way to go in Risk Management and overall GRC – not only in the finance industry.

GRC is a key task for the C-level management. It needs sufficient funding. It needs support for the organizational changes, to build an organization with a high degree of process maturity and the understanding of the GRC requirements. It needs a strategic approach to integrate Business and IT to optimally support GRC, given that most business relies on IT systems and fraud in these systems causes the most severe harm. It needs an organizational and an IT-architectural approach to be able to manage different regulations and all types of risks in a structured and efficient way.

For the ones thinking about how to move forward in GRC, today’s KuppingerCole webinar might be worth to attend. It won’t answer all questions, but it will provide some valuable hints for moving forward in GRC. For sure, this is a long journey. But I strongly believe that it is feasible to avoid incidents like the one which happened now at UBS – and to mitigate the overall risks for organizations by a strategic GRC initiative (instead of point solutions).

During the last years, there has been a lot of change in the Identity Provisioning market. Sun became part of Oracle, Novell is now NetIQ, BMC Control-SA is now at SailPoint, Völcker has been acquired by Quest, Siemens DirX ended up at Atos. These changes as well as other influencing factors like mergers & acquistions, failed projects, and so on lead to situations where customers start thinking about what to do next in IAM and around provisioning. Another factor is that sometimes provisioning solutions are implemented with focus on specific environments – SAP NetWeaver Identity Management for the SAP ecosystem, Microsoft FIM for the Active Directory world. Not that they only support this, but they might be just another provisioning system. In addition, especially in large organizations it is not uncommon that regional organizations start their own IAM projects. The result: There are many situations in which organizations think about what to do next in provisioning.

However, just moving from product A to product B is not the best approach. In most cases, the deployment of provisioning tools took quite a while. In many cases there have been lot of customizations been made. And even while there might be some uncertainty about the future of the one or other product (or, in some cases, the certainty that the product will be discontinued sometimes in the future), just migrating from one provisioning tool to another seems to be quite expensive for little added value.

From my perspective, it is important for organizations to move at their own pace. The approach to do that is to put a layer on top of provisioning systems. I’ve described several options in a research note (and some webinars) quite a while ago. The research note called “Access Governance Architectures” describes different approaches for layered architectures on top of provisioning products. I’ll write an update later this year but the current version illustrates the basic principle well. By adding a layer on top of provisioning, which might be Access Governance, a Portal/BPM layer, or IT Service Management (or a mix), organizations can deal with more than one provisioning tool. The architecture is more complex than just using one provisioning tool. But if you are not able to rely on one provisioning tool only, its at least an approach that works.

Organizations then can for example replace provisioning tools fully or partially. The latter is quite common if complex customizations have been made for selected target systems. Organizations can deal with multiple provisioning systems that “just appeared” for some reason - M+A, specific solutions for a specific part of the IT ecosystem, or whatever. And they can move forward more flexible than in a monolithic architecture. Yes, these approaches require some more architectural work at the beginning, but that pays off. It pays off by more flexible migrations, by avoiding migrations at all, by less “political” conflicts with some of the lobbies within IT. It even enables to change the integration layer without affecting the underlying provisioning systems. And for sure it allows to interface with target systems in a flexible way, not only using provisioning tools but service desks or other types of connectivity if required.

But, at the end, the most important thing is that it allows customers to move forward at their own pace. Thus, before you think about migrating away from your current provisioning tool, think about how you can save your investments and add value – by new functionality and by business-centric interfaces of Access Governance and the increased flexibility of your IAM environment.

Is there a mismatch between the reality in organizations and the implementations of at least several of the Identity Provisioning and Access Governance solutions when it comes to the representation of physical persons in IT? To me it appears that there is a mismatch.

The reality in all large organizations I know is that the real world is sort of 3-tiered:

• There is a physical person – let’s call him Mr. X
• Mr. X can act in very different contexts. You might call them roles or digital identities, however all of these terms are overloaded with meanings. I’ll give three examples for that. 1. Mr. X might be an employee of an insurance company and a freelance insurance broker for the insurance company at the same time. 2. Mr. X might be an employee of a bank and a customer. 3. Mr. X might be the managing director of both company ABC, Inc. and DEF, Inc., which both are owned by XYZ, Ltd where he is employed as well.
• In each of these contexts, Mr. X might have more than one account. If he acts as external freelance insurance broker or customer, that might only be one account. If he is the managing director of some corporations within a group, he might have different Active Directory accounts, different RACF accounts, different SAP accounts, and so on.

You might argue that these are exceptions. However, being a customer of the employing company isn’t an exception in many organizations. And, by the way: A good and valid model has to support not only a standard approach but the exceptions as well. With other words: There are few situations in which a real-world model isn’t 3-tiered.

And there are good reasons to model the systems according to that. If someone is a customer of a bank and an employee, there are very obvious SoD rules which apply to this. He shouldn’t give loans to himself. If someone is a freelance insurance broker and an employee of the insurance, the same is true. He shouldn’t manage the insurance contracts he is selling. If someone is a customer and and employee, it’s the same again. He shouldn’t give discounts, grant consumer loans, or just change the delivery queue.

However, several tools follow a 2-tiered approach. They know for example an “identity” and “accounts” or “users” which are associated with the identity. If someone has more than one such identity, the problems begin. In some cases, it is very easy to adopt the object model. In others, you have to find workarounds like mapping the unique IDs of these identities into the other identities, which then might require a lot of additional code and is error-prone.

From my perspective, supporting a 3-tiered model out-of-the-box, with

• Persons
• Context, Identities,… (whatever term you prefer)
• Users (in specific systems), accounts,… (again – choose your term)

is mandatory to reflect the reality in organizations and to support the business requirements – especially when it comes to SoD policies. If you don’t need three tiers, it is easy to just use two of them. But if your tool supports only two tiers out-of-the-box, it might become a tough task to implement your real-world model. Looking at that point is, from my perspective, one of the most critical aspects when it comes to technology decisions.

Access Governance tools are becoming standard in IAM infrastructures. However, they mainly focus on “static” access controls, e.g. the entitlements granted to a user based on roles and other paradigms. Recertification is supported by these tools, and the solutions are maturing quickly. Thus, that part of Access Governance is easy to solve.

However, the next wave is coming with the increasing success of tools which are commonly called Entitlement Servers or Policy Servers. I tend to call them Dynamic Authorization Systems because they authorize based on rule sets and attributes at runtime. While the rules are set, the attributes are changing. I’m a strong believer in these tools and in XACML als the underlying standard for communication between the different modules and in heterogeneous environments.

But: What about Access Governance for these environments? Some of the Access Governance tools support that to some degree, allowing to pre-evaluate some business rules which use defined roles or attributes. However, many rules – especially business rules like “users of the life insurance backoffice with the role xxx and the defined constraint for signing payments up to 50,000 € are allowed to sign that type of claim” are out of scope. There is some support for testing such rules for example provided by Axiomatics.

However, I don’t see a solution which provides integrated Access Governance for all types of entitlements. Given that Dynamic Authorization Systems gain momentum, its just a matter of time until auditors will ask for such solutions. These solutions should, like modern Access Governance tools, support the lifecycle management for the policies including approvals, auditing and analysis, and the recertification of such rules. That is more complex than what is done today. But, without any doubt, we will need this soon.

It will be interesting to observe who becomes the leader in that market. The vendors in the market of Dynamic Authorization Systems themselves? The Access Governance vendors? New startups?

By the way: The topic isn’t that new – look here.

Data Sprawl appears to me to be one of the biggest challenges in information security. And, by the way, Data Sprawl is not an issue that is specific to Cloud Computing. It is a problem organizations are facing day by day.

What happens when data is extracted from a SAP system? One example: a CSV (flat) file is created with some data from the HR system. This file is delivered to another system, in best case using some secure file transfer. But what happens then? That other systems processes the file in some way or another. It might export some or all of the data, which then ends up in yet another system. And so on…

The point is: Once data leaves a system, data is out of control.

The problem is that this might happen not only with one CSV file but with 100′s of them. And dozens of systems exporting and importing that data. Governance is difficult to implement. You can define a process for allowing exports. You might defined even rules for the use of exported data. You might review the exports regularly – are they still needed? However, reviewing what happens with the data at the target systems (are the rules enforced?) is pretty complex. But there is, up to now, no technical solution to solve that problem.

Things become even worse with Data Warehouse and Business Analytics. Data frequently ends up in large data stores and is analyzed. That means that data is combined, sometimes exported again, and so on. How do you keep control? Implementing Access and Data Governance for Business Analytics systems is a big challenge, and auditors frequently identify severe risks in that area – which is no surprise at all.

Another scenario is PII in the Internet. If we give some PII to some provider for some reason, how could we ensure that he doesn’t give that PII away? No way, I’d say. We might use special eMail addresses or faked information to track back some abuse of PII, but that’s not really a solution.

So what to do? Short term, it is about implementing processes which at least try to minimize Data Sprawl and the associated risk, like mentioned above. These processes and policies are far from perfect. That helps internally, but not for PII.

We might use (very) long-term technical solutions like homomorphic encryption and other technologies which are developed around the “minimal disclosure” approaches to address some of the issues. We then might use an approach like Information Rights Management which works not no a document basis but on an attribute basis. But most of these things will help us sometimes in the future, if ever.

But what about defining a policy standard which is sticky to the data? A standard which describes how data could be used? If systems support this standard, they could enforce it. That would be about having such a standard and allowing exports at least of sensitive data only to systems which support the standard and enforce the policies. If data is split up, the policy has to be sticky to all parts (as long as it applies to all parts). If data is combined, policies have to be combined – the intersection of the policies applies then.

Such an approach has limitations, because it will first of all need some people to define the standard. And, like with all standards, it is about the critical mass. On the other hand: Virtually every organization has the problem of Data Sprawl and lacks a valid answer to the questions which are asked in the context of Data and Access Governance. Thus, there is a real need for such a standard. From my perspective, the large vendors in the markets of Business Applications (e.g. ERP, CRM, and related systems), of Business Analytics, and of all the ETL and EAI applications are the ones who should work on such a standard, because they are the ones who have to support it in their systems. And they should start quickly, because their customers are increasingly under pressure from the auditors.

This is sort of a “back to the roots” post, but for some good reason. I’ve done several advisories and customer calls recently, and in some of them it became obviuos that companies tend to miss some of the critical success factors for IAM (Identity and Access Management). Some of the projects are still too technology-focused. So I’ve put together some key success factors for IAM projects. These are not that technical, so you won’t read things like “support the cloud”, because that should just be a result of the requirements analysis.

Requirements: Understand the requirements of Business and IT – of both! And look at what might become requirements soon, so the obvious trends (like Cloud Computing, like the increasing regulatory compliance pressure even in not-that-heavily regulated industries). Knowing the requirements helps in defining the right architecture and in slicing the big elephant of IAM into smaller pieces, e.g. projects you can handle successfully.

Architecture: IAM is more than only provisioning, even while provisioning still is an important element. But oeverall, architectures are increasingly modular, providing more flexibility, better integration with other pieces of IT, and the ability to serve new requirements quickly when needed. So, look at the architectural options you have today and don’t focus on the classical architectures only.

Context: IAM is one element of IT, and one piece of your Information Security framework. It has to interface with Service Management and with other Information Security technologies, as well as with the entire GRC (Governance, Risk Management, Compliance) stack. So don’t look at IAM without understanding how it fits into the big picture.

Policies, Processes, Roles: Does your organization have well-defined policies for IAM? Does it have well-defined processes? And how about business roles, defined by the business? If any of these elements is missing, important input for your IAM deployment is missing. The policies define what you have to do and what to do first, the processes are about your implementation of provisioning and Access Governance (and more) – not even to speak about roles. The good news is that businesses better understand the need for these and are more willing to actively work on these topics then some years before.

Team: For sure it is always about having the right people – the ones who understand technology, the ones who understand business, and the ones who connect both sides.

Service focus: Last but not least it is about having a service focus. IAM is one service IT provides, as part of Information Security. It has to be user-centric, focusing on the services the users (from business and IT) require. That includes integration points to your service management environment.

You might define other ones – but these are the ones I find most important from my experience.