CSE-60770 (40770) Secure Software Engineering

This Is Not The Course Website You Are Looking For

This course website is from a previous semester. If you are currently in the class, please make sure you are viewing the latest course website instead of this old one.

  • Lecture: M W - 2:00P - 3:15P (DeBartolo Hall 125)
  • Instructor: Joanna C. S. Santos
    • Office: 382 Fitzpatrick Hall
    • Office Hours: Monday 3:25PM-4:25PM and by appointment. (For appointments: send an e-mail to the instructor at least 24hrs prior the intended meeting time).
    • E-mail: joannacss@nd.edu
  • GitHub: https://github.com/joannacss/cse60770-secure-software-eng
Course Objectives:

Upon successful completion of this course, students will be able to:

  • Comprehend security principles and be able to apply security principles through the software development lifecycle;
  • Identify the differences and commonalities across vulnerability detection techniques & practices.
  • Be able to follow a systematic process to collect and analyze metrics for assessing and improving the security of a software system.
  • Be able to develop techniques to (semi-)automatically detect software vulnerabilities
  • Critically evaluate and recommend the most appropriate security solutions for a software stack.
ABET Outcomes
Analyze a complex computing security problem and apply principles of computing and other relevant disciplines to identify solutions. Design, implement, and evaluate a computing-based solution to meet a given set of security requirements in the context of the program’s discipline. Communicate effectively in a variety of professional contexts. Function effectively as a member or leader of a team engaged in activities appropriate to the program’s discipline.
Text Books

All necessary materials will be provided in the lecture notes, code samples, and through weekly readings. However, some course materials have been taken from the following books, which students may choose to purchase:

  • McGraw, Gary. Software Security: Building Security in. Germany, Addison-Wesley, 2006. http://www.swsec.com/
  • Software Security Engineering: A Guide for Project Managers by Julia H. Allen, Sean Barnum, Robert J. Ellison, Gary McGraw, and Nancy Mead. Addison-Wesley, ISBN 978-0-32-150917-8

This is the approximate schedule for the course; however, the schedule will be adapted if needed. Slide decks are linked in advance but will be modified up until the lecture.

Week # Monday Wednesday
Week 1 Jan 10
L1: Course Overview & Introduction
Slides Activity 1 ⏰ 01/12 @ 2PM
Jan 12
L2: SW Security Pillars
Slides HW1 ⏰ 01/25 @11:59PM
Week 2 Jan 17
Martin Luther King Day
No Class
Jan 19
L3: Software Weaknesses (Deadly Sins of SW Security)
Slides Activity 2 ⏰ 01/24 @ 2PM
Week 3 Jan 24
L4: Weaknesses & OWASP Top 10 (Part 1)
Slides Activity 3 ⏰ 01/26 @ 2PM
Jan 26
L5: OWASP Top 10 (Part 2)
Slides Activity 4 ⏰ 01/31 @ 2PM HW2 ⏰ 02/08 02/10 @11:59PM
Week 4 Jan 31
L6: OWASP Top 10 & PyGoat
Slides Activity 5 ⏰ 02/02 @ 2PM
Feb 02
L7: Snow Day
Canceled Class
Week 5 Feb 07
L8: Secure By Design & Design Flaws/Principles
Slides 📄 Seminar Presentation
Feb 09
L9: Security Requirements, Misuse/Abuse Cases
Slides Activity 6 ⏰ 02/14 @ 2PM
Week 6 Feb 14
L10: Threat Modeling
Slides
Feb 16
L11: Security Patterns
Slides Activity 7 ⏰ 02/21 @11:59PM 🔎 Case Study
Week 7 Feb 21
L12: Static Analysis-1
Slides
Feb 23
L13: Static Analysis-2
Slides
Week 8 Feb 28
L14: Static Analysis-3
Slides Course Project ⏰
Mar 02
L15: Static Analysis-4
Slides
Week 9 Mar 07
Mid-Term Break
No Class
Mar 09
Mid-Term Break
No Class
Week 10 Mar 14
L16: Seminar Presentations - Day 1
Mar 16
L17: Seminar Presentations - Day 2
Week 11 Mar 21
L18: Seminar Presentations - Day 3
Mar 23
L19: Static Analysis-5
Slides HW3 ⏰ 04/05 @11:59PM
Week 12 Mar 28
L20: Secure Coding - Part 1
Slides Activity 8 ⏰ 03/30 @ 2PM
Mar 30
L21: Secure Coding - Part 2
Slides Activity 9 ⏰ 04/04 @ 2PM
Week 13 Apr 04
L22: Dynamic Analysis - Part 1
Slides Activity 10 ⏰ 04/06 @ 2PM
Apr 06
L23: Dynamic Analysis - Part 2
Slides Activity 11 ⏰ 04/11 @ 2PM HW4 ⏰ 04/19 @11:59PM
Week 14 Apr 11
L24: Dynamic Analysis - Part 3
Slides Activity 12 ⏰ 04/13 @ 2PM
Apr 13
L25: Security Testing - Part 1
Slides Activity 13 ⏰ 04/20 @ 2PM
Week 15 Apr 18
Easter Monday
No Class
Apr 20
L26: Testing - Part 2
Slides HW5 ⏰ 04/26 @11:59PM
Week 16 Apr 25
L27: Project Presentations-1
Apr 26 (Tuesday)
L28: Project Presentations-2
Coursework:

