1 Raindrop

Avoiding the Mobile Blindside

I am not much of a football fan, in fact over Thanksgiving holiday I didn't watch a down. One thing I do appreciate about the sport though is the acknowledged role of defense in success. Many of the most successful teams are defense oriented, and even the offense is built around protection schemes like protecting the quarterback. The worst place for protection to fail is on the Quarterback's blind side, then rushers can close in quickly without the QB being able to scramble out of the way. Catching the QB unaware makes a bad situation (broken protection) worse (QB unable to react = sack).

This same blindside dynamic plays out over and over in infosec. The most common is that infosec only hears about a project a short time before the project is due to go live. Even when there are obvious problems with clear and doable fixes its often too late to put them in. The result of this process is some sub optimal decisions - (attempt to) delay the project or let it go live with rudimentary fixes in place. Neither adds much value from a security standpoint, and it stresses everyone out on top of that.

Mobile takes the security blindside to a whole new level. Mobile projects are often sponsored outside of IT, say by marketing. They are often developed outside IT by new, mobile specialist teams unaware of standard dev practices. And compounding the problem, Mobile dev cycles are very short, a iOS or Android app can go from cocktail napkin to "done" in the time a traditional enterprise app spends writing requirements.

But, you say, there have not been that many mobile app security issues we need to be concerned about. And that is fair, but only to a point. Apps are not static. Not too many people had heard about SQL Injection in 2001 but the seeds of lots of problems were sown in Web code built during that time.

In addition, mobile apps are not islands. They connect to the enterprise back end. This mobile to enterprise wormhole creates an opportunity for attackers. They can find holes in identity schemes, new ways into backend data and functionality. Mobile clients do not get near enough focus from a security perspective, and yet they get way more than most mobile servers. And yet the mobile server side mainly represents far more downside risk than the client.

All is not lost though. Many companies are setting up mobile SWAT teams, or Centers of Excellence. To "do something" around mobile. These teams usually harvest a handful of people from dev, ops, security and other teams. They have the chance to write the playbook from scratch for mobile.

A decade ago, we lost a lot of time in web security with heads in the sand that the firewall would protect us, the industry mostly ignored vulnerabilities like SQL injection to the attacker's benefit. We do not need to see that movie again. The industry has learned a lot about building SDLs, deployed better tools, and so on. We have a chance now to get ahead of the software security problem for mobile instead of waiting and letting it fester. This means doubling down on Mobile SDL, Mobile App security tooling, and frameworks.

The best time to get involved is now, because waiting just replays the same movie and our future selves will wonder - hey why didn't they build a better mobile identity scheme or deal with mobile App security in 2013? Not just getting involved, but getting involved in a way that anticipates the Mobile blindside, having tools, frameworks and security processes built out that are ready to go to work quickly when the project you never heard of crops up with - hey we are going live in four weeks. The mobile blindside is probably unstoappable for most companies, but we can still prepare. I have built out a few services along these lines and will blog more on them, in the meantime email me if you want to get some more info.

Betwixt and Between - Service Gateway for Enterprise Mobile Applications

Over the next several posts, I will explore some of the core patterns for Service Gateways that provide access to Enterprise Mobile Applications that need to leverage enterprise apps and data. Before I go there - a word about risk. Mobile security is a hot topic. Is Android less secure than iOS? What about rooted devices? How should enterprise deal with BYOD? How do mobile dev teams write secure code for mobile platforms? And the list goes on and on, there are plenty of important questions to ask. 

Amidst all these gnarly big and small questions on technical security for enterprise mobile applications. its vital to remain focused on risk. And where is the risk for enterprise mobile applications? On the apps, identity, and data housed on the numerous mobile devices? Sure. There's risk on individual mobile apps and devices, but the lion's share of data, functionality and identity is on the server side, and that's where the lion's share of the risk is too.

Boundary crossings are a key focus area for security architects. The Enterprise Service Gateway defines the boundary between "external" systems and "internal" systems (note - I am not sold that this is a valid distinction in many instances but its commonly used and holds up for the purposes of this pattern). The transition between external and internal confronts the security architect with a number of design choices. We can divide the message exchanges into two sets

1. Mobile device -> Gateway: asynchronous Web service calls via REST

2. Service Gateway -> Enterprise backend app servers: synchronous and asynchronous calls via REST, JMS, SOAP, and more

