Identity Management wrapped in access governance

The following is an excerpt from an article I just wrote for Enterprise Innovation.

The Singapore Ministry of Information, Communications and the Arts (MICA) recently announced it will require public sector entities to include, as part of their annual security reviews, system access control reviews for systems with high business impact. This requires all system owners or managers to re-certify and attest to access requirements at regular intervals in-line with the risk profile of business applications and systems.

Check out the rest of it here.

IBM just became a serious GRC player

IBM just announced that they are acquiring OpenPages and it will become part of their Business Analytics and Optimization division (which came into being because they acquired Cognos and SPSS some time ago and have since added Coremetrics and Unica to). For those who are unaware, OpenPages is a serious player in the Enterprise GRC space.

I'm not planning on analysing this to the nth degree because I'm not an expert on Business Intelligence (or Analytics as IBM calls it), but I do know a little something about Governance, Risk and Compliance (GRC).

As I mentioned previously, OpenPages is actually an Enterprise GRC vendor. That is, their focus is more on business and financial risk/compliance. If you're still confused, think Basel II (soon to be Basel III) rather than COBIT.

It makes sense for them to roll OpenPages into the Business Analytics group. But this also means that it is unlikely that the other software brands will get to have very much to do with it. I'm naturally thinking about my old mates from Tivoli here.

That said, there's actually only a very thin, dotted line that can be drawn from OpenPages to Tivoli. To make that dotted line a solid one, IBM needs to add another piece to their arsenal: IT GRC, specifically the type that links GRC to Identity and Access Management.

I'm almost certain that there are a few IT GRC (especially the Identity-centric ones) vendors that IBM Tivoli has their eye on. It's only a matter of time before they acquire one for my old mates to sell. I wonder if the relevant product teams at Oracle and CA (whom I've spoken to in the past) are sitting up a little straighter at their desks today (side note: if anyone at CA is listening, it was REALLY difficult to find a link to CA GRC Manager from your website - I almost wondered if you discontinued it).

CA GRC Manager adds IT GRC focus

Earlier last week, CA sent out a fairly lengthy press release with a list of products they've updated. The 2 products that caught my eye were GRC Manager 2.5 and DLP 12.0. This post covers GRC Manager.

Back in February, I spoke to CA about their 2.0 release of GRC Manager. Then, it was all about what they called RiskIQ and turning raw data into useful information to better manage risk and compliance. To me, version 2.0 marked the real arrival of CA as a GRC vendor to contend with because it showed they were serious and that the 1.0 version wasn't a flash-in-the-pan-side-project they thought they'd try out to see what would happen.

Late last week, I spoke with Marc Camm (SVP & GM, Governance, Risk and Compliance Products) and Tom McHale (VP of Product Management for CA GRC Manager) to see what they had to say about the new release.

The message that came through loud and clear was that version 2.5 is very much about IT GRC. If you're interested in specific new features (I don't normally do this but since it was a long press release), here's the relevant section lifted directly from CA's press release:

• Automated Questionnaires - Allows customers to easily create, distribute, and analyze the results of questionnaires for risk and compliance controls assessments.
• Robust Reporting Engine - Provides a set of pre-defined, role-based reports, as well as easily configured reports for local needs.
• Ongoing IT Controls Monitoring - Automates input of IT controls status information into CA GRC Manager and provides a single view of overall IT risk and compliance profiles.
• Extensions to IT Control Framework - Supports mapping between individual controls and authority documents, featuring a library of more than 400 regulations with mappings to IT controls from the Unified Compliance Framework.
• Streamlined Management of Select FISMA Requirements - Offers a centrally managed information security system with extensive dashboards and reports, providing instant, comprehensive information about controls and processes related to Federal Information Security Management Act (FISMA) requirements.
  

