Risk-Based Access Control: Part One

A couple of years ago, I published an approach to doing risk-based access control using Oracle Adaptive Access Management (OAAM).

http://fusionsecurity.blogspot.com/2011/01/risky-business.html

More recently, I've had a chance to play with Symantec's VIP (Identity Protection) user services, which is most well known for its two-factor one-time-pin (OTP) service.  VIP also includes a risk component that can collect footprint information about the client and return a risk score back to the PEP or PDP for enforcement.   VIP user services is divided into a couple of different areas:

• Query Services: Provides information on the end-user and when the credential was last bound to the user and when the credential was last authenticated.
• Management Services: CRUD operations on users, adding credentials to those users
• Authentication Services: Validate OTPs and evaluate risk

These are SOAP based services and the WSDLs are available for download from the VIP Management Console.  I used Axis2 to connect to convert the WSDL to Java stubs and connect to the service.  Here is a snippet:

                        RiskScoreType riskScore = null;
EvaluateRiskRequest riskRequest = new EvaluateRiskRequest();

EvaluateRiskRequestType riskType = new EvaluateRiskRequestType();
IpAddressType remoteIpAddress = new IpAddressType();

remoteIpAddress.setIpAddressType(ipAddress);

RequestIdType myRequestId = new RequestIdType();
myRequestId.setRequestIdType(requestId);

UserIdType myUserIdType = new UserIdType();

myUserIdType.setUserIdType(user);

UserAgentType myUserAgentType = new UserAgentType();

myUserAgentType.setUserAgentType(userAgent);

IAAuthDataType myIAAuthDataType = new IAAuthDataType();

myIAAuthDataType.setIAAuthDataType(fingerprint);

riskType.setIp(remoteIpAddress);
riskType.setRequestId(myRequestId);
riskType.setUserId(myUserIdType);
riskType.setUserAgent(myUserAgentType);
riskType.setIAAuthData(myIAAuthDataType);

riskRequest.setEvaluateRiskRequest(riskType);
Boolean isRisky = true;
try {
       EvaluateRiskResponse response = authServiceStub.evaluateRisk(riskRequest);
       System.out.println("Status: " + response.getEvaluateRiskResponse().getStatus());
isRisky = response.getEvaluateRiskResponse().getRisky();
System.out.println("Risky? " + isRisky);
System.out.println("Policy Version: " + response.getEvaluateRiskResponse().getPolicyVersion());
System.out.println("Risk Reason: " +           response.getEvaluateRiskResponse().getRiskReason());
        riskScore = response.getEvaluateRiskResponse().getRiskScore();

The response I get back is something like:

Risky? false

Policy Version: 1.0

Risk Reason: Device recognition, Device Reputation

Risk Score: 51

The risk score is based on configurable settings on the VIP management side.  I'll discuss the VIP policy side in the next part of this series.

WWBD, My First Jailbreak, MAM Compliment to IAM

At CSA Congress earlier this month, I told the story about this creepy dude sitting next to me on the plane down to Orlando.  I don't know if it was the bad scottish accent or the strange dental work, or the feeling that he was shoulder-surfing me when I was working on the iPad.  I got a picture of him leaving the airport...

Yea, turns out that was MY iPad he got off with while I was in the bathroom on the plane.  I called my company and they were able to wipe the device with MDM.  I have to wonder though, how long would it take any good super-villian to get the data they wanted off a device?   I had to assume he had the device password since he probably saw me punch that in on the plane.

I needed to present again off my backup iPad, a first generation model.  It doesn't support mirroring, so I would need to jailbreak it anyway in order to hack the device to support display to VGA.  It took me all of 10 minutes to do so.  I thought back to the incident on the plane.  What would Bane Do?   He probably had the device broken and all of the data pulled off before it was wiped.  Then I had to ask myself, what data did those mobile apps keep on the device?  It's not always obvious to me what apps are storing on the file system.  I do know that developers make it easy to access the applications once you've signed in once to app, not to have to do again.  How could I have mitigated this risk once my device was compromised?

I've found that Mobile Application Management (MAM) paired with a robust access management solution can help in a lot of ways.   With the MAM solutions I've evaluated, the theme is essentially a corporate app store.  Applications downloaded through the MAM have been vetted through the company and thus have some degree of governance.  MAM can apply application specific policy for those apps that come from the MAM app store.  Some of these policies are very MDMish in nature (prevent access when device is jailbroken, or prevent apps from storing data locally for instance), but specific to the app.  This is nice on the BYOD front, as the company can protect its interests, without wiping out someone's personal data that happens to be co-located with the corporate apps.  It also helps with the Bane scenario, because for the apps that matter to the company, data is always remote from the device.

The more interesting part to me, though, is the authentication aspect.  The ability to require authentication per application provides a consistent authentication experience, linking the MAM with the corporate access management system.  Through a web view and SAML approach, one can authenticate to the app, propagate identity to the service provider, and get SSO within the device.  Once you're linked in with the IAM, then you can start applying context-based authorization to the scenario.  How did the user authenticate?  What device?  Where was the user when he/she requested the app?  What is the historical profile of the user accessing this application?   What is the environmental risk condition presently?  What time of day was it accessed?  How sensitive is the application or content being accessed?  Using a risk engine, these factors can be leveraged to generate a verdict that might trigger a 2nd factor to be required before accessing the cloud resources.  Bane might have device access, but he isn't going to get to the more sensitive apps.