April 2013

Volume 28 Number 04

SDL - Using the SDL for LOB Windows 8 Apps

By Tim Kulp | April 2013

More and more content is appearing online offering guidance about how to build line-of-business (LOB) Windows Store apps. In this series, I’ll add another layer to LOB Windows Store apps in an examination of how to build security into your Windows Store project with measurable results.

In this first installment, I examine the planning phase of the Secure Development Lifecycle (SDL). By the end of the article, you’ll understand the project goals and produce two deliverables: a risk assessment and the security/privacy requirements. Although I don’t cover every activity of the SDL in this article, I build a base for you to grow from. To learn more about the SDL, please see the SDL Web site.

Background

For this series, we’ll imagine ourselves employees of the Contoso Corporation. Contoso provides medical services for its clients via medical facilities in remote locations around the world and through call centers that assist members with medical needs in countries outside their country of origin. Case managers (people who deal with the medical issues of Contoso’s members) provide medical guidance for Contoso’s customers by recommending safe medical facilities—acting as a liaison between the customer and the medical team providing care in a foreign country. Case managers have seen cases ranging from car accidents in Germany to shark attacks in Australia. The remote medical staff provides patient care in areas of the world where you would not find a traditional hospital, such as an oil rig or an Arctic research facility.

Case managers currently use a modified customer relationship management (CRM) system that does not meet the needs of the new remote medical division, whose members do not have access to computers that can run a heavy desktop client application. Currently, the remote medical division (recently acquired by Contoso) is using a variety of mobile devices such as phones, netbooks and laptops to track case information via a Microsoft Access database. The Access database does not directly interact with the case managers’ CRM; instead, the database exports HTML reports of the case information, which are then sent nightly via secure FTP to the call centers for entry into the CRM. Files are sent from each location where Contoso has a medical facility. Contoso recognizes that this process is inefficient and considers it a stop-gap solution that is targeted for improvement.

A few years back, to improve customer service, Contoso launched a medical-records application that members could use to load information about medical history, current medications and so on. This application was a front end to Microsoft HealthVault and was used to provide a more complete view of a client’s medical situation. The medical-records application has allowed case managers to provide a higher level of service to customers and to make better medical recommendations. The tool also allowed case managers to provide content to HealthVault for their clients so that other HealthVault applications could access the data.

Leadership at Contoso has requested a new system that unifies the work of the remote medical team and case managers. To keep costs low, the development team would like to build one application for use by both teams. Because of the highly mobile nature of the remote medical staff, Windows 8 and tablet hardware are ideal. Building an LOB Windows Store app allows the developers to target both tablet devices (along with the various form factors used by the remote medical team) and the case managers’ desktop computers with a single application.

Should We Use the SDL on This Project?

I haven’t described everything about how the case management system works, but we do know one very important piece of information: the system will collect and manage personally identifiable information (PII), including medical information. This attribute alone makes the new case management system an excellent candidate for using the SDL. Our goal is to produce a system that will facilitate business, and we need to do this with the least amount of risk to the business. Medical information that is leaked from an insecure system can cost Contoso a lot of money in fines as well as lost trust with their customers.

If you are unsure whether the SDL is right for your project, consult the SDL Process Guidance document and review the section “What Products and Services Are Required to Adopt the SDL Process” (p. 11). This section gives a few samples of software that should implement the SDL to improve the security of the product. In our case, the presence of PII and personal health records(PHR)) is a clear indicator that we need to use the SDL to ensure security in the case management system.

Good Security Begins with Quality Training

Building quality software is a large step forward toward building secure software. Many developers who build high-quality products are already on the path to producing more secure software. To ensure that the most secure products are released, Contoso conducts biannual security training for all the teams related to the development process (business analysts, project managers, developers, and quality assurance). These online courses are used to keep team members up to date with the newest security challenges facing software, but they also cement core concepts such as the principle of least privilege, secure default and data/command segregation. For nondevelopers, some of the training focuses on topics such as:

