Today we start taking a quick, top-level look at the current software development process, both used within, and recommended by, our friends at Microsoft.
In January 2002 Bill Gates, in response to customer feedback, grabbed his dilemma by the horns, and issued a back-me-or-sack-you directive known lovingly as Trustworthy Computing. Company-wide memos like this were rare. This one went into every department, as company-wide memos are wont to do, and demanded sweeping improvements in the "four pillars" on which the customer experience is based: security, privacy, reliability, and business integrity.Trustworthy Computing encapsulated the overall process in the guiding principles labelled "S3+C", chosen to represent "Security (and privacy) by design, by default, in deployment; and Communications". When you add steps to your software development process model, to accommodate security, privacy, and the communications elements to support these, you get a security software development process model. But if you are Microsoft, then you get the industry-leading software security assurance process known to millions as The Microsoft Security Development Lifecycle, or SDL.
There is a nice colourful diagram of this entity on MSDN. Can't show it to you here, as it's ©2009 Microsoft Corporation. All rights reserved. But you might follow this link. If you did, you might also stumble across an ad for their SDL Process Template for Visual Studio Team System. I'll be looking at that in a later article, but for now, I'll just mention that it almost looks like sufficient justification, on its own, for changing over a mature development process to VSTS.
Returning to the SDL, there are identified five core phases in the lifecycle, bracketed by pre- and post-SDL requirements. The overall process that these phases cover, can be seen as starting with new developers being introduced to new technologies and new user requirements, and finishing with a product in its "maintenance" phase (incidentally, it gives this 50-year-old developer great satisfaction to see the assignations "maturity" and "continuous improvement" interchangeably applied to this phase!). Actually though, it can equally be treated as a standalone security project lifecycle, suitable for retrofit to an existing or ongoing product development.
Today I'll talk about preliminary security-related training, then go on to describe the first two phases of the lifecycle, Requirements and Design.
In these sections you will find that many and various security and privacy matters are merely glossed over, if indeed they are name checked at all. As mentioned in Part 1, Security Is Big! Some of these will be returned to in future articles, others may be less lucky...
Pre-SDL: Training
The constantly evolving nature of the threats means that frequent retraining should be a component of the development security strategy - at least annually. Threat modelling should be as natural and routine an activity as reference to design patterns, unit tests, or documentation, while itself including elements of all of these.
Secure design, coding and testing afford multiple opportunities for training. So you know about SQL Injection attacks, and the perils of weak cryptography. Your good housekeeping means that your code is virtually immune to buffer overrun attacks. But have you checked what happens when that 32-bit ID generator overflows?
Training should also cover risk assessment, as well as the methodology of security testing, and its automation.
Finally, once everything's been covered from the viewpoint of securing data against unauthorised access, it needs to be triplicated! You still have to deal with guaranteeing access to properly authorised users, and ensuring the integrity of what's stored and/or transmitted.
There are several resources, recommendations and guidelines relating to pre-SDL training, in this MSDN article.
Phase 1: Requirements - Introducing Security Guy
At the requirements stage, if the security and privacy concerns of a project warrant the use of the SDL at all, then there should be identified a team member (or members) with overall responsibility for tracking and managing the security and privacy aspects of the piece. In small teams, these responsibilities often fall to the project manager.
Acceptable levels of quality should be determined, and it is a feature of this particular SDL that the security bug bar is never lowered. Not even on release day! Security bugs are categorised and managed like any others, i.e. by severity. They also have their own, unique family of categories, complete with silly acronym: STRIDE! Basically, you should be able to classify any security bug with one or more values from this list:
Spoofing
Tampering
Repudiation
Information Disclosure
Denial of Service
Elevation of Privilege
Another unique requirement of security bug management, is that information about the bug must itself be treated in a secure way, for reasons that should be obvious! So, this might mean securing your bug reporting tools, e.g. restricting permissions to team members and security advisors only.
All bugs have associated costs; privacy and security bugs can be among the costliest. Risk assessment is an indispensible requirement of security design, and may identify features of the product that need deep security review.
Phase 2: Design
The design phase is the plan building phase. Functional and design specs are now used to determine best practices, while the project's vulnerabilities and threats are identified by performing the risk analyses identified in the threat modelling of Phase 1.
Threat modelling must be completed during this design phase. How could it be otherwise? We can't have a software design, if we don't yet know what we have to defend against, and how we intend to do that!
Two recent additions to this SDL phase merit special mention.
- The first is UAC compliance, where we ensure that our app is fully useable and runs correctly as a non-administrator.
- The second introduces a new set of restrictions and prohibitions in connection with firewalls. Basically, don't disable or change their state; don't open a port or enable a rule without admin privileges; and don't do anything else without the user's consent, mkay?
Next time: Implementation, Verification, Release and Response.
No comments:
Post a Comment