Ask any business leader if they’re OK relaxing their mobile security standards and they’ll quickly tell you it’s not an option. But as mobile apps transition from standalone experiences to integral parts of an overall physical/digital ecosystem, securing them becomes more complex and more dynamic—a job well beyond the duties of mobile app developers.
Mobile developers are, by definition, people that write code for mobile devices. While their job often requires attention to other parts of a mobile-enabled business process, if the activity doesn’t influence an end-user experience, mobile developers won’t be passionate about it. As a result, enterprises become faced with an age-old challenge: How do you produce high-quality, secure applications when the developers are not motivated to meet those same goals?
(Related: NIST releases a guide to mobile app security)
The answer: Don’t place the sole responsibility for securing mobile apps on individual developers. Instead, drive security through a coordinated effort between the business and development teams. To do so, organizations should follow four key steps.
First, define mobile security at the corporate level to remain consistent across all apps. This requires companywide app classification. Within each class, you should define the individual aspects of the app to be secured and the strategy for implementing each aspect. These policies should be able to be updated as new security scenarios are encountered or corporate governance changes occur. Flexibility is key!
Then, rather than have app developers write code to secure data connections, encrypt local data, and create appropriate login screens, they should now simply denote in the code where these aspects occur. This way, if corporate policy changes, what was once unsecured may now be secured without requiring new development efforts. The markup can simply be metadata or comments that wrap the aspect in question.
Once the security policies are defined and source code is marked up, use build tools to apply these security policies through best-practice implementations. Doing so won’t be a static application. Because mobile security has many layers, the teams will want to make sure that the policies applied can be altered as different conditions arise in real time. For example, the CEO will have different mobile app permissions and security controls while he’s in the office than the newly hired associate who’s on vacation.
Finally, map deployed apps to existing security policies. As a given policy changes, apps can be flagged for updates that will bring them back into compliance. Because this process should rarely require direct development efforts, developers can spend their time doing what they love: creating engaging new experiences for consumers.