• How to build security and privacy requirements.
• Project tasks specific to secure development processes, such as security code reviews, threat modeling and the final security review (FSR).
• Basic security testing for products using risk-based security testing and penetration testing (for those who do not know the difference, I will explore it later in this series).

Security training for LOB apps needs to be more specialized for the business producing the application. Some sample topics (from “Pre-SDL Requirements: Security Training for LOB”) include the following:

• Secure design
  • Authentication: How does the business (in this case Contoso) expect authentication to be handled within applications? Is there an existing authentication system that every system uses or is every system its own identity island?
  • Authorization: Is authorization to be handled by each application or by a central repository? What existing infrastructure is set up to handle authorization? Are there standards that must be adhered to in building new authorization systems?
  • Auditing and logging: Is there an existing logging subsystem that all new applications must use for centralized logging? What does the business require to be captured in a log? What data should not be captured in a log?
  • Secure communications: The business controls the network and can set standards for how applications communicate. Does all or some network traffic need to be encrypted? Is the use of encryption situational (for instance, must all medical information be encrypted)?
• Secure coding
  • Input validation: Does the business have specific standards for input validation and handling? Is there a common input validation and/or sanitization subsystem that processes data from outside the system?
• Regulatory
  • Compliance: For Contoso, HIPAA will be a driver for the security of the new case management system. Depending on the business, compliance can be a core component of security training.

Contoso’s goal with their security training program for software security assurance (SSA) is to ensure that all contributors to a development project have the right skills to produce the most secure software product. Contoso schedules these trainings twice a year to ensure retention.

Planning Phase

Just like the standard Systems Development Lifecycle (SDLC), the SDL begins with planning. In this phase you define what you’re building and frame the rules that the system must adhere to. This phase is a collaborative effort of the information security team and the development team, who produce two deliverables for our case management system: the risk assessment and the security/privacy requirements.

To start, we defined our application concept using the guidance in "Planning Windows Store apps."  Please refer to the concept document for the Contoso case management system for details about the app.

Risk Assessment

For Contoso, this product carries with it significant risk. Any failures in the case management system will result in a poor customer experience and could even expose the company to liabilities. In SDL-LOB, this app would be categorized as a high-risk product because the security and privacy risks surrounding the product could have a significant negative impact on Contoso. To identify and manage the risks associated with this product, we will use “The Five Stages of Activity for Risk Management” from Gary McGraw’s book Software Security. Following these stages allows Contoso to understand risks, prioritize them and then define a mitigation strategy.

Stage 1: Understand the Business Context

Contoso’s case management system is not the first or last business application that Contoso will build. To understand the risks this system faces, the project team needs to understand the business context the product will operate in. In this stage, we need to answer the following questions from a business perspective:

1. Who cares about this system? Contoso operation teams (case managers and remote medical staff) need the system to be available and accurate and to restrict the medical information provided only to individuals who have approved access. Customers care about this system because they rely on the business services it enables.
2. Who uses the system? Case managers and remote medical staff will use the system. Members of these teams will be trained users, and their capabilities (what they can do in the system) can vary on the basis of staff rank (senior, midlevel, or junior staff member). Managers of the operations teams will use the system to assess the current resource allocation for cases.
3. How will this system relate to others? The case management system will interact with a variety of internal and external systems:
   1. Reporting systems
   2. Workforce management system
   3. Customer relationship management system
   4. Others ...

Stage 2: Identify the Business and Technical Risks

This section breaks down to one question (What could go wrong?) and focuses on two types of risks: business and technical. For technical people, technical risks are very easy to understand, but they take a keen eye to discover. A technical risk is any risk that would result in the system not working according to the system’s design. An example is when a user encounters an exception that kills the process for entering a case event. Business risks are issues that occur if something goes wrong with the system, such as losing consumer confidence. Technical people can think of many technical risks, but remember that this is a business application. Thus, everything comes back to the risks to the business because identifying and explaining those are how you convince the people holding the project purse strings to provide funding for addressing the technical and business risks. If you cannot tie a technical risk to a business risk, you may not get the funding you need to mitigate the risk.

