Secure Coding mailing list archives
What's the next tech problem to be solved in software
From: Jason.Bennett at thales-esecurity.com (Bennett, Jason)
Date: Mon, 11 Jun 2007 12:27:24 +0100
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 2NX. 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 postmaster at thales-esecurity.com. 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".
Current thread:
- What's the next tech problem to be solved in software Bennett, Jason (Jun 11)