Analysis Paper

Instructions for Choosing a Security Analysis Project

Your team can either (1) pick a project from this list of pre-authorized projects, or it can (2) find a project itself and get an authorization from the system owner. In the latter case, make sure to include in your project proposal project authorization form (located on Canvas: Files/TermPaper/Analysis Project Authorization Form) ) which your team should fill out, sign, and get the system owner signing it off.

Analysis Paper

Analysis papers should contain the following sections. All sections are required for the final paper. For the pre-final draft of the paper, all points and questions shown in bold and italic font are required.

The final paper is supposed to be free from grammatical and other language-related errors and issues. Points will be taken off for lack of clarity, incorrect grammar or spelling. Make sure to follow writing-related requirements for term papers.

Abstract

The abstract should summarize the problem addressed, methodology, results, conclusions, and contributions.

I. Introduction (10%)

The section should provide the following

  1. Explain clearly the problem addressed by your project.
  2. Explain why this is an important problem.
  3. Summarize the analyzed system
  4. Summarize related work.
  5. Summarize the methodology that you have followed in your project.
  6. Summarize results you obtained.
  7. Summarize the conclusions you drew from the results.
  8. Summarize your recommendations for improving the security of the system.
  9. List contributions of your project.

II. Analyzed System (5%)

This section should describe

  1. The main components of the system and the technologies used for implementing the system components. Make sure to use diagrams and figures to illustrate the main components of the system and their interconnections.
  2. The data flow between the components,
  3. The ways various stakeholders interact with the system.

III. Related Work (5%)

This section should explain what other, particularly as reported in academic literature have done analyzing systems similar to the one analyzed in this project.

Make sure to compare and contrast your work with the related work.

IV. Analysis Method (40%)

This section should:

  1. (System Analysis) Explain in as much detail as possible what exactly was done for analyzing the system.
  2. (Ethical Considerations) Discuss ethical aspects of the project, explaining how the project team followed the ethical principles.
  3. (Risk Management) Discuss how the project team managed various risks of the project, including but not limited to legal risks and risks of administrative sanctions by the system owners. Explicitly state whether your analysis of the system/technology was authorized by the system owner or technology vendor.

The above enumerated items should be discussed in separate subsections of Methodology section. Their titles are suggested in the parenthesis.

V. Results (20%)

This section should provide results obtained during the analysis.

When reporting results of your analysis, demonstrate that the identified weaknesses are exploitable, and, as such, are actual vulnerabilities. “Potential vulnerabilities” don’t count as “actual vulnerabilities” unless you demonstrate that they can be exploited to violate security and/or privacy properties of the assets.

VI. Discussion of the Results (8%)

    1. (Interpretation of the Results) This section should draw conclusions from the results, i.e., explain what the results mean.
    2. (Adversary Model) Describe in a separate subsection an adversary model, specifically its capabilities and objectives, that are necessary for exploiting the vulnerabilities that you have discovered.
    3. (Principles of Designing Secure Systems) Describe
      the principles of designing secure systems that were violated either by the system/technology developers or the system owners/operators and that led to the discovered vulnerabilities. Instead of just listing the principles, show the relationship/mapping between the violated principles and the discovered vulnerabilities.

The above enumerated items should be discussed in separate subsections of Discussion section. Their titles are suggested in the parenthesis.

VII. Recommendations (7%)

    • Offer recommendations for fixing the problems you’ve discovered or for additional countermeasures.
    • Explain how these recommendations/countermeasures follow the principles of designing secure systems.
    • Explain why you choose these particular recommendations/countermeasures (e.g., effectiveness, feasibility, practicality, cost, usability) and which other plausible candidates you had considered and why you did not chose those ones.

VII. Conclusion (5%)

This section should summarize the paper and acknowledge those who helped with the project or the report.

References

Place references here. Make sure they are complete (e.g., page numbers, conference and journal titles, author names). Aim to use more academic references than non-academic ones.

Appendix A. Project Code of Conduct

This appendix should list the code of conduct that the project team followed throughout the project. Make it relevant to your project and yet clear which ethical principles it follows.

Appendix B. Responsible Disclosure

  1. Discuss how findings of the project were (or will be) reported to the affected stakeholders, particularly the system/technology owner/developer.
  2. Include the time-line of the responsible disclosure process.
  3. Include the contact information of the system owner (name, e-mail address, and phone number), and other affected stakeholders that was (or will be) used for responsible disclosure.
  4. Schedule a face-to-face meeting with the system owner for December and include the date, time, and location of the meeting in the project report. The main objectives of the meeting should be (1) to debrief the system owner about the findings of the project, (2) to discuss the project team or the course professor can collaborate with the system owner on developing countermeasures for the discovered vulnerabilities, and (3) to determine the time-line for making the project findings public. The project team should send an e-mail message (CC-ed to Kosta) to the system owner, describing outcomes of the meeting and any resolutions/decisions/agreements made during the meeting.