Oracle integrates Bharosa

I spoke about having a to blog list of things back in August. One of the things on that list was some thoughts on the Oracle acquisition of Bharosa. In light of Oracle announcing a few days ago that they had completed the integration, I thought now would be a good time to cross the item off my list.

First of all, the product name. It's now called Oracle Adaptive Access Manager (OAAM). They've kept to the boring naming convention that seems to be the norm in the Enterprise Identity and Access Management (IDM) industry (with an exception which I talked about here).

Oracle also acquired Bridgestream recently (I wrote about that here). As I've said previously, couple that with the Bharosa acquisition and this gives Oracle 2 products in their suite that the other major vendors do not have the capability to match.

I've spoken with many a customer who has commented on the fact that it would be great if web access management solutions provided some protection against fraudulent activity. This used to occur on a monthly basis, so it's something that the market has been asking for (which is exactly why Bharosa filled a need). The large vendor answer used to be "well, just hook the audit logs of the access management product to a security event management product and write in some rules for alerting". To be truthful, this answer was crap. Unfortunately, it was the only answer that could be given without being kicked out of the room.

With the Bharosa acquisition, Oracle filled this need and added much needed and very useful capability into their suite. Sure, OAAM gives Oracle additional features around authentication. But the most important thing is that it monitors and reacts to potentially risky or fraudulent behaviour in real time. For example, a user could have access to perform certain actions or access certain parts of a web application, but if they exhibit risky behaviour leading up to the sensitive transaction, they can either be challenged further or be denied access completely. This is extremely powerful and can be a preventative measure which stops fraud dead in its tracks instead of only allowing for follow up analysis after an incident, assuming someone even noticed in the first place. This is true dynamic authorisation based on behaviour rather than traditional "yes/no" authorisation decisions that are so prevalent in the access management technologies today.

There will of course be times where the technology gets it wrong and prevents legitimate users from doing things. This will no doubt cause some pain on the user's part and subsequently on the service provider's part (e.g. customer satisfaction issues). But this is a lot better than allowing fraudulent activity to occur and then telling the user about it after the fact. In the case of banks, the costs are usually absorbed (although they are not necessarily required to - they just do it to keep their customers happy). In other cases, the user has to wear the loss. Ask someone if they would rather be denied access as opposed to losing their money and 99% of the time, they'll pick the "deny access" option. Of course, there are trade offs. If they get denied too often, then they go somewhere else. It's a balance and this is where getting the rules and policies correct are critical. You want to be able to protect against fraudulent activity without getting in the way of business. This should be the mantra of all security departments. DO NOT get in the way of business while keeping things secure. The best security technologies are business enablers, NOT business inhibitors. It's how one gets the balance correct that will go a long way towards measuring the success of a security department and subsequently the IT department.

What I'm about to say may sound familiar to those that read my Oracle and Bridgestream post.

Having OAAM gives Oracle an additional dimension to the way they can perform access controls and access management in their Identity and Access Management deployments. It also puts them ahead of their competition in terms of feature/function comparisons. So from a technical marketing standpoint, they are ahead and may win some deals this way. I mention this because it's only going to help if someone REALLY wants this type of functionality. It possibly also makes Oracle more favourable when analysts do their quadrants and charts.

But the main thing to keep in mind is that most software sales are not made based on feature/function comparisons. They are only useful in tenders (RFIs, RFTs, RFPs) to allow vendors to answer "yes" to more questions. Having something extra will generally not win a deal. NOT having something that is mandatory however, can lose a deal. That's all Oracle have done. Bought insurance against losing a bid. From a technical and IDM suite perspective however, it's a good move. It's also great to have the capabilities in place if you're implementing it in your environment. Whether it actually works as prescribed however, I don't know. I've never implemented Bharosa. Time will tell.