I'd be interested to hear what people think of the two approaches (separate
security courses vs. spreading security all over the curricula).



Well, I have been asked to teach a new forth year course at the British Columbia Institute of Technology (BCIT) this fall on Secure Programming (COMP4476). I have no problem sharing my course outline and breakdown, since a lot of this is adopted from experiences many other structured secure programming courses and literature are taking. The idea is that students need to build a strong foundation of learning that they can adopt in which ever discipline they follow in the future. This shouldn't be a first year course, but I think its a bit late being a fourth year course. You will note that the course I am teaching is somewhat language agnostic, and even platform agnostic to ensure that the foundation isn't tainted with 'fad-of-the-day' techniques, technologies and tools. (Hold that to Web applications, which the jury is still out on)

Course Breakdown
1. Essentials of Application Security
* Types of attacks (hackers, DoS, Viruses, Trojans, Worms, organizational attacks etc)
* Consequences of Poor Security (Data theft, lost productivity, damage reputation, loose consumer confidence, lost revenues)
* Challenges when Implementing Security (Security vs Usability, Attackers vs Defenders, The misinformation about the security cost)

2. Secure Application Development Practices
* Implementing security at every stage of the development process
* Designing clean error code paths, and fail securely
* Planning on Failure through results checking
* Code review

3. Threat Modeling
* Attack Trees
* STRIDE Threat Modeling
* DREAD risk analysis

4. Using Security Technologies
* Encryption
* Hashing
* Digital signatures
* Digital certificates
* Secure communications (Using IPSec/SSL)
* Authentication
* Authorization

5. Detecting and fixing Memory and Arithmetic Issues
* Buffer overflows
* Heap overflows
* Integer overflows

6. Defending against Faulty Inputs and Tainted Data
* User input validation techniques
* Regular expressions
* Parameter checking
* Fault injection reflection

7. Design, Develop and Deploy software through least privilege
* Running in least privilege
* Developing and debugging in least privilege
* Providing secure defaults using the Pareto Principle
* Applying native OS security contexts to processes and files (ACL, perms etc)

8. Securing Web applications
* C14N
* SQL Injection
* Cross-site scripting
* Parameter checking

As I complete the lesson plan this summer this outline will change. I think more study on understanding trusted and untrusted boundaries needs to be added, and some areas such as Threat Modeling will be flushed out with more detail. Overall though, you can get an idea of areas of education that I feel make up a core foundation of learning in secure programming. I wish I could take credit for this thinking, as its a strong foundation to build on. Alas I cannot; pick up any number of secure coding books and realize that this is all covered there in some degree:

* Building Secure Code
* Secure Coding Principles & Practices
* Secure Programming Cookbook
* Security Engineering
* Building Secure Software

I only wish I could make all these books be textbook requirements for the curriculum. It should be mandatory reading. Although you can teach some aspects in any course being provided, the reality is I think a dedicated course helps to build on the real foundation of learning. All other courses can re-enforce these teachings to further drive it home for the student.

Of course, I also think students should have to take at least one course in ASM to really understand how computer instructions work, so they can gain a foundation of learning for the heart of computer processing. And I think they should be taught the powers and failures of C. Since I know many of you think I'm nuts for that, you might want to look at this outline with the same amount of consideration.

Dana Epp
[Blog: http://silverstr.ufies.org/blog/]

Reply via email to