Engineering Secure Software

Case Study Project

Overview

The purpose of the case study project is to get you acquainted with the security challenges of a real, complex, messy software product. In class, you will be learning about security ideals, common mistakes, and best practices. In the case study, you will see how those ideals are applied, or not applied.

This case study is designed to help you in two key ways: investigation and co-authorship. The investigative part of this project is to help you to learn about software projects from the outside in. This means reading bug reports, documentation, mailing lists, commit logs, and anything else you can get your hands on to understand what's going on. The co-authorship part of this project is to help you learn what it's like to describe complex arguments (i.e. specific security risks) to a technical, yet non-security-minded audience. The "co-" part is to help you learn how to write much like how you've learned how to code... communicating, coordinating, know when to work alone, know when to work collaboratively, giving good feedback, and reacting to feedback.

The main component of this project is a paper that will be written much like we write code - iteratively. Every few weeks we will have another chapter of the paper due, along with the revisions from the previous chapter. A significant grading emphasis will be based on how well you react to the instructor's feedback, and how well you give feedback to others.

In terms of writing style, here's what the instructor likes to see:

For formal, technical writing, brevity and clarity are key. I would far rather see one clear, thoughtful sentence than three repetitive sentences. You might notice that we have no word minimums or maximums here - only questions that must be answered.

Furthermore, the paper must have a cohesive writing style. Like coding, this is not something you want to be slapping together from a few paragraphs people wrote separately. The varying sections need to be all part of a single narrative.

Submissions and Deadlines

• All of the work on the case study will be in the RIT GoogleDocs system, thus there will be no submissions to dropboxes in myCourses for this portion of the class.
• Deadlines are posted on the course schedule.
• Note that the instructor can view the revision history on all GoogleDocs in case a deadline was in question.

Formatting

• 10pt font
• Justified text (no ragged edges)
• Headers have a maximum size of 16pt font
• Tables & Figures must be numbered starting at 1 going through the whole document.
• Tables must have their caption be above the table
• Figures have their caption below the figure.
• Cite URLs by using hyperlinks in the text.

Case Study Proposal

Your instructor will assign teammates for this project (2-3 members per team). As a team, choose a case study project. Choosing a project may take some effort, as not every project out there makes a good candidate. Here are the minimum requirements for a good case study:

• Must have a domain that has significant security risks
• Non-trivial. The larger the better. Minimum of 10k lines of code or 20 developers. You will not need get this system to build.
• Must be actually used in production
• Source code must be available
• Must have had a list of reported vulnerabilities. The more detailed the records, the better (e.g. do they trace to bugs and source code patches?)

In your proposal, include the following:

• The names of each team member
• Project overview.
  • What is the product used for?
  • What is the development team like?
  • How often does the project release?
• Security Risks. This section can be very brief.
  • What kinds of data does this product protect?
  • What are the ramifications of this software is compromised?
• Provide links (using just a regular hyperlink) to the project website, the source code repository, issue tracker, past vulnerabilities, and any other relevant information.

Submission

Using the RIT GoogleDocs system, create a GoogleDoc Collection called "SE331 X" (where X is the name of your case study). Give editing permissions for that collection to all of your teammates, and to your instructor (you will have to use a special, non-RIT email for the instructor - given in class).

For this proposal, create a document called "X Case Study Proposal".

Grading scheme (10pts)

• 6pts - Submit a case study proposal naming a project.
• 1pt - Project matches the minimum criteria
• 3pts - Proposal demonstrates a surface-level understanding of the project security risks

Chapter 1: Domain Analysis

The purpose of this chapter is to provide an overall assessment of the security risks posed by the domain of your case study. Your chapter must include:

• Overview. A description of the product itself and an overview of the findings of this chapter. Discuss users, purpose, business objectives, development team, process, and any other information that might be relevant to understanding both the project and product.
  • This section should be more in-depth than your case study
• Product Assets. A listing and discussion of the product resources, functionality, and intangible properties that an attacker would want to exploit. Give a prioritization of these assets.
  • How did you decide on your prioritization?
  • How might this list of assets change in the future? Are there some that will become obsolete?
  • How might the prioritization of these assets change in the future?
