This repository includes things related to the Software Assurance course at UNO.

Syllabus
Supplies
Class Topics
Semester Project
Project Hall of Fame
Project Inspiration
Projects to Avoid
Project Deadlines
Final Exam
License

Syllabus

• Bringing a laptop to class is highly encouraged for in-class activities.
• A notebook and pencil.
• Online Lab Computer

1. Introduction to Software Assurance
2. Collaborating when working on Software

• Get familiar with version control. Github Primer

3. Corporate Engagement with Open Source Software (OSS) and Licensing

• Guest Talk by Matt Germonprez

4. Engineering For Assurance

• Systems Security Engineering. Based on Chapter 2 from NIST SP 800-160 Public Draft 2.

5. Assurance Cases for Software Security Engineering

• ISO Standard for Assurance cases.
• Diagramming in Lucidchart. You can sign up for a free student account. You may start a new assurance case using this template.
• Formal diagramming in Adelard ASCE
• Assurance Case Exercise (Team Deliverable)

6. Requirements for Software Security Engineering

• Problem Frames (Abuse and Security Frames)
• The Meaning of Requirements for Software Security Engineering
• Misuse cases
• Using Misuse cases to Elaborate Assurance Cases: Misuse Case Exercise (Team Deliverable)
• Translating compliance constraints to requirements (NIST 800-160 public draft 2, Appendix J)

7. Maturity Models for Software Security Engineering

• Build Security In Maturity Model (BSIMM)

8. Midterm Exam. Sometime in October.
9. Design for Software Security Engineering

• Design Principles for Security (NIST 800-160 Appendix F)
• Threat Modeling. Data flow based threat identification and mitigation techniques.
• Diagramming using Microsoft Threat Modeling Tool.
• Design patterns (See Blackboard for Slides):
  1. Expressing design principles as patterns
  2. Architectural patterns for security
  3. Object-oriented code patterns for security

10. Coding for Software Security Engineering

• Knowledge base: Common Weakness Enumeration, CAPEC, CERT Secure Coding Guidelines
• DHS SWAMP
• Code review tools and techniques

11. Testing for Software Security Engineering

• Guest Talk by Matt Hale

12. Other topics

• Guest talks from other faculty or practitioners.

* These topics will get refined and updated as the semester progresses

Team projects

Team projects: TBD

This class strives to encourage learning by doing and making a real difference to the practice of building software. To turn this spirit into reality, a semester long project will require you to work with a open source software project. A group of three students will select a unique open source software project and contribute security related improvements.

The project will have the following deliverables:

1. Project Proposal: 2-3 page report that describes the following:

• Open source project description (What is it?, Contributors, Activity, Use, Popularity, Languages used, platform, documentation sources, etc.)
• Functional security requirements for the software
• License, procedures for making contributions, and contributor agreements
• Security related history (E.g. known vulnerabilities)
• Your motivation for selecting this project

2. Requirements and Design for Secure Software: 2-3 page report that describes the following:

• Links to your version control repository that shows your internal collaboration and project related activity.
• Security requirements for the project captured using mis-use case diagrams. Include links to Lucidchart diagrams with brief descriptions in the document.
• Threat models for critical dataflows through the software. Include diagrams and a link to download these files.
• Links to suggested updates for project documentation for security related configuration and installation.

3. Code analysis and testing for Secure Software: 2-3 page report that describes the following:

• Code review strategy
• Automated code scanning results summary. Include links to full reports.
• Summary of key findings
• Links to pull requests to the original project and any follow-up interactions.

4. Class Presentation: 10-minute class presentation that highlights the following:

• Project description
• Gaps in security requirements and design of the original project
• Findings from code review and automated software scanning
• Contributions to the original project (documentation, design changes, code changes, communications)

• List of successful contributions to OSS projects from student teams

• Github guide for contributing to Open Source Projects
• Openhub by Black Duck Software
• Github search and trends.
• DHS SWAMP listing for public software packages.
• Code Triage
• Some blogs to consider. 1, 2, 3

• In-active projects (no recent contributions, no activity on forums, lack of wiki or documentation)
• Old vulnerable project versions
• Android Apps
• Projects with languages that do not have a lot of tool support
• Project with little or no functional security requirements. As surprising as it may sound, not all software have security needs!
• Projects not accepting contributions

1. Project Proposal – September 13, 2017
2. Requirements and Design for Secure Software – TBD
3. Code analysis and testing for Secure Software – TBD
4. Class presentations – December 6, 2017

* All dates are subject to change as the course progresses

• In-class exam on Wednesday, December 13, 2017, 5:30pm

Use these instructions if you do not intend to contribute any upstream changes. In a CLI navigate to the directory where you want to clone the repository. Then run the following clone command:

# Clone the Repository to the current directory
# Notice the `.` at the end of the command
git clone https://www.github.com/robinagandhi/swa .

Now examine the swa directory structure. It should have the same directory structure as this repository on Github.com.

The master branch includes the following content:

• master: This branch includes files for course planning, project description, course syllabus, markdown based slides and any self-paced tutorials for class lectures.

To keep your local repository updated with upstream changes use the git pull command.

# update the repository
git pull

First fork this repo on Github.com while logged into your account. Then clone the forked repo on your computer.

Now you will need two capabilities: 1) Keep your fork (downstream) synced with this repo (upstream) and 2) Make upstream pull requests for changes made in the forked repo. Both these can be accomplished by following these steps:

1. Fork a Repo
2. Syncing a Fork
3. Push changes to your remote fork: git push origin master
4. Create a pull request from a fork

More advanced collaboration features can be found here: https://help.github.com/categories/collaborating-on-projects-using-issues-and-pull-requests/

Don't have contributor agreements ready just yet. TBD.
In general, if you are making it a pull request you agree to abide by this CLA: https://cla.github.com

Software Assurance.
Copyright (C) 2016 Dr. Robin A. Gandhi

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.

tl;dr Legal summary