Perimeter
10/10/2012
09:58 PM
Gunnar Peterson
Gunnar Peterson
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Walking The Mobile Mile

Putting the 'i' in identity means navigating the hidden complexities in mobile identity

Mobile applications have disparate characteristics from normal Web applications and so demand different requirements from developers. This in turn drives the need for new security models. When enterprises write mobile apps, they are not simply delivering data to the customers as in a Web app, they are delivering code that interacts with the mobile device OS, data, and security tokens (and beacons) that will reside on the device for some period of time.

This opens a window of vulnerability for devices that are lost, stolen, or compromised by malware. The enterprise response has been largely focused on Mobile Device Management (MDM), which closes out several important gaps through services like remote wipe. Today, MDM is a sina qua non technology for many enterprises but its not sufficient by itself to get the job done for mobile. After all, as Paul Madsen posits: "If my CEO and I both have the same phone, is the device the right level of granularity?" Further, the device is only one asset in play.

To get a full picture of the risk involved, you must look end to end. Mobile apps do introduce new risks, but it's not just about the device its about how they connect up to the enterprise. Mobile Access Management (MAM) -- access control services that sit in front of the enterprise gateway -- has emerged as a server-side guard enforcing access-control policy for requests from the mobile app to the enterprise back end. Mobile apps get the lion's share of attention, but do not neglect the Web services that provide the wormhole from the iPhone straight into the enterprise core mainframes, databasesm and back end services.

MAM provides mobile-specific security services for the server side. But what about the app on the device? Yet a different set of controls called Mobile Information Management (MIM) enable policy-based communication on the device.

Confused yet? The result in the short run is that the enterprise's identity architecture must factor in many different kinds of identity claims needed to resolve an access-control decision, including the device identity claims (such as hardware fingerprint), the mobile app identity claims (such as the Android PID), the local/mobile user identity claims, and the server-side identity claims. From there, these claims about an identity must be resolved and need to work cohesively across a mobile session, mobile-to-server communication session, and, in some cases, mobile app-to-mobile app communication.

This makes for a real challenge -- difficult, but not impossible, getting consistent policy enforcement across sessions, devices, and servers. As with so much else in security, there are no silver bullets. There's no single product to solve all of these challenge. The mobile app provides a new set of challenges -- specifically an integration challenge -- and likely requires different protocols than enterprises have used in the past, such as OpenID Connect and OAuth. Identity requires first-mile integration (identity provider) and last-mile integration (service provider). But, in addition, mobile "mile" integration requires meshing an array of disparate identities and attributes to enforce consistent policy.

Gunnar Peterson is a Managing Principal at Arctec Group

Gunnar Peterson (@oneraindrop) works on AppSec - Cloud, Mobile and Identity. He maintains a blog at http://1raindrop.typepad.com. View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-8243
Published: 2014-11-01
Linksys SMART WiFi firmware on EA2700 and EA3500 devices; before 2.1.41 build 162351 on E4200v2 and EA4500 devices; before 1.1.41 build 162599 on EA6200 devices; before 1.1.40 build 160989 on EA6300, EA6400, EA6500, and EA6700 devices; and before 1.1.42 build 161129 on EA6900 devices allows remote a...

CVE-2014-8244
Published: 2014-11-01
Linksys SMART WiFi firmware on EA2700 and EA3500 devices; before 2.1.41 build 162351 on E4200v2 and EA4500 devices; before 1.1.41 build 162599 on EA6200 devices; before 1.1.40 build 160989 on EA6300, EA6400, EA6500, and EA6700 devices; and before 1.1.42 build 161129 on EA6900 devices allows remote a...

CVE-2013-0334
Published: 2014-10-31
Bundler before 1.7, when multiple top-level source lines are used, allows remote attackers to install arbitrary gems by creating a gem with the same name as another gem in a different source.

CVE-2014-2334
Published: 2014-10-31
Multiple cross-site scripting (XSS) vulnerabilities in the Web User Interface in Fortinet FortiAnalyzer before 5.0.7 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, a different vulnerability than CVE-2014-2336.

CVE-2014-2335
Published: 2014-10-31
Multiple cross-site scripting (XSS) vulnerabilities in the Web User Interface in Fortinet FortiManager before 5.0.7 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, a different vulnerability than CVE-2014-2336.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.