Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

2009-08-26 Thread Bennett, Jason
 
 
So many mistakes have been made in
generations before mine that we are now trapped in a box of our own
making that has us squabbling over academic minutiae like how to teach
secure coding when we should not have to consider this topic at all -
the code itself should be inherently secure.
 
This is the comment that agrees with my own belief. When teaching how to
program secure coding should be seen as inherent in this and not as some
sort of optional add that is only required if the code is supposed to
secure. Many of the techniques are just making the code more robust and
this covers a considerable amount of the problems with code today. I see no
reason that this shouldn't be taught as part of any programming course. Does
this cover all secure coding, no of course not, but unless the foundations
of secure implementation is inherent then more advance issues ar the least
of the communities worries.
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 postmas...@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. 
___
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.
___


Re: [SC-L] Conditional Compile statements-- coding standards, and code review

2009-02-16 Thread Bennett, Jason
Robert/Sean,

It's a good question and one that I've never seen a really good answer to!
Robert your option certain works but I feel that it somewhat prone to error
if deployed on a large source base. So for example if a developer actually
uses:

#ifdef FRED
#  define MACRO(x) (x + 5)
#endif

... then it's quite possible that this is missed by the review team and
there is of course no guarantee that all code is reviewed manual. There is
also the problem that there may be more than a single target release build
for different variants i.e. it's not just a binary choice of release or
debug versions.

To make a more 'fool proof' mechanism I believe that it's better to have a
more controlled use of which pre-processor directives are allowed for
conditional compilation and ensure their use is consistent -- this is
particular true of debug information which I believe causes the most
problems. Following this approach would allow you to perform automatic
searches for directives that are not on a defined white list. A word of
warning this isn't as easy as it seems once you start getting statements of
the following type -- this just re-enforces the problem of conditional
compilation:

#if defined c1  !(defined c2 || defined c3)
 ...
#elif defined C4
 ...
#endif

What would be really nice is to have an automatic tool that can check that
for say build target A you can only have I, J and K defined but for not L
and M -- using 3rd party code which is often designed to be ported to
multiple targets sorting out what is actually used is not easy at all!

Use should also looked at carefully to ensure that conditional compilation
is only used where 'required'. So as an example do you really want all those
call traces and information output used during development left in the code?

In conclusion I believe that you should aim for as much automation as
possible and also taking the problem out of the developer's hands. It's much
easier to ensure that you've done something right once in your build system
than expect every developer to do it right every time -- in my experience
developers are happy to change what is in their 'local domain' but think
about things a bit more carefully if they are making a change the can affect
the entire development.

Obviously these are just some ideas and I'm sure that there or other equally
good solutions and as with all these things it does depend on what level of
assurance you want otherwise you get the answer of don't allow conditional
compilation! 
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 postmas...@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. 
___
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.
___


Re: [SC-L] Secure Coding Books

2008-03-12 Thread Bennett, Jason
Hi All,

With all the questions about what are good books are there any views on
actually implementing the principles i.e. using them on real programmes to
drive security improvement. In particular the contrast between exisitng
programmes and new programmes?

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 [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.
___


Re: [SC-L] What's the next tech problem to be solved in software

2007-06-11 Thread Bennett, Jason


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 [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.
___