Analysis Projects

Instructions for Choosing a Security Analysis Project

Before choosing to do a security analysis project, make sure to read carefully Legal Implications of Real World Security Analysis (password is provided via Piazza). Be mindful of possible legal implications of your interactions with a real-world system that you plan to analyze.

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 this project authorization form which your team should fill out, sign, and get the system owner signing it off.

Analysis Project Report

Reports for analysis projects should contain the following sections. All sections are required for the final report.

Pre-final Draft of the Report

For the pre-final draft of the report all points and questions shown in bold and italic font are required.

Grammar and Language Clarity

The final project report 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 (see the bottom of the general instructions for details).

Abstract (3%)

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. Explain what this project has contributed to the society in general and the cybersecurity community in particular.

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. Explain similarities and differences between your and 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.

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 (2%)

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.