Re: Another opinion on using extreme programming for security
"Jeff Williams" <[email protected]>
| Newsgroups | gmane.comp.security.programming |
|---|---|
| Organization | Aspect Security, Inc. |
| Message-ID | <[email protected]> |
I don't really understand the argument that XP is somehow inconsistent with producing secure systems. I mean, it's not like the traditional way of building software has been doing such a terrific job ;-) I think many of XP's practices are likely to reduce the introduction of vulnerabilities into software -- particularly peer programming, test-first, and simplicity (see http://www.extremeprogramming.org/rules.html). I find it difficult to argue with any of these practices from a security perspective. The argument against XP and security appears to be something like "if you don't design all the security up front, you'll never get it right." But even if you do design it all up front, you'll still run into issues along the way. And you may be better able to deal with those issues if your process is set up to handle them. I'm hoping that people will explore these issues more carefully. I'd love to see a study that focused on vulnerabilities in XP vs. other methodologies. --Jeff Jeff Williams Aspect Security, Inc. http://www.aspectsecurity.com ----- Original Message ----- From: "George Dinwiddie" <[email protected]> To: "Mads Rasmussen" <[email protected]> Cc: <[email protected]> Sent: Wednesday, April 14, 2004 1:49 PM 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 > > > 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 > ----------------------------------------------------------------------