This is the final installment of a series of blog posts centered on mobile app security. Here is a recap of the basic tenets we have covered thus far in Part 1, Part 2 and Part 3:
1. Protect data from disclosure for privacy reasons
2. Protect data from alteration for integrity reasons
3. Protect data from destruction for availability reasons
4. Know where data resides and passes through for auditing reasons
5. Authenticate requests to identify the requestor
6. Authorize the requestor’s role to define privilege
7. Audit the operations for evidentiary collection
8. Manage configurations, sessions, and exceptions
9. Know your attack surfaces to expose vulnerabilities to threats
10. Model your threats and secure against them accordingly
11. Monitor your security posture continuously
“If you expect universities to teach students a set of facts that will make them secure coders, you’re dreaming. You have to teach a mentality.”
– Brian Chess, PhD
This was stated nearly a decade ago by the founder of Fortify (now HP Security), during a debate about the role of education in security for software developers. While mobile smartphones were still in their infancy, this statement is as true now for mobile app development as it was then – developing secure code is very different from developing many of the other functional elements, and teaching how to develop securely requires a shift in mentality from the “positive” space to the “negative” space.
This is why the twelfth and final tenet of secure mobile app development is:
12. Educate your regular staff, development, test and deployment teams continually
Agile development – the process to which almost every development team now subscribes – has done little, in my opinion, to help shift this mentality, and in some cases may have even made things worse.
“I am a user, and I want to … do something normal and average.”
Too often I find developers and designers focused on creating user stories that can readily be consumed, developed and showcased within a sprint in order to maintain the the steady pace demanded by the process. In order to do this, the “happy path” – the user flow that centers around the most common and least dangerous set of operations a user would perform while interacting with the product – becomes the primary (and in some cases the only) path addressed in the story. Left untrodden is the more dangerous and hidden path, the one that bad actors and poorly informed users would take, which ends up exposing critical vulnerabilities in the logic of the solution or implementation of the code.
Developing secure code requires a mentality centered around the defensive, the skeptical, and the pessimistic. It requires exploring user stories that start with “I am a hacker, and I want to…” and “I am a user, and I have no clue what I am doing…”
To develop user stories of this nature, teams need to be aware of the threats and vulnerabilities that exist out in the real world, and the damage that can be caused when a vulnerability is exploited by one of these bad actors. As with everything in security, education takes a multi-staged, layered approach to teaching teams how to code in a secure manner. For mature development organizations, awareness and training is an essential component to building out core competency in secure development, starting with elements such as:
Leave your details below and we'll be in touch soon.