The new features and focus on IT GRC came about through feedback the product management team gathered from existing GRC Manager customers. Reading between the lines, it also looks like CA tried to make version 2.5 of the product much more usable (I'm in no way suggesting 1.0 was not usable).

Some examples mentioned include:

• Dashboards improvements to allow for better navigation between risks, controls, application contexts etc.
• Standard, pre-configured roles included out of the box for better support from day one. In a way this could be viewed as "best practice" roles for controlling access to various parts of the application and actions performed.
• Extended functionality within the reporting engine to allow users to customise pre-built (out of the box) reports without having to build their own from scratch all the time.
  

The addition of FISMA requirements and extended Unified Compliance Framework support are further evidence of this.

That's not to say there isn't any work to be done from an implementation standpoint. It's a GRC product. Anyone who thinks you can implement a GRC product without a good amount of internal effort (and external help) is delusional. What I think CA's tried to do is make GRC Manager more of an enabler for Enterprise GRC; in other words, they want to help fast-track efforts by providing as much up front as possible.

One thing that's interested me for some time is the notion of managed services (I even ran a survey to try to find out more). As a result, I couldn't help but ask Marc and Tom whether any of their customers actually use CA GRC Manager On Demand (the hosted version of the product). Apparently 20% (I won't hold CA to this number as it was just a rough figure) of their customers use GRC Manager in this capacity with a bunch of others wanting to migrate.

The fact that this version still starts with a "2" isn't lost on me. It's not a major release in the traditional sense, but CA added enough features to warrant them making some noise about it. I'll be interested to see what version 3 holds, but I'm even more interested in the percentage of customers that end up going with GRC Manager On Demand in the next release.

Spinning entitlements

A few of us (e.g. me, Nishant Kaushik, Matt Flynn, Paul Madsen, Ian Glazer) have been lamenting the negative effect Twitter has had on our blogging frequency. As a result, we've also had a lack of discussion via our blogs. But Twitter discussions can only go so far.

As such, my previous post about entitlement management was intended to stir the pot a little bit (which is why I posted the "equation" as a hypothesis) and also bring to the surface one of my pet peeves with how some vendors position entitlement management.

I wanted to achieve 2 things:

1. Point out what you're actually getting if you buy an entitlement management product from an access management vendor.
2. If we MUST use the term "entitlement management", we should at least have a good reason for doing so instead of using it to sell more products by re-branding an old concept.
   

I purposely focused only on the authorisation/access management side of things to serve the first part of the agenda. That is, if we look at the entitlement management products from access management vendors today, the hypothesis that entitlement management = fine-grained access management + XACML holds. In other words, that's all you are buying.

The second point required discussion so I conveniently ignored everything else that I've heard people refer to as "entitlement management". The most common example is in relation to IT Governance, Risk and Compliance (GRC), specifically identity compliance and attestation-type activities. I don't typically refer to this as "entitlement management", but others do.

These are the 2 obvious sides to the entitlement management coin, but there are others that could conceivably pop-up. For example, Eve Maler brings up the possibility that Vendor Relationship Management her ProtectServe/"relationship management" proposal could potentially be thought of as "Enterprise 2.0 entitlement management" (update: Eve clarified that she meant ProtectServe rather than VRM via the comments to this post).

It's clear that the term "entitlement management" means different things to different people. It's a bit like the spinning lady illusion (where depending on how you focus, you see it spinning in one direction while others see it spinning the opposite way). In our case, some might not think we're even looking at a lady's silhouette. I don't like things to be complex (which makes people wonder why I chose this line of work). But it's also for this reason that I don't like the term "entitlement management". It confuses the heck out of everyone!

I received a few email responses. There were also a couple of opinions on Twitter, a few more in the comments to my post (which I responded to there) and a handful of blog responses (Nishant, Ian Glazer and Dave Kearns). Some agreed, others partially and some not at all.

Before I move on, I should clear something up. Paul Toal (from Oracle) comments:

"I think you are making a huge assumption that entitlements management is only related to the web access layer".

I'm not. And that is part of the problem with calling all these access management products "web access management" products. It makes everyone assume that's all these products do. And that was part of my point; that they can do so much more. Simply calling them "web access management" products does their capabilities an injustice (although some have less fine-grained access management capabilities than others). I should be able to add a little more context when I write about my first Identity and Access Management project (as promised in my previous post) but I won't talk about this "web access management" generalisation today because we'll lose focus.

In reading through the opinions of others, I noticed one thing in general; most toed the company line, which was not unexpected:

• People from Sun more or less agreed (probably because I said I liked how they are approaching it with OpenSSO).
• People from Oracle tended to use fine-grained access management as a baseline and expanded on it to include centralisation across all platforms with a common enterprise services view on everything.
• Consultants didn't like having a new term to define something they've been doing for a long time and find it difficult to explain it to customers without confusing them.
• Those who have been around and know security but don't have as much of a vested interest in "entitlement management" like to take a more pragmatic approach in trying to segment the definitions into manageable portions that make sense while not discounting the term altogether.
  
• Some of the more sales-oriented folk who don't have to sell a so-called "entitlement management" product didn't like having to explain the term because it distracts customers. Either that or they worry about the need to "shoe-horn" their product/s into the "entitlement management" hype if that's all they hear about when doing sales calls.
  

I more or less agree with what Nishant says in his blog post, but not Oracle's strategy in having 2 separate products. Then again, Oracle Entitlements Server was brought on board via their acquisition of BEA so I can understand why they chose to keep it separate. It probably didn't make much financial sense to try to roll one product into the other. In their case, cash won out over idealism.

Ian Glazer has 4 problems with my hypothesis/definition. I'll address each here:

1. "Definitions that include a protocol are worrisome as they can overly restrict the definition" - He has a point. I should probably have said "an authorisation/access management policy standard". But in reality, my view is that it'll be XACML or some evolution of it. So if we wanted to make an academic definition, then we should probably not say "XACML". I'm not a fan of academic definitions though, otherwise I would have accepted the PhD offer from my university professor instead of joining IBM.
2. "I fear this definition is a reflection of products in the market today and not a statement on what “entitlement management” is meant to do" - Bingo! Ian Glazer's just summed up a lot of what I'm getting at. I DID define it as per what the access management vendors think it should mean. Whether this is what it should mean is up for debate.
   
3. "There is something missing from the definition – the policy enforcement point" - True, if you think the definition should include the terms: policy administration point (PAP), policy decision point (PDP) and policy enforcement point (PEP). Then again, I didn't have PAP or PDP in the hypothesis either. It comes down to whether one thinks that access management products as they exists today have PAPs, PDPs and PEPs. Even so, I personally think they should be in the finer details and not the definition. As an aside, access management products with fine-grained authorisation capabilities do have some PEPs. But PEPs are a little bit like connectors in provisioning products; one size does not fit all. There's usually some work that needs to be done to build a PEP that works for whatever system you are hooking into the access management product. The obvious exception here is the web reverse proxy component in access management products because they can assume a standard protocol is in place for web-based interactions. Of course, the web reverse proxy does coarse-grained access management (aka "web access management") by many common definitions. But now I'm just confusing the matter so I'll stop :-)
   
4. "I have a problem with the phrase “entitlement management”...enterprises do not use the phrase “entitlement management” the same way we do" - It's because the vendors have managed to confuse customers. On one hand, we have the "entitlement management" that vendors use to describe run-time authorisation (which I've been referring to as access management). On the other hand, we have vendors that talk about certain aspects of IT GRC as being "entitlement management". Based on what Ian Glazer is saying, the companies he's talked to see it more from an IT GRC (or operational) perspective.
   

