Re: Strategies for teaching secure coding practices

["Dana Epp" <dana () vulscan com>]

I love using this quote in my presentations at the University when I am
discussing secure coding practices:

"You cannot build secure systems unless you know the threats to which you
are susceptible".

In my opinion, (and you can take that for what its worth :) ) it is futile
to try to teach the intricities of a particular language as it relates to
secure coding, without first having a foundation on secure coding as a
whole. It is better to teach them WHY things happen the way they do, and not
simply "use strncpy over strcpy cuz its safer". They really need to
understand what the risks are, and then how to prevent them.

Why do I say that? Because I can look back on time and see things haven't
gotten better even though our history is riddled with the same experiences.
We have had the same errors in C for decades, from overflows to misuse of
the sizeof() op, and people don't know WHY its a problem. I am noticing a
sad trend of new developers coming out of school. They know very little
about how a computer works, and more about the syntax of any one or two
particular languages. Of course I am over-generalizing here, but hopefully
you can see my point.

Some areas that are essential when designing an educational program that
relates to secure coding should include (in no particular order):

1) How to design clean error code paths, and fail securely.

2) How and why to validate any input crossing an untrusted boundary to a
trusted boundary, and when to do it. Until students realize to trust
nothing, verify everything... we will always find paramater validation
issues. Further to this, make sure you show to only accept properly
formatted data, and reject everything else, rather than the reverse.

3) Results checking. Don't be lazy, deal with it. Plan on failure and handle
it correctly.

4) Code flow, state syncronization and race conditions.

5) Overflows. WHY they happen, and techniques to audit your code to ensure
it doesn't happen to you. Buffer overflows are not enough. Heap overflows
and interger overflows should also be covered.

6) Threat modeling. Explain why this should be done BEFORE a single line of
code is written, and then again midway and the end of development.

7) Security testing. Fault injection, data mutation and running in
environments of least privilege.

8) Running in least privilege. Developers need to understand that they
should only expose their applications to the minimum amount of access
privileges that they need to accomplish their tasks. If they understand this
at the beginning, they will code differently, looking for error results in a
new way.

9)  Employment of secure defaults. They need to understand the Pareto
Principle (thats the 80/20 rule for those that don't know), and how that
reflects on their feature base and the attack surface of the application.
Ship it off, then let the user decide if they wish to turn it on.

10) Use whats there. The operating system on any given platform normally has
great security features, and developes doesn't seem to use them. A really
good example is the fact very few Windows applications use security
descriptors correctly. To many people think they are going to be the next
godlike cryptographer and roll their own ciphers when they don't need to.

Those are a few thoughts off the top of my head. You will notice most of it
is about secure coding principles and practices, and not "Howto do blah".
Thats because without this foundation, developers won't apply the principles
correctlly and will not mazimize the benefits from this learning. They won't
look for tainted or malicious input if they don't realize WHAT it will do to
a program. They won't check for failure if they can just get by on the
normal flow of a working application. blah blah blah. Hopefully you see my
point.

David Wheeler did a pretty good presentation a while back that addressed
writing secure apps in Unix-like environments. You might be able to get a
good start by checking out his slideshow at:
http://www.dwheeler.com/secure-programs/secure-programming.pdf and his
hadouts at:
http://www.dwheeler.com/secure-programs/secure-programming-handouts.pdf

Hope this was helpful. Good luck!

---
Regards,
Dana M. Epp
[Blog: http://silverstr.ufies.org/blog/]


----- Original Message ----- 
From: "Carl G. Alphonce" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, December 12, 2003 7:05 AM
Subject: [SC-L] Strategies for teaching secure coding practices


> The editor of the list has expressed a desire that the discussion move
> away from "away from a discussion of the merits and !merits of a
> particular operating system", so here's a contribution in a different
> vein.
>
> I am a recent subscriber to this list and also an educator.  I teach
> primarily undergraduate courses, often the first and second semester
> courses, and I am very interested to hear from the list what you all
> consider to be important "secure coding" topics to cover in these
> first-year classes.  Also, what topics to you feel should be covered
> in an undergraduate curriculum but later than the first year?
>
> To give you some context, our first-year sequence currently takes an
> OO approach, incorporating design patterns and discussions of the
> merits of alternative designs.  We also introduce some team-based work
> in the second semester, and I am will begin to incorporate test-first
> practices (using JUnit) this coming spring semester.
>
> -- 
> Carl Alphonce                             email: [EMAIL PROTECTED]
> Dept of Computer Science and Engineering  phone: (716) 645-3180 x115
> University at Buffalo                       fax: (716) 645-3464
> Buffalo, NY 14260-2000
http://www.cse.buffalo.edu/~alphonce
>