GMU Catalog: “Theory and practice of software security, focusing in particular on some common software security risks, including buffer overflows, race conditions and random number generation, and on identification of potential threats and vulnerabilities early in design cycle. Emphasizes methodologies and tools for identifying and eliminating security vulnerabilities, techniques to prove absence of vulnerabilities, ways to avoid security holes in new software, and essential guidelines for building secure software: how to design software with security in mind from the ground up and integrate analysis and risk management throughout the software life cycle.”
People around the world now depend vitally on computers for their health and well-being. Unfortunately, this software can often be exploited by attackers, resulting in terrible harm. This class will study how to develop software that is far more resistant to attack. This includes how to prevent many vulnerabilities from being in the software in the first place. We will also discuss detecting break-ins when they do occur, containing their impact, and responding to them. The goal of the class is to prepare you to be able to develop software that is far more secure, and to prepare you to help others do the same.
This classes focuses on defense, not on attack. We’ll discuss attack to some extent, but only enough to help us understand how to defend. Most software security problem stem from the same small set of types of vulnerabilities (aka weaknesses), so we will spend a lot of time learning about these common weaknesses and how to counter them. We will also cover general designs and techniques for securing software designs and implementations in general, so this is class is not just an enumeration of common mistakes.
This is an extremely practical class. We will cover theory and principles, but we will also cover many practical specifics so you can apply these principles in the real world. If you cannot apply the theory, then you understand neither the theory nor the practice. What’s more, I want you to have experience in trying to convince others to change their behavior; that is absolutely necessary to get more secure software worldwide.
Most students report that this class has above-average workload. There is a lot of reading (because there is a lot of material to cover), a topic paper/presentation, and final group programming project. None of it is busywork, though; it all has a purpose. Most past students have said that although this class is a lot of work, they were glad they took it; I hope you will be able to say the same.
| Class: | SWE 681 / ISA 681 Secure Software Design and Programming | |
| Professor: | Dr. David A. Wheeler. Email dwheele4 at gmu *dot* edu (no “r”). 703-845-6662. GMU email is my preferred method, but call if you are in a hurry. Office hours by appointment only. | |
| Possible Guest Lecturer: | Dr. Reg Meeson. | |
| Class Hours & Location: | Wednesdays, 4:30 pm - 7:10 pm, East 122 | |
| Prerequisites: | SWE 619 or permission of instructor. Must be able to read C and Java and must be able to develop software. | |
| Class website: | Use Blackboard 9.1. Log in to mymasonportal.gmu.edu, select the “Sources” tab, and select “ISA-681 / SWE-681” (for this semester) |
To get to the course website, use your web browser to view http://www.gmu.edu. Click on Students (at the top right), then click on “My Mason” (in the middle-left). Log in to “myMason”. On the top right, click on the “Courses” tab (next to the “Home”) tab. Click on “SWE-681 / ISA-681 for this semester”.
Do not use “http://mason.gmu.edu/~dwheele4/swe681/” as that is an obsolete site.
The syllabus, including the schedule and topics to be covered, is subject to change, but I will notify you of any changes.
Here is the current reading list (the first two are the required textbooks, the rest are required articles):
I may add a few additional required reading articles as we go.
You are also responsible for learning the materials in the class presentations by me. I make most of the presentations publicly available at http://www.dwheeler.com/secure-class/, and when I am about to present them, I copy that into the Blackboard site. I routinely update the presentations at http://www.dwheeler.com/secure-class/, so for study purposes you should probably use the stable copies on Blackboard.
You may find some useful topic ideas in: Goertzel et al, Software Security Assurance State of the Art Report, May 2007.
You must be able to write programs. This is a practical class for developing programs, and you’ll have a programming project as part of the class.
You must be able to read and understand programs in both Java and C. The principles are language-independent, but I have to pick some languages so we can discuss specific examples. Java and C are two of the top programming languages according to the TIOBE programming community index; using both lets us examine a variety of real-world issues with widely-used languages. In particular, C lets us examine issues that can only occur in memory-unsafe languages (e.g., C, C++, and Objective-C), while Java lets us examine issues that can still occur in memory-safe languages. Some students have had success learning C simultaneously, but plan to spend a lot of extra time if you do that. You’ll need to be able to understand both Java and C code for the mid-term exam, and I can’t be a language tutor.
The lectures will cover the key issues and explain some things that might not be clear otherwise. However, you are responsible for reading and understanding the material in the assigned readings (and not just knowing what’s in the lectures). Note that there is a significant amount of reading, especially in the first half of the course; we then move into more specialized topics and application.
First actual class date is September 2, 2015; the last normal class day is December 9. I do not plan for us to meet on the exam day, but please hold it open just in case I change my mind. We do not meet on November 25 due to Thanksgiving recess. See the GMU calendar for general information on the GMU calendar. I routinely check the list of ”non-work” religious holidays maintained by GMU.
Here is the current calendar (changes may occur):
| 2015-09-02 | 1: Introduction (including integrating risk management); Wheeler chapters 1,2,3, Chess/West chapter 1; Software Assurance Using Structured Assurance Case Models. |
| 2015-09-09 | 2: Input validation and regular expressions (including whitelists); Wheeler chapter 5 (includes regular expressions), Chess/West chapter 5. |
| 2015-09-16 | 3: Buffer Overflows; Wheeler chapter 6, Chess/West chapters 6, 7, Aleph, Cowan, Pincus papers. |
| 2015-09-23 | 4: Design for security and least privilege (including race conditions); Wheeler chapter 7, Chess/West chapter 12, Saltzer & Schroeder (glossary and part I “basic principles” - see the “design principles” in particular!!), and McGraw’s discussion of S&S. |
| 2015-09-30 | 5: Calling out to other resources (databases/SQL injection, other injection); Wheeler chapter 8, review Chess/West section 5.3. |
| 2015-10-07 | 7: Cryptography: Privacy, secrets, random numbers, and password hashing, and implementing authentication and access control. Notice that we're doing 5, 7, 6 in that order. Wheeler chapter 11.1 through 11.6, Chess/West chapter 11, Georgiev et al. 2012 paper (“The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software”). Timing attacks (whether or not they involve cryptography). Minor assignment due. |
| 2015-10-14 | 6: Output (send information back judiciously), Web Application Vulnerabilities (XSS, CSRF, etc.), and top vulnerability lists. Notice that we're doing 5, 7, 6 in that order. Wheeler chapter 9, Chess/West chapter 9,10. Read the SANS Top 25 and SwA Pocket Guides (these supplement and fill in previous materials) and the OWASP XSS cheatsheet. Must have topic selected. Must have project group and project (game) selected. |
| 2015-10-21 | Mid-term exam: Closed book; will include multiple choice, matching regular expressions, at least one essay, and you’ll need to find vulnerabilities in C and Java programs. I strongly encourage you to have your project group and game selected by this point; if you do not, I will randomly assign the stragglers into pairs. If you will be unable to take the mid-term on this date (e.g., because it is a non-work religious holiday for you), let me know so we can make alternate arrangements. |
| 2015-10-28 | 8: Error Handling and Language-specific issues; Chess/West chapter 8; Wheeler chapter 9 (9.1, 9.2, 9.3 only), 10. Newsham. |
| 2015-11-04 | 9: Tools (static and dynamic analysis). |
| 2015-11-11 | Topic presentations (you present!). Remember, do NOT just admire a problem, but give tell us something software developers can do about the issue during software design and implementation. Remember to dress up if you are presenting! |
| 2015-11-18 | Topic presentations (you present!). Topic papers due. I recommend that your project have SSL/TLS working by or before this date. |
| 2015-11-25 | (Thanksgiving recess) |
| 2015-12-02 | 10: Miscellaneous topics - part 1. Miscellaneous topics include open source software (and their relation to secure software development), formal methods (which allow you to prove properties of specifications or even programs), and countering malicious tools/compilers. Read Wheeler chapter 11.6, “Reflections on Trusting Trust” by Ken Thompson, and “Fully Countering Trusting Trust through Diverse Double-Compiling” (abstract, chapter 1, and chapter 4). |
| 2015-12-09 | 10: Miscellaneous - part 2. |
| 2015-12-16, 4:30pm - 7:15pm | Project due (documentation and source code). Documentation must briefly explain its design and why you think it’s secure (its assurance case). You need to submit a video demonstration of the program showing that it works, the video must not be longer than 5 minutes. This is the exam time for the class. I do not plan to physically meet on that day, but please be prepared to physically meet in case I change my mind. |
| Minor Assignment | 5% | Pick a known vulnerability in a specific program from the NIST Software Assurance Reference Dataset (SARD, formerly the SAMATE Reference Dataset (SRD)) or similar source. Please look at several examples before you pick one to write about (you can click on a test case id to see its specifics)! Do not just pick the first one in the list, but try to be a little more random; I do not want to read about the same one from everyone. Then write a short (1-2 page) paper showing the vulnerable code snippet, explaining the vulnerability (where is the vulnerability? why is it vulnerable? what kind of vulnerability is it?), and explaining how it could be fixed (give specifics). Be sure to cite your source(s). This is intended to be an easy assignment to give you early experience looking at programs with vulnerabilities. Looking at vulnerable programs, with information on why they’re vulnerable, can help you find vulnerabilities in other programs... and is great practice for the mid-term. |
| Mid-term exam | 30% | Covers everything up to that point. |
| Topic Paper and Presentation | 25% | A paper on a class-related topic (15%) and matching 5-minute presentation (10%). Everyone’s topic must be different. The purpose of the paper is to give you a little more depth in some specific topic. The purpose of the presentation is to give you experience in being an effective advocate for others to do (or not do) something, to improve security; it also gives the rest of us a taste of the many other issues in the field. You will need to dress up on your presentation day. See the separate page ("Topic Paper/Presentation requirements") that describes the paper and presentation requirements in more detail. |
| Programming Project | 35% | Create a secure game, in teams of 2 people. Pick someone, otherwise I will randomly assign you someone. (If you have a compelling work reason, or there is an odd number of students, I may allow a 1-person group. Trios are possible but discouraged; ask permission first.) Please get to know your classmates so you can pick a partner you can work with. This is a critical part of the course, because it gives you experience in applying the concepts. By working in pairs, you can easily review each other’s work, and reduce the effort too. If I believe (based on the information I receive) that someone didn’t do any significant useful work on the programming project, then the non-worker gets a 0 for the project. My goal is not to be punitive; my goal is to protect everyone from “partners who won’t work”. I think this is fair, indeed, it’s not fair to give someone credit for work not done. If you find yourself in a situation where your partner isn’t doing real work (after your project begins), please let me know as early as you can. I realize that the potential downside of pair/group work is that one person might end up doing all the work. I hope that this will reduce that risk. |
| Post-midterm participation | 5% | Attendance in class post-midterm. You can miss a class without penalty, after that it’s -1% per class. I want people to participate in this part in particular, since at that point you will have some of the basics, but I do not want to assign both a project and a final. |
Do not turn in materials late. Penalty is 10%/day and they won’t be accepted after three days (except for unexpected health/ family emergencies or special permission).
I grade on results, not effort.
In class, please pay attention and don’t distract others. Please configure cell phones to vibrate (and not make noise) in class.
Please talk to me ahead-of-time if you have an anticipated absence that will interfere with the mid-term, your topic presentation, or final presentation, e.g., a non-work religious holiday, out-of-town work travel, or GMU athletic meet. I can easily reschedule topic presentations; the others are much harder. Don’t bother telling me if you’ll miss other class times; I strongly recommend class attendance, but I understand if work, family, or other commitments sometimes make that difficult to do. You can always turn in work early (e.g., if the deadline conflicts with a religious holiday).
GMU is an Honor Code university; please see the University Catalog for a full description of the code and the honor committee process. The principle of academic integrity is taken very seriously and violations are treated gravely. What does academic integrity mean in this course? Essentially this: when you are responsible for a task, you will perform that task. When you rely on someone else’s work in an aspect of the performance of that task, you will give full credit in the proper, accepted form. Another aspect of academic integrity is the free play of ideas. Vigorous discussion and debate are encouraged in this course, with the firm expectation that all aspects of the class will be conducted with civility and respect for differing ideas, perspectives, and traditions. When in doubt (of any kind) please ask for guidance and clarification. Do not plagiarize. See the Computer Science Honor Code policies for more.
Please use the instructor’s email address for class questions. You must use your Mason email account for all email correspondence having anything to do with your work at Mason. Federal laws protecting your privacy rights require that we only communicate student information directly to students - and use of the university email system is our only way to validate your identity when using email. You may forward your campus email elsewhere, but we can respond only to a Mason email account. This is per GMU policy 1315.
We can also communicate via Blackboard, however, I only intermittently look at the Discussion Board on Blackboard, so that's a terrible way to get my attention.
If you are a student with a disability and you need academic accommodations, it’s nice to let me know as a courtesy, but you must contact the Office of Disability Services (ODS) at 703-993-2474 or http://ods.gmu.edu. All academic accommodations must be arranged through the ODS, not through me. If you qualify for accommodation, the ODS staff will give you a form detailing appropriate accommodations for your instructor (me), please bring that form to me.
The following are comments of past students. In 2012 I received the “outstanding adjunct faculty” award, primarily for teaching this class, and some of these comments were in support of this award:
Amin Tora, one of my former students, found and reported a vulnerability in Apache (involving not updating the length of a string) that has since been fixed. You can learn more from the NVD entry for CVE-2013-6438 and also his blog post.
This syllabus is version 2015-08-09.