Ian Glazer goes on to say:

"Using a single term (“entitlement management”) to span both the run-time authorization decisions as well as the necessary legwork of gathering, interpreting, and cleansing entitlements can lead to confusion."

Yeah, tell me about it. Unfortunately, this is what we have today. It's an overloaded term which has already lead to confusion. At this point however, I'm unsure what Ian Glazer's position on the whole matter is. On one hand, he's helping round out the entitlement management definition from an access management (or run-time authorisation as he puts it) standpoint but on the other hand alluding to the fact that including this aspect in the overall definition can lead to confusion.

Dave Kearns doesn't agree with the hypothesis either. He also says he doesn't quite agree with Ian Glazer but I think he's actually disagreeing with Burton Group's perception of how enterprises define entitlement management. As I said, I'm not quite sure how Burton Group wants to define it. No matter. At least it prompted an opinion from Dave. But he goes on to say that he thinks entitlements should be tied to roles, not individuals:

"Differentiate entitlement management from access management, also (else, why use both terms?). Individuals get access, roles/groups get entitlements. Access is granted to resources (hardware, applications, services, etc.) while entitlements specify what a particular role/group can do with or within that resource."

If I were to simplify this, I would interpret it as saying access and entitlements are more or less the same thing but with intricate, important differences in terms of how you look at it. You use one term for individuals and the other term for roles. I do agree with Dave from a conceptual point of view, but I don't see the need to differentiate individuals and roles here because we're getting very close to implementation specifics if we do and are in danger of adding to the confusion.

