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.

Do you remember Calendra? The vendor which was acquired by BMC many years ago? At least many existing and remaining customers require Calendra. And some of them really miss the company.

What made Calendra popular was their tool which allowed to quickly building applications to deal with information held in directories. That approach was different to provisioning, different to meta directories, and it was not just hard coding everything. Being a specialized IDE for database environment, it allows customer to quickly build directory-based applications for example to manage employee data or to implement specific approaches for delegated administrators.

Even while some few vendors try to fill the gap, there appears still to be sort of such a gap. But there is more than a silver stream at the horizon. The German company ITConcepts, a BMC partner (amongst others), has acquired the Calendra technology and is re-launching it. The product will be named Cognitum. The first version, available now, is more or less a rebranded version of the existing Calendra product. ITConcepts plans to quickly release an updated version with support for newer versions of Java stacks and some other maintenance, before moving forward with functional enhancements.

The good news for existing Calendra customers today is: Someone is working actively on that product again and provides support. And ITConcepts has a defined roadmap which looks realistic and doesn’t promise too much. However, given that ITConcepts has been a system integrator only until now, it will be interesting to observe how they execute in the software business. In any case, it is worth for Calendra customers to have a look at this offer. And chances are good that the gap in the overall IAM landscape which has been sort of left when Calendra was acquired by BMC will be filled again.

One of the intensively discussed issues in Cloud Computing is compliance with local data protection and privacy laws. The European laws, for instance, are sort of “location-dependent”. It is much easier to deal with PII (Personally Identifiable Information) within the borders of the EU than outside of that region. That is the reason why many large Cloud Providers build data centers within the EU to support their European customers.

The question which recently came to my mind is: Does it really make sense to focus on location? Shouldn’t we better focus on the information security itself? The target is to avoid abuse of PII and other sensitive information. The laws focus on processing, with a very broad definition of the term “processing”. Processing is allowed only if the providers are following specific rules. However: When we clearly define these rules, when we audit the providers, when we do certification – why should the location really matter?

You could argue that there are regions where you won’t expect the government to respect these rules. You could argue that there are countries like the US where some laws are contradictory to European laws. However, that all could be easily part of the rules defined in the law. There is no logical reason to do it by location. If you look at the way governments in some European countries act I wouldn’t say that location is the best choice for enforcing data protection.

From my perspective it would be a good idea to fundamentally re-think data protection laws and to define protection requirement levels for different types of PII and different types of processing. Then rules for the requirements external (cloud) providers have to fulfill can be defined – independent of the location. If one of these rules is contradictory to the local laws in the country the provider has its data center the result would be the same as today. But overall, we would end up with far more flexibility for the cloud.

However, IT reality is always far ahead of the laws. Thus we probably have to accept that it will take many years until the laws reflect the reality of today’s globally distributed, service-based IT.

There has been a lot of FUD (Fear, Uncertainty, Doubt) regarding Control-SA. The product has been moved from BMC to SailPoint in spring 2011. But communication about the impact for customers has been weak (to use a positive term…). After several talks with both SailPoint and BMC I’d like to provide some information. First of all, SailPoint now owns Control-SA, including the support team and other related human resources. There even is a roadmap for Control-SA and support for the newer releases (ESS 7.5.x) will be provided for several years from now.

