The golden rule that governs business technology is that it’s continually changing and evolving. Change can be introduced to better meet market demands, maybe to drive efficiencies or business agility, or simply to allow us to keep up with competition. Whatever instigates the change, businesses need a way to not only build the best and most feature-rich software and systems, there also needs to be robust security process that address today’s pervasive threat environment. Let’s look at how security can be integrated into the enterprise’s change process, irrespective of whether it’s infrastructure or software related, using Microsoft’s Secure Development Lifecycle.
In 2004, Microsoft got serious about fixing its security problem. Redmond announced the that all their development programs from then on would follow a repeatable securityoriented development process, which became known as their Secure Development Lifecycle (SDL). This was to be a company-wide initiative and was mandatory for all programmers to follow, irrespective of how large or small their coding projects were. There’s no doubt about it, introducing a massive change in process such as this into a company like Microsoft would have been costly, Redmond needed to do something to fix its reputation as the most vulnerable and exploited code in the industry. Interestingly, 13 years on and the SDL is now used by many Microsoft development companies and has become an industry standard approach to building more secure and robust code.
Getting Stated
The SDL won’t help developers code applications, but what it does do is teach them how to decide what functions code needs to have, based on the paradigm of “cause and effect. “This means that the developer can model their code from the security perspective, allowing them to see exactly where the weaknesses could be, through a continuous process of improvement. This feedback loop ensures that applications are always being fixed and vulnerabilities are continuously being discovered, with a high percentage being found faster and earlier in the development lifecycle than before. This has the knock-on effect of meaning that far fewer vulnerabilities are making it into their production code. Furthermore, accountability sits at the heart of making the SDL work, since programmers need to adhere to the SDL, producing threat models and mitigation strategies as deliverables when they create anything new.
Figure 1 shows the full SDL, from the up-front training focus of getting everyone up to speed with using the SDL, understanding secure coding and understanding how hackers work, through to the incident response planning at the end of the cycle should there be a need to address something that’s been overlooked.
“Figure 1 Microsoft’s Secure Development Lifecycle”
Training
This aspect of the SDL means that all project managers, architects, developers and testers are aware of the requirements of the secure development lifecycle and they all know how to code defensively, as well as how to model security requirements and test for security related defects.
Microsoft has provided a selection of training courses for each stage of the SDL. Even though you may have special requirements that are peculiar to your industry or market sector, this is a great place to start and will help accelerate your adoption of the SDL. Look at: https://www.microsoft.com/en-us/SDL/process/training.aspx
Requirements
A common way of discovering and documenting security requirements is based on the Universal Modelling Language construct known as the use case. Use cases describe a desired behaviour within a system, documenting how users interact with processes and systems, while showing how data is transmitted and processed within the task. Tasks are written as a single high-level interaction, such as “buy a Coke” or “put on your socks”. The developer then uses the use cases to build functions that deliver on these outcomes. However, the security problem is not so easily modelled. Security guys need to model what systems should not do, rather than what they should do, which is where the concept of misuse cases came from. Two Norwegian computer scientists, Guttorm Sindre and Andreas Opdahl, described misuse cases in their paper, “Eliciting Security Requirements with Misuse Cases” (Springer-Verlag London, 2004).
There are three key stages to security requirements modelling in the SDL:
- Establish security and privacy requirements
- Create quality gates and bug bars
- Perform security and privacy risk assessments
Each of these stages are accompanied by reference material, downloads, tools and training so Microsoft has already provided all the material you need to introduce this into your enterprise.
Design
This design phase of the SDL helps the business architects establish best practice around design and functional specifications and ensures that all the decisions that affect security are based on risk analysis. This ensures that the resultant code will mitigate security and privacy issues throughout the resultant system, while each individual security requirement is proven as being addresses and is capable of being tested. The design phase has three stages:
- Establish design requirements
- Perform attack surface analysis and reduction
- Use threat modelling
The core of the entire SDL relies on the ability for the architects or designers to use threat modelling. This is where the architect or designer will represent threat scenarios in a model that identifies vulnerabilities and hence determines risks from those threats. From that threat model, the architect or designer can then suggest the appropriate mitigations that the coder can build into the system, which again can feed into the test objectives for the release.
To help with threat modelling, Microsoft developed a Visio based tool, creatively known as the Threat Modelling Tool, which can be downloaded here: https://www.microsoft.com/en-au/download/details.aspx?id=42518
Implementation
The implementation phase relates to working with the developers to help them make informed security decisions relating to the way their software is deployed. The SDL breaks the implementation phase up into three deliverables:
- Use of approved tools
- Deprecation of unsafe functions
- Performing of static analysis
To help automate security practices and put rigour around enforcing of controls, you should publish a list of approved tools and security standards for use in the development process – the example Microsoft gives is compiler/linker options and warnings. It’s important to maintain this list of tools, since using the latest version of a development capability will ensure your team is including the latest security functionality and protections the toolset offers.
The second aspect of implementation relates to the removal of all unsafe functions within the development environment and resultant products. By analysing the functions in the system and forbidding inclusion of insecure ones in the final product, you should see less security bugs make it into the production code. The examples that Microsoft gives here are: use header files; newer compilers; and code scanning tools to check code.
Finally, the last aspect of the implementation phase is to undertake source code review prior to compilation. This is known as static analysis, since the code is not running, instead it is reviewed for security bugs and vulnerabilities by someone well-versed in secure coding principles who can review code within the IDE (or on paper). This ensures your secure coding policies are being followed.
Verification
After implementation, we move to a testing phase, which, like the others, has been split into three constituent deliverables:
- Perform dynamic analysis
- Perform fuzz testing
- Conduct attack surface review
These three kinds of verification testing approaches are incredibly important to the SDL and, if undertaken properly, will dramatically improve the chances of delivering high-quality software with reduced security bugs. Dynamic analysis is the running of special tools that do real time verification of your code, looking for behavioural issues and memory corruptions, user privilege misuses and other operational security vulnerabilities. Fuzz testing is where the tester deliberately tries to force a programming exception or failure using malformed or randomised data, with the expectation that the failure will leave the application exposed or reveal security-related information to the attacker. And finally, the software should be checked again to ensure any changes made during previous phases have not resulted in the introduction of more vulnerabilities. At this stage, you should be going back to the initial design threat models and checking that the production system is still aligned with the initial objectives.
Release
The release phase is when your team prepares to deploy the system to the user base – this could be an internal release to enterprise users or a public release to your customers. Part of the service design aspect of release planning includes how your team will support the system in its production environment and how vulnerabilities will be managed if they are found later. The three aspects of release planning cited in the SDL are:
- Create an Incident Response Plan
- Conduct Final Security Review
- Certify Release and Archive
The Incident Response Plan is something that every team should have, but it’s vital if you are managing a system or software application that has real world impacts. You need to be prepared and ready to deal with new or nascent threats, ones that arise through no fault of your own – such as the big named ones that hit the press over the past few years, like Heartbleed and Shellshock. You’ll need to include all the emergency contacts that your team needs to notify if an incident occurs, and you’ll need to have both established and tested security maintenance plans for your systems, especially relating to code, modules or systems that are integrated into your solution from an external source. In the SDL, the Final Security Review (FSR) results in you having to re-examine your initial threat models, the tools you used to build and deploy the systems, the security outputs from testing and performance metrics against any quality gates you have established. Lastly, the act of certifying software through a formal accreditation process helps make sure that the requirements have all been met that were initially established. Then, once you are happy you have established a formal release of the product, you should archive it. As Microsoft states, this “includes all the specifications, source code, binaries, private symbols, threat models, documentation, emergency response plans, and license and servicing terms for any third-party software.”
Response
After the system or programme is released, it enters standard support. You need to ensure the support team (often comprising some of the developers) can respond to issues, bugs or security vulnerabilities and is aware of the incident response plan.
Conclusion
Microsoft’s Security Response Centre is the team that works closely with industry to help prevent security incidents in Microsoft’s product set. This is the team that security researchers call when they find a new vulnerability in a Microsoft product, especially if it’s an issue that could lead to a serious security breach.
Microsoft has developed mature processes in the SDL that is now incorporated throughout their design lifecycle, across every development tower in their business. Yet, they are not slowing down in terms of their security investments and a recent public pledge to continue ploughing over a billion dollars a year into security research and development is a trend that others might want to follow. (http://www.cnbc.com/2017/01/26/microsoft-to-continue-to-invest-over-1-billion-a-year-on-cyber-security.html)
The SDL is a free, open source process model that anyone can use and it applies equally to software as it does to systems engineering. If you don’t follow a process today for putting security into your deliverables, the SDL is a great place to start, so why reinvent the wheel when Microsoft has done the hard work for you.
