Are MSSPs the future of IDaaS?
Or is it the reverse: Is IDaaS the future of MSSPs? That is the question...
For some time now, I have been talking about Identity as a Service (IDaaS) and discussed a few approaches to IDaaS for Enterprise Identity Management, which truly set a baseline for what we believe is the next paradigm in Identity and Access Management (IAM): the shift towards managed services, away from traditional Enterprise deployment models.
Are we talking about a paradigm shift?
I believe we are. Let me illustrate with a few questions:
- Have you been involved in, or responsible for, the deployment of an IAM solution?
- Has this deployment succeeded in meeting the business objectives and stayed within the timelines and estimated budget?
- Has your organization needed only one attempt to implement an IAM solution, without re-architecting, replacing technology vendors or system integrators, etc?
- Is your organization able to measure the return on investment (ROI) on this initiative?
- Lastly, was your ROI positive?
After over 12 years of experience deploying IAM solutions, large and small, I have seen only a small percentage of people who answered these questions in the affirmative. Even though the number has increased over the years, it is still not as high as most would want or expect, given the availability and maturity of IAM technology.
Why is this so? Many respondents cite issues with the technology choices underpinning the solution. Others point to a lack of alignment and sponsorship between technology and business stakeholders. Some say that there were no clear business objectives and expectations were not properly managed. A few venture that IAM solutions are complex and difficult to implement and underestimating their size or complexity proved a recipe for disaster.
All of these are valid reason. But does this mean that most IAM solutions are doomed to fail? The answer is not very encouraging if you follow "traditional" deployment approaches. To date, most if not all IAM deployments follow a scenario like this:
Faced with requirements from the business, IT selects a technology vendor, allocates the environment in which it will run (hardware, software, network, and data center), and in most cases engages a system integrator to help design the architecture, map the business requirements and processes, and implement the solution. Once deployed, IT is then tasked with hiring, retaining, or developing the qualified personnel it needs to operate the infrastructure. As we discussed in a recent blog post titled "Top 10 Common Pitfalls of an IAM Initiative", this combination of factors causes most projects to run longer and cost more and, in many cases, do not meet the business requirements they were meant to address. The organization is then left with a capital expenditure that needs to be recovered over time. Therefore, IT embarks on programs looking to integrate more applications and absorb more environments (M&A, intranet, extranet, etc.)-and their success rate increases only marginally. In many cases, attrition of the internal personnel further complicates the ongoing success of the deployment.
Sound familiar? The fundamental issue with the "traditional" approach is that the organization's best interest is not well aligned with that of the partners it relies on to undertake the deployment. The organization is at the center of the storm, looking at mediating and balancing the interests of vendors, system integrators, and, its own staff, who are typically not qualified to deploy an IAM solution or aware of its complexities.
This is why a new approach is needed-one that aligns more closely with the interests of the organization.
In my view, this paradigm shift is the motivation for IDaaS. One could also say that the economic conditions of the last two years, combined with the rise of the Software-as-a-Service (SaaS) model have been catalysts for this new direction.
But what is different about IDaaS?
The idea with IDaaS is that rather than having the organization strike a balance among the interests of vendors, system integrators and its own staff, an external entity acts as a trusted provider, entering a long-term relationship that is gauged by measurable results (i.e. SLAs, performance metrics, delivered milestones, etc.)
From the organization's standpoint, this model can alleviate the need for selecting, purchasing, and depreciating IAM technology; building, maintaining, and operating the IAM infrastructure; customizing and integrating various products; and staffing, training, and retaining personnel to manage the IAM environment, all of which will immediately translate in a reduction in costs.
The idea is to engage a trusted provider to build, integrate, deploy, and operate an IAM infrastructure that suits the organization's requirements. This approach should reduce upfront costs (not needing to procure hardware and software and their respective maintenance annuity), which are now blended as part of the managed service. Likewise, by not having to recruit, train, and retain specialized staff to operate the environment, the model expedites deployment timelines and reduces operational costs and risks to the organization. For the provider, the need to reduce the implementation timeline and create the capability of a repeatable model forces it to streamline the deployment process and ensure that it is done with such quality that its operation after deployment requires minimal involvement. In the end, these elements accelerate time to value.
Under this model, the trusted provider is involved in the delivery of the IAM solution, which is then governed by established parameters and service standards. Whether it is hosted on premises or outsourced (in the "cloud"), in the end the organization sees immediate and measureable value for the services they purchase-in a predictable and simpler manner.
Well, this kind of sounds like an MSSP model?
Bingo. This is precisely our prediction: the IAM deployment model as we know it is already being transformed from a highly complex approach toward a simpler one. It does not mean that IAM technology is simpler; it just means that the deployment model needs to get simpler.
"Everything should be made as simple as possible, but no simpler." - Albert Einstein
From my standpoint, this is just a natural evolution, and while it will take time for it to pan out, it is already at play, as evidenced by events like these:
- April 27, 2010: Verizon and Novell Unveil Cloud-Based Security Solution - an interesting quote from the announcement grabbed my attention: "Additionally, as part of this agreement, Verizon will be Novell's preferred identity and access management managed service provider."
- December 12, 2009: SecureWorks Expands its Global Operations and Services with the Acquisition of UK-based dns Limited - here are two relevant quotes from the announcement: "For ten years, dns has been delivering a wide range of security services to its clients, including an innovative Identity and Access Management Service"; and "SecureWorks is expanding the scope of its service offerings with the addition of dns' Identity and Access Management Practice which will benefit clients worldwide."
- May 14, 2007: Verizon Business acquires Cybertrust - and the quote: "Cybertrust's services include identity management, managed security services, vulnerability/threat management, security certification programs and a range of professional services..."
Similar events have been taking place for some time, such as IBM Managed Identity Services (part of IBM's Managed Security Services) and BT's Identity Administrations Solutions.
If you follow this logic, you will see that two paths are intersecting:
- Established MSSPs are adding IAM to their model because they want to differentiate and grow their role as a trusted partner to their clients or are responding to client pressure.
- IAM solution providers, and even software vendors, are evolving and embracing the SaaS model, and as such are starting to morph into MSSPs with a focus on identity, or as I like to call them: MISPs (for Managed Identity Services Providers)
Over the next three years, IAM will shift from the traditional deployment model (buy, host, deploy and operate) to an IDaaS model, making the latter the default. IAM technology will be mainly designed to enable IDaaS deployment models, and customers will most likely procure IAM via their MISSP of choice.