• Malicious Actors & Threats. Describe the types of attackers that this system ought to defend itself against the most. Describe the high-level view of the threats to the system (i.e. not specific to any one type of vulnerability - broader). Use the STRIDE acronym from threat modeling as inspiration, as well as the Confidentiality, Integrity, & Availability concepts.
  • What types of information will be available to the malicious actors?
  • How might a malicious actor find vulnerabilites and exploit this software?
  • How are the threats spread across STRIDE and CIA? If the majority of threats fall into one category, why do you think that is?
• Vulnerability History Describe, in a broad sense, the vulnerabilities that the product has had in the past. Then, discuss two vulnerabilities in depth. (Cite your URLs using normal links, but please be sure to remember to link back to specific examples.) Feel free to include code snippets and specific examples. A code snippet is considered a figure.
  • Is there any evidence of how these vulnerabilities were found?
  • Are there any commonly-occurring vulnerabilities?
  • What category of CIA do most of the vulnerabilities fall into?
  • Are most of the vulnerabilities in your project specific to this domain? Specific to the technology? How might this history compare to this product's competitors?
  • Has the frequency of these vulnerabilities increased, decreased, or remained the same in recent years? Why do you think this is the case?

A few notes:

• Create a separate GoogleDoc called "Case Study". All subsequent chapters will be in this document.
• You may recycle sentences from your proposal, if you like (e.g overview stuff)
• Use your own words. You may quote product's website, but be sure to cite it - otherwise it's plagiarism.
• Remember to keep the writing cohesive. I recommend setting a team writing deadline ahead of time, and giving a few days to revise.
• Cited, specific examples are better than generalities

Grading scheme (30pts)

• 3pts - Overview section
• 5pts - Assets section
• 3pts - Actors & Threats section
• 9pts - Vulnerability History section
• 5pts - Overall quality of the research
• 5pts - Reaction to any comments from the proposal

Chapter 2: Design Analysis

The purpose of this chapter is to assess the high-level design of the system. Your chapter must include:

• Architecture Overview. Describe the architecture of the system. Please answer the following questions:
  • What are the subsystems? What does each subsystem do?
  • Are there subsystems that are expressly security features? (e.g. encryption, authentication) Describe these in more depth.
  • Consider the cost of developer mistakes in terms of subsystems. For example "if a developer makes a mistake in this subsystem, what happens?"
  • Do some subsystems appear to be more susceptible to code-level vulnerabilities?
  • Do you see security built into system at this architectural level? (e.g. distrustful decomposition)
  • How might compromising one subsystem affect the security (integrity, reliability, etc) of the others or of the system as a whole?
  • How does the system’s interaction with external systems put it at risk?
  • Consider how the architecture might change over time.
• Threat Model. Build a threat model diagram and conduct an analysis using the Microsoft tool. Write up your analysis.
  • What are the machine boundaries of the system? Does this vary from deployment to deployment?
  • What are the trust boundaries of the system? Are there any trust boundaries more important than others?
  Please make this diagram legible - I would rather you show the riskiest parts of the threat model than enumerate every possibility. As a guide, threat models get pretty confusing after about 12 primitives per diagram. If you feel your diagram must be more complex, feel free to break it up into multiple diagrams.
• Assets to Threat Model Tracing Provide a mapping from your assets in Chapter 1 to the elements in your threat model. Discuss this mapping:
  • Does the location in the architecture affect the p(exploit) of an asset? Why or why not?
  • Are there locations in the architecture where no assets reside? Did you miss any assets there?
  • In your opinion, are there locations in the architecture where too many assets reside?
  Use your terminology from the domain chapter (remember, this is all one cohesive paper!).

A few notes:

• Inferring the architecture for the system can be a real challenge if it's not documented. Here are a few places you can look for hints on what the subsystems are:
  • Bugs. Any custom fields, or what is mentioned in discussions.
  • File system layout.
  • Javadoc or other documentation.
  • API documentation for third-party developers can imply the subsystem layout.
  • You can always ask them on your mailing list. If you do, be sure to have the whole group review that email before it goes out.
• Resolve any comments from the domain analysis. Feel free to respond to those comments with clarifications, or just contact the instructor directly.

Grading Scheme (50 pts)

• 15pts - Overview and subsystems
• 20pts - Threat Model diagram and description
• 10pts - Mapping to Assets
• 5pts - Reaction to previous comments

Code Inspection Assessment