The SDL team has provided a very useful risk assessment questionnaire that you can use to get the ball rolling for determining risks to the application. To start, open the concept document (from the supporting documentation) and look at the “What Is Our App About?” section. Use the concept document to answer the questions posed in the risk assessment questionnaire. For the sample document, I added two new questions specific to LOB Windows Store apps:

• What external libraries are required for this project? This question is focused more on JavaScript Windows Store apps because a JavaScript library designed for the Web could introduce unintended security risks to your app.
• Which contracts will your app use? This question is meant to get the team thinking about how contracts (Windows 8 contracts such as Search, Share, or a file picker) could pose a risk to the application. As an example, if Share is enabled, what happens if someone shares a medical case to Twitter? Is this okay or would this be a concern?

After you populate the questionnaire, look at your answers and ask yourself three more questions:

1. What is the technical risk this issue could impose?
2. What happens if the technical risk is realized?
3. How is the business affected if the technical risk occurs?

So, for the question “Does your application contain personal data?”, the answer in the sample document is yes. What is the technical risk this could impose? Sensitive data has the risk of being leaked. If the technical risk is realized, a member’s medical information and personal information could be exposed to an unauthorized resource. How does the result of the technical risk occurring impact the business? In this case, the result could lead to a lawsuit from the member and a possible HIPAA violation that could result in litigation.

Ask yourself these three questions for each of the answers in the sample risk assessment questionnaire. From the baseline that you build, interview other project team members to get their input on risks.

Stage 3: Synthesize and Rank the Risks

From the questionnaire, you should have a long list of risks, both technical and business. You will produce a lot of possible risks, but how do you know which ones are the important ones? We have only limited resources from Contoso management to produce this application and must use those resources wisely. Begin determining which items are important by defining each risk’s impact and likelihood. Number each risk for easy identification. Figure 1 shows a sample from the risk-rating spreadsheet (found in the supporting documentation).

Figure 1. Sample Risk Rating

Each risk uses one of five levels of likelihood (very likely, likely, possible, unlikely, very unlikely) and four levels of impact (severe, high, low, very low). These are subjective measures but should be driven by objective reasoning. If a data leakage will result in a $200,000 lawsuit and stolen geographic information will result in a $1,000 intellectual property loss, the data leakage clearly has a higher impact. After defining the likelihood and impact for a risk, I use a matrix I found in the GAO’s Information Security Risk Assessment guide (on p. 23) to identify the highest priority items. Figure 2 shows an example.

Figure 2. Risk Assessment Matrix

Based on where the risk falls in this matrix, it is assigned a risk rating. Using the matrix, you can identify where a risk lies and how to address it.

• Level 1 risk (dark red): Undesirable and requires immediate corrective actions.
• Level 2 risk (red): Undesirable and requires corrective action, but some security team discretion is allowed.
• Level 3 risk (light red): Acceptable with review by security team.
• Level 4 risk (pink): Acceptable without review by security team.

These rankings and descriptions can be found in more detail in the GAO’s guide.

Stage 4: Define the Risk Mitigation Strategy

I once had a manager who would say, “Give me solutions not problems”—the thought being that every problem had a solution, and, in essence, don’t complain about the problem without presenting a solution. This stage is just that. For each of the risks we have listed, we need to provide a mitigation technique.

Which risks do we address first? The level 1 risks that we just identified in the previous step. Attack each risk according to its place in the matrix. As you identify mitigations, keep a few things in mind, and most importantly, ask whether a particular mitigation can address another risk as well and how much will this cost. These two questions help you remain fiscally focused so that the project does not become too expensive and the final product remains lean. (By using a single mitigation to address multiple risks, you can reduce the overall size of the system.) This is a balancing act between the price tag of the product and providing enough security.

