Modern enterprises seem to be slowly catching up to security, and with this also comes the need for developers and project managers (PM) alike to understand the security paradigm. We hear some people saying “Think like an attacker,” or do this and that, but when it comes down to the day-to-day, project managers and developers must be able to communicate effectively about security (Biafore, 2011).

Miscommunication in a project is a risk that enterprises cannot afford. Businesses are usually striving to be the first to market with applications that bring value, help captivate clients, drive sales, become excellent marketing tools that showcase the company as a center of excellence in technology, and build trust especially when it comes to security (Biafore, 2011).

The lack of project managers in the market has encouraged a culture that accepts project managers that don’t have experience in the types of projects or industries in which they are working. If the PM doesn’t know anything about IT how can we expect they will know anything about Cybersecurity? This lack of knowledge makes security requirements look like scope creep. To compound the issue, the other project funding venue for security—Project Risk Management—is in many cases relegated to an afterthought, if it’s considered at all.

This scenario, as absurd as it may seem, is quite common. For this reason, Microsoft brought to the market three compelling solutions that bridge the communication gap quite nicely. These are part of a simple approach, with clear communication at its core, which allows all sides to understand each other. It also simplifies tracking security requirements with team foundation services (TFS) integration and a risk management framework (OWASP, 2015).

These solutions are part of software development Threat Modeling Process which is an integral component of Threat Risk Modeling. These tools come from Microsoft’s Security Development Lifecycle (SDL) and are STRIDE, DREAD, and Threat Modeling Tool.

SDL Threat Modeling Process

he idea is simple; an organization will engage the CSO, the PM, development, and QA to identify security objectives. It is important to receive the go-ahead from leadership so that everyone can devote enough time to this work.

Subsequently, the team goes on to the software architects and decompose the application into one or more data flows that can be imported into Microsoft Threat Modeling Tool. They can then start a series of brainstorming activities analyzing the drawings following the STRIDE methodology (i.e., identifying at which points the application incurs the threat of allowing spoofing identity, tampering with data, repudiation, information disclosure and denial of service) (Shostack, 2009).

Once STRIDE has identified all the risks and the team is ready to start sprint planning, they can use DREAD (which stands for Damage, Reproducibility, Exploitability, Affected Users and Discoverability) to classify and prioritize the risks and when they will be worked on in the development cycles. The extra icing on the cake is that Microsoft’s Threat Modeling Tool integrates with TFS, and security-related requirements and tasks can be tracked. Also, the classification from DREAD can be incorporated into TFS using a template customization, which will depend on the version of TFS in use (Sullivan, 2010).
As we see with these contributions from Microsoft, it is possible for organizations to incorporate security risk management into their IT project practices. Also allowing them to start addressing software security designs from the beginning and have the software be developed and tested to be secure.

References:

Biafore, B. (2011). The Project Communication Plan. Retrieved from: http://www.mpug.com/articles/the-project-communication-plan/

Microsoft (2005). The STRIDE Threat Model. Retrieved from: https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx

Microsoft (2016). SDL Threat Modeling Tool. Retrieved from: https://www.microsoft.com/en-us/SDL/adopt/threatmodeling.aspx

SDL Team. (2015). What’s New with Microsoft Threat Modeling Tool 2016. Retrieved from: http://blogs.microsoft.com/microsoftsecure/2015/10/07/whats-new-with-microsoft-threat-modeling-tool-2016/

Shostack, A. (2009). Security Briefs – Getting Started with The SDL Threat Modeling Tool. Retrieved from: https://msdn.microsoft.com/magazine/dd347831.aspx

Sullivan, B. (2010). Security Briefs – Add a Security Bug Bar to Microsoft Team Foundation Server 2010. Retrieved from: https://msdn.microsoft.com/en-us/magazine/ee336031.aspx

OWASP (2015). Application Threat Modeling. Retrieved from: https://www.owasp.org/index.php/Application_Threat_Modeling