The inbound calls to the Service Gateway usually follow a simple message exchange pattern (albeit its asynchronous which is something new to many enterprises but we'll save that for another day), whereas the Gateway -> Enterprise message exchange patterns can run the gamut. In effect, the external services simplify the experience for the user and the internal services- well they just go where the data is.

The implications here shed light on the core utility of the gateway. The gateway is the location to implement three sets of security policies. 

1. External security policy: for the Mobile device -> Service Gateway message exchanges

2. Internal security policy: for the Service Gateway -> Enterprise backend message exchanges

3. External <-> Internal mapper security policy: to facilitate the right security and identity services for each boundary transition 

Security is about reducing vulnerabilities (access control services) and coping with threats (hardening, defensive services).  Service Gateways play a key role in each.

In the case of access control and identity services, the identity protocols and tokens that are used by the mobile device are usually validated and terminated at the gateway. The gateway then maps the relevant user identity, such as username and attributes, and instantiates a second protocol to communicate with the enterprise backend.

In the case of defensive services, enterprise applications are not hardened for external access, after all that's why there is a DMZ. Inbound calls, messages, and data must be inspected for malicious code targeting the enterprise.  In effect the Service Gateway is what enables the internal services to be consumed externally.

To make sure mobile security is effective, from a big picture, strategic perspective its important to keep in mind the vital role of the gateway in managing risk on both the mobile device and the enterprise backend. To execute tactically its important to divide the Gateway's role in to how it works for each separate policy zone, and how it maps between the zones.  So many projects, start out assuming that mobile is just another front end to hook up to existing middle tiers - it isn't. To get an idea on some key differences, I highly recommend this Mobile Middleware White Paper as a solid read for more on the subject.  In the next post we'll look at some policy options for each zone.

 

Mobile Session Management - Which Session?

Session management vulnerabilities are tricky. They are highly dependent on context. Identifying session fixation, session replay and the like means looking at the end to end session lifecycle from creation to use to termination. 

On normal webapps this is mostly a straightforward affair including - examine the session cookie, ensure proper cookie hygiene, make sure transport is protected, and that timeouts are set correctly. On normal webapps the server sets the timeout for the session cookie (say 20 minutes), sends to the browser and the server validates the session on the return trip. The session lives as a relationship between the browser client and the web server. But what about mobile sessions? They are pretty different, let's count the ways.

First off the user likely authenticates locally to the mobile app itself, let's call this session #1. Then any time the app needs to do something on the network (like synchronize data or replicate) it authenticates from the mobile app to the server, let's call this session #2. Next the server is very likely an API Gateway with no data or business logic, that is on the backend app servers, so the Mobile API Gateway has authenticate to the backend servers, let's call this session #3.

Now just logging into each of these sessions is a decent bit of work in and of itself. Add onto that the fact that very likely these are three fundamentally different protocols - maybe username/password for #1, OAuth for #2 and SAML for #3. Logging in is where it begins, but that's not where it ends.
How do you ensure consistent policy across these different protocols? When do you timeout the session? What happens if session #1 times out but sessions #2 & 3 are still alive? How do you reinstantiate? What happens when your user logs out?

Today these are mainly exercises left to the implementers to figure out, the tools market is pretty nascent. The above scenario is a pretty simple view compared to some Mobile apps. Enterprises still struggle with sessions management for webapps, ensuring session data isn't easily spoofed or stolen requires careful review, but its vastly more complicated for many mobile apps. Until ready made tools are available, enterprise's time spent on end to end design and testing that the sessions mesh appropriately is time well spent.

Update: Paul Madsen added on in Twitter "and the original SAML session from enterprise IdP"  For sure there are many combinations and permutations to consider. What I am seeing though is that a base case Mobile app has at least 3x more compelxity for session management than a base case web app. Considering may webapps still struggle this is food for thought.

**
Three days of iOS and Android AppSec training with Gunnar Peterson and Ken van Wyk - Training dates NYC April 29-May 1

Security Implications from One Year of Mobile Only

Benjamin Robbins (@PaladorBenjamin) just completed 52 solid weeks working solely on mobile. Of course there were some issues, but he did it and the lessons learned are instructive.

A key takeaway:

From a practical perspective I’ve learned that there are certain needs of human ergonomics that you just can’t engineer your way around no matter how cool the technology. I can say with confidence that a monitor and keyboard are not going anywhere anytime soon.

This is a key insight for people in mobile security.  Its not Mobile only that we should be designing for. Its Mobile +. Mobile and something else, on top of that any number of hyrbid models like BYOD and COPE.

Your mobile device is an extension of other things, its not a full replacement. So as someone designing security and identity services for mobile, you have to be able to mesh that identity with the server, the other machines and the directory management systems.

It tempting to think of machines and mobile devices as islands that we need to protect (enterprise archipelago security architect?), but this is to miss the point. The mobile device needs data input from other places (likely by people using keyboards ;-P), need access to documents, and they need server side communications. Users also want something resembling a consistent set of access rights no matter what platform they are using - laptop, webapp, mobile, workstation or tablet. These are unsolved problems in the security and identity industry today.

Still Benjamin Robbins' piece is a great testament to, practical issues aside,  how far things have come in a short while for mobile. I continue to expect that we see more mobile apps not less and that the devices will snowball on top of the servers, browsers, services, and desktop/laptop machines you already have to cope with. Design your security services accordingly.

**
Three days of iOS and Android AppSec training with Gunnar Peterson and Ken van Wyk - Training dates NYC April 29-May 1

What Comprises a Mobile DMZ?

The DMZ is a Web app security architecture workhorse. The DMZ operates under a different ruleset both in terms of what is allowed and in terms of the level scrutiny design, deployment and operations get. To the extent Web security works at all, its due in no small part to the isolation the DMZ provides.

The DMZ concept has lived on in the Web services world primarily through Web services gateways which limit Web Services attack surface, help developers navigate byzantine security protocols, and facilitates inbound and outbound app monitoring. 

Here we are in the first or second inning of Mobile apps, will the DMZ still play a role? I think the answer is a resounding yes. The DMZ will continue to serve an important role but the nature of the role and the capabilities will adapt for Mobile apps. I think the DMZ still plays a role and is supported by the Web Service Gateway, but in addition expect to see increased deployments of API Security & Management layers to handle some front facing tasks

 

Capability	What Stays the Same	What Adapts
Identity & Access Mgmt	Authenticaiton Authorization Audit	Support for OAuth, OpenID Connect Key mgmt (developer, user) Mobile Session management
Defensive  services	Limit Attack Surface Malicious content Monitoring access	Support client encryption Lost, Stolen Use case support
Enablement	Publish apps and content Centralized Policy enforcement	API Curation Facilitate new roles

For Mobile Secuirty architetcure I expect each layer in the DMZ to handle similar responsbilities as they have to this point but to take on additional responsibilties with a mobile flavor.

Identity is the new perimeter, and so Identity and Access Management is a core problem at the DMZ. There is a clear need to support different token types and different protocols for mobile apps. OAuth and OpenID Connect are two of the most important here, but importantly its not just session cookies, the type ot identity token and protocol will change and so will how they are used. The session length is longer and there are local client based access control decisions to be made. The Mobile DMZ must have a way to enforce security policy for apps and data over asynchronous protocols.

In addition the access control protocol is often not just a client --> server, the security architect must account for the app developer who gets access via an API. The Mobile DMZ must have a way to issue, validate and refresh developer keys. 

The Mobile DMZ serves an important function in providing defensive service, limiting what the app has access to and monitoring that access.Two additonal responsbilities include dealing with Lost/Stolen aka Remote Wipe. Many enterprises look to MDM here and that plays a role but does not help much on consumer facing applications. Client side data is often encrypted and here the Mobile DMZ is very likely involved to provision keys.

The DMZ is really about managing enterprise risk - publishing some data and functionality, while limiting the downside. This delicate balance is a result of the tension of push by development organzations and security's job to ensure prudent measures are taken to manage the risks. API Curation is an important step ring fencing the scope of the enterprise mobile interface.

To support these activities new organizational roles must be fostered including the Service Admin and API Developer role. The Service admin readies the backend enterprise services to be published. The API Developer builds content on top of them. In addition security architects and app developers must factor in how to collaborate with these folks to ensure a clear chain of responsibility - who does what. For example, the Service Admin can instrument policies for security, measurement and monitoring, but the API developer is responsible to develop the front end. Understanding what is published and how to safely use the services is key.

So I think the DMZ is here to stay, I expect the some changes, some structural, some subtle. The structural change is the decoupling of the front facing part of the DMZ to API Security and management systems with the back end enterprise gateway served up by Service Gateways. Its still early days in mobile in general and mobile secuirty in particular but I think this shift already under way.

Android Jelly Bean adds a Secure Default for Content Providers

Security requires some thought in design, lots of developer attention in secure coding, but there are gaps that the platform can close that can make the designer and the developers lives easier, setting secure defaults. Default Android introduces a number of ways that companies can unwittingly open up vulnerabilities. Jelly Bean offers a number of security improvements, one of the more interesting is adding a new and important Secure Default which protects Content Providers, aka your data. The setting protects against data inadvertently leaked to other apps. Android's permission model is pretty expressive and lets you set fine grained access control policy. Unfortunately, this means that there are many options and so many enterprises that ship with default settings can expose their data to any other app running on the Android device.

Most developers assume that when they create a database for their Android application that its only able to be used by their app. Unfortunately, this assumption is not valid. The security policy defined in the Android Manifest is the place to check to make sure this is set properly. A developer who sees the following may assume their data is protected:

<provider android:name=”com.example.ReadOnlyDataContentProvider”

    android:authorities=”com.example” />

But for Android 4.1 or prior the Manifest has an insecure default for Content Providers in that if read and write permission are not set (turned off) then its assumed that your Content Provider is readable and writeable by other apps. (note - its unlikely but I can imagine why some app might want their data readable by other apps, why there is a default for other apps to write is something I have never understood). In any case, if you have deployed Android apps its pretty likely that you have the defaults set unless someone specifically turned off read and write acces, so you should check the Android security policy and test the app.

How to check
For yours apps, the best place to start is to review your Android Manifest.xml and check that the permissions are set to disallow access that you do not want, such as other apps reading and writing to your apps databases. On 4.1 or prior this has to be set otherwise the permission is granted.

How to test
There are a variety of ways to test for this, the Mercury test suite for Android gives you a way to see what is running:

               ..                    ..:.
              ..I..                  .I..
               ..I.    . . .... .  ..I=
                 .I...I?IIIIIIIII~..II
                 .?I?IIIIIIIIIIIIIIII..
              .,IIIIIIIIIIIIIIIIIIIIIII+.
           ...IIIIIIIIIIIIIIIIIIIIIIIIIII:.
           .IIIIIIIIIIIIIIIIIIIIIIIIIIIIIII..
         ..IIIIII,..,IIIIIIIIIIIII,..,IIIIII.
         .?IIIIIII..IIIIIIIIIIIIIII..IIIIIIII.
         ,IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII.
        .IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII.
        .IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII:
        .IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

        The heavy metal that poisoned the droid
     
mercury> connect 127.0.0.1

*mercury> provider

*mercury#provider> info -p null

Package name: com.example.myapp
Authority: com.example.myapp.mydataprovider
Required Permission - Read: null
Required Permission - Write: null
Grant Uri Permissions: false
Multiprocess allowed: false

Package name: com.android.alarmclock
Authority: com.android.alarmclock
Required Permission - Read: null
Required Permission - Write: null
Grant Uri Permissions: false
Multiprocess allowed: false

Package name: com.android.mms
Authority: com.android.mms.SuggestionsProvider
Required Permission - Read: android.permission.READ_SMS
Required Permission - Write: null
Path Permission - Read: /search_suggest_query needs android.permission.GLOBAL_SEARCH
Path Permission - Read: /search_suggest_shortcut needs android.permission.GLOBAL_SEARCH
Grant Uri Permissions: false
Multiprocess allowed: false

(truncated)

Probably most Android apps have null permissions set and do not realize that it is the case or the impact of that omission (that other apps can read and write their data). In the case above the example app is set to allow other applications read and write its data. This happens many times with Android apps that contain sensitive data and the companies do not realize the exposure. This is just a snapshot but the Android permission sets are very much like a Purdy shotgun, great for skilled hunters, but also great for committing suicide.

**
Three days of iOS and Android AppSec geekery with Gunnar Peterson and Ken van Wyk - Training dates NYC April 29-May 1

The Next Mobile Wave- NYEAABTODADWI

Security departments are getting spun up over BYOD and its younger brother COPE (Company Owned, Personal Enabled).  I suggest a new approach that is neither BYOD or COPE, I have even have a catchy slogan that is sure to catch one its called NYEAABTODADWI (Noticing Your Employees Are Already Bringing Their Own Devices And Dealing With It).


WSJ summarizes the issues in How BYOD Became the Law of the Land:

The most challenging adjustment—and one that still has the longest way to go—is the need for better systems to authenticate network users, essentially all of whom now access corporate systems with mobile devices. This is an area of strength for RIM, known for the resilience of its security network. The IT infrastructure to support BYOD "has grown up quickly, with the exception of identity management," Mr. Dulaney said. 

CIOs also have shifted the onus of responsibility for the devices and the data they process to the employees themselves. CIOs created new policies spelling out how companies and employees would treat mobile devices and data, and by addressing related questions of liability and insurance. In some cases, companies insist on the right to wipe a device clean of all information, including personal files and data.

The initial response from IT security to mobile was MDM, this is fine but nowhere near sufficient. The device level of granularity is not enough to deploy and enforce security policy in the same way that "Laptop user" is not good enough. We need user identity, app identity, and data encryption. And we cannot always assume that the server will be in play. Further, MDM is only applicable for enterprise and does not help with the myriad of customer facing, external mobile apps that are being deployed every day.

Then there is the server side, Travis Spencer did a round up of some of the core identity issues at play here. From there decisions need to be made on key management, hardening Mobile web services, and implementing Gateways. So there is a lot to do and not much time to lose, because if you look, the risk of your mobile apps - what they are transacting - is pretty high. Another little wrinkle is that many initial mobile app projects are outsourced, so there tends to be this black box - well Company X is responsible. But the security team should really be more actively engaged and in a proactive way to make sure there is a Mobile specific security policy that is backed by guidance, architecture, patterns, and testing that the end product gets the job done. But before we get to all of that, we must NYEAABTODADWI .

**

Three days of iOS and Android AppSec geekery with Gunnar Peterson and Ken van Wyk - Training dates NYC April 29-May 1

Mobile App Sec Training in NYC

Are you interested in Mobile app security, Ken van Wyk and I are happy to announce our hands on training class for iOS and Android security will be in NYC this April 29-May 1. Early bird rates are offered now for this three day training session. 

I've written on mobile security a number of times, its a new technology and its not a surprise that security is lagging technological innovation, but at the same time this time is worse. The initial use cases that you see in mobile are not low risk "dipping our toe in the water" use cases, they are high risk financial, healthcare, transactional and sensitive information-laden use cases. Security needs to accelerate and get up to speed quickly, we aim to address this in the training.

Two other related posts:

• Whats the worst Mobile security posture
• How's your 2013 Mobile app security fitness looking?

 

Mobile Brings a New Dimension to the Enterprise Risk Equation

In yesterday's blog we looked at Technical Debt, and how its infosec's habit to lag technology innovation. In the big picture, this approach worked pretty well in the Web, early web security was pretty poor but early websites were mainly proof of concepts and brochureware. As the value of the websites increased, infosec was able to mostly get just enough of the job done and played catchup for the whole decade.

But this catchup approach does not work in Mobile, the first apps are not brochureware, they are financial transactions, medical decision making tools, and real dollars flowing through the apps on day zero! That's 180 degrees different from how the Web evolved, with the Web we waded in the shallow end for years, with Mobile we are diving off the high dive with 1.0.

This risk profile should embolden infosec teams to get active way earlier in the process and to be more prescriptive. But it does not stop there, the nature of the engagement has changed as well, case in point:

The personal data of about 760,000 people was temporarily leaked onto the Internet through an address book application service for smartphones, information security company NetAgent Co. reported.

The Tokyo Metropolitan Police Department is set to launch an investigation after being informed of the case Saturday by Tokyo-based NetAgent. The application developer said the data leaked online has been deleted.

The latest version of the application, Zenkoku Denwacho (Nationwide Address Book), has been distributed for Google Inc.'s Android operating system for free since mid-September. It enables users to search information listed in a major address book developed by Nippon Telegraph and Telephone Corp., according to NetAgent.

But the application is also designed to send personal data stored in smartphone users' address books, including names and phone numbers, to a rental server.

Such information temporarily became available through the Internet mainly to users of the application, which at least 3,300 people are estimated to have downloaded.

Here we see another dimension to the risk equation for Mobile that enterprises have little experience facing- they are not just providing a browser front end, they are shipping code (apps) to users. The enterprise security team now needs to not only care about the site working on Firefox, IE, and Chrome. They need to care about a whole array of platform and device specific security considerations; ensuring the application does not introduce vulnerabilities, inadvertantly steal or leak data, location, addresses, and more. And its all specific to each Mobile OS. 

Because Mobile is a Balkanized environment, platform specific Security architecture and guidance is required to get the job done. This means more up front work, but its essential to avoid mistakes like apps that can leak data or provide entry points for attackers to the Mobile app and data (bad) or enterprise gateway and backend (worse). 

Its time for Infosec to step up

Patch and pray is not good enough, enterprise security teams must roll up their sleeves, do the work required to support security services for iOS, Android apps, data, and identity. Nothing is perfect but there are absolutely better and worse ways to implement here, Infosec *should* play a leading role, as the grown up, in practically navigating these choices.

Take a hard look at the Use Cases your company is going Mobile with, this isn't beta brochureware, this is real data, real transactions, real identity, real risk, and real new technology. Now is the time for Infosec to get smart on iOS and Android, and build security in.

**
Come join two leading experts, Gunnar Peterson and Ken van Wyk, for a Mobile App Security Training - hands on iOS and Android security, in San Jose, California, on November 5-7, 2012.

Line in the Sand on Subprime Security- Mobile Apps Can't Afford to Take on Technical Debt

If there is one thing that's crystal clear in Infosec its that Infosec lags software innovation. Its a field where we are always playing catch up and the important question tends to be - how fast can we catch up?

Because innovation outpaces security, Infosec has been a passive bystander shuffling debt issuances around like someone processing subprime mortgages and rating it Triple A when the first payment cannot even be made. The industry ships apps everyday with substandard access control that do not reliably authenticate or authorize users, much less deal actively malicious actors.

Technical debt measures the necessary work that does not get shipped in a release. Taking on too much debt is like borrowing too much money, it might work but once things begin to go against you its hard to recover because you are not in a position of strength. As Warren Buffett says, "You don't know who is swimming naked until the tide goes out."

Its important to note that Technical debt for security is not a passive thing, there are people actively looking to find and exploit your Technical debt.

As of now, the Information Security Technical Debt Clock (appropriately implemented in Javascript) shows 17 years (or 6,517 days) since the internet's foundation security architetcure of Network Firewalls and SSL were deployed. Since then we've been waiting for identity, authentication, authorization, and logging standards (de facto or otherwise).

The reason why playing catch up is not good enough in Mobile is one that will be familiar to my clients - the Mobile Use Cases are too important to screw up. 

The security industry skated by the whole history of the Web on a security architecture past its sell by date, but at first it did not matter. Go way back to the mid 90s, what kind of apps were being deployed? Mostly brochureware. It took years to get to dynamic, data driven sites, and then years to get to profitable, transactional sites (pets.com anyone?). Point being - early Web was cool as hell, but it was a giant science project followed by a hype bubble. The fact that Infosec did not move quickly enough to deal with the security issues was too bad, but at the same time not a systemic failure because the arly Web Use Cases were low risk brochureware.

Most companies just dipped their toe in the water, and security incrementally figured out how to deal with SQL Injection, XSS, and so on in an iterative process. But there was time to do this in most cases.

Mobile is different

The first generation Mobile Use Cases are most certainly not dipping toes in water, they are diving in head first (and perhaps a lifeguard may not be present)! Doctors with iPads, brokerage applications, and pretty much the whole remote work force pinging your mainframe from who knows where. This has the makings of a bad cycle of events for security. Infosec is used to playing catch up because the technology moves fast but the business will take awhile to roll things out. Not in Mobile, the backend hooks are largely already there, just need to find the right Web services to call and write an iOS and Android front and dive right in the deep end.

Wait and see what happens is not good enough any more, Infosec needs to act now and get in front of the Mobile security issues. Take a hard look at the Use Cases you are deploying on Mobile, this is 1.0 technology running High Risk Use Cases, your Mobile Security architecture and implementation cannot be patch and pray.

Mind the Gap: Compare the risk level of what's being deployed to the robustness and assurance of your mobile security. Its time to invest: learning ways towards building a more resilient security foundation.

**
Come join two leading experts, Gunnar Peterson and Ken van Wyk, for a Mobile App Security Training - hands on iOS and Android security, in San Jose, California, on November 5-7, 2012.