On Friday, 16 December, Michael Howard hosted a webinar for FedCyber on the Microsoft Security Development Lifecycle (SDL), Howard is Microsoft’s Principal Security Architect with nearly 20 years of experience in the field and literally wrote the book on SDL, a topic that keeps growing more relevant. This year, the federal government put into policy with the National Science and Technology Council’s strategic plan for federal R&D what industry has already learned – the only way to protect against modern cyber attacks is to design security into software development.
While Microsoft is recognized as the leader in their Security Development Lifecycle, SDL is non-proprietary, platform agnostic, and suitable for organizations of any size. The tools for many SDL proceses can be downloaded for free and most content is published under Creative Commons License. Simply put, SDL is a series of 16 practices to ensure that security is incorporated into every part of the software development process rather than as an afterthought. The driving philosophy ofSDL is that no amount of security technology can compensate for insecure applications, and currently 75% of attacks occur at the application layer. There is simply too much that can go wrong. Applications may contain millions of lines of code, but it only takes one line to create a fatal vulnerability. There are many other places in a computer system where security can fail, from web-based attacks such as SQL injections for which vulnerabilities are almost ubiquitous to insecure data configuration and human error by users. Fortunately, the often repeated security paradigm “a system is only as secure as the weakest link” is only partially true. Through compensating controls, a central tenet of the Security Development Lifecycle, we can both reduce vulnerabilities and decrease the severity of the vulnerabilities we missed.
The 16 practices that comprise the Security Development Lifecycle are training requirements, security requirements, quality gates/bug bars, security and privacy risk assessment, design requirements, attack surface reduction, threat modeling, use of appropriate tools, depreciating unsafe functions, static analysis, dynamic program analysis, fuzz testing, attack surface review, creating an incident response plan, a final security review, and release/archive. Specifics on all of these steps can be found here, or in more detail here. In brief, while each practice is important, training is the highest priority. Everyone in the enterprise must know something about cybersecurity. For example, every time they begin a new project, every single software engineer at Microsoft gets some training whether security is in their job title or not. SDL is a systematic way to make sure you inventory your applications for common vulnerabilities like cross-site scripting and SQL injections, inventory your engineers to make sure they have adequate security training and tools, and inventory your supply chain to make sure all steps in the creation process use secure practices. Though security can’t be perfect, SDL aims to compensate for vulnerabilities in a way that products and technology cannot.
You can find out more about SDL here, or when Michael Howard returns to deliver another webinar for FedCyber going into greater technical detail.