For Contoso, we will describe how to mitigate the risks mentioned earlier by adding a column named Mitigations to our risk register. (Yes, you can have more than one mitigation for a single risk.) Figure 3 shows an example.

Figure 3. Updated Risk Register

Notice that for risk #3, we do not list a mitigation because, as a business, we have decided to accept that risk. In other words, if it happens, it happens. There are four strategies for handling a risk: accept it, avoid it (through avoiding the risk altogether), defer it (make it someone else’s problem) or mitigate it. For risks #1 and #2, we mitigate the risk through encryption and redundancy. We could defer #2 by moving the entire infrastructure to Windows Azure and let Microsoft handle the redundancy.

Examine the risks you have identified for the case management system. How can you address the risks with one of these strategies?

Stage 5: Carry Out Fixes and Validate

You have identified risks, ranked them and proposed risk-management strategies (avoid, accept, defer or mitigate). Now, you just need to carry out your strategy. This stage breaks down into two parts: implementing the strategies you built and verifying that the strategies work.

For Contoso, the execution of risk mitigations will be tracked by adding the mitigations as tasks to the case management project. Those tasks will be identified as security tasks and assigned to responsible parties. By embedding these tasks into the project plan, we not only assure completion (in theory) but also provide a mechanism for both reporting and measurable progress. Using a tool such as Microsoft Project or Team Foundation Server, the development team members can provide task completion information so that the project manager can assess overall project completion.

A Final Word on Risk Management

Risk management is a cyclical process. It requires numerous iterations to be successful. By performing the risk-management stages described earlier throughout the project life cycle you will identify risks in concept and design that save you overall development costs (risks can be mitigated for less cost earlier in the life cycle).

Building Requirements

In a traditional application, requirements are usually broken down to functional and nonfunctional requirements. Our concept document focuses on functional requirements—what do we want the system to do? Security and privacy requirements are not features; these are not interfaces for security or privacy but requirements for what needs to be protected and what the user is expecting from a security/privacy perspective.

Security Requirements

Before we go into defining actual requirements, we need to answer two very important questions: who is responsible for ensuring the security of the product and how is the development team going to track bugs? The security point person is responsible for keeping the project team informed about the security situation of the product. This person will set a schedule for communications and be the go-to person when someone has questions about security bug issues. See the security requirements support documentation for an example of how to identify the security person for the case management system, the communications plan and templates.

The bug-tracking system needs to be able to track bugs as security bugs with a cause and effect. Tracking this information is important to understanding the impact of the bug. The SDL guidance documentation provides a definition for the various cause and effect values in Appendix B, “Security Definitions for Vulnerability Work Item Tracking.”

Building out the actual security requirement statements is part art, part checklist, and part science. Do not, under any circumstances, get into the habit of cutting and pasting requirements, where you simply copy the security requirements from a previous project as generic statements such as “The system must provide a login.” There are numerous techniques that you can use for building out security requirements (such as SQUARE). I’ll focus on three areas: what do we want to protect, what is the user expecting to occur and what don’t we want the system to do.

Using our concept document, we can identify high-level functionality for the case management system. Take the “User Activities for Our App” section and consider for each activity how STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure and Elevation of Privileges) can be applied. As an example, here are descriptions for our first activity: Create, read and update a medical case.

• Spoofing: System must require all users who create, read and update medical cases to be identified via their domain credentials.
• Tampering: System must protect network communication from unauthorized access and interception.
• Repudiation: System must log all create, read and update actions on a medical case.
• Information Disclosure: System must protect network communication from unauthorized access and interception. System must prevent data classified as PII from being viewed as clear text in transit or at rest.

