CA Risk Authentication [EOL] Reviews

The benefits are that it allows us to have real-time risk analysis on authentication traffic, so we can determine whether or not it's suspicious. How suspicious is it? If it's suspicious, we can enable step-up authentication and challenge for some additional credentials, or we can block the authentication attempt completely. 

If it's a known good customer, we can actually remove the friction of authentication, or even automatically authenticate them without challenging their credentials. That aspect has been working well, even at the expense of causing some latency for authentication for everybody else because of the amount of traffic we're getting.

It gives us the ability to deny authentications for known malicious traffic. We have a webmail platform that people are constantly trying to hack into. Mostly, a large number of it comes from known bad IP addresses or unknown foreign countries which you can determine are bad or blacklisted. We can do that on the fly.

Make sure you scale for at least five times your actual load. We're having issues getting it to scale as well as SiteMinder.

It works when you really need it to work, such as when you've got a denial-of-service attack, or some other attack when you need to be able to intelligently differentiate good traffic from bad traffic. That's when you start having performance issues that start to affect the ability of legitimate customers being able to authenticate. So make sure you really plan out your back-end databases accordingly.

In addition to password authentication, we use it for anomaly detection to understand the risk of someone not having a username password that is theirs. So, if we spot anomalies, we can step up authentication in a less intrusive way. It is a second factor that the user isn't really aware of unless the user is prompted at set-up.

At the moment, we are using it in America in our wealth-management space. From an organizational perspective, it is a good system because the legislation in America is such that there's certain authentication methods that are accepted by the regulators, and risk-based authentications are normal.

I think one of the things about Risk Authentication at the moment is that the policies for it are static. What I mean by that is, when a user gets asked to step up authentication, assuming that step-up is successful, that authentication piece with the device in use at the time should really be taken into account as the next good state. So if he successfully authenticates on a step-up authentication, then that is the new good. The policy entrance should learn from that state rather than reverting back to what it believes is the static good.

I have heard of minor things with this. We've had a few issues with false positives. I think RiskMinder works on policies and rules based on the user's device and whether things change. I think there have been issues with certain people being challenged multiple times a day because the rules engine thinks things have changed between the times that you logged in. Whereas, potentially, they haven't changed at all. So, there are a few issues there. They are being addressed now and there are conversations about trying to fix them.

It is more complicated than Arcot because it has to evaluate a lot more. I think there's a whole policy engine in the back it has to go through. I don't think we've had any issues with scalability at the moment, but it's something we would have to look out for in the future as we scale up the number of people. We would potentially have to scale the system horizontally, but I wouldn't see an issue with scaling horizontally.

I think the support is okay. I think there may be limited resources in terms of the number of actual experts in the country who can support it. I think there's a question about whether we have the right people who are able to come and help with operation issues that we've had. It's really down to the prioritization of that staff. I think one of the issues is that there are limited people who understand the product. It's a fairly new product and expertise may be light.

Understand the policies you would want to make use of, understand how you want to deploy it, and make sure you have all of the use cases covered of what policies you want to use.

The most valuable features for us are the the behavioral analysis and functionality. Because RiskMinder is integrated with SiteMinder, it allows us to be able to protect the customer's identity and then react to events based on rules and rule-sets.

It operates automatically so long as you've built in the rules. It takes out a lot of the manual work. It will take the criteria you've set and the default rules and automatically reacts based on those. This comes in really handy when there are malicious attacks.

We leverage it for our customer base, which is very difficult to do for all CA products generally because CA is enterprise-focused. We've been able to customize a lot in order to make it work for us. I'm on the Customer Advisory Board for Security within CA, and as far as I know, I'm the only one on the board who's handling it from a customer perspective.
With RiskMinder, we have seen a reduction in malicious attacks by at least 75%, and we've only implemented a few rules so far. So that's a really, really big win.

During the authentication process in SiteMinder, you're not supposed to be able to notice any impact from RiskMinder. So we have it integrated in the backend. At authentication, we do a device fingerprint and collect other data. And then based on that, we determine your risk and whether we let you continue or not. But one of the things that we noticed is that it does at times impact performance when it's not supposed to.

Scalability is not a problem at all. From a capacity management perspective we've had no issues scaling.

I was actually the champion behind getting RiskMinder put in. What kind of pushed it over the edge was multiple DDoS attacks taking my platform down, over and over and over again. So that was about like five years ago. We started looking at different options because what was different in our space from the network and the security standpoint, you couldn't do anything about that traffic. It was at an application layer and within an identity perspective, so we needed it to protect our customers from that side. Botnet attacks were sending a whole bunch of authentication attempts for different identities. And they were sending so many through at the time it ended up taking my platform down, and authentications and authorizations stopped working for all of our web applications and third-party providers.

It was not easy. It took us a full year to implement it. Setting up RiskMinder was easy, it was the integration piece that was difficult. It wasn't as straightforward as we thought it was going to be and the architects that were assigned from CA, one of them was like really, really helpful, others not so much. So it was trial-and-error trying to figure out how to implement the two platforms.

We evaluated another product. I'm cannot remember the name of it. This was about five years ago, and all it did was the behavioral analytics. It did not act on behaviors. But there wasn't anything else similar to all the functionality that RiskMinder performed for us.

I would recommend that you ensure that you give yourself enough time to implement it. Take your time, don't try to rush to put it in, and ensure that you have alignment for any of your stakeholders that may be effected by it in one way or the other. Make sure that you gain alignment across the board, it'll make things a lot easier.