Re: Another opinion on using extreme programming for security

From: Jeff Williams (
Date: 04/15/04

  • Next message: ken kousky: "RE: Code Assessment"
    To: "George Dinwiddie" <>, "Mads Rasmussen" <>
    Date: Thu, 15 Apr 2004 00:03:44 -0400

    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 I find
    it difficult to argue with any of these practices from a security

    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 Williams
    Aspect Security, Inc.

    ----- Original Message -----
    From: "George Dinwiddie" <>
    To: "Mads Rasmussen" <>
    Cc: <>
    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;
    > So many I loved were not yet dead,
    > So many I love were not yet born.
    > 'The Middle' by Ogden Nash
    > ----------------------------------------------------------------------

  • Next message: ken kousky: "RE: Code Assessment"