Re: Another opinion on using extreme programming for security

This quote seems to illustrate a common misperception of Extreme
Programming, that it forbids all practices that are not explicitly
mentioned in the Extreme Programming literature.

Software development requirements are always at the whim of the
people paying for the software development.  If they require 
security, then the security requirement should be stated.  It
should not be expected as a freebie, no matter what the development
methodology.

Secure software, as stated, cannot be ensured by testing alone.
I'm not a security expert, but I would want a review of the code
for potential security issues before each public release (but
not necessarily for internal releases).  Perhaps some of that 
review could be automated by tools searching for particular 
shakey practices and therefore made part of the normal build
procedure.  I doubt that would provide sufficient analysis if
the requirement is absolute security.

Extreme Programming is not fundamentally different from other 
methods of developing software; it mere tries to eliminated
wasted effort.  You still have to think about what you're doing.
You still do design; you just continue to refine the design 
throughout the project.

 - George

> Mads Rasmussen said:
> 
> 
> I found this excerpt from Matt Bishop's book, "Computer Security, Art & 
> Science" very nice and wanted to share it.....
> 
> "Extreme programming is a development methodology based on rapid 
> prototyping and best practices such as separate testing components, 
> frequent reviewing, frequent integration of components, and simple 
> design. A project is driven by business decisions, not by project 
> stakeholders, and requirements are open until the project is complete. 
> The design evolves as needed to remove complexity and add flexibility. 
> Programmers work in teams or pairs. Component testing procedures and 
> mechanisms are developed before the components are developed. The 
> components are integrated and tested several times a day. One objective 
> of this model is to put a minimal system into production as quickly as 
> possible and then enhance it as appropriate.
> Use of this technique for security has several benefits and several 
> drawbacks. The nature of an evolving design leaves the product 
> vulnerable to the problems of an add-on product. Leaving requirements 
> open does not ensure that security requierements will be properly 
> implemented into the system. However, if threats were analyzesd and 
> appropriate security requirements developed before the system was 
> designed, a secure or thrusted system could result. However, evidence of 
> trustworthiness would need to be adduced _after_ the system was 
> developed and implemented."
> 
> --
> Mads
> 


-- 
 ----------------------------------------------------------------------
  When I remember bygone days                         George Dinwiddie
  I think how evening follows morn;            [email protected]
  So many I loved were not yet dead,           http://www.Alberg30.org
  So many I love were not yet born.
                                            'The Middle' by Ogden Nash
 ----------------------------------------------------------------------