As enterprises struggle to keep up with their internal demand for mobile apps, more are turning to more speedy development workflows, such as the Minimum Viable Product (MVP) , which essentially calls for mobile development teams to focus on the highest return on effort when compared to risk when choosing apps to develop, and features to build within them. That is: focus on apps and capabilities that users are actually going to use and skip those apps and features they won’t.
Sounds simple, but what does that mean when it comes to security? We know application security is one of the most important aspects of data security, but if software teams are moving more quickly than ever to push apps out, security and quality assurance needs to be along for the process.
The flip side is minimum apps and features could mean less attack surface. To get some answers on the state of mobile app security and securing the MVP, we reached out to Isaac Potoczny-Jones research lead, computer security with a computer security research and development firm Galois.
galois.com Isaac Potoczny-Jones
Potoczny-Jones has been a project lead with Galois since 2004, is an active open source developer in cryptography and programming languages. Isaac has led many successful security and identity management projects for government organizations including (Navy, DOD), (DHS), federated identity for the Open Science Grid (DOE), and mobile password-free authentication (DARPA), and authentication for anti- forgery in hardware devices (DARPA).
Please tell us a little about Galois and your role there in security.
Galois is a computer security research and development firm out here in Portland, Ore. We do a lot of work with the US federal government, been around since 1999 and I've been here for 11 years now. I think a lot about this topic, I really appreciate and employ myself the lean methodologies for product development, and I love the lean startup approach. I also do security analysis for companies, so I've gone into a number of start-ups too and looked at their security profile for their products or their infrastructure, and help them to develop a security program. I've definitely seen both sides of the issue as far as where MVP thinking leads you.
What are you seeing out within organizations today when it comes to mobile security?
There's definitely a lot more development in mobile happening. The best practices in mobile aren't as well developed as best practices for the web. That's getting a little bit better.Consider HTTPS. What we saw for quite some time was something that on the Web is relatively straightforward, which HTTPS is. People were doing it wrong on mobile for years before anyone really noticed. There's a lot you can get wrong with HTTPS, and they were getting it all wrong. As people move over to mobile they are definitely having to relearn some of the lessons we learned over the years.
Password security is another one of those. People began to make passwords on websites a lot more robust. You can't just have a four or five letter password anymore on most websites. But because mobile devices are so difficult to type password into, a lot of sites have relaxed those password rules. In reality, the threat is just the same as it always has been.
What impact do you see the minimum viable product, or minimum viable app, trend?
On the MVP front, there's a very fascinating challenge with security because security is a non-functional requirement. I tend to like the lean scrum methodology. I don't know if you're familiar with that one, but I can use that one as an example. They're all kind of similar in some ways. They emphasize features, they emphasize things the users can see. They emphasize testing out ideas, and getting them into the market. Testing them, gathering metrics about how effective they are, and using that as feedback into the product. That's a really good idea about how to develop a product. But because even just the terminology, minimum viable product, it is really emphasizing minimizing.
It emphasizes getting rid of what you don't need. Those things together, minimizing things and really having an emphasis on what the user can do and see, that makes it so that non-functional requirements are kind of an afterthought. You have to squint to figure out how to apply non-functional requirements like security to a lot of these processes like scrum.