Notice that protecting network communications appears twice. This one requirement addresses both threats. Under Information Disclosure, we add more requirements because the network is not the only place where data must be protected. As you build out each statement consider two questions: what do you want to protect relating to this activity, and what are users expecting with this activity? We want to be sure that we can account for any modifications to the medical case data (for security auditing purposes), so under Repudiation we note that we need to keep a log of anyone who modifies anything. We know that we need to protect medical data, so under Information Disclosure we define a requirement for keeping the data safe. For each activity, use the threats in the STRIDE framework to build out the beginning of your security requirements.

Now for a bit of fun, think like an attacker. Given the ability to create, modify and read medical information, how would you exploit that? Let’s say that a developer for Contoso was just dumped by his girlfriend, who works for one of Contoso’s clients. The developer might want to snoop on her medical information. We just built out what is referred to as an abuse case—a way that someone can abuse how the system works to meet their needs. Now think of preventing an attack like this as a requirement. You might end up with something like “The system must not allow unauthorized access to medical case information.” Although this statement is a bit vague for a requirements statement, it drives home the point that the system must prevent people who do not need access to medical case information from accessing it.

Gary McGraw in Software Security calls these anti-requirements—requirement statements that define what a system should not do, as opposed to a standard requirement, which states what the system should do. Whether you build anti-requirements or abuse cases first tends to be a team decision based on how your team thinks (in stories or statements). Whatever your techniques, thinking like an attacker offers a deeper view into your system’s security. This is an excellent opportunity to engage the information security team because its members will have many real-world examples of actual abuses.

Now it’s your turn. Build out some security requirements for the rest of the user activities in the concept document. Think about the features and other sections of the document as well. Could a live tile create an information disclosure? Could a secondary tile result in an elevation of privilege? Explore these ideas and add them to the security requirements document.

Privacy Requirements

Sometimes privacy and security are lumped together. This is an understandable grouping, but the two topics are different. Privacy has many components, such as consent, data retention and minimization. There are many great resources on how to build products with great privacy (such as "Privacy Guidelines for Developing Software Products and Services" from Microsoft). Here, we will focus on building privacy requirements and not the broader vision of privacy best practices.

Begin assessing privacy requirements by filling out the privacy questionnaire provided in the SDL process guidance documentation. Using the concept document, you can provide answers to the various questions used to determine the amount of privacy risk our application faces. In the case of the Contoso case management system, the application is classified as a P1 High Privacy Risk. This ranking is applicable because the system stores PII and transmits it. A privacy violation in a high-privacy-risk application can result in the exposure of sensitive information about Contoso’s members.

Knowing that we have a high-risk system, we can answer the “Privacy Analysis" section of the questionnaire to fully understand our privacy exposure. Having these questions will help keep the focus on protecting private information (going back to the security requirements earlier) as well as justify why the system needs this private data. For instance, describing what PII is collected in our case management system could be as detailed as identifying each data point that would be collected about a member. Having a document that details the system’s privacy concerns and all the data fields about a member could be useful when dealing with a request for proposal (RFP) from a client who is very concerned about privacy. Many international companies are much more focused on privacy than U.S. companies. Showing your privacy analysis can increase consumer confidence and may even be required.

Bug Bars

Two core deliverables of the SDL are the security and privacy bug bars. These drive the quality expectations for the product. Using the templates in the SDL guidance documentation, you can create sample privacy and security bug bars for the case management system. Use what has been defined in the privacy questionnaire and the “Security Requirements” section to build these deliverables.

Requirements and Planning

In this first installment, we built out requirements and a risk analysis for our case management system. I encourage you to apply these lessons and templates to a project you’re currently working on, and to build out the bug bars for the case management example. By analyzing the samples provided and applying them to a real-world situation, you can see how a little extra effort in planning can identify potentially significant security issues. In the next article, we’ll tackle the design phase, build the threat model for our case management system and also analyze the attack surface that could expose all the medical information we just planned how to protect.

Tim Kulp leads the development team at FrontierMEDEX in Baltimore, Maryland. You can find Tim on his blog at https://seccode.blogspot.com or the Twitter feed @seccode, where he talks code, security and the Baltimore foodie scene.