Before investing a great deal of time designing and implementing software, you should understand the costs of building secure applications, especially those handling data with privacy considerations. Obviously, you want to expend as much effort as needed to create the appropriate level of protection, but not too much more. Higher risk translates into higher development and support costs. As discussed in Chapter 1, privacy and security are intricately intertwined, and understanding the impact of both on your software is an important part of performing a risk assessment required to build protections into the software.
The purpose of the product risk assessment stage is to clarify the level of effort required to fulfill Security Development Lifecycle (SDL) requirements. During this phase, you should identify
What portions of the project will require threat models before release.
What portions of the project will require security design reviews.
What portions of the project will require penetration testing (possibly by a mutually agreed-upon third party).
The scope of fuzz testing requirements.
Note
The steps involved in this stage of the SDL are for guidance purposes only—it is left to the development team to estimate the actual amount of effort required to build the application. Obviously, security and privacy ramifications are important considerations in software estimation, but so are product size, product scope, level of automation, maturity of the development team, and so on. See Steve McConnell’s Software Estimation: Demystifying the Black Art for more on estimation (McConnell 2006).
Your risk assessment should include two distinct deliverables: first, the Security Risk Assessment and, second, the Privacy Impact Rating. Let’s look at each.
The Security Risk Assessment is used to determine the system’s level of vulnerability to attack. When we first started the security engineering effort at Microsoft, one of our earliest requirements was for teams to fill out a short questionnaire, which the security team used to determine how deeply to probe various parts of the software. This questionnaire was a little like the health-related paperwork you fill out when you first visit a medical practitioner; the paperwork helps the physician know where to poke and probe to determine what might ail you.
On the CD
The disc that accompanies this book includes a version of the Security Risk Assessment document.
Some of the questions in the risk assessment are listed in the following sections.
Although there are no absolute right or wrong answers in the risk assessment questionnaire, if you can answer affirmatively to many of these questions, the security team will need to analyze your application more deeply to ensure that the development team does the best it can to shore up the application’s defenses.
That being said, here are some general rules you can apply:
Every method and property on every ActiveX control must be reviewed to determine safety.
If this is a new product, it will require a thorough security design review.
If the application has a networking interface, it must be threat modeled.
If the application has kernel-mode and user-mode interaction, it must be threat modeled.
If non-administrators interact with higher-privileged processes, the application must be threat modeled.
If the application is a security feature, it must be threat modeled.
Sample code must meet the same quality standards as shipping code and must therefore follow all SDL requirements.
If an application parses files or network traffic, the application is subject to the SDL fuzzing requirements as defined in Chapter 12.
The next part of product risk assessment is to assess the Privacy Impact Rating of the project. This assessment is much simpler than the security risk analysis because it has only three policy values: privacy ranking 1, privacy ranking 2, and privacy ranking 3. Before we explain the three levels, take a look at Table 8-1 for descriptions of some important terminology used when describing the data associated with the privacy levels.
Table 8-1. Important Privacy-Related Definitions
Data Type | Description |
|---|---|
Anonymous data | Any user data that is not unique or tied to a specific person and cannot be traced back to the person. This data might include hair color, system configuration, method by which a product was purchased (retail, online, and so on), or usage statistics distilled from a large collection of users. Note that if anonymous data is associated with personally identifiable information (PII), it must also be treated as PII. |
Personally identifiable information (PII) | Any user data that uniquely identifies a user such as contact information (name, address, phone number, e-mail address, and so on). –Or– Data that is commingled or correlated with the user’s PII, for example, demographics stored with the user’s PII or with a unique ID that can be linked to the user’s PII. –Or– Data that is sensitive PII. |
Sensitive PII | Any user data that identifies an individual and could facilitate identity theft or fraud. This data includes social security numbers, tax IDs, credit card numbers, and bank account numbers. –Or– Data that is commingled or correlated with PII and used as an authorization key, such as passwords and PINs (personal identification numbers), biometric information (when used to authenticate), mother’s maiden name, and so on. –Or– Data that is commingled or correlated with PII and could be used to discriminate, such as sexual preference or sexual lifestyle, political or religious beliefs, ethnicity or race, or trade union membership. –Or– Data that is commingled or correlated with PII and contains medical history or health records or financial information. –Or– Data that has breadth and contents that are unknown at the time of collection and could hold sensitive PII. An example of this kind of data is a raw memory dump. |
Now we’ll explain the three privacy rankings. Components determined to be at the highest privacy ranking must be subjected to thorough privacy analysis, often involving privacy experts, to make sure that the application does not leak private data or violate any privacy laws or regulations.
Note
Privacy rankings do not indicate the software’s correctness; rather, they indicate the level of privacy thoroughness required, which translates into necessary cost, time, and effort.
If any of the following statements are true of your application, it has the highest-possible privacy ranking and therefore requires the highest privacy due diligence:
The application stores PII or transfers PII to the software developer or a third party.
The application is targeted at children or could be deemed attractive to children, or the application includes any user experiences in which you know the user’s age. Knowing that the application might be used by children is especially important in online applications because such applications must protect users under age 13 to abide by the Children’s Online Privacy Protection Act (COPPA 1998), which requires adult permission to collect PII.
The application continuously monitors the user of your application.
The application installs new software or changes the user’s file-type associations (for example, it changes the application that handles JPEG files), home page, or search page.
Important
Before collecting and transferring PII, you must have compelling business value and customer value. Many customers are accustomed to making deals, but when a deal does not benefit them, they often feel cheated and might begin to distrust your company. Collect personal data only if you can clearly explain the benefit to users. If you are hesitant to any degree to tell users what you plan to do with their PII, do not collect their data.
If your application transfers anonymous data to the software developer or to a third party, the application is rated at privacy ranking 2.
Once you have determined your application’s level of security and privacy risk, you must allot time in the schedule to make sure the appropriate level of expertise and effort is applied to reduce the overall risk to customers. For example, if your software product has many security risks, you must evaluate and analyze each risk to make sure the correct security decisions have been made to protect customers.
Note
Sometimes an insecure design is necessary to support legacy environments. In that case, you should evaluate the tradeoff between risk and compatibility.
If the application handles and transfers sensitive data, identify the business and customer benefits for doing this. If there is no customer and business benefit for collecting such data, remove that feature from your application.
The product risk assessment stage is critically important because it helps you determine how best to spend resources when developing the software. Before you begin product development, your team should complete a simple questionnaire to determine the software’s highest-risk components. If the questionnaire shows that you employ numerous potentially risky technologies, or if you determine that you risk privacy violations, the application must undergo much greater security and privacy scrutiny. In some cases, your potential security issues determine the level of effort you must dedicate to other parts of the SDL, such as fuzzing, security design review, and threat modeling.