Relevant texts

There are no required textbooks for this course. However, the following are quite good, and we recommend them. They may be helpful for reinforcing concepts, practice problems, and delving deeper into some topics than we may go into in class.

  • Security Engineering, Anderson, 2nd ed. (free online)
  • Threat Modeling, Adam Shostack (free online)
  • Introduction to Computer Security, Goodrich & Tamassia, 1st ed.
  • Gray Hat Hacking: The Ethical Hacker's Guidebook, Harper et al., 3rd ed. (free online)

Relevant links

Git references

git will be your friend in this course and in the future.

Slack Workspace

We'll be using the following Slack workspace to simplify intra-team communication. Each team will have a private channel created once you select teams.

Commit Description Requirements:

Whenever you make a commit to your codebase or break submission, you are required to answer the questions based on the relevant competitoin round. Copy each of the appropriate questions (shown in bold) and specify your respective answers in a bulleted list format.

To include the required long commit message in git, simply use the command git commit, which will redirect you to a command-line text editor where you can enter your full message.

Build

  • Description of the change - A high-level discussion of what changes were made and how this effects program functionality.
  • Reason for the change - That is, why wasn’t the previous code sufficient?
  • Associated requirement - What functionality, performance, and/or security requirement is the commit meant to address (e.g., message confidentiality). Note, this can include multiple requirements.
  • How did you come up with this change? - Was there any specific inspiration for the change such as lecture topics, prior experience, or StackOverflow?
  • Was an update to the design required?

When to submit

Commits should be atomic as much as possible. That is, they should be focused on adding a single feature or fixing a single bug. This can include changes to multiple files, but should be associated with the same overarching feature or fix.

If it is impossible to split the commit by function or fix, indicate all associated requirements. Err on the side of more commits or ask the instructors for clarification.

Break

  • Description of issue in target’s program - A high-level discussion of what vulnerability is being exploited.
  • How was the break found? - Were you trying to exploit a vulnerability you mitigated in your own system, a vulnerability another team found in your system, based on an in-depth code review, or something else?
  • Requirement broken - What functionality, performance, and/or security requirement does the break target (e.g., message confidentiality). Note, this can include multiple requirements.
  • Is it a fixed version of a failed break? - That is, did you attempt to submit the break previously, but it failed? What did you change?
  • How hard was the break to find? - Rate the difficulty of identifying the vulnerability on a scale of 1-5, with 1 being not difficult at all to 5 being extremely difficult.
  • How hard was the break to exploit? - Rate the difficulty of creating a successful break once you identified the vulnerability on a scale of 1-5, with 1 being not difficult at all to 5 being extremely difficult.

When to submit

Break commit messages should be submitted each time a break is submitted.

Fix

When you can fix your code

  • What was wrong about your implementation? - That is, what vulnerability in your code did the breaking team take advantage of?
  • What caused the problem? - What do you think lead the vulnerability to be introduced in the first place? For example, was it a misunderstanding of the requirements or a miscommunication between teammates?
  • How did you fix the vulnerability?
  • How confident are you that your code is now secure? - Rate on a scale from 1-5, with 1 being not confident at all and 5 being extremely confident.
  • How hard was it to identify the problem? - Based on the submitted break, rate how hard it was to determine the underlying vulnerability on a scale from 1-5, with 1 being not difficult at all to 5 being extremely difficult.
  • Was an update to the design required?

When to submit

A fix commit should be submitted for each vulnerability (this can cover multiple breaks if they all exploit the same vulnerability). The fix commit message can being submitted with an updated to the code to remedy the identified vulnerability or simply with a list of associated breaks. The latter option can be used if you are unable to fix the vulnerability.

When you are unable to fix your code

If you are able to determine the vulnerability exploited by the breaking team, but determine that it is not practical to remedy (it would require weeks of work), then you can make a commit stating your decision not to fix. Note, your justification for not fixing will be assessed by the instructors who will determine whether it is sufficiently impractical to deserve points toward your criterion score.

  • What was wrong about your implementation? - That is, what vulnerability in your code did the breaking team take advantage of?
  • What caused the problem? - What do you think lead the vulnerability to be introduced in the first place? For example, was it a misunderstanding of the requirements or a miscommunication between teammates?
  • Why is it impractical to fix the vulnerability?
  • How would you fix the vulnerability if you had sufficient time or resources?
  • How confident are you that the fix you described above would be secure? - Rate on a scale from 1-5, with 1 being not confident at all and 5 being extremely confident.
  • How hard was it to identify the problem? - Based on the submitted break, rate how hard it was to determine the underlying vulnerability on a scale from 1-5, with 1 being not difficult at all to 5 being extremely difficult.
  • Was an update to the design required?

Web Accessibility