Neil Readshaw, an ex-colleague of mine from IBM and a worldwide authority on Tivoli Security products says (via a comment in response to my previous post):

"I try to talk about authorization when taking a resource centric view (e.g. who can do something), and entitlements for a user centric view (e.g. what can this user do). In the end, it may be the same data making both of those determinations."

Neil and Dave are talking about pretty much the same thing but I prefer Neil's version because it takes a higher-level approach and avoids specifics like mappings between individuals, roles and resources. Neil's statement about "the same data making both of those determinations" however, begs the question: why do we need a separate product to do entitlement management?

I did find this statement by Ian Glazer interesting though:

"A bit of history – three or so years ago Burton Group, at a Catalyst, introduced the phrase “entitlement management” to include the run-time authorization decision process that most of the industry referred to as “fine-grained authorization.” At the time, this seemed about right. Flash forward to this year and our latest research and we have learned that our definition was too narrow."

The automatic assumption would be to blame Burton Group for this mess. But if you think about it, it's not really their fault. It's the fault of all the vendors for jumping on the bandwagon and hyping it to the point it's now out of control and we find ourselves having to come to terms with some sort of definition so we can see through the entitlement fog.

Burton Group's views seem to have evolved and the vendors are stuck with a definition a couple of years old. My objection all along has been to vendors jumping on the bandwagon and trying to convince everyone that it's such a "must have", new concept to the point where customers need to buy their new "entitlement management" product before understanding what it really means. Worse still, a few went out and built brand new products and slapped the name "entitlement manager" (or a variant) on it. Would it not have made more sense to allow their access management products to evolve naturally with business needs and keep calling them "access management solutions"? Why did they have to go and confuse the matter and in the process force customers to support separate data and policy stores for products with a lot of overlapping capabilities?

If we must have the term "entitlement management" hanging around in the lingo, we need to re-adjust our understanding of what it means. Once this is done, perhaps the vendors will rename/re-think their "entitlement management" products or roll them into their access management offerings like they should have done in the first place. Analysts like Ian Glazer should be able to help the market define this because they talk to companies about what they are actually doing. My objection isn't with the industry as a whole for talking about entitlement management. It's out in the wild now and nothing any of us can do will put the entitlement genie back in the bottle. But we shouldn't be re-branding an old concept just to sell more products.

If this discussion doesn't get us closer to a good definition, I'd like at least one thing to happen. If you are looking at an entitlement management product, please take a step back to understand what it is you actually want. You might already have the tools to do it. If not, make sure you're buying the right tool for the right reason. Not just because the vendor tells you it's their "entitlement management" product and you MUST have it because you are looking at user entitlements in your environment.

CA continues their GRC march

I've observed in the past the CA looks to be getting serious about this whole Governance, Risk and Compliance (GRC) caper. Today, they released version 2.0 of their GRC Manager. I first found out about the impending release some time last week when CA got in touch offering a briefing, which I accepted (Aside: I usually accept these requests unless there's a conflict of interest on my part).

