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

How's your 2013 mobile app security fitness coming along?

In my Computerworld column this month, I described how being secure is in some ways similar to being fit. There's good reason why Gunnar (@oneraindrop) and I (@krvw) chose the name "Mobile App Sec Triathlon" for the training events we do.

So, how are your 2013 security-related resolutions coming along? We're about 2/3 of the way through the first month of the year, after all. Not so good, eh? Well, let's consider a few things to help out a bit.

• Be realistic. It's really easy to make a massive list of everything you should be doing, and then simply become overwhelmed by it all. Prioritize what matters most to you, your organization, and your users. The good folks over at OWASP recently did a threat model of mobile devices, from which they derived (yet another) Top 10 list, this time of the risks surrounding mobile devices.
  
  In that project, the two biggest risks that directly impact the client side of things are: 1) Lost or stolen device and 2) Insecure communications.
  
  So, prioritize what you need to do around these things, for starters. Consider how your apps store data on the mobile device. Make an inventory of every file they create or touch, and take a candid assessment of what's there and how that information might be used by an attacker who has access to it.
  
  Consider too how your app communicates with the server (or other comms). How are you securing those connections and protecting the privacy of the information? What data are you sending and receiving, and how might that be used by an attacker who has access to it?
  
  These are great starting points to get your mobile app security efforts launched in the right direction.
• Assign responsibilities and/or set clear goals and milestones. It's one thing to come up with a great list of stuff that needs to be done, but who is going to do the work? When is it going to be done? What measurable milestones exist between now and completion?
  
  Sure, these are basic project management 101 sorts of topics, but they're still important. After all, you can't manage what you can't measure.
• How are others addressing the issues? Whatever topics you're looking to address, it's worth spending some time to find out how other people have tackled them. While you won't always find a solution, it's quite possible someone has published a book, paper, talk, blog entry, etc., on your topic, or something very similar. If you have interns, launch them at this sort of domain analysis. Also consider seeking community forums where you can go and chat with your peers from other organizations. I've found OWASP Chapter meetings to be hugely useful for that sort of thing. An active OWASP Chapter that meets once a month or so can be a fabulous place to talk with others in the field.
• Don't give up. While tackling app security may seem a Sisyphean task at times, failure is worse.
• Three pillars. Keep in mind the three focus areas necessary for a software security program: risk management, security activities, and knowledge. On risk, you have got to be able to rationalize the business risks associated with your apps, and make design decisions that are commensurate. For activities, look at what activities others are doing. The BSIMM is a great starting point for that. And for knowledge, encourage and incentivize your developers to be sponge all the app security info they can find. Training, of course, is helpful, but that's only one of many sources of knowledge in a balanced knowledge "diet".

The bottom line, as I pointed out in the column, is that becoming secure takes effort. It requires someone to push that rock up the hill day after day, and there are bound to be setbacks.

Still overwhelmed? Here's a concrete thing you can do to get 2013 off to a good start. Register yourself or your developers for our next Mobile App Security Triathlon. Three days of iOS and Android hands-on training, starting on April 29th.

Hope to see you there -- and to have some meaningful discussions about other things you can be doing to bolster your mobile app security efforts.

Cheers,

Ken

What's the Worst Security Posture for Mobile?

To say its early days in Mobile is an understatement. To say its early days in Mobile security is (and I know its only January) an early candidate for understatement of the year. Making sweeping statements about Mobile anything is hard. But there are a number of promising green shoots spring up out of the ground in Mobile security. Will these sprouts grow into mighty oaks or get crushed like so many Orange Books before them? Remains to be seen.

 One thing most people agree on, for the moment, is that iOS offers better protection than Android. While Android offers a chance at a more secure environment due to its open platform, this is not always realized in end products. Still there is another dimension to the Android fragmentation problem as it relates to security, which I will get to in a second.

 Most mobile projects I have worked on start with excellent developers. The company taps their top devs to tackle and deliver on this new iOS or Android future. However, these developers are usually web gurus. Along the way, they realize things are not quite the same in Mobile. Yes there is HTTP but the client and server implementations work differently. There's additional API rework necessary to build out a Mobile middle tier. And oh did I mention testing?

 Let's return to the fragmentation issue I mentioned above in the context of a recent year end review post by Dave Aitel:

You know what didn't pan out? "Mobile attacks" in commercial attack frameworks. The reasons are a bit non-obvious, but deep down, writing Android exploits is fairly hard. Not because the exploit itself is hard, but because testing your exploit on every phone is a nightmare. There's literally thousands of them, and they're all slightly different. So even if you know your exploit is solid as a rock, it's hard to say that you tested it on whatever strange phone your customer happens to have around. 

 And of course, iOS is its own hard nut to crack. It's a moving monolithic target, and Apple is highly incentivized by pirates to keep it secure. So if you have something that works in a commercial package, Apple will patch it the next day, and all your hard work is mostly wasted.

Just like developers learned, the fragmentation issue is a real one for attackers too. Of course, the rising popularity means this is no long (or even medium) term advantage to the defender, but its an interesting marker along the journey. It does infer an answer to the general question what is the worst position to be in? Perhaps a popular Android device with poorly provisioned security. At least for now.

Of course, that is not the worst security posture. The most dangerous posture, we know from Brian Snow is - to assume you are secure, and act accordingly when in fact you are not secure.