|
Secure Programming
Writing Secure code Dec 27 2002 12:46PM Rahul Chander Kashyap (rahul nsecure net) (6 replies) Re: Writing Secure code Dec 27 2002 06:03PM Valdis Kletnieks vt edu (2 replies) RE: Writing Secure code Dec 27 2002 08:51PM Roger Alexander (rta cs colostate edu) (1 replies) RE: Writing Secure code Dec 30 2002 12:41PM Matt McClellan (mmcclellan nfr com) (2 replies) Re: Writing Secure code[update] Dec 31 2002 10:20AM Rahul Chander Kashyap (rahul nsecure net) (2 replies) Re: Writing Secure code Dec 27 2002 05:43PM John Viega (viega list org) (2 replies) |
|
|
Privacy Statement |
>First of all i'm thankful to all for responding to my query. Well this shows
>one thing for sure..we share similar concerns :-)
>Actually i'm quite surprised that no one as yet has said that yes! we follow
>some standards to <or rather attempt to>make our coding more secure.
>
Safety standards. They sound great: specify a standard, have everyone
follow it, and we'll have far fewer problems.
The problem is that the standard must be *effective*. Safety standards
in other engineering disciplines are only implemented after it is *very*
well understood what cookbook recipe a competent engineer should follow
when designing a steam boiler, bridge, skyscraper, etc. such that it
will not fall down.
We cannot specify a cook book for programmers to follow to write secure
code, because we do not know what such a cook book should say.
Prematurely specifying a security programming standard would be
disasterous, for several reasons:
* Unrealistic expectations: lay people will believe the hype, and
expect standard-following code to be secure, and then regret it
when they get hacked anyway.
* Poor uptate: users starting to notice that the standard doesn't
work will fail to pay the price premium for standard-following
products.
* Contempt: developers who know that the standard doesn't work will
be contemptuous of it, and refuse to follow it.
With nearly everyone having such a negative view of the standard, it
will substantially delay the adoption of standards that are actually
effective when they eventually come along.
Oh wait! This has already happened: Orange Book, Common Criteria, and
ISO 9000 are all standards that seek to do what you propose, they are
all hugely expensive to propose, and none of them work. They have not
been widely adopted, and one or two of us are a tad contemptuous of them :)
So long as "writing secure code" is still a research problem, it should
not be standardized.
So what can be done? We *do* have a bunch of good practice knowledge
(the Saltzer and Schroeder paper
<http://web.mit.edu/Saltzer/www/publications/protection/index.html>,
books <http://buildingsecuresoftware.com/>, and on-line resources
<https://sardonix.org/Auditing_Resources.html>) and that knowledge is
very poorly diffused into the general programmer population. *Education*
is the key here: share these best practices with every programmer you
can. If you are software educator, make sure your students are made
aware of these issues.
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX http://wirex.com/~crispin/
Security Hardened Linux Distribution: http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
Just say ".Nyet"
[ reply ]