Lots of interesting points been raised in thread so here a few points I've
picked out:

- It's the developer's fault: A few comments were made that the lack of
security lies at the door of the developers because they implement insecure
code. True to an extent but I don't think you can blame developers unless
they been educated in the first place. The situation here seems to be slowly
improving but is far from ideal. What I would like to see is more general
education and also more integration of technologies into the standard
low-level development environment that helps educate a developer into what
they are doing wrong. So explaining why it's wrong and secondly automating
the stopping of them doing it wrong. 
- The low-level problems have already been solved: I always find this
difficult as has been rightly pointed out the problem has been solved from a
technical point of view for some time now. Putting a 'finger in the air' you
might suppose that 95% of low-level problems (i.e. not inherent in the
design) would just disappear. Why doesn't this happen - difficult answer but
the inertia built up by certain languages and the developers is not
something that is going to change over night and vendors are going to start
producing the right 'tools' unless there is a demand for them from
developers. To borrow a phrase from someone else you don't get fired for
choosing C/C++ as your implementation language.   

- How to specify security: This I think is the biggest challenge facing
security at present. As has already been stated the low-level problems have
been solved but at the higher levels (requirements, design etc.) the
security arena makes the software development arena look advanced. We hardly
have the techniques of defining the security policy of a system and just as
importantly how are these integrated into the software development
life-cycle as part of it and not considered just an add on?

I don't have the answer to what the challenge is let alone how you achieve
it but how you express 'security' within a software design and how you make
this and integral part of the software design and implementation seem
fundamental in the stages to make software 'secure'. Some of the attempts I
have seen although interesting always seem to have the flaw in that they are
viewed as almost a separate process to the software development. There are
many technologies that a software developer takes as second nature as part
of their toolbox but security doesn't seem to be one that features highly.

Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email [EMAIL PROTECTED]
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited". 
Secure Coding mailing list (SC-L) SC-L@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.

Reply via email to