I spoke with Marc Camm (SVP & GM, Governance, Risk and Compliance Products), Tom McHale (VP of Product Management for CA GRC Manager) and Sumner Blount (Senior Principal Product Marketing Manager for Governance, Risk & Compliance) regarding the release. Apart from the press release, CA's also made a blog post and a video. There's even a few screen shots. All I can say is that they've gone all out to get some discussion around the release.

I won't rehash any of the stuff CA's already put out there because I really hate when others do it. What I will say is that version 2.0 is centred around what CA calls Risk IQ, which is another way of saying they want to help turn raw data into useful information that organisations can use to make better decisions around risk. This however, has always been the "holy grail" of any product with "risk" or "monitoring" as part of its features. Whether CA's Risk IQ delivers on promise remains to be seen. 2.0's features are essentially all the useful "risk bits" they didn't put into version 1.0. It's available via the standard off-the-shelf model we're all so used to, a managed services offering or the SaaS version (CA GRC On Demand).

Some other things I did pick up during the conversation:

• CA did not deny that there would still be a sizable amount of "heavy lifting" done by organisations and implementation partners (such as PwC). GRC Manager is simply a tool to facilitate risk and compliance requirements.
• GRC Manager leverages the IT Unified Compliance Framework as a way of attempting to implementing a core set of policies that allows for easy expansion for use with regulatory requirements (e.g. Sarbanes-Oxley, HIPAA). Note: a lot of the large vendors take a similar approach - for example, IBM Tivoli likes COBIT.
• CA runs their GRC and Security divisions as separate business units. In other words, they will ensure they integrate nicely with the Security products but are just as happy to integrate with other Identity and Access Management suites (this is "toe the company line" speak for "we don't really care if our potential customers don't use CA's security products"). I asked them how they saw the recent acquisitions of IDFocus, Eurekify and Orchestria and they said it was great to have as additional tools for integration within the CA family, but don't have any plans for wrapping GRC Manager around them as they belong to the Security division.
• One thing I wanted to clarify for my own understanding was whether they saw GRC Manager more as an identity-focused, operations-centric GRC tool or an enterprise GRC tool. The answer was that GRC Manager is an enterprise GRC tool, a "manager of managers" if you like. In other words, GRC Manager competes more with OpenPages than it does with SailPoint.
  

Relatively speaking, CA are just their GRC software journey, but I think they've got a head-start on many of the other large vendors they are usually pigeon-holed with (except for Oracle, who have a genuine claim to at least be on par, if not ahead). I'm not sure if they're quite there in terms of functionality when compared with some of the established smaller players (e.g. OpenPages) but they certainly have the ambition and company focus to get there. Once again, it'll be about execution (and perhaps the odd acquisition here and there).

CA sprints towards 2009

Oracle acquired Bridgestream (I wrote about this here). Then Sun acquired VAAU. Now CA's acquired the last remaining high profile role management player, Eurekify.

First of all, congratulations to founder Ron Rymon (he's the only person from Eurekify I've actually met) and the team. As I said to Ron earlier this week, it makes a lot of sense and I think it's a good fit.

I've written about CA's moves in the past and also mentioned the CA-Eurekify partnership in passing. It looks like they're keeping the momentum up and making a lot of headway towards competing with the other leaders in the Identity and Access Management marketplace.

I don't think the Eurekify acquisition is going to change the landscape too much mainly because of the existing partnership. The initial benefit is going to be that their sales reps probably get paid more commission for selling "CA Role Manager" or whatever they call the Eurekify product. In the longer term however, they're obviously going to have to integrate Eurekify's products into the CA stack so there's eventually going to be the "out of the box" integration benefits. Of course, the main benefit to CA as a company is in being able to market the fact they are now a serious role management player (along with Oracle and Sun).

