FW: What's the next tech problem to be solvedin softwaresecurity?

[dcrocker at eschertech.com (David Crocker)]

IMO the real problem is that software developers are still focussed on
programming, not on specification. We should leave programming to computers,
instead of wasting money paying people to do it and hoping that the resulting
system meets user requirements, including some semblance of security.

If instead we pay people to perform the more skilled tasks of establishing
requirements and specifying the systems to meet them, and use computers to
generate programs that meet the specifications, then such things as freedom from
buffer overflow come free of charge. By "freedom" here, I don't mean the sort of
freedom that comes in "safe" languages such as Ada and Java - in which the
buffer overflow raises an exception, probably requiring a restart of the
subsystem - but rather, genuine immunity.

Other security issues (like freedom from SQL injection and cross-site scripting
attacks) may not always come free but are relatively easy to add to the
specification, as long as people are aware of the need to do so.

It amazes me that software development techniques have progressed so little in
the last 50 years. In the 1950s we had assembler. This was followed in the 1960s
by "high level programming languages". Nearly 50 years later we have... slightly
better "high level programming languages". For example, one of the major
languages in use today is C, which is more than 30 years old. The only
significant advance since the invention of C (and Algol before it) is
object-oriented programming - a welcome improvement, but far short of the
paradigm shift that is desperately needed.

Let's stop focussing on the minute detail of the steps that a computer needs to
execute in order to solve a software problem, and turn our attention instead to
describing what the program is supposed to achieve - including its resistance to
hostile input. Until we do so, we will be doing little more than patching up
outdated technology.

David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com




-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On
Behalf Of SC-L Subscriber Dave Aronson
Sent: 07 June 2007 13:53
To: SC-L at securecoding.org
Subject: Re: [SC-L] FW: What's the next tech problem to be solvedin
softwaresecurity?


Michael S Hines [mailto:mshines at purdue.edu] writes:

> Product integration - why have an editor, separate source code analizer,  >
separate 'lint' product, compiler, linker, object code analyzer, Fuzz
> testing tools, etc...    apart from marketing and revenue stream - it
> doesn't help the developer any.

It may.  IME, "all-in-one" products usually integrate the pieces well.  On the
other claw, they don't tend to do most, if any, of the pieces well.  On the
third hand, "integration" doesn't have to mean they're no longer "separate".
They can "play nicely together" if they adhere to relevant standards for
interoperability.  Witness how you can develop a lot of software without leaving
Emacs, or Eclipse.

However, I don't think that's all that relevant to software security in
particular, as opposed to software development in general.

-Dave

-- 
Dave Aronson
"Specialization is for insects."  -Heinlein
Work: http://www.davearonson.com/
Play: http://www.davearonson.net/



_______________________________________________
Secure Coding mailing list (SC-L) SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a
free, non-commercial service to the software security community.
_______________________________________________