During the past few years, Quest has acquired several other IAM vendors: Völcker Informatik (Provisioning and Access Governance), Symlabs (Virtual Directory Services), Vintela (Linux/UNIX Authentication and Integration), and e-DMZ (Privileged User/Account Management) are just some examples of this shopping spree. The newest addition to the Quest portfolio is Bitkoo, a vendor in the  Dynamic Authorization Management space (http://jacksonshaw.blogspot.com/2011/12/quest-acquires-bitkoo-and-dives-into.html).

This acquisition comes as no surprise given that Dynamic Authorization Management is one of the most interesting amongst the emerging segments within the IAM market. Dynamic Authorization Management is about externalizing authorization decisions from single applications and performing them against centralized backend systems, based on centralized rules. Instead of hard-coding security into applications and instead of having to maintain authorization rules in a lot of different applications, Dynamic Authorization Management systems build the backend for such decisions.

Dynamic Authorization Management thus is a core piece of identity and security services and “Application Security Infrastructures”, i.e. the set of services applications rely on when externalizing identity and security. Such services include administration (for example using central directory services), authentication (best based on versatile, context-/risk-based authentication), authorization (Dynamic Authorization Management), and auditing/alerting. The latter is sort of the missing piece, and in that area there is a lack of standards. But that is a topic I’ll cover in another post.

So Quest has acquired Bitkoo. That is not surprising given that Bitkoo fits well into the Windows-centric strategy of Quest. It adds to the portfolio, making Quest one of the vendors with a comprehensive portfolio of IAM solutions. Quest is, from the breadth of its portfolio, playing in the same league as the well-known big vendors in that space like CA, IBM, and Oracle (which, by the way, all have something to offer around Dynamic Authorization Management). Quest has shown a clear strategy in acquiring other vendors over the past years. Now it’s up to Quest to tell this message to the world, proving that they are more than the corner store selling a mish-mosh of tools for administrators. Quest has another portfolio now – and that makes them a really interesting competitor in that market.

This acquisition will most likely also increase the attention on Axiomatics, the most prominent specialized vendor left in the market of Dynamic Authorization Management. Axiomatics is on one hand the independent alternative – and on the other hand the obvious acquisition target number one now that Bitkoo is part of Quest.

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.

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.

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.

User Management in SAP environments has fundamentally changed over the course of the last 10 to 15 years. When centralizing user management became an increasing demand of SAP customers, SAP introduced CUA (Central User Administration) several years ago. However, CUA has some restrictions and many customers have chosen other options like provisioning tools from 3rd party vendors. Thus, SAP has decided to change the approach. SAP NetWeaver Identity Management no is the strategic recommendation of SAP for managing users across SAP systems. If blogged about that before here and here.

We have recently run a survey on what SAP customers are doing today and plan to do. The range of SAP systems in production is pretty big, from several respondents using 4 to 10 instances, but a few having a farge bigger number in use, up to 200. Amongst the responding organizations, close to a quarter is using CUA today for all production instances, while another third is using CUA for some of the production instances. That might be based on the fact that CUA doesn’t support all SAP systems. The reason might be also that CUA hasn’t deployed as the strategic tool for user management in the SAP environment, covering all instances.

Most of the organizations started using CUA early, but some few deployed the tool after 2007 and thus after the first strategic announcements of SAP that SAP NetWeaver Identity Management will be the successor for CUA. However, most customers will migrate from CUA. Roundabout 60% plan to migrate to SAP NetWeaver Identity Management, but only one out of ten companies plans to move to provisioning tool of another vendor. Interestingly, some 30% of the organizations don’t plan to replace CUA within the foreseeable time. From the ones migrating roughly half have started their migration, while most of the others will make that move within the next two years.

The numbers prove that SAP appears to be successful with their strategy of migrating from CUA to SAP NetWeaver Identity Management. The customers tend to choose SAP NetWeaver Identity Management for user management within their SAP environments. Given that there are sufficient architectural options for IAM today, with Access Governance solutions or Service Request portals on top of one or multiple provisioning tools below that, this approach still leaves sufficient strategic options for the holistic view on IAM and Access Governance for the entire, heterogeneous IT environment.

To learn more about these options and how to best manage SAP and other environments from the user management, access management, and IT governance perspective, visit EIC 2011 in Munich, May 10th to 13th.

I’ve blogged last week about the RSA SecurID case. In the meantime there were several other posts and advices on that and I’d like to put together some thoughts from my side about that, looking at what customers should do now.

What should existing customers do short-term?

In most cases, RSA SecurID will be a standard mechanism for strong authentication which can’t be replaced immediately. If customers don’t use a solution for versatile authentication they usually aren’t able to opt for another (stronger) authentication mechanisms on the fly. Not using RSA SecurID however will make things even worse, because that would mean to step back to one factor with one or two means for authentication. Thus it is about staying with RSA SecurID and deciding about which additional actions to take – “compensatory controls”, e.g. increased auditing, additional fraud detection technologies, and so on.

Customers who have a versatile authentication approach in place might evaluate whether they can replace RSA SecurID with another factor – which then would be, for time and logistics reasons, an approach not depending on hardware. However doing that will be somewhat complex (helpdesk calls, technical aspects,…). Thus customers should first check whether the increased risk of using RSA SecurID is acceptable or not. Instead of replacing the option of adding another factor/means for interactions and transactions with high risk appears to be most appropriate. Besides this, the actions mentioned abovr in auditing have to be implemented.

What should existing customers do mid-term?

Replacing a technology like RSA SecurID is quite expensive. Given that RSA will harden its own systems and seeds can be changed over time, the threat will decrease. However, as mentioned in my last post, RSA SecurID never will be the same again. The mid-term answer, from my perspective, is versatility. Having more options for quickly changing to other and additional factors and means for authentication is the most promising approach. Thus, RSA SecurID is just one of multiple approaches.

For high risk environments, biometrics might come into play again (if not used yet). In addition there are some approaches of two-factor authentication which don’t rely on seeds and secrete algorithms. However they aren’t necessarily absolutely secure (if anything could be absolutely secure), thus customers should carefully evaluate whether other approaches provide real advantages above the established RSA SecurID approach. The same level of mistrust should be used for all types of authentication.

What should potential buyers do?

It is about re-evaluating the strategy for authentication. Versatility is key – and the strategies need to be re-thought if they are not focused on a versatile approach allowing different types of authentication mechanisms to be used and exchanged flexibly. Regarding RSA SecurID, the risk has to be rated again and decisions about whether the approach is sufficient for the interactions and transactions which have to protected have to be reviewed. From my perspective it is not that much about not using RSA SecurID (depending on what RSA does to increase security again, for sure – but I assume they will do a lot) but to carefully analyze the level of protection provided and weigh this against the risks of authentication fraud for what has to be protected. When deciding to use RSA SecurID appropriate controls have to be implemented – but that is true for any other authentication mechanism as well.

By the way: Regardless of the RSA SecurID approach, any authentication strategy which doesn’t focus on versatility, risk-based authentication/authorization and context-based authentícation/authorization should be re-thought.

Some general thoughts:

RSA has had a very strong image for their RSA SecurID approach – and it worked for many years. However there are two fundamental issues:

• Centralized seeds
• Confidential algorithm

Both are risks of that mechanism. Thus security is obviously limited. Regardless of which approach you use, thinking about the potential weaknesses (social phishing; central stores which might become target of attackers;…) is important. Unfortunately, security comes at a price, because there aren’t simple, cheap, easy-to-use approaches without logistics cost and other shortcomings which provide perfect security.

Again, like mentioned in my last post, we will discuss things like versatile authentication and the RSA SecurID incident at the EIC 2011. You shouldn’t miss that event.

These days I’ve met with some of the executives of SAP to talk about their roadmap. Overall, SAP is moving forward with its Identity and Access Management products. e.g. SAP NetWeaver Identity Management (NW IDM). And the integration of the recently acquired SECUDE products and technology will significantly enhance the SAP product portfolio. Some of the new features are improved role management capabilities, reporting via SAP BW (Business Warehouse), and new REST-based APIs for UI creation. No rocket science, but valuable add-ons for their customers. For sure SAP is as well enhancing the integration with their core products and with SAP BO GRC AC (SAP BusinessObjects GRC Access Control).

The most interesting step forward, from my perspective, is the strong focus on SAML 2.0 which shall become the strategic replacement of SAP Logon Tickets, which are some form of proprietary cookies. This allows cross-domain use, in contrast to domain-dependent SAP Logon tickets. And it will provide simpler integration in business processes which span not only the SAP environment but heterogeneous applications. Besides the increased flexibility, SAML can provide much more information about the user. However the step from SAP Logon Tickets to SAML 2.0 won’t be a hard or even quick migration. SAP will further support the SAP Logon Tickets – and SAML 2.0 is supported only in backend systems starting with the 7.0.0 release. However, SAML 2.0 offers significant features and SAP provides (besides the integrated IdP in SAP NW IdM 7.1 and higher) as well SP capabilities at the backend.

Another area of migration is about moving from CUA (Central User Administration) to SAP NW IdM. SAP strongly recommends to use SAP NW IdM instead of the limited CUA capabilities. Again, this is a smooth migration – CUA won’t, according to SAP, be shut down as long as ABAP-based systems (the older SAP systems) are around. However it isn’t recommended anymore to install CUA.

In essence, SAP is continuously enhancing the Identity and Access Management capabilities and strengthens not only the integration into the SAP environment but adds support for heterogeneous environments and standards. Thus, SAP NW IdM is, from a SAP perspective, an enabling technology for the integration within the SAP infrastructure and (especially with SAML 2.0) beyond.

Quest today announced that they will acquire e-DMZ Security, a PxM (Privileged Access, Account, Identity, User Management) vendor. That comes to no surprise given that PxM has been one of the last (relatively) white spots at the IAM map of Quest Software. Quest is further completing its portfolio, being a full-service provider for IAM now and offering one of the most complete portfolios in the market.

The e-DMZ portfolio consists of several module, providing different types of PxM capabilities:

• Managing passwords for privileged accounts in a central repository
• Application password management to get passwords out of scripts and applications
• Privileged session management to monitor and manage sessions of privileged users
• Privileged command management with the capability to limit the commands allowed within sessions

With these features, Quest closes some gaps. Together with products like Quest Authentication Services, Quest One ActiveEntry, or Quest ActiveRoles Server, plus the monitoring capabilities provided by different Quest tools, Quest can provide a comprehensive set of features to manage all types of accounts and their access.

However, that will require (like with virtually any PxM platform) some integration work to be done given that customers have to work with several products. One-stop-shopping doesn’t necessarily lead to a single-step-installation. With the increasing number of tools, Quest will have to look on how to provide the balance between integration and modularity to its customers. Integration in the sense of providing well integrated solutions which are up and running quickly – and modularity with focus of the Quest approach to provide focused products instead of monstrous suites.

Whilst not being the most prominent vendor in the PxM market, e-DMZ security provides good support as well for UNIX/Linux as for Windows environments, which fits well into the Quest portfolio.