The Eurekify acquisition also plays very nicely into CA's move towards being a strong GRC player. Eurekify's product set does include some GRC components geared towards identity compliance with an obvious focus on roles. CA's existing GRC Manager lacks some of the features around the identity-centric compliance niche that SailPoint and Aveksa play in but I'd be very surprised if CA doesn't fill the gaps using Eurikify's technology given that Sun just released their Identity Compliance Manager (which I believe was based on VAAU technology - all you Sun bloggers can correct me if I'm wrong about this) product and the fact that Oracle has something along these lines on the roadmap (according to Amit Jasuja when I spoke to him).

CA compounded their GRC march this weekend at CA World by announcing a Software as a Service (SaaS) version of their GRC Manager product, dubbed GRC Manager On Demand. This makes them the first large Identity and Access Management software vendor (the others being IBM, Sun, Oracle and Novell) to release a SaaS offering. I'm unsure how well it's going to sell given the results of my Managed Identity Services survey but what it does show is intent on CA's part to get serious about competing and getting ahead.

Oracle, Sun and CA have been very active of late. IBM and Novell have not. In fact, they have been VERY quiet. IBM will actually be releasing a new Entitlement Management product later this year but that's a little ho hum as I've already said. I have a feeling something is brewing because IBM and Novell cannot afford to sit around and watch everyone else get waaaay ahead. Novell's Access Governance Suite is an OEM of Aveksa's software. In other words, if Novell acquires someone in the role management/identity compliance area, my money's on Aveksa. This leaves IBM and SailPoint as the remaining pair. Watch this space.

Part 2 of my conversation with Amit Jasuja from Oracle

I mentioned yesterday that I spoke with Amit Jasuja, Oracle's Vice President of Development for their Identity Management Product Suite. This is the follow up post to part 1, which focused on Oracle Adaptive Access Manager (OAAM). In this post, I'll cover some of the other things we discussed.

It's probably a good idea to point out that we discussed some roadmap items and even though Amit didn't remind me that items on a roadmap are not guarantees that functionality will make it into the planned release, I'll do Oracle the favour of mentioning it on their behalf. I used to have to do this all the time so I'm aware of the drill :-)

