As a project starts—perhaps it’s a new version, iteration, or a brand new product—it’s important to get all the security ducks lined up correctly. From our experience, a good project start leads to a much smoother final security review and a more secure product.
The project inception phase has a number of discrete and important steps:
Let’s look at each of these steps in detail.
The first course of action is to determine whether the product is covered by SDL. Ultimately, all software will benefit from the processes described by the SDL, and managers are always encouraged to follow the SDL. However, products that meet any of the following criteria listed must follow this software development process:
Any product that is commonly used or deployed within a business—for example, e-mail and database servers.
Any product that regularly stores, processes, or communicates personally identifiable information (PII). Examples include financial, medical, and sensitive customer information. Because of various child online protection laws, such as the Children’s Online Privacy Protection Act (COPPA 1998), any products or services that target or are attractive to children are of particular concern.
Any product that regularly touches or listens on the Internet:
Always online: services provided by a product that involves a presence on the Internet—for example, instant messaging software
Designed to be online: browser or mail applications that expose Internet functionality—for example, Web browsers and e-mail clients
Exposure online: components that are routinely accessible through other products that interact with the Internet—for example, mobile code or games with multiplayer online support
Any product that automatically downloads updates.
The next course of action is to nominate a security person to guide the development team through the SDL process with the aim of successfully completing the Final Security Review (FSR). (See Chapter 14, for more on the FSR.) Historically, Microsoft has referred to this individual as a Security Advisor.
If your company has a central security team, or an engineering quality team, it makes sense to nominate someone from that team to be the security point person. Specific skills are required to fulfill this role, however. Following is a sample job description used within Microsoft:
Do you enjoy probing and analyzing product security, finding holes in assumptions, and working with product teams to make our products as secure as possible for our customers? Are you interested in a job that provides incredible opportunities for learning and visibility? The Secure Windows Initiative (SWI) team is looking for a stellar PM to continue to drive the adoption of good security practices across Microsoft. You will own working with teams such as Office, Windows, Visual Studio, or SQL Server to help them develop secure products from beginning to end and finally verify the security of each product before it ships.
We are looking for a Program Manager with a strong technical and security background, strong cross-group and communication skills, attention to detail, and solid process skills. Coding skills are helpful but not required; security-mindedness is a must.
Candidates should have 3–5 years’ experience building and shipping software and have solid PM skills. A Bachelor’s degree in Computer Science is preferred.
Come and help the company ship secure products to customers.
We have noticed that although deep security skills are important, it’s even more vital that the Security Advisor have good project and process management skills. Having both security and project management skills is a bonus. Having neither skill is obviously a disqualifier.
Best Practices
Large software development houses should assign similar products to the same security point person so that the Security Advisor can pass on lessons learned from one group to other groups.
The tasks of the security advisor include:
Acting as a point of contact between the development team and the security team.
Holding an SDL kick-off meeting for the development team.
Holding design and threat-model reviews with the development team.
Analyzing and triaging security-related and privacy-related bugs.
Acting as a security sounding board for the development team.
Preparing the development team for the FSR.
Working with the reactive security team.
We want to delve briefly into each of these areas. But before we do, do not lose track of the high-level goal of the security advisor: it is to help product teams become self-sufficient and “good at security.”
Before the creation of the SDL process, security communication between product groups and the security team was unstructured and prone to miscommunication. To remedy this, the Security Advisor acts as the central point of contact for the development team. Most notably, a person is selected from the development group to be the security point person for the development group, and that person and the Security Advisor act as a conduit for security information. Of course, there is nothing stopping anyone on the development team from communicating with the Security Advisor, or vice versa, but it’s important that the advisor and the security point person are made aware of all security- and privacy-related communication.
Before the development project gets fully underway, the Security Advisor presents the goals of the SDL and the key points about the SDL process to the engineering staff. Often this is simply a one-hour presentation. It’s imperative that, at a minimum, the development, test, and program management leadership staff attend. It’s also important that management and the people building the schedule understand that the SDL tasks and deliverables must be built into the development schedule.
At the point during the design phase when the designs are nearly complete, the Security Advisor should sit down with the development team to discuss the design and system architecture. At this stage, the Security Advisor will critique the design to see if she can find security issues within it. For example, the Security Advisor will make sure that:
The application has a low attack surface.
The application uses the appropriate development best practices.
The application follows secure design best practices.
The threat models are complete and reflect how the system will defend itself.
There is appropriate testing and test coverage.
Attack-surface analysis and reduction and secure design best practices are both covered in Chapter 7; appropriate secure development best practices are covered in Chapter 11, and Chapter 12; and threat models are discussed in Chapter 9.
Invariably, security and privacy bugs will be detected in the product during development, and such bugs must be triaged accordingly. Reviewing these kinds of bugs requires a great deal of expertise to make sure the correct course of action is taken for each. Some may be fixed with code or design changes; others might not be fixed at all because the risk is very low and the amount of work required to perform a correct fix may be large. Whatever the outcome, it’s important that the Security Advisor review the list of unfixed security and privacy bugs.
The Security Advisor should address security and privacy questions and ideas as they arise from the product group. Indeed, the advisor should encourage this kind of discourse and have ideas evaluated and verified as soon as possible. At Microsoft, this process is usually handled in the manner shown in Figure 6-1 (on the next page), but many software development houses may not have the luxury of a central, dedicated security team. In this case, the advisor will probably be the security contact and problem solver for all security issues.
Figure 6-1. The communication relationship between the Security Advisor, the development team contact, and the security leadership team.
Security Advisors also serve as great sources of security wisdom and education for the software development team.
Before a product ships, it must successfully complete an FSR as defined in Chapter 14. An important task for the Security Advisor is to make sure that all the required SDL tasks are completed so that the FSR goes smoothly. You don’t want surprises at the FSR stage because they could hold up the final product release to customers.
If an externally reported security bug is found in a product you create, it saves a great deal of time for the Security Advisor to be in the loop when triaging the issue because she will have a great deal of background knowledge that may aid in determining the most appropriate way to fix the issue.
In all software development endeavors, there is a person or team that leads the development process. At Microsoft, there is a central project management team driving the day-to-day coordination of team communication, scheduling, and features. This team should also handle security leadership for the project. The team’s tasks include
Regular communication, usually by e-mail, to the development team about security and privacy bug counts.
Communication of security and privacy policy updates.
This role is different from the development team contact; the development team security contact is technical in nature, whereas the security leadership team sets policy and communicates status to the team.
Here’s a real example of how this communication system works. In late 2004, I (Michael) learned of a security bug that affected the Java programming language from Sun Microsystems (Huwig 2004). To my surprise, it was an integer overflow problem. As I dug deeper, I found that this bug could affect C# or Microsoft Visual Basic .NET code. So I spoke to the Security Advisor for the Microsoft .NET Framework about the issue, and he then talked to both the security contact on the .NET Framework team and the .NET Framework security leadership team. Between them, they decided that this kind of error could indeed affect managed code and should be fixed prior to shipping the .NET Framework 2.0. The .NET Framework security contact then created some prescriptive guidance, and the leadership team made the entire product team aware that this guidance must be adhered to. Three bugs of this nature were found and eradicated from the code base before the product shipped.
This may seem like a lot of communication overhead—and for some software development teams it certainly is—but for larger software projects it works well because there is a combination of security and privacy technical expertise (the security team, Security Advisor, and security contact) and policy setting to make sure that it happens. Figure 6-1 shows the relationship between these roles discussed previously.
It is critically important that security and privacy bugs be tracked correctly in your bug-tracking database. Even more important, such bugs must be tracked in a consistent manner. Here are the SDL-required bug-tracking fields that should be added to your bug-tracking software:
Security/Privacy Bug Effect
Security/Privacy Bug Cause
The Security/Privacy Bug Effect field should then have these predefined values:
Note that Attack Surface Reduction is akin to defense in depth and is not necessarily a true security bug. Rather, it’s a bug that identifies a task that should be triaged like any other security or privacy bug.
Note
Defense in depth employs multiple security defenses to help mitigate the risk of one defense failing.
Information disclosure threats can also be privacy threats if the data exposed is personally identifiable or confidential data, so there is a separate bug category to make it easy to search for privacy bugs. Privacy issues are almost always high-impact bugs, and this should be reflected in the severity rating of the bug.
The Security/Privacy Bug Cause field should then have these predefined values:
Not a Security Bug
Buffer Overflow or Underflow
Arithmetic Error (for example, integer overflow)
SQL/Script Injection
Directory Traversal
Race Condition
Cross-Site Scripting
Cryptographic Weakness
Weak Authentication
Weak Authorization/Inappropriate ACL
Ineffective Secret Hiding
Resource Consumption (DoS)
Incorrect/No Error Messages
Incorrect/No Pathname Canonicalization
Other
At the outset, you should decide what types of bugs you will fix within the project development lifecycle, including security and privacy bugs. Defining the bar up front reduces confusion about what should be fixed, what should be mitigated, and what can be left unfixed. The SDL mandates that critical, important, and moderate security and privacy bugs be fixed prior to releasing the product. You can get a feel for the relative risk rankings by looking at Figure 9-6 through Figure 9-10 in Chapter 9.
Having a Security Advisor, security contact, and security leadership team in place as the project begins can make the process of building more secure software easier because expert security advice is available via a defined channel, and security communication flows well. More important, this level of communication makes it harder for important data to fall between the cracks.
Setting the bug-tracking system and bug bar at the outset also helps to streamline the process by establishing a consistent and well-understood bug standard. This reduces friction during development by defining the nomenclature and what will and will not be fixed prior to product release.