This class includes the following graded components:

  • Case Study: An in-depth investigation of security challenges experienced by a real software product. While in class you will be learning about security tactics, common weaknesses, and secure coding practices, in the case study you will see investigate how those concepts are applied (or not at all). The outcome is a technical report (2-3 pages).
  • Seminar Presentation: Every student will select (or be assigned) one paper on a course-related topic. The student is to gain a detailed understand of the paper, and present it to the class. The student should highlight the motivation of the work, its novel contributions, any surprising findings and possible applications of the work. This also includes a critique which contains at least three strengths of the paper and at least three weaknesses of the paper.
  • Course Project: A a group project where the students would be working throughout the semester. You are expected to work on the course project in pairs (or in rare occasions groups of three students). Each group is expected to write a research paper by the end of the quarter. The topic is to be negotiated with the instructor. Examples include: building a tool to support secure software engineering practices, or a survey paper of a software security related topic (typically involves surveying several research papers), or empirical studies, etc. The final report (10 pages in length) should be submitted by the end of the semester. All project-related documents (i.e., project proposal and project report) should use the IEEE conference publication format. If the paper is deemed publishable, the instructor will work with the student to make appropriate changes to the final report and submit the paper for publication.
  • Homeworks: Each lecture cover a different practice or tool. The homeworks are intended for the student to apply the studied concepts in class. Most of these homeworks are individual.
  • Attendance & In-Class Participation: Classes may include short hands-on activities/exercises that are submitted during class. These may be used as points towards attendance.

Your final course grade is computed according to the following breakdown:

Component Points
Case Study 25%
Homeworks 15%
Course Project 30%
Seminar Presentation 20%
Attendance & In-Class Participation 10%
Grading:

Grades are assigned as follows:

Grade Points Grade Points
Grade Points A >=93 A- >=90 and <93
B+ >=87 and <90 B >=83 and <87 B- >=80 and <83
C+ >=77 and <80 C >=73 and <77 C- >=70 and <73
D >=65 and <70 F <65

Any re-grade request shall be made by the regrade request deadline on Gradescope (i.e., no more than 5 days after the grades are posted). All the re-grade requests shall be made through gradescope, unless specified otherwise in class, via e-mail, or on feedback notes.

In-Class Activities & Attendance:
Students are expected to come to class and actively participate on discussion, asking questions as well as helping peers when appropriate (see Honor Code Below). Classes may include short hands-on activities/exercises that are submitted during class. These may be used as points towards attendance.
Late Policy:

Deadlines are strictly enforced. There is a penalty of 10% for submissions up to 24hrs past the deadline. Submissions made more than 24hrs past the deadline are not accepted (i.e., they will be assigned 0). Late submissions are accepted if (a) the student make prior arrangments with the instructor, or (b) the student has a university-approved reason (and notified the instructor in advance). In case of justifiable exceptional circunstances, please communicate with the instructor as soon as possible (and prior the deadline if humanly feasible) to make arrangements.

HOWEVER...
Life Happens. We all lead densely-layered lives; therefore, one of my core values is leading with grace. As a result, I institute a "Life Clause": should you need it, you may invoke the “Life Clause” on ONE assignments, and get 3-day extension: no explanation required. To invoke a life clause, please send an e-mail to the instructor.

To maintain fairness, the instructor does not grant extensions on a case-by-case basis (i.e., the rules laid out in here applies to all students -- without exceptions).

Honor Code:
Students are expected to abide by the principles of intellectual honesty and academic integrity.

It is cheating to copy, to allow another person to copy, all or part of an exam or an assignment, or to fake program output. It is also a violation of the Undergraduate Academic Code of Honor to observe and then fail to report academic dishonesty. You are responsible for the security and integrity of your own work.

For the individual assignments in this class, you may discuss with other students and consult printed and online resources. You may quote from books and online sources as long as you cite them properly. However, you may not look at another student's solution, and you may not copy any significant portions of other's solutions.

For the group project, the same rules applies. The main difference is that you are allowed -- and expected -- to discuss specifics of the solution for the project with your team members (i.e., students in your group). However, the group may not copy a solution from elsewhere (i.e., another team, book, tutorial, etc). Any honor code violation to the project will be reported as a major violation.

The following table summarizes how you may work with other students and use print/online sources:

Resources Solutions
Consulting Allowed Not Allowed
Copying ⚠️ Cite Not Allowed

See the CSE Guide to the Honor Code for definitions of the above terms.

The "Pencils Down" Rule: You may communicate about homework with your classmates at a high-level, give general advice, and chat about common problems. You may not communicate specific knowledge such as problem solutions or steps or planning documents. A good litmus test is if you would need to write it down to communicate or remember something, it is off limits. Seek homework help from the Professor or the TAs instead.

Per stated in Section 2.4.1 in the Undergraduate Academic Code of Honor "Faculty and anyone else responsible for teaching or assisting in a course will not tolerate academic dishonesty.". Therefore, if an instructor sees behavior that is academically dishonest, that professor is required to file either an Honor Code Violation Report (HCVR) or a formal report to the College of Engineering Honesty Committee.

This course will be recorded using Panopto. This system allows us to automatically record and distribute lectures in a secure environment. You can watch these recordings anytime, anywhere, on any device. In Sakai, look for the "Panopto" tool on the left hand side of the course. These recordings are jointly copyrighted by the University of Notre Dame and your instructor. Posting them to other websites (including YouTube, Facebook, SnapChat, etc.) or elsewhere without express, written permission may result in disciplinary action and possible civil prosecution.