An often overlooked aspect of software development is secure software design. With rapidly changing technologies, tight release schedules, and sloppy architecting to begin with, finding a securely designed application is too rare of an occurrence. Additionally, the application security community has not done a great job at providing meaningful guidance around secure software design. Fortunately, the IEEE has recently established a Center for Secure Design which has been sponsoring efforts to address this very issue. Since secure software design is such a key aspect to any meaningful secure software development program, it is worth highlighting some of their recent work.
In 2015, the IEEE Center for Secure Design released a document titled Avoiding the Top 10 Software Security Design Flaws which highlights several of the common issues that can and should be addressed while designing an application. Some of the Principals discussed in this document include Authorize After you Authenticate, Use Cryptography Correctly, and Always Consider the Users. Overall, this document a great resource for software designers and security engineers to reference while delving into an applications architecture.
To compliment Top 10 flaws document, the Center for Secure Design desired to publish more hands-on guidance detailing how to apply the principles for a realistic application. After careful consideration, we decided to publish a detailed analysis of a fictitious wearable tracking device dubbed WearFit. The system included realistic components such as a wireless tracking device, a mobile application for viewing health data and communicating with the tracking device and a centeralized server, etc. The end result is a new publication published in February 2016 titled WearFit: Security Design Analysis of a Wearable Fitness Tracker. Each of the 10 flaws discussed in the Top 10 Flaws document make in an appearance at one point or another in the design of the WearFit system. As such, it makes for an excellent case study showing how these flaws might appear and how they can be avoided.
To give an example of the type of guidance provided in the WearFit analysis, consider the section Earn or Give, but Never Assume, Trust. This section highlights several situations where trust relationships exist between different components of the WearFit system. One interesting scenario is how a user's handheld tracking device communicates back to the centralized servers. The tracking device can pass sensitive user data through either a user's mobile device or any other mobile device with the WearFit app installed. In both cases, the mobile device is trusted to pass the data on to the server but care must be taken to ensure that your mobile device cannot inappropriately access other users' data (and vice versa). However, only my own tracking device is able to establish a full trust relationship with my mobile app through a device pairing process.
Both of these documents have been thoroughly researched and carefully designed by leading application security researchers, engineers, and architects. Designing applications securely will always be a challenge but having guidance like this is a good first step to help you do the right thing. Please take some time to review these documents yourself; you're bound to find some helpful insights and suggestions.