The Artima Developer Community
Sponsored Link

Weblogs Forum
Security and Agility: Never the Twain Shall Meet?

35 replies on 3 pages. Most recent reply: May 21, 2006 11:34 PM by Chris Hart

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 35 replies on 3 pages [ « | 1 2 3 ]
John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Acceptance vs. Business tests Posted: May 20, 2006 8:32 PM
Reply to this message Reply
> Unless I'm missing something (I just flipped through the
> FitNesse website, so it's entirely possible), FitNesse
> seems like a watered-down version of good automated
> testing practices, with the twist that the customer is
> supposed to be involved. I think this type of testing is
> critical to building any non-trivial system, and have used
> it on many project w/o the help of a framework.
> But it's still neither "requirements" nor "acceptance
> tests."
> Why?
> It's too low level. It tests whether the system behaves
> as specified (very important!), not that the specified
> behavior supports/achieves the objectives associated with
> building the system.
> IMHO, the purpose of acceptance tests is more to validate
> the requirements (against objectives) than to validate
> that the system meets the requirements.
> As for the tests being requirements, I think they are
> again too low level to be sufficient. They specify the
> "what" so precisely that the "how" becomes implicit in
> their definition.

Yes, those are working at very different levels.

There's a difference between an acceptance test and a business test. A business test is something that's measurable by the business to validate the outcome of the use of the system. E.g., "revenue increases 20% year over year". That's very different from an acceptance test for the functionality of the system.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Security and Agility: Never the Twain Shall Meet? Posted: May 20, 2006 8:47 PM
Reply to this message Reply
One of the problems discussing something like ASD is that there isn't a single authoritative definition of it.

Having said that, I do think that in some cases ASD has been sold to developers (at least implicty) as a methodology that requires less formal documentation. This is an important selling point because it's developers that most dislike creating documentation.

Since there is no way to know in general whether organizations using pre-ASD methods are producing more documentation than they really need, then you can't claim that ASD will save time or money on documentation. Yet ASD is often pitched as if it will.

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: Lakoff's Political Analysis Applies Posted: May 21, 2006 1:18 AM
Reply to this message Reply
> I need to sit down and write this up at some point, but
> the idea has been rattling around my head for a while.
> George Lakoff explains the divide between liberals and
> d conservatives through the family model frame: liberals
> correspond to a nurturant parent model and conservatives
> to a strict father model. I believe the same metaphor can
> do a lot to explain the split between agilistas and
> CMM'ers. And I think the fact that I haven't said who is
> which, but you know it anyway, suggest that it's a very
> effective metaphor.

Or CMM is leftist, authoritarian like Stalin, Castro, Kim Jung Il, Hitler, Mugabe....

Sebastian Kübeck

Posts: 44
Nickname: sebastiank
Registered: Sep, 2005

Re: Security and Agility: Never the Twain Shall Meet? Posted: May 21, 2006 6:34 AM
Reply to this message Reply
I think the discussion here lost track a bit.
The question is if it's possible to ensure security
in an agile process.

The answer for me is: Sure!
When you have a look at the OWASP top 10 or the
whole guide, you see that it's just a set
of requirements and best practices.
Why not model those as tests?
It's way easier that way since
you can be sure that the requirements
are met even if the software changes.

With some design documents you can never
be sure what the people really did during development.
I don't know any other process that requires that much

I think the problem is that security experts usually
don't know much about agile software development.
As lot's of software developers and managers do.
Most of them think that it means
"do what ever you feel like" and "chaos is OK!"
where in reality, the opposit is the case.

Erlend Oftedal

Posts: 1
Nickname: eoftedal
Registered: May, 2006

Re: Security and Agility: Never the Twain Shall Meet? Posted: May 21, 2006 11:09 PM
Reply to this message Reply
I think we can turn the question around and ask "How does agile development improve security?".

TDD helps making sure that your classes/method act the way you expect them to. This can help in reducing the number of bugs in your software, which in turn improves security. Of course TDD does not necesserily remove design flaws (no silver bullett).

Automatic regression testing helps make sure that the classes continue to act the way that was originally specified. If a test fails, you know that either a requirements of the class/method has changed or some of the altered code is erronous.

If you want TDD to help improve security, you need to put security into your tests. This means writing tests specifying the behaviour of a class/method in case of extreme parameter values.

As Mr. Kübeck suggested, I think using the OWASP top 10 as a set of requirements/tests is a good idea. Input validation is easy to write as tests for your business objects. And I also think web testing tools like fitnesse can be used to test for XSS faults. The character set that causes XSS is fairly small, and writing tests that inject these characters into the different parameters of a web page and checks if the result is escaped, should be fairly easy.

Chris Hart

Posts: 4
Nickname: chart
Registered: Mar, 2006

Re: Security and Agility: Never the Twain Shall Meet? Posted: May 21, 2006 11:34 PM
Reply to this message Reply
What do Security and Agile have to do with one another? Nothing. When security capabilities are important deliverables in an eXtreme Programming project the security specs get added in as user stories and acceptance tests. Same goes for formal documentation. It's just another story that takes time and resources to create.

And what does security have to do with formal documentation anyway? Again nothing. How specifically would formal documentation verify that the developers are producing secure software? It can't. The only way to validate the software is secure is to put the software through comprehensive penetration testing. With a complete suite of automated penetration tests (aka security acceptance tests that the security team is responsible for writing) you could determine how secure the software is compared against the organizations' security specifications. It's important that the penetration testing is automated in order to make sure the tests are repeatable and to disclose the full extent of what was tested. All too often I have seen audit-passable, formal security documentation, that was neither verifiable nor repeatable.

Flat View: This topic has 35 replies on 3 pages [ « | 1  2  3 ]
Topic: Security and Agility: Never the Twain Shall Meet? Previous Topic   Next Topic Topic:

Sponsored Links


Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use