The purpose of this chapter is to do a brief security assessment of your system at the code level. You will choose three different pieces of source code (e.g. a file or module) and conduct a code inspection as a group. Your goal is to find potential security concerns in your product. Your chapter must include:

• Inspection Selection. Describe your motivation for selecting the three source code files that you chose.
  • Why did you choose these files for inspection?
  • After doing your code inspection, do you still feel you made a good selection? Any guidelines for finding files for code inspection?
• Code Inspection Results Provide a summary of your code inspections, including the following information:
  • What does this source code do?
  • What are the specific assets affected by this source code?
  • What subsystem is this code in?
  • If a developer made a mistake in this module, what kinds of security risks could arise?
  • Are there any potential vulnerabilities in this code? List them and describe each one.
• Project-Specific Checklist. A common practice for code inspections is to maintain a project-specific checklist, or a list of things that most source code files may have issues. This list is influenced by past vulnerabilities, what assets are involved, and the functionality of the code.
  • Provide a checklist of security concerns from your code inspections that the team ought to check for in their future code inspections. Make these specific to the project itself so that developers on your case study can benefit from your research.
  • Be sure to include the following types of concerns in your code inspection checklist:
    • Domain-specific concerns
    • Coding mistakes
    • Past vulnerability mistakes
    • Design concerns
    • Availability concerns
• Summary Provide a summary of your findings, generalizing upon the specific concerns you had in the code inspections.

A few notes:

• "Looks fine to me" is not an option here. If you are not finding very many mistakes in their code, then focus on pointing out the risks of future mistakes in their code.
• You are not expected to compile, build, or test on this system. This is a purely static exercise.
• Finding vulnerabilities in these big systems can be highly challenging, so you are not expected to find anything actionable. However, if you do find a vulnerability that is worth reporting to back to your case study team, then that will definitely help your grade. Please contact Professor Meneely first if you decide you found something worth reporting, as he will work with you on writing that bug report (so they take you seriously and fix it).
• On choosing files to inspect, consider the following methods:
  • Use your knowledge of your product's subsystems to narrow down your search.
  • Go back to your vulnerability history. Try to find the original fix (i.e. version control commit or patch) for a few of those vulnerabilities, then inspect those files, or other similar files in the same subsystem.
  • Look at their version control logs. Find files that were committed to many times recently, or by many developers (your instructor has a few command-line tricks for this, ask him if you are curious)
  • Consider some of the assets you identified earlier, and then try to find some source code files that mention those assets.
  • Take a look at some recently-fixed bugs that sound like they might involve some of your assets, and go to the files mentioned on those bugs.
  • Look for files that are particularly large (i.e. many lines of source code - your instructor has tricks for this, too)
  • Consider looking for bugs in security features as well. However, please do not do more than three inspections on files in security features.
• Regarding the inspection meeting, consider setting the following goals for yourselves:
  • Have two separate meetings: one for one file, another one a few days later for the other two. This gives you time to mentally "reset" and think about other places to look if your first two inspections don't go very well.
  • Set aside two hours for each meeting, or about 45-60 minutes per file. In-depth code inspection meetings can take a while.
  • Designate one person to scribe, and another person to facilitate. Try rotating facilitators for each file.
  • Examine the file ahead of time.
• If you don't understand what the file is doing, try the following:
  • Use the version control system's log method (e.g. svn log somefile.c) to lookup the history of a file. Take a look at any bug IDs mentioned in the version control commits.
  • Just read the comments, then read the code.
  • Walk through the file line by line verbally as a group.
• As usual, react to any comments from the instructor. Feel free to clarify with him directly if a comment is unclear.

Grading Scheme: (50 pts)

• 10pts Inspection Selection discussion
• 20pts Code inspection results
• 10pts Checklist
• 5pts Summary Section
• 5pts Reaction to previous comments

Presentation

Prepare a lightning talk of your case study. You do not need to cover every chapter of your paper. Instead, choose the most interesting part of your case study and present it in 7 minutes. You will have 3 minutes for questions. Powerpoint is not required. You may have one person present, or multiple people. Concrete examples are strongly encouraged.

Total Points: (20 pts)

• 10pts - Demonstrating thorough research of the project
• 5pts - Engaging choice of content from the case study
• 5pts - Engaging style