On the other hand, SailPoint IdentityIQ now is on the price list of BMC. It can be bought with BMC contracts, BMC 1st level support, and so on. It is the strategic solution for Access Governance and Identity/Access Management offered by BMC. BMC itself only focuses on BIRM (BMC Identity Request Management), not to be mixed up with BRIM (BMC Remedy Identity Management), which is no longer sold through BMC (but the relevant parts are either BIRM or SailPoint products (ex Control-SA) now.

SailPoint will soon provide its own provisioning engine, which is sort of a lightweight implementation, being controlled by the Access Governance (and Lifecycle Management) components of IdentityIQ and which uses the existing connectors of Control-SA. SailPoint additionally plans to release new connectors.

This gives customers a lot of choices to move forward. They can use Control-SA for quite a while, at least if they use ESS 7.5.x and higher. They might move to the SailPoint provisioning engine, using IdentityIQ on top and the existing connectors. They might migrate to other provisioning tools, and so on. But the most important thing is: Control-SA isn’t dead and customers can take their time to consider their options. And my advice is: take your time and think about how your IAM, Access Governance, and Service Request Management should look like in the future.

I’ve written a research note on “Access Governance Architectures” some 15 months ago. I talk about different architectural approaches for Access Governance – and many of them are relevant when rethinking your strategy and architecture around the three topics mentioned above. The most important point is: it is not about having exactly one central provisioning tool anymore. Provisioning tools are an important element, but a lot of companies struggle with standardizing on one tool. There might be tools in use for quite a while for specific environments, sometimes with a lot of customization – think about mainframe connectors. There are mergers and acquisitions, bringing in new tools. There are lobbies pushing specific solutions for the Microsoft Active Directory environment or the SAP infrastructure. There might be too complex IT infrastructures in large organizations, divided across many organization divisions.

That’s were integrating layers like Access Governance and/or Service Request Management come into play. They might become the glue for different provisioning systems. And they even enable you to easier make changes at the provisioning layer. Modular architectures are somewhat more complex architecture-wise and from the integration perspective, but they provide you more flexibility for changes.

Looking at Control-SA environments, putting such a layer on top (which might be Sailpoint IdentityIQ but could be another Access Governance tool, SRM tool, or portal as well) allows you to migrate Control-SA at your own pace to whatever you want – or to add other provisioning tools if required. This provides you the flexibility. And in most cases it is the better choice than just replacing one monolith with another one. By the way: that is true for all the other provisioning systems, which might have to be migrated at some point of time as well.

Thus: evaluate your options first. Build a future-proof architecture (as future-proof as one could be based on what is there today). Then decide on what to do with Control-SA when. This will give you more time for your decisions and you most likely will end up with a better solution. If you then end up with a pure SailPoint or a mixed SailPoint/BMC (BIRM) solution or with a mixed vendor solution or a solution purely provided by another vendor, depends on your requirements. But it should be a well-thought decision, not something done in a hurry.

Quest just acquired another vendor in the IAM market. Symlabs is definitely more sort of a “hidden gem”, a vendor not being very well-known. That isn’t that surprising given that Symlabs mainly focuses on Federation (somewhat popular) and Virtual Directory Services (not as popular as they should be).

From a Quest perspective, Symlabs adds some missing pieces to the more and more complete puzzle of the Quest Identity Management portfolio, the Quest One Identity solutions. Starting with some Active Directory-centric solutions some time ago, Quest has managed to build one of the broadest IAM portfolios in the entire industry by selectively acquiring vendors like Völcker Informatik or Symlabs – by the way both being European vendors.

The virtual directory technology allows to access data out of various sources like directories and databases and to flexibly consolidate this data to virtual directories, e.g. at runtime and without building yet another physical directory through (more complex) synchronization. I’m a strong believer in virtual directory services for several (not all!) use cases and my experience from a large number of advisory workshops with end users is that they all are interested in virtual directory services once they have learned about that type of technology. Thus, this non-intrusive technology not only enhances the capabilities of Quest to integrate with different directory services and to access the data therein but might also become a door-opener to new customers.

In addition Quest has now some own federation technology available, another cornerstone of IAM technologies. This will help Quest to expand its Single Sign-On and authentication offerings, but might as well help Quest to add (incoming) federation support as a standard feature to their other solutions.

From my conversations with Quest I know that they have a plan for IAM – and they are successfully on this, at least when it comes to acquisitions. However, the more Quest acquires, the more they will have to work on integration and on positioning themselves not as the vendor of a set of tools but of solutions. It will be interesting observing how Quest executes on that part of what should be in the plan.

BYOD: Again one of these acronyms. It stands for “Bring Your Own Device”. You’d also say that it stands for IT departments accepting that they’ve lost against their users. They have lost the discussion about which devices shall be allowed in corporate environments. When I travel by train, I observe an impressive number of different devices being used. There are Windows notebooks, netbooks, iPads, iBooks, other types of “pads”, smartphones,…

For a long time corporate IT departments have tried to limit the number of devices to a small list, thus being able to manage and secure them. However, the reality especially in the world of mobile devices proves that most IT departments have failed. For sure many have restricted the access to corporate eMail to Blackberry devices. But many haven’t managed to achieve that target. And the popularity of Apple devices increases the heterogenity of devices being used by employees.

It increasingly looks like the solution only can be acceptance. Accept, that users want to use different types of devices. Accept that the innovation especially around smartphones and pads is far quicker than corporate IT departments can adopt their management tools.

At first glance that sounds like a nightmare for corporate IT departments. How to manage these devices? How to secure the devices? However, it is not about managing or securing the devices. That would be “technology security”. It is about managing and securing information, e.g. “information security”. It’s about the I in IT, not the T. Thus, we have to look at when to allow access to which information using which tool.

To do this, a simple matrix might be the starting point. The first column contains the classes of devices – notably not every single device. The first row contains the applications and information being used. In the cells you can define the requirements, based on the risk score of both the devices and the information. In some cases you might allow access based on secure browser connections, in others you might require to use virtual desktop connections. In others you might end up with having to build a specialized app. However, if banks are able to secure online banking on smartphones, why shouldn’t you be able to secure your corporate information on these devices?

You might argue that building apps or deploying desktop virtualization is quite expensive. However, trying to manage all these different devices or trying to restrict the devices allowed is expensive as well – and much more likely to fail. I don’t say that it is easy to protect your corporate information in a heterogeneous environment, supporting BYOD. But it is much more likely to be feasible than to manage and secure any single device – given the increasing number of these devices, the speed of innovation, and the simple fact that corporations don’t own all these devices.

Thus it is about preparing for BYOD by providing a set of secure paths to access corporate information and to protect that information – and by understanding how to protect which information where. When you start with BYOD, do it risk-based.

The data theft at Sony has been in the headlines for some days now. What makes me most wonder is that – from what I’ve read and heard first – even the passwords were stored unencrypted. However, Sony claims to have used a hash to protect these passwords. It looks like Sony also has stored the credit card numbers plus the associated security codes (which are, by the way, one of the most ridiculous approaches to enhance security) together and, no surprise, unencrypted. But if Sony has used hash values: Why did everyone assume that these passwords become common knowledge (at least for the hackers and their “customers”)?

But let’s start with passwords: Even while it is still done frequently, it is anything but good practice to store passwords unencrypted. You not even need to store them encrypted. Just store a hash, apply the same mathematical algorithm to passwords entered and compare the hashes. Even while some of the algorithms in that area aren’t “bullet-proof” that is far better than storing millions of passwords unencrypted. Storing passwords unencrypted is such a fundamental error that you just can call that grossly negligent. That is not a simple fault but ignorance against fundamental security requirements – even more, when that information is associated with credit card information and other types of highly sensitive data like bank accounts. If Sony has stored hash values that would be good practice, depending a little on the algorithm used. That reduces the risk for the Sony customers even while there is still some risk of having the hash values being stolen. Passwords might be derived from these for example based on brute-force attacks.

Let’s look at the next point. Sony has become, from what we know, a victim of an external attack. Accessing large numbers of data most likely involves a SQL injection attack. Interestingly, the Sony Playstation website has been hit by such an attack before, some three years ago. Given that something happened before raises the question why Sony didn’t protect information better. Haven’t they heard about database security tools and especially database firewalls? That’s exactly the type of technology which helps you protecting data like (if you have them) hashed or unprotected passwords or credit card data. We recently had several webinars on database security and database governance, the last one yesterday about database firewalls specifically. All the recordings are available.

Overall it looks like this hasn’t been the most sophisticated hack ever. It looks like no internals were involved (which would lead to the topic of PxM, e.g. protection against privileged access/users). It looks like Sony just has ignored not even best or good practices, but in many areas even average practices in security.

The bad thing about this is, that Sony isn’t alone out there when it comes to ignoring good/best practices in security. The most common reason is that they just don’t think about security – either because it is too complex or because of the price to pay for security. Hopefully, the Sony case alerts some of the others to review their security and to improve it. However, there is a saying in German that hope dies at last. And I feel that this is more about hoping than about really expecting web sites to become more secure by design.

By the way: European Identity Conference, to be held next week in Munich, is about information security, IAM, GRC, and database security. A good place to learn more and to meet the analysts of KuppingerCole to discuss Information Security issues in person.

There is a new initiative driven by Google, salesforce.com, and Ping Identity called SCIM (Simple Cloud Identity Management). It claims to overcome the shortcomings of SPML (Simple Provisioning Markup Language), a standard being around for some 10 years. SPML has the target of being a standard for provisioning information between systems. It is supported by most provisioning and access governance tools, but only few target systems. SAP probably is the most important supporter.

Google, salesforce.com, and others in the cloud don’t support SPML. Thus, provisioning to these systems requires using proprietary APIs, if available at all – Google and salesforce.com provide such APIs, but not every cloud provider does. To overcome this, work on SCIM has started.

The first question however is: Why not use SPML? The main reason might be that SPML is XML-based, not focusing on REST which appears to be the somewhat more efficient (and especially, more accepted) way to implement standards for the cloud. Another might be that SPML is moving forward very slowly, if moving at all. There are many defencencies in SPML, no doubt about that. These start with the limited support by non-IAM-vendors. There are technical limitations as well, including performance issues in large scale deployments and limitations regarding what could be provisioned via SPML.

Nevertheless, I’d like to ask two questions:

• Wouldn’t it be better to join forces of SPML and SCIM to build a SPML version 3.0 which supports REST as well?
• If working on a new or improved standard, wouldn’t it make sense to address all relevant use cases? SPML doesn’t today and SCIM is not likely to do, when looking at the information provided today.

The first aspect seems to be more sort of a political issue between different vendors. However, having two standards doesn’t help anyone at the end of the day.

That’s even more true if both standards are too lightweight and don’t cover all the companies need today. When looking at the little piece of SCIM specification published it looks like SCIM will only touch the surface of what is required. The use cases are focused on providing user information to cloud services. However, the topic isn’t identity management, it is identity and access management. The access or entitlement part is the big thing to solve. Dealing with different APIs of different cloud providers for identities is an issue, but it isn’t the biggest one – several vendors (federation, classical on-premise provisioning, cloud provisioning) have addressed this at least for the leading cloud providers.

But what about controlling who is allowed to do what in these services? How to manage entitlements, e.g. group membership, authorization rules, and other things? XACML is a standard which supports this, but again there is little to no support by cloud providers for XACML – like with SPML. Thus, when starting to define a new standard, it shouldn’t be a too simple one, which SCIM appears to be at that point of time. It has one which covers all relevant use cases of identity and access management. There is only limited value in providing user information to a cloud service but still having to enter the proprietary web administration interface (or using some proprietary APIs) to control access for that user, to define groups, roles, policies, and so on.

My conclusion: There should be open standards for identity and access management in the cloud. Building on proprietary services is about repeating errors made before. But a new standard shouldn’t be too limited from the beginning. That, by the way, is one of the reasons I see behind the very limited success of SPML: It was too limited. I remember a conversation with one of the leading people involved in SPML years back from now where I suggested looking at use cases like supporting client lifecycle management solutions, e.g. tools supporting (amongst other features) software deployments. There are vendors today in the client lifecycle management market building custom integrations to HR or provisioning tools today, but not based on SPML – because they have never heard about SPML and because SPML never looked at this use case.

There might be a good reason for an effort like SCIM. But just being a REST-based standard but not really thinking beyond what SPML supported won’t solve the real world problems. Thus I strongly recommend to rethink SCIM and to look at significantly extended use cases.

If someone likes to discuss this with me in person, best is to meet at at EIC in Munich, May 10th to 13th.

In these days of slowly increasing maturity of Cloud Computing it becomes more and more obvious that and why IT depends on a well thought layer which I tend to simply call “infrastructure”. I have two simple pictures of IT in mind:

• The somewhat classical model of platform, infrastructure, and software, like found in PaaS, IaaS, and SaaS in the common Cloud Computing meta models. It’s about hardware and other foundational components like operating systems, about the layer between to manage and orchestrate everything, and the applications themselves.
• Another view consists as well of three layers. The services exposed to the users (i.e. in most cases the business) on top, the service production (either in the public cloud or a private cloud or in non-cloudified IT environments) at the bottom – and a layer in between which again is used for managing and orchestrating everything. Again, this layer might best be called “infrastructure”.

This layer is which connects everything. Thus, efficiency and effectivity of this layers are the foundation of efficiency and effectivity of the entire IT. Optimizing this layer allows to better connect the available services to the business demands. It allows to manage the different layers in the cloud.

When looking at that layer, there are some few key elements:

• Service Management, e.g. the entire area of procurement, service request management, accounting, availability, performance, and whatever it requires to ensure that the services are delivered as expected
• Information Security Management, including IAM (Identity and Access Management) and at least IT GRC (Governance, Risk Management, Compliance)
• Application Infrastructures, e.g. middleware allowing to connect services, to enhance them if required and to do the orchestration

Did I miss important elements? OK, there is the classical IT security, however that’s part of Information Security – the reason we are looking at IT security is to protect information. You might add some other elements, however I tend to keep this model simple.

To me it appears to be more important to look at the dependencies of the three services. Information Security and Service Management have to work hand in hand, to ensure that access to services is restricted and controlled. Applications and Information Security are tightly related – think about how to build secure apps. And applications are, at the end of the day, nothing else than services which have to be managed.

I personally believe that starting with such a model and outlining the blueprint for your future IT definitely helps in separating the important from the less important things and to focus on building an IT ecosystem in your organization which is stable and works with whatever you plan to do in the Cloud.

See you at EIC 2011 in Munich, May 10th to 13th.