You are not nuts.  Your course outline  is a very substantial step in the
right direction.
----- Original Message ----- 
From: "Dana Epp" <[EMAIL PROTECTED]>
To: "Fernando Schapachnik" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, July 06, 2004 16:42
Subject: Re: [SC-L] Education and security -- another perspective (was "ACM
Queue - Content")


> > I'd be interested to hear what people think of the two approaches
(separate
> > security courses vs. spreading security all over the curricula).
> >
> > Regards.
> >
> > Fernando.
>
> 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.
>
> -- 
> Regards,
> Dana Epp
> [Blog: http://silverstr.ufies.org/blog/]
>
>


Reply via email to