market for training CISSPs how to code

[dwheeler at ida.org (Wheeler, David A)]

> At 7:27 PM +0200 3/17/10, AK wrote:
> > Regarding training non-developers to write secure code, what are  the
> > circumstances that a non-developer would create code that would
> > *require* security?

As soon as a "non-developer" creates code, they are no longer a "non-developer".  By definition, they are now a 
developer!

Of course, they may completely lack any kind of knowledge about security.  Just like most developers, I should add.  I 
expect this problem to *increase* over time.


> > I am assuming that system administrators know the
> > basics of their trade and scripting language of choice so security
> > there is taken care of

That may be true in some places.  But all too often real knowledge and expertise is rare.  Many "System Admins", esp. 
in the Windows world, do not understand the underlying technology at all.  They only know how to how to point-and-click 
based on recipes created by others (e.g., local instructions or whatever Google tells them).  All too often we *train* 
while ignoring *education*.

When they have to program at all, these kinds of people perform "cargo cult programming" (see 
http://en.wikipedia.org/wiki/Cargo_cult_programming ).


Larry Kilgallen:
> Scripting languages should not be used for security-sensitive programs.

Perhaps, but they are and will be used that way anyway.  We need plan B.

Perhaps we have a different definition of "security-sensitive program".  If you're trying to protect confidentiality, 
integrity, or availability of information or a service, then I think you have security properties you're trying to 
maintain.  For example, most websites are developed with scripting languages, and many of them are important for their 
organization's business, making them security-sensitive in at least that sense.  Sure, there are degrees of 
sensitivity, but many websites are key to a business *AND* are primarily developed with scripting languages.  Saying 
"don't use scripting languages" won't make this go away, so let's figure out how to get them secure.

If the alternative is "use C for everything", I shudder.  The people who have trouble with scripting languages will 
*not* do better with C :-).

I think part of the solution is devise languages and libraries which are not only easy to use, but in which the *easy* 
way to do things is also the *secure* way.  That's easier said than done, but when you have non-genius developers, it's 
a start.


--- David A. Wheeler