RE: Another opinion on using extreme programming for security

> [Security] should not be expected as a freebie, no matter what the development
> methodology.

I disagree with that to a certain extent.  Security is a subset of reliability, and should be thought of in the same way.  Just as a customer by default expects reliable software, customers should be able to expect reasonably secure software, for a certain narrow definition of secure.

In neither case is that an absolute, of course.  Special security requirements, such as encryption and strong authentication, would be spelled out in requirements.  Similarly, special reliability requirements, such as high availability and redundancy, have to be specified explicitly.

Of course, customers cannot expect software to be 100% secure any more than they can expect it to be 100% reliable, but in both cases it is the developer's job to do his due diligence in doing a good a job as possible given a budget and timeframe.

Now coming back to the original question of XP security, I read it a little differently.  It seems to me the argument is that XP consists of frequently extending software, so you increase the security risks associated with extensible software.  But the original quotation seemed to address this adequately: if you know the risks beforehand, and are aware of them as you proceed throughout the project, it is possible to mitigate any risk associated with the methodology.

In some cases it may make sense to design a security model into the software initially, and extend that model as you extend the functionality.  This may or may not introduce extra restraints, which is a question that probably could be looked at a lot more deeply.

I agree that this doesn't seem any worse than traditional programming methods.

Cheers,
Ken


-----Original Message-----
From: George Dinwiddie [mailto:[email protected]]
Sent: Wednesday, April 14, 2004 1:50 PM
To: Mads Rasmussen
Cc: [email protected]
Subject: 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