Apart from discussing OAAM, I revisited some of the questions I asked Oracle President Charles Phillips when I met him earlier this year (because Charles didn't really answer them completely) and Amit obliged.

Essentially, part of the strategy for Oracle's overall software stack (particularly Fusion Middleware) is to have everything be "hot pluggable" with their Identity Management suite. But let me take a step back for a moment. Like many other large vendors out there, Oracle's been pushing an open strategy around Service-Oriented Architectures (SOA) and the fact that all their products will eventually support the ability to leverage (and underpin) an enterprise service bus (or whatever buzzword you feel like using). One of the main benefits in doing so is to allow for a vendor agnostic architecture where organisations aren't "locked in" to specific products (note that the industry is a long way from this being a reality despite all the hype). There are other benefits but that's a topic for another day.

The organisations arguably making the most noise around SOA are IBM and Oracle. But Oracle is making more noise (and it seems progress) around the notion of Enterprise Identity Services (Nishant Kaushik in particular seems to be spending lots of time on this) and Amit was quick to point out that the Identity Management group will be keeping with the strategy of openness while being mindful of having to show the value Oracle's products can provide over their competitors. In short, most of Oracle's software will eventually be built to support the use of SOA-like interfaces thus allowing for interoperability with competitive solutions (assuming the likes of IBM, CA, Sun and Novell build products that support the relevant standards for the relevant use cases). It will then be up to Oracle to convince organisations that even though they could use a competitor's product, Oracle's Identity and Access Management suite is the best option because of additional benefits. Amit mentioned some examples like certified support for the Identity Governance Framework (which I should point out was originally an Oracle initiative but has since been submitted to the Liberty Alliance to carry forward) and perhaps things like "quick start" initiatives with pre-built policies for use with Oracle software.

It's great to see Oracle's strategy is to make all their software "play nice together" while being open at the same time. In reality however, the sales teams will sell whatever combination of products that will fit into a customer's budget. If they have to drop products out of the solution proposal to bring it under budget, they will. It's just how the sales teams work, especially if their numbers aren't 100% tied in to Oracle Identity and Access Management software sales :-)

We also briefly touched on various pieces of the Identity and Access Management suite being "pre-baked" into other Oracle software products (e.g. there's a lot of work being done to embed Oracle Virtual Directory within other products) before moving on to exploring Oracle's relatively new Entitlements Server (OES), itself a prime candidate for being embedded within other products. I didn't want to focus on functionality because I already knew about it at a high level. I was more interested in where Oracle's headed with the product from a strategic standpoint.

The obvious direction is to have OES be the fine-grained authorisation engine for just about everything, but Oracle's software stack is HUGE. In other words, it's not an easy task (even if they go with the SOA approach) and I don't think it's going to happen very quickly. Knowing this, I shifted the focus purely to the Identity and Access Management products and their use of OES to externalise authorisation. The answer: yes, but not yet. I used Oracle Identity Manager (OIM) as an example and Amit told me that the plan is to allow for the externalisation of OIM authorisation policies to OES in the next release (e.g. delegated administration settings). He did note that OIM can already provision to OES out of the box (I would have been VERY surprised if that wasn't the case).

Finally, we moved on to speaking briefly about Governance, Risk and Compliance (GRC) that controversial "catch all" three letter acronym. I wanted to know Oracle's plans around identity-centric GRC. If you aren't familiar with the whole GRC thing, I've written about it in the past so have a quick read and then come back.

As it stands today, Oracle's GRC product is much more focused on the financial and enterprise governance (and compliance) aspects and is hooked into their Finance, ERP and CRM applications. In terms of Identity Management and compliance however, we tend to hear a lot more about identity and user account focused access controls, attestation and segregation of duties (SoD). The products in this area receiving the most press of late are SailPoint's IdentityIQ and Aveksa's Compliance Manager.

Oracle's GRC product doesn't actually compete in the identity-centric GRC area (at least not directly). But in light of Sun's very recent launch of its Identity Compliance Manager and Novell's entry into this space through their Access Governance Suite (which is actually Aveksa re-branded via an OEM agreement), I wanted to know if Oracle had any plans to expand their GRC offering to address identity-centric compliance.

Amit's answer was that Oracle does in fact have plans to do this and they are looking at expanding the capabilities of the existing GRC product instead of building a brand new one. This essentially means that the GRC product will get additional features and hooks into the Identity and Access Management suite and vice versa. This includes things like building on the existing attestation capabilities of OIM and supporting the ability to deal with SoD policies through mining existing user entitlements and also using preventative measures (like CA will have once they finish integrating the features of the recently acquired IDFocus product).

Despite Amit almost calling me a journalist on the call, I'm far from one. What I'm trying to say is that I didn't really take any notes. I just spoke to him about a topic I find very interesting and now I'm writing about it. Hence if any of you in the Oracle community (Nishant? Clayton? Mark? Anyone else?) want to confirm, deny, correct or add to any of this (or part 1) feel free to do so via the comments. If not, we'll all just take everything I've said as fact and hold product management to my claims :-)

Ultimately, talking about plans which make a lot of sense means very little other than to communicate intentions. They key will be how Oracle executes and how quickly they do it. Otherwise, they might as well be telling us they want to put a guy on Jupiter.

CA positioning itself to be a GRC vendor that matters

I've been away for the past week on a short break (Athens and Santorini - if you haven't been to Santorini, you MUST add it to your to-do list). Naturally, that means that I've missed a whole bunch of news and have to catch up.

CA made a bunch of announcements last week regarding their line of security related products. The first about a new release of CA Identity Manager, another regarding CA Access Control, a third referring to CA GRC Manager and the last in relation to a brand new product called CA Security Compliance Manager.

I found the Identity Manager and Access Control announcements boring because they are just upgrades to existing products which almost all their competitors have. Upgrade announcements are boring because they are about new features which no one will really understand until they see them in action...and even then the competitors will all say "oh yeah we can do that too" even if they can't and just get the sales engineer to hack something together for the demo or POC that looks like it's out of the box.

I found the other 2 announcements much more interesting from a strategic standpoint...

The first thing I noticed was that they are sticking to the industry norm of using a completely boring name for new products while at the same time managing to use the same name as another vendor (e.g. all the major software vendors have a product called Identity Manager which does all the provisioning, de-provisioning, password management and account workflow related activities). In this case however, they have managed to use the same name as a product IBM has (Tivoli Security Compliance Manager) but for a completely different purpose.

The second thing I noticed was that they suddenly have 2 GRC centric products. If you are a regular reader, you'll know that I'm now doing some work in the GRC area after my year long sojourn into DLP so anything GRC related gets my attention.

Like many industry terms floating around (especially newer ones), GRC means different things to different people. It also means there are many software vendors out there claiming to solve all your GRC problems. What people don't necessarily always understand is that there are many different approaches (and drivers) for a GRC program within an organisation. Most commonly, a GRC initiative is viewed from one of the following angles:

• Risk Management
• Finance/Audit
• IT Security
• Business Controls/Operations

This is not an exhaustive list and most of the time there's a fuzzy line between each. In other words, there's always going to be overlap. I should also point out that an approach is not necessarily the same as a driver, but they can be the same thing. For example, the driver might be that the organisation needs to meet regulatory requirements. The combination of the regulatory requirements and the business areas affected will determine what approaches need to be taken. Or the driver might simply be that business controls need to be better monitored, controlled and audited to improve the bottom line. In this case, the approach is the same as the business driver.

As a result, there a lot of GRC software vendors that don't necessarily compete with each other even though at first glance you might think they do (usually because they stick the term GRC in their description). In fact, it makes sense for a lot of vendors out there to partner with each other to provide a more complete solution for organisations because none (including the large vendors) actually cover off the entire GRC solution. Whether an organisation needs the complete solution is an issue for another day.

Here's why the CA annoucement is interesting. CA GRC Manager looks to be enterprise risk management focused. They've now added CA Security Compliance Manager which looks to be IT Security focused. It's starting to look like organisations have decided that IT Security Governance needs to be centred around identities, which is why IT Security GRC is sometimes referred to as Identity Centric GRC. In my opinion, this means CA Security Compliance Manager competes directly with the likes of Sailpoint and Aveksa. Notice that I haven't mentioned any of the large vendors (e.g. IBM, Oracle, Sun, Novell, SAP) in this space. This is because they don't have anything that competes. Here's why:

• IBM don't have a GRC product. They use a combination of IBM Tivoli Identity Manager (ITIM) and IBM Tivoli Compliance Insight Manager to do GRC-like tasks. IBM, I'm afraid nice looking reports and some ugly ITIM screens that do some level of attestation but business users can't figure out how to use doesn't cut it.
  
• Oracle have a product, but it hooks into all their Finance, ERP and CRM applications. This means it's very focused on business controls.
  
• Sun thinks Role Management = GRC. I have news for you Sun. Even in combination with some of the things Sun Identity Manager does, you're still not there.
• SAP have solutions, but they all hook into...well, SAP! Just like Oracle, it's focused on business controls.
• Novell are even worse off than the others because they are still peddling their provisioning and access control solutions as being able to solve all your governance and compliance problems.
  

It looks like CA is ahead of the curve in this case. Keep in mind I'm talking strategy and ability to execute and bring something to market. I'm sure all the other large vendors I've mentioned have some sort of plan. A lot of the discussion behind closed doors is probably around who they should acquire to fill the gaps. That said, the new CA Security Compliance Manager doesn't look to have some of the functionality that Sailpoint and Aveksa have, but they've essentially just released a version 1.0 of a product and they have the marketing dollars to make up for it in the initial stages. They can also claim to have integration into their GRC Manager product and their Identity and Access Management suite so that's also a leg up on Sailpoint and Aveksa because they can sell the "suite concept" instead of convincing organisations to go with a "best of breed" approach that smaller vendors have to preach.

Thinking out loud, it might make sense for CA to partner with SAP on a joint GRC marketing campaign. I seriously doubt Oracle (or CA) will agree to such a concept. Or maybe SAP should